On Thu, 29 Jan 2009 16:29:12 +0300 sda <dmitry.serpok...@gmail.com> said:
> On 09:04 Thu 29 Jan , Toma wrote: > > > As the top of the page says, we need to finalize the list of things > > TODO. > > hi guys, > > i'm not the dev so beg your pardon if things below are "out of scope". > > 1) after the review of a mentioned page > (http://trac.enlightenment.org/e/wiki/Release) > i decide to fill 'trac' with some more 'tickets'/(requests) instead of > the page modification. assume that it's your (and not mine) decision to > set a milestone to the Release. ugh. now i need to find all the tickets spread around with bugs and feature requests too... much harder that just reading the page and knocking off line items and deleting them. > 2) there're no 'magic' word we're all aware about (no doubt that it ... > you know...). here it is (in capital letters): > == "SYSTRAY" == > suppose that clear definition of our POV to this case is required. it's > o'k not to make one and explain why. but Release of a Desktop Shell > without a tray will attract less Users i guess. yes, Wiki FAQ advise to > use 'trayer', 'stalonetray', etc., but references to the various > discussions are unable to state the case clear. not happening. tray protocol/mechanism is broken as fare as e is concerned. > 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). nothing is needed from themes - nada. simply users will not be able to fine-tune config for private DIFFERENT fonts and colors. they get what the theme gives them. > 4) another "chewing gum" - "Should add lua support? (optional)" Just > make a decision and say it. No/Yes - doesn't matter much (though the > amount of maintenance if "Yes" will be sufficient). it's a pity that > both VM's ('embryo' and 'lua') can't exist together. they can. the question is - do we want to ship with a vm/scripting engine we WILL drop in the future thus having a pain for people post-release of having to adapt stuff they built on 1.0 releases. > 5) last couple of days i'm using 'Ecomorph' and it's much more stable > then "bling" module. suppose that "bling" should be improved (in terms > of stability) or explicitly marked as 'unstable'. yes, FAQ tells that > E17 doesn't work with composite, but it's an easy task for "bling" now > to create a nice segfault of E17 :). not touching bling. compositing is scheduled for e18 - for e17 it's a "someone elses problem". you chose to use bling - you should take it up with bling's author/maintainer. :) e is not doing compositing itself until e18. > offtop> http://en.opensuse.org/Ecomorph > > 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. removing almost all of e_remote. the window management features of eesh are of niche use and can be done by simply x tools without the wm. feel free to write these tools. :) no need to go add work for e17 release for something that has no need to be in e. > 7) the "bridge" between "qt" <-> "edje" && "gtk" <-> "edje" still "under > heavy discussion" suggest to create a couple of themes like existing > "Clearlooks" (it's really nice) to match the major ones used by others. > dunno about "qt" (don't use it here) but it's an easy task to copy a > couple of most popular "gtk+" ones. to be honest - gtk and qt are out of scope for e17 release when it comes to edje or evas. > thanks for your kind attention. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
