Eyeon Talk:Script/Reference/Applications/Fuse/Classes/Input/MultiButtonControl
From VFXPedia
Is there a way to make the buttons fixed in size, ala 3TT's RotOrder buttons? --Chad 11:48, 20 October 2009 (EDT)
- By default they'll size themselves to their text, which is what I think 3TT does. Alternatively you can set the width explicitly, or enable autosizing with MBTNC_StretchToFit. --Daniel
- Ah, it never occurred to me to leave a default size, I've always specified the 0-1 width. So how do we use an icon instead of text? I'd like something more like 3Xf and less like 3TT, if I could. --Chad 10:53, 21 October 2009 (EDT)
Got "Toggle" working (very cool) but can't get "TriState" or "Normal" to do anything. What's the trick? Is it the datatype? --Chad 18:39, 22 November 2011 (EST)
- Tri-state isn't implemented. What would that even look like for a button anyway? Normal acts like a normal button control, ie. NotifyChanged() gets sent a value indicating the button was pressed (the button number in this case), and then again with 0 indicating the release of the button. --Stuart 20:07, 22 November 2011 (EST)
- If it was implemented, I would expect TriState to do the same thing that Checkbox does. Return the negative button number. --Chad 11:47, 28 November 2011 (EST)
- No, it can't work that way for a *multi* button control. It would have to work similar to Toggle, except that it would need 2 bits per button, rather than one. But, like I said, it's not implemented. --Stuart 15:10, 28 November 2011 (EST)
- If it was implemented, I would expect TriState to do the same thing that Checkbox does. Return the negative button number. --Chad 11:47, 28 November 2011 (EST)
Is there a way to have more than one MultiButtonControl on a line, like we can do with Checkbox, Slider, Combo, etc? --Chad 18:39, 22 November 2011 (EST)
- Yes, the same way you would with Checkbox, Slider or Combo, etc. --Stuart 20:07, 22 November 2011 (EST)
- Then I must be doing it wrong. With Checkbox, Slider, Combo, etc., as long as two controls have a total width less than 1, they sit on one line. Such a setup does not work for MultiButtonControl. --Chad 11:47, 28 November 2011 (EST)
How would we go about adding an icon or changing the color of the button/text? --Chad 18:39, 22 November 2011 (EST)
- Fuses can't add an icon. You can't change the colour of the button or text. The button imagery and text colour comes from the skin. --Stuart 20:07, 22 November 2011 (EST)
- But how do we pull it from the skin? Like if I have a color defined in the skin, or have a set of icons in the skin, how does the fuse pull them? --Chad 11:47, 28 November 2011 (EST)
- I said, Fuses can't add an icon. It doesn't matter if the icon is in a skin or not, Fuses can't add an icon. I also said you can't change the colour of the button or text. The colour does come from the skin (from the entry that specifies the text colour for *all* buttons), but you can't choose to have any colour you like for an individual button (whether the actual colour is specified in a skin or not). --Stuart 15:10, 28 November 2011 (EST)
- I see. I was just going by the docs. This section needs some editing. :) --Chad 18:55, 28 November 2011 (EST)
- I don't see anywhere in the Fuse docs that it mentions you'd be able to set/add an icon, or change the colour of the button or its text. The only reference I can see is an option to show an icon or not. It's rather useless, given that you can't set/add an icon, but the documentation is correct. --Stuart 20:02, 28 November 2011 (EST)
- Really? So MBTNC_NoIconScaling, MBTNC_ShowLabel, MBTNC_ShowIcon all do absolutely nothing by design, and that's not mentioned in the docs? MBTNC_Type is missing one variation, yet has another that doesn't work? The description relating to what it returns is only correct for some cases of MBTNC_Type. The link for General Control Attributes is broken. For clarity, MBTNC_StretchToFit should include a note that it only works if you don't set MBTNCD_ButtonWidth. I have no idea how to get the MBTNC_Align to work. The latter two aren't incorrect (unless MBTNC_Align is actually broken by design or accident) but they're just tricky, and we sort of expect documentation to tell us how to use something, including any special dependencies. I'm not picking on MultiButtonControl, either, there's other chunks of the docs that are in worse shape (MultiButtonIDControl is so close to being there, GradientControl is a broken link with no clues, and ImageControl, HistogramControl, SplineControl, etc. are all nowhere to be seen. --Chad 12:03, 29 November 2011 (EST)
- Remember that you're looking at Fuse-ified bits of the C++ API, and the C++ API is an internal API, that we use for everything, that we just happen to publish/provide certain parts of for 3rd party plugin developers. We will define all sorts of things, thinking that we may want it in the future, or it might be a nice feature to have, but that doesn't mean it ever get implemented. We tend to document the things that we expect people to use, and almost never document things we rarely or don't actually use ourselves. You expect documentation to tell you how to use something? I know, how about, if it's not documented, don't use it!? Also, just because the C++ API has certain features and abilities, it doesn't mean that they can or will all be Fuse-ified. MBTNC_NoIconScaling, MBTNC_ShowLabel and MBTNC_ShowIcon all do exactly what they're supposed to do. You just can't see what MBTNC_NoIconScaling and MBTNC_ShowIcon do, because a fuse can't add an icon, but C++ code can. Of course MBTNC_StretchToFit doesn't do anything if you've set MBTNCD_ButtonWidth on all buttons. How could it if you've made the buttons a fixed width? We're not going to spell out every single little nuance. We do expect some common sense.
- But what I'm complaining about is the parts that ARE documented under Fuses and are just wrong or otherwise unusable (or have broken/missing links). The C++ API doesn't have current documentation either, and we're forced to go by the comments alone, or by pestering Eyeon (which is remarkably effective from our end, but probably not so much from yours), so we sort of assume that what's in there is what we should be going with. We DO end up with a lot of guesswork and trial-and-error, but Fuses are still a strong selling point for Fusion (and it could be argued that the C++ plugins are as well). You might "just happen to publish/provide" an API, but you also just happen to use that API in your marketing and sales. I know, no one at Eyeon wants to be making documentation for a living, but I feel justified in complaining about the current state of the docs. Heck, just look at the modified dates of the files in the Help folder of the standard Fusion 6.3 install... The only thing that appears to have changed since 2007 is the helpmap, and even that's not complete (though the missing bits should of course be reported independently). EDIT: I'm liking the shape of the comments with the indentation. I fear the asymptotic reply though.--Chad 16:56, 29 November 2011 (EST)
- Let me put it this way: Our C++ API is not a separate layer specially designed for plugin users. Our C++ API is Fusion, and we just happen to expose that, rather than forcing the use of some other API layer (eg. OpenFX) for 3rd party plugins. We could have produced a separate layer to make sure only the things we deemed necessary were available, but instead we expose everything. That doesn't mean you're meant to be able to use everything you see. If you happen to figure it out, good for you I suppose.
- But what I'm complaining about is the parts that ARE documented under Fuses and are just wrong or otherwise unusable (or have broken/missing links). The C++ API doesn't have current documentation either, and we're forced to go by the comments alone, or by pestering Eyeon (which is remarkably effective from our end, but probably not so much from yours), so we sort of assume that what's in there is what we should be going with. We DO end up with a lot of guesswork and trial-and-error, but Fuses are still a strong selling point for Fusion (and it could be argued that the C++ plugins are as well). You might "just happen to publish/provide" an API, but you also just happen to use that API in your marketing and sales. I know, no one at Eyeon wants to be making documentation for a living, but I feel justified in complaining about the current state of the docs. Heck, just look at the modified dates of the files in the Help folder of the standard Fusion 6.3 install... The only thing that appears to have changed since 2007 is the helpmap, and even that's not complete (though the missing bits should of course be reported independently). EDIT: I'm liking the shape of the comments with the indentation. I fear the asymptotic reply though.--Chad 16:56, 29 November 2011 (EST)
- Remember that you're looking at Fuse-ified bits of the C++ API, and the C++ API is an internal API, that we use for everything, that we just happen to publish/provide certain parts of for 3rd party plugin developers. We will define all sorts of things, thinking that we may want it in the future, or it might be a nice feature to have, but that doesn't mean it ever get implemented. We tend to document the things that we expect people to use, and almost never document things we rarely or don't actually use ourselves. You expect documentation to tell you how to use something? I know, how about, if it's not documented, don't use it!? Also, just because the C++ API has certain features and abilities, it doesn't mean that they can or will all be Fuse-ified. MBTNC_NoIconScaling, MBTNC_ShowLabel and MBTNC_ShowIcon all do exactly what they're supposed to do. You just can't see what MBTNC_NoIconScaling and MBTNC_ShowIcon do, because a fuse can't add an icon, but C++ code can. Of course MBTNC_StretchToFit doesn't do anything if you've set MBTNCD_ButtonWidth on all buttons. How could it if you've made the buttons a fixed width? We're not going to spell out every single little nuance. We do expect some common sense.
- Really? So MBTNC_NoIconScaling, MBTNC_ShowLabel, MBTNC_ShowIcon all do absolutely nothing by design, and that's not mentioned in the docs? MBTNC_Type is missing one variation, yet has another that doesn't work? The description relating to what it returns is only correct for some cases of MBTNC_Type. The link for General Control Attributes is broken. For clarity, MBTNC_StretchToFit should include a note that it only works if you don't set MBTNCD_ButtonWidth. I have no idea how to get the MBTNC_Align to work. The latter two aren't incorrect (unless MBTNC_Align is actually broken by design or accident) but they're just tricky, and we sort of expect documentation to tell us how to use something, including any special dependencies. I'm not picking on MultiButtonControl, either, there's other chunks of the docs that are in worse shape (MultiButtonIDControl is so close to being there, GradientControl is a broken link with no clues, and ImageControl, HistogramControl, SplineControl, etc. are all nowhere to be seen. --Chad 12:03, 29 November 2011 (EST)
- I don't see anywhere in the Fuse docs that it mentions you'd be able to set/add an icon, or change the colour of the button or its text. The only reference I can see is an option to show an icon or not. It's rather useless, given that you can't set/add an icon, but the documentation is correct. --Stuart 20:02, 28 November 2011 (EST)
- I see. I was just going by the docs. This section needs some editing. :) --Chad 18:55, 28 November 2011 (EST)
- I said, Fuses can't add an icon. It doesn't matter if the icon is in a skin or not, Fuses can't add an icon. I also said you can't change the colour of the button or text. The colour does come from the skin (from the entry that specifies the text colour for *all* buttons), but you can't choose to have any colour you like for an individual button (whether the actual colour is specified in a skin or not). --Stuart 15:10, 28 November 2011 (EST)
- But how do we pull it from the skin? Like if I have a color defined in the skin, or have a set of icons in the skin, how does the fuse pull them? --Chad 11:47, 28 November 2011 (EST)
- Fuses are a separate layer, but for consistency, when we expose something, we try to expose everything that's in the C++ API (and in a way that's similar to use as the C++ API), even if it's not intended for general usage. There might be some reason to use it in the future, we don't know. Better to expose all that we can, when we do, rather than later regretting not doing so (eg. exposing all the MultiButtonControl options we can, even though some don't work (like Toggle mode, which also wouldn't work from C++) or some are useless or pointless because of some options that couldn't be translated/exposed). That does mean all these things look like they can/should be used, but that isn't the case. Some things just get exposed simply through the generic nature of some of Fusion's API, but that doesn't mean it can actually be used either. Good examples are the HistogramControl and the SplineControl. Sure, you could specify you want them as your input control (there's no particular way we could stop you, without putting in special cases within the Fuse layer), but since Fuses don't currently have any way to manipulate Histogram parameters, or LookUpTable parameters (though they can at least call Image:ApplyLookUpTable() these days), and can't evaluate LUT splines directly, there's not much point in providing any more documentation for Fuses than might be gleaned from the C++ headers or the Fusion SDK PDF document (which does describe how to use LookUpTable parameters and SplineControl for C++ plugins). For some things, the C++ API is the only way.
- As for user documentation, I think a conscious decision was made to keep online (ie. vfxpedia) documentation (relatively) up-to-date. Various methods of semi-automated extraction of that documentation - even including some of the user tips - to then use as local/offline documentation, have been investigated, but have never quite met our requirements. Until then, the local/offline help will continue to be out-of-date.
- Hmm... I think I've said all I wanted to say, but just to extend the shape of the comments, I should probably think of something else. Err... nope, can't think of anything else. Well, nothing on topic anyway. Oh well. --Stuart 18:04, 29 November 2011 (EST)
- Yeah, the exposure stuff I understand. I don't expect HistogramControl to work, no. But it would be nice if A) things that did work, like ImageControl were documented, and B) thing that don't work, like MBTNC_Type = "TriState", were noted as such, and C) all the links worked. I'm not sure who's tasked with QA for VFXPedia, but it seems weird that we have all these random user tips scattered about because the official (read-only for us) documentation is incomplete/incorrect. --Chad 13:28, 30 November 2011 (EST)
- They wouldn't be random if users were consistent. You think randomly scattered user tips is a problem? We have to deal with users randomly choosing to reports issues, or ask questions in any number of places: apart from bugs@, requests@, tech@, sdk@, a number of other closed mailing lists, and e-mailing some random eyeon person directly, there's also random vfxpedia pages, laffey list, pigsfly, vfxtalk, occasionally the dfsdk yahoo mailing list, and (if we managed to get the time to post to it ever) the eyeondev blog. Which method gets used by even the same user seems to randomly change from moment to moment. --Stuart 17:48, 30 November 2011 (EST)
- Guilty on all but 2 of those counts, but there's a difference between sharing tips like "How to get rid of key spill" or "How to speed up file I/O" and "This is what PreCalcProcess() probably is" or "CT_ParticleTool is currently on holiday". --Chad 11:16, 2 December 2011 (EST)
- I think the user tips pages are great and visible, but especially for Fuses, these sections are not available in some places. There should be one for Eyeon:Script/Reference/Applications/Fuse/Fuse Reference Manual to mention the additional events that are now on the discussion page. And some stuff I had to add to the 3rd party Fuses since Eyeon:Script/Reference/Applications/Fuse isn't editable. --Tilt 02:05, 3 December 2011 (EST)
- They wouldn't be random if users were consistent. You think randomly scattered user tips is a problem? We have to deal with users randomly choosing to reports issues, or ask questions in any number of places: apart from bugs@, requests@, tech@, sdk@, a number of other closed mailing lists, and e-mailing some random eyeon person directly, there's also random vfxpedia pages, laffey list, pigsfly, vfxtalk, occasionally the dfsdk yahoo mailing list, and (if we managed to get the time to post to it ever) the eyeondev blog. Which method gets used by even the same user seems to randomly change from moment to moment. --Stuart 17:48, 30 November 2011 (EST)
- Yeah, the exposure stuff I understand. I don't expect HistogramControl to work, no. But it would be nice if A) things that did work, like ImageControl were documented, and B) thing that don't work, like MBTNC_Type = "TriState", were noted as such, and C) all the links worked. I'm not sure who's tasked with QA for VFXPedia, but it seems weird that we have all these random user tips scattered about because the official (read-only for us) documentation is incomplete/incorrect. --Chad 13:28, 30 November 2011 (EST)
