Should GadgetHidden() be recursive?
BlitzMax Forums/MaxGUI Module/Should GadgetHidden() be recursive?
| ||
| Time for another vote... Should GadgetHidden() return True if its parent is marked as hidden but the gadget itself isn't? I'm tempted to say that it should return False, and that a new separate command (perhaps GadgetVisible() maybe?) should be used to find out if a gadget and all of its parents are visible. A similar question but for GadgetEnabled() is probably also applicable... What do people think? |
| ||
| Should GadgetHidden() return True if its parent is marked as hidden but the gadget itself isn't? I vote that it should because if the parent is hidden, then so is the child gadget, and if the child gadget says it's not hidden when it is, then that would be incorrect. Well, that's my opinion on the matter. :) EDIT: Also, I have a request about DisableGadget(): Would it be possible that when you call DisableGadget on a window or panel or something "parent-like" could it also disable all of the child gadgets? The Win32 RequestFile function does this, and I like it a lot. |
| ||
| I believe that it should be recursive. I'm tempted to say that it should return False, and that a new separate command (perhaps GadgetVisible() maybe?) No ambiguity please (not that I really use MaxGUI.. but still). |
| ||
| I don't think it should be recursive in any manner. If the gadget is hidden only because of a parent and you unhide it, it's still going to be hidden. As a compromise, you could add an optional recursive argument like "checkParent" to indicate you want a recursive search as well, but that might be more complicated than it needs to be. Such an argument would default to not checking parents, thus making the existing behavior unchanged for code using it now, and allowing one to use the new feature if needed. |
| ||
| Would it be possible that when you call DisableGadget on a window or panel or something "parent-like" could it also disable all of the child gadgets? As long as it doesn't override their individual disabled-ness. i.e. If some where already disabled, when you call EnableGadget on the parent, those should remain disabled. Of course, having to manually manage everything is fun... |
| ||
| As a compromise, you could add an optional recursive argument like "checkParent" to indicate you want a recursive search as well, but that might be more complicated than it needs to be. Such an argument would default to not checking parents, thus making the existing behavior unchanged for code using it now, and allowing one to use the new feature if needed. I like Nilium's suggestion. Would people be happy with this? |
| ||
| I would like to call DisableGadget() on a window with child gadgets that may or may not be enabled. I would like to call EnableGadget() on the window again and have the child gadgets be disabled or enabled according to their own states, so they appear as they were before disabling the window. GadgetEnabled() and enabled behavior should be recursive. Enable/DisableGadget() should not. GadgetHidden() should be recursive. Hide/ShowGadget() should not. |
| ||
| I like Nilium's suggestion. Would people be happy with this? Yes Also, I have a request about DisableGadget(): Would it be possible that when you call DisableGadget on a window or panel or something "parent-like" could it also disable all of the child gadgets? One more vote for this and iirc the old MaxGui did it that way. And yes, the old/own state should be kept. |
| ||
| Would it be possible that when you call DisableGadget on a window or panel or something "parent-like" could it also disable all of the child gadgets? This should currently behave like Brucey and Leadwerks describe, i.e. disabling a window/group stops any of its children from receiving mouse/keyboard input, but re-enabling restores each gadgets 'enabled' state to its individual property. If you notice this not to be the case, please post a bug report for me. |
| ||
| Well, yes but the gadgets still appear enabled. They just don't respond to input. I'd like it if they all looked disabled so I could just disable an entire panel at once, and have it be visually obvious it won't work. |
| ||
| Well, yes but the gadgets still appear enabled. Right! And sometimes it is hard to see that the parent panel is disabled, which confuses the user. |
| ||
| The enabled check should be recursive.. ie, if a gadget is enabled but its parent is disabled it should appear disabled... the enabled state of the gadgets should be preserved for when enablegadget is called. IMHO |
| ||
| Well, that is the *behaviour* atm, but as Leadwerks correctly pointed out, the child gadgets don't appear greyed out, even though they are effectively disabled. OK, I've spent an hour scratching my head, and have got something working... I assume this what you guys mean?  The IDE Options window is modal - i.e. when shown, the parent window is disabled but as you can see this behaviour makes the gadgets underneath look yucky. I don't like this look when disabling an *entire* window. How about if I fix it so that if you disable *any other* container gadget (e.g. panels, tabbers) then all of their children will be greyed out? But disabling a window will effectively just make child windows modal just like it always has been. Everyone's happy... :-) (I hope...) |
| ||
| What about the window menu? Shouldn't it appear different when disabled? I think how you have it there looks good because it is visually obvious the main window is disabled. |
| ||
| What about the window menu? Shouldn't it appear different when disabled? Yep. The text is grey if you look closely... I think how you have it there looks good because it is visually obvious the main window is disabled. Well, yes and no. It isn't really common convention for a modal window's parent to appear greyed. Take the standard save-as requesters in notepad/paint. The modal nature of the child window is made clear to the user because the front window has focus, and if they try to click to the back window, the system beeps and flashes the front window several times - you can't really get a bigger clue than that that something needs your attention. I guess this is because users don't like seeing all their work 'disabled' at the touch at a button, just because the apps needs their attention for one mo. It might be quite disturbing thinking that you can't save/select/copy any of your source, even if it is for a split second. Meh, I guess it's personal preference. But you guys are right in that it would be nice that if you disable a container gadget, you all nested children should also appear greyed out. So if I implement this for everything but windows, then modal windows appear as they should if you want to follow system convention, otherwise you can parent a client panel to your panel and disable that whenever you disable your window, and you'll get the same effect as above. Sound cool? |
| ||
| That makes sense. |
| ||
| Sounds good to me. :) |
| ||
| Okey-dokey. This has been fixed for all three drivers for the next release. Of course, having to manually manage everything is fun... Brucey - I've managed to find quite a 'neat' way of doing this if you want to implement such behaviour in GTKMaxGUI too... |
   |