On 1 Apr, Peter Wehrfritz wrote: > 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 >
Just adding a "+1" to this. I have had similar difficulties theming Gtk+ in the past. I admire the old Athena (Xaw) and Motif widget sets because they grant the 'themer' the ability to pick out a widget based on it's parents names and classes as well as it's own. It was somewhat possible to do this with Gtk+ 1.x, but it was a very obscure technique that never quite worked perfectly and failed completely in some apps. I might be wrong, but I think it needs a certain amount of policy dictation to work 100%: "If you want a toolbar-like object, you use this toolbar widget or you risk breaking the user's theme." Maybe there's a better solution, but I can't think of one right now. -- Ethan Grammatikidis 16:32:10 <+flux_control> git blame "struct filled with hex" && shoot_on_sight ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
