Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 19 12:51
    BigRoy commented #343
  • Sep 19 11:29

    davidlatwe on 1.10.2

    (compare)

  • Sep 19 11:22

    davidlatwe on master

    Bump version (compare)

  • Sep 19 11:19

    davidlatwe on master

    Prompt failed message if any er… Add an internal flag `onPublish… Refactor `onPublished` into `te… and 3 more (compare)

  • Sep 19 11:19
    davidlatwe closed #344
  • Sep 19 11:19
    davidlatwe closed #343
  • Sep 19 11:17
    davidlatwe closed #341
  • Sep 19 11:17

    davidlatwe on master

    Fix #341: Ignore Categories whe… Merge pull request #342 from Bi… (compare)

  • Sep 19 11:17
    davidlatwe closed #342
  • Sep 19 11:07
    mottosso commented #342
  • Sep 19 11:02
    BigRoy commented #342
  • Sep 19 10:15
    davidlatwe synchronize #344
  • Sep 19 10:05
    davidlatwe commented #342
  • Sep 19 09:57
    mottosso commented #344
  • Sep 19 09:56
    mottosso commented #352
  • Sep 19 09:40
    davidlatwe commented #344
  • Sep 19 09:13
    tokejepsen commented #352
  • Sep 19 08:27
    mottosso labeled #352
  • Sep 19 08:27
    mottosso labeled #352
  • Sep 19 08:27
    mottosso opened #352
Roy Nieterau
@BigRoy

Oof. It doesn't sound like a use case I know of. Usually the Collecting part actually collects the states, including any confirmations, based on scene data.

Could you describe what kind of "confirmation" you're trying to pass to the user and why you are letting them confirm it during validation?

Basically any user options/choices/settings are set before validation. For example on a node in your work file that holds information like the start/end frame, whether to enable/disable a specific setting, etc.
Tweekazoid
@Tweekazoid
you need to edit function in . > control.Controller.reset before assigning new value to self.context,
Andre Anjos
@andre.anjos_gitlab
Hi @BigRoy, as an example we have different projects that can have different fps. Is something that sometimes people forget to setup properly before sending it to render (It's crazy, I know). Unfortunately I can't raise an exception/error, because I will not know that specific project fps. So had the "idea" of raising a warning to the user in validation and give them the possibility to change the fps or if initially correct confirm it, for logging.
Tweekazoid
@Tweekazoid
you can check if it is pyblish.api.context class. And if so store values to some variable and after assigning new self.context value just restore from different variable. But this is short sighted, I would recommend adding update function to completely bypass reset if needed
Andre Anjos
@andre.anjos_gitlab
Hi @Tweekazoid, Cheers for that!
hmmm... Right! I need to digest what you explained and have a go :)
Roy Nieterau
@BigRoy

Hi @BigRoy, as an example we have different projects that can have different fps. Is something that sometimes people forget to setup properly before sending it to render (It's crazy, I know). Unfortunately I can't raise an exception/error, because I will not know that specific project fps. So had the "idea" of raising a warning to the user in validation and give them the possibility to change the fps or if initially correct confirm it, for logging.

The tricky thing with warnings is that if they are always presented at some point people will start ignoring the warnings as they just recognize it as the way it should be.

How about storing inside your scene the data for the current FPS and set it to 0 by default, e.g. on whatever you collect the default value is zero. Then the artist can set it correctly to e.g. 25 FPS until it can be automated by collecting that information at the project.

As such:

  • The artist will apply it only once, from that moment on you can accurately keep checking whether the scene matches the required setting.
  • If the value is zero or not stored somewhere, then you know the artist must still confirm what the FPS should be for the check.
It's still prone to human error, but I believe it might be less prone to error than relying on a warning that'll always pop up.
Just a quick idea of course. I'm not entirely sure how you're managing things of course, so this could just as well be very odd in your workflow.
Andre Anjos
@andre.anjos_gitlab

@BigRoy I agree with your user experience explanation. Definitely would prefer to keep warnings out in validation for this case.

How about storing inside your scene the data for the current FPS and set it to 0 by default, e.g. on whatever you collect the default value is zero. Then the artist can set it correctly to e.g. 25 FPS until it can be automated by collecting that information at the project.
As such:
The artist will apply it only once, from that moment on you can accurately keep checking whether the scene matches the required setting.
If the value is zero or not stored somewhere, then you know the artist must still confirm what the FPS should be for the check.

This is an excellent idea and I can see it working :)
Thank you both very much for your help! very useful
Marcus Ottosson
@mottosso

Hi @andre.anjos_gitlab just saw this.

Generally, you would store and edit user data outside of Pyblish. For example, you could have a Python module that you set values on; that module, once imported anywhere else, would remain persistent.

Then it's a matter of how persistent you need the data to be; for example, it's quite common to store (and edit) data on something in a scene, as for example attributes. The action could then edit this attribute, which persists until the next time you collect. That would also enable you to design and edit that data outside of Pyblish, which is where data authoring and editing should probably happen anyway. For ultimate persistence, you could of course also store data in a file, and use your action to edit said file.

Pretty much what Roy said, now that I read it again
Pyblish is generally a data collection and output mechanism; it isn't well suited for actually authoring or editing data
Andre Anjos
@andre.anjos_gitlab
Hi @mottosso, Apologies for the slow reply!
Thank you very much for your solution and explanation. It makes sense to have the two separate. :)
Marcus Ottosson
@mottosso
No, haven't seen that; does it include Pyblish? :)
Andre Anjos
@andre.anjos_gitlab
I haven't heard all of it yet, but I'm expecting a mention ;)
Andre Anjos
@andre.anjos_gitlab
image.png
Hi guys, is it normal when you have multiple actions attached to a validation plugin to indicate that it contains actions before being processed. I.e. I want the action icon to appear on failed only.
Thank you! :)
P.S. i definitely have the actions with on = "failed"
Marcus Ottosson
@mottosso
@andre.anjos_gitlab I'm unsure, it sounds like you've got it right; do have a look at the source, to see whether there has been some regression lately as to how that attribute is interpreted
Roy Nieterau
@BigRoy
The A icon should only start to show whenever it actually has actions to show on right click. Does anything show on right-click? :) Are they both set to show on "failed"?
Andre Anjos
@andre.anjos_gitlab
Hi guys! Thank you for your help! Here's a gif with its behaviour.
https://imgur.com/a/8WpxgCJ
@mottosso Hi will have a look at the source! :)
@BigRoy As per the demo, the right-click menu does not show until you validate the plugins. They are both set to failed.
Roy Nieterau
@BigRoy

As per the demo, the right-click menu does not show until you validate the plugins.

Perfect, then at least that's consistent and as it should be. It's only the icon that is off. The A icon should only be visible whenever right-click would show a menu.

Would you happen to have "Separators" in the list?
Andre Anjos
@andre.anjos_gitlab
Hi Roy, No I haven't included a separator originally, but now when adding one I can't see any changes as well.
Andre Anjos
@andre.anjos_gitlab
I can also add that it only happens when you add a category. If I remove both it will be correct.
Let me know if you want to add this as an issue in GitHub
Roy Nieterau
@BigRoy
If you have a simple reproducable case then it's definitely worth a Github issue. :)
Andre Anjos
@andre.anjos_gitlab
yeah, I'm testing with different plugins and does the same to all, irrelevant of number of categories. Looking at the source it does not look like something was updated recently regarding changes to categories, but it may also be something that is beyond my knowledge :) ( @mottosso)
I will open an issue just in case
Thanks @BigRoy
Roy Nieterau
@BigRoy
I've set up a PR @andre.anjos_gitlab that should be able to solve it. :+1: Feel free to test it out: pyblish/pyblish-qml#342
Andre Anjos
@andre.anjos_gitlab
@BigRoy Thank you very much! that's some quick fixing. Will have a look now :smiley:
Andre Anjos
@andre.anjos_gitlab
@BigRoy Can confirm it is definitely working on my end with python 2.7 now :) Thank you very much! :+1:
Roy Nieterau
@BigRoy
Thanks for checking and confirming.
David Lai
@davidlatwe
I just found out that using the pyblish.api.register_test to register custom test function will not work with pyblish_qml. Since the main iterator used by QML was running in subprocess, and the custom test function was no way to pass into there. :construction:
Has this been mentioned before ? Could not find any issue related to this.
Roy Nieterau
@BigRoy
Haven't used a custom test so wouldn't know. But this looks like something that's a bug if it doesn't work.
Marcus Ottosson
@mottosso
Hm, that is odd, but I think you're right. The test is exposed to the remote QML here, but isn't being used (see here). I think it should be a matter of swapping that call for one that calls on the service. But do confirm that it doesn't work first.
Roy Nieterau
@BigRoy
It's being used here right? :) So I guess it should work.
Marcus Ottosson
@mottosso
Yes
Roy Nieterau
@BigRoy
Or wait, should that actually be calling the one from the Service instead?
David Lai
@davidlatwe
Not unless the pyblish inside the subprocess know's the custom test it's registered. Since that main iterator is inside the subprocess and usually the custom test was registered in host.
Roy Nieterau
@BigRoy
^ Ah, that makes sense yes. So it should somehow be retrieving the registered test from the host.
David Lai
@davidlatwe
Yeah