pieterg wrote: > I'm relatively new to edje, been picking most things up rather quickly. > There's one thing I would like to accomplish, but haven't managed yet: > > How can I emit a signal to a 'type: GROUP' part, to be received by a program > in that group? > The other way around is easy, a signal from source "groupname:partname" is > received just fine. But edje_cc doesn't allow me to use > the "groupname:partname" convention in a target, or as a program name. And > I assume that this isn't just a limitation of edje_cc. > >
I can't recall a damn thing about this anymore, Brian Mattern (aka. rephorm) did the work for this. Maybe others can help you here, but it's likely not too difficult to implement what you want edje to do here.. if indeed it's not possible to do so already. > My experience is that edje data collections will grow quickly, and it will > become more and more difficult to keep track of the whole thing, as it > grows. > Putting different screens and even certain parts of windows into separate > subgroups really helps to keep things tidy. > But these groups need to communicate with eachother. > That they should. It would also be nice if you could define more complex structures, like 'widgets', declaratively and have them be 'swallowed'. Or be able to fully extend edc to have groups as specific kinds of declarative types, or any number of other interesting things. Some work related to this was done by Hisham on the etk based "evolve" (a lib and simple gui builder based on an edc kind of declarative format for defining etk widget types, which allowed you to reference edje theme groups). Perhaps "ewl", or the new "elementary" widget set, might have something like that in mind as well - don't know. > A possible workaround is emitting a signal to the application code, and > letting the application emit the signal to the (sub)group. > I'm doing that now, so I can at least get the desired functionality. > > But that's not very nice, especially when those signals are not meant for > the application to act upon, just for graphical effects in the > userinterface. > Changing the userinterface would mean changing the application, to > accomodate all new signal connections between the various parts. > Note that I don't just mean changing a theme, my goal is to have a > userinterface which controls not just the way things look, but also the way > things work, which steps the user has to take, and in which order. > Well, that's kind of the 'holy grail' of gui programming isn't it.. How to be able to easily define the look and behavior. In this case via some declarative format plus minimal logic or scripting. Or at least, to do as much of this as possible. Hence there are things like css, html, xul, mxml, xaml,.. and assorted scripting languages, and a variety of gui builders/designers around those. Big important stuff in the gui world at large it seems. I recall seeing something about a Mozilla based desktop-shell called "Pyro" for which you could actually use html,xul,css, ... (plus some javascript) to define the actual desktop - very interesting. Edje/edc itself is somewhat limited right now - the group part was an attempt to allow for some amount of re-usability and for some amount of tree-structuring that was similar to the external 'swallow' model, but I can't recall how much of it was finished. There may also have been some extension to embryo to have something like an "on_load" function... can't recall for certain though. More is definitely needed.. whether as part of edje itself, or via some other lib, or whatnot. And of course gui builders/designers are likely the only real way that "most people" would ever be able to do large amounts of complex stuff. > Another possible way around this is not to use seperate groups for the > different windows / window regions, so every component can signal every > other component in the same large group (and perhaps just put different > building blocks into different files, to keep a bit of overview) > > So my question, again, is it possible to interact with a subgroup? Emit a > signal to it, or perhaps run a subgroup program directly? > If not, what would be the prefered way to structure large edc's? > > Rgds, Pieter > ____________________________________________________________ Earn a degree in Criminal Justice and work as a Police officer. Click here for more info. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEe1V7Gxz3fMuXs4f0BZi87LdhfLT8axjJrtQqqQyHx1mFudSNVvy/ ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
