> There was a systray mention on there a while ago... maybe it was a > different TODO list. Added in modules-extra for now. > ok. thx. > > 3) annoying question related to the "color and font config modules". as > > it was mentioned by Raster: > > > >>thats what i meant - just wouldn't compile the color and font config > >>modules. > >>they they wont appear anywhere. code will be there - just not being > >>compiled or > >>used until its fixed. > > > > ok. but does it mean that all themes/(.edj files) which use custom fonts > > and/or "color_class:"-es will require maintenance? if "Yes!", then > > suppose that the info should be spread all over the community or only new > > default theme will remain usable (it's a nice option, but some may > > prefer other variants). > > > > I think scraping the modules to config it would be good, but leave the > support for it via enlightenment_remote would be good as well. If > anyone was keen, they could revamp it and reintroduce into a major > release eg, E17.1. That way, we dont need to alter themes, and if you > really want, just include a brief howto in the theme about. Kind of > like what i did with Cerium. > please read this thread: http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg20486.html and your response unfortunately doesn't answer the question: "does it mean that all themes/(.edj files) which use custom fonts and/or "color_class:"-es will require maintenance?" the "milestone" left this point as pending (optional). just suppose that clarification is needed. > > 6) as i mentioned in trac ticket #201 the "gap" exist in a window > > management between E16/eesh and E17/enlightenment_remote. it could be > > nice to eliminate this "mismatch" especially for the experienced Users > > of E16. > > > > Like buying a new TV, you need to learn the new remote. :) > the question is not in "learning a new remote" unfortunately. it's more related to the "should we buy this new TV or let's look at another one?" just for fun you can read trac ticket #201 and try to make the same trick with E17. should i prepare the draft of a "Comparison Table" and outline the "mismatches" in general? just assumed that we're all here know a bit about the "roots" and no such things are needed.
frankly speaking it doesn't matter will the same functions (like "eesh" has) work with "enlightenment_remote" or via "qdbus" (we're usind dbus now, right?). but i guess that a simple questions like "How many windows/apps are running under E?" should have an answer readable in your terminal app. "eesh" has a clear answer: "eesh window_list". that's it. > What we SHOULD > worry about, is the cross themeing of E with EWL and ETK. It is all > very possible, but as a themer yourself, its quite tedious to add the > other parts and duplicate and so on. We could of course, investigate > making the toolkits (Or toolkit) work with edje parts from an E theme. > nice point. agree with you. but... let's say that IMHO - ETK has a stable API and a bunch of a software which work for my Linux and OpenBSD. EWL is constantly evolving and assume that the "Ephoto" app is the only one in a "pure EWL basket" (plus "Elitaire"?). also "elementary" is coming, right? that's why all my modest .edj files contain E17 + ETK only. and the final question is: - several "unified" themes exist (yep, i created the first one... my fault). can we expect a "unified switcher" to control the look of E17, ETK and EWL from a single location/app? regards, sda ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
