We had already some discussion in the bugtracker (bug #381) about this issue, but I want to give it a wider audience. To give you a short overview about the discussion, here the it is in a nutshell. It started with the question, if the checkbutton needs to be be split into several widget (as it is now: a container that holds the checkbox and the label) or if it wouldn't be better to have it in a single widget. The main reason for this question is/was that if the state of the parent container (the checkbutton) will change, for example a "mouse,in" event or a "focus,in", there is no way to change the label or the checkbox. Although putting it in a single widget would solve this, and we might/will go that way, it showed a more basically problem, that needs another - more general - solution.
To describe the problem more general, if the parent or grandfather or even higher ancestor will change it look it might to want that some offsprings will look different, too. For example this is solved in e menu that the label get a signal "e,state,selected" when the parent is selected. Although this solution works fine for this case, imagine a tree where a row is selected (or highlight, why ever) and any label that has this widget as parent needs to adjust it fg color to be readable, no matter how many ancestors are between it and the row itself, makes it much more complicated. And when you concern that any theme action might do that, like "mouse,in/out", "focus,in/out", "disable/enable" or even random changes or parent related signals like to have a lighter or no background, it becomes a very difficult job. So here comes my idea, how this could be solved. Any theme part (actually any edje group) can send a signal to its children. Maybe with the source set to "this", or some general string. And ewl will pipe them into the offspring widget theme objects. To reduce some of the upcoming noise, the theme groups could define if they want to receive/emit signals, if they want to pipe them directly to their children or if they want to stop those signals because they have solid bg, so they aren't affected to those changes. Pros: - theme groups can control the look of the offspring widget - it is very general solution because the theme isn't constricted to the signal the library (here ewl) is aware of Cons: - we need to have a way to distinguish between transient signals and states, because a new created or a revealed widget child needs to know of the state too, but don't need to know about the whole event history Any suggestions are welcome! Peter ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
