From: Carsten H. (T. R. <ra...@ra...> - 2012-07-30 00:16:54
|
On Sun, 29 Jul 2012 10:43:27 -0400 The Wanderer <wan...@fa...> said: > On 07/29/2012 09:35 AM, Carsten Haitzler (The Rasterman) wrote: > > > e16 and e17 are not even the same wm - e17 is a new wm entirely, thus don't > > expect it to have the same config options, nor even work the same way. > > I don't; I do know that E17 is entirely new. I simply figured that as it > developed and grew, most of the features from E16 (which presumably existed > for a reason) would end up appearing in one form or another. > > > certain things have just been dropped as they are "not useful" or "painful > > to support" or conflict with some new things. others are probably in e17 > > just "in disguise" under the name of a new option or just done in a > > different way. > > So I've discovered. I actually expected most or all of the "missing" options > to turn out to be present in that fashion, but I was disturbed at how many of > them didn't seem to be there at all. > > > some things are changed due to experience in trying to support e16 and > > discovering pain as a result (eg no fully customisable main menus - they are > > pretty close to fixed except for specific sub-sections due to the fact that > > distributions would play with the menus and change them and leave us to > > support people who now have different menus to those we ship). > > Fortunately, I have little objection to "fixed" main menus, provided that the > appropriate sub-menus are sufficiently configurable to suit my needs. > > I do object in principle to any refusal to allow customization, but I > certainly do recognize that practicality must take precedence. in some cases we have to refuse = because it either makes the code hard to maintain or hard to add real usability features. > > so simply listing them and finishing the same or similar option name is not > > a useful task. of course unlike, let's say gnome, we don't believe in > > "options are the tool of the devil, so remove them all!" :) (ok just having > > fun), but the gnome guys do have 1 good point - if you can do something so > > it "just works" without there being an option, this is MUCH better than > > using an option to patch over laziness in coding. in some cases we will be > > lazy because we don't know the solution yet, in others we just don't want > > to spend the time, and in yet others we've gone and solved it, removing the > > need for an option. > > I don't fundamentally disagree about any of this. I do think that there will > *always* be cases where someone wants a behavior different from the default, > especially if there used to be an option to allow that behavior, and so making > sure that there is still such an option is a good thing - but I do concur that > having it Just Work is best. > > > i will never bother going through e16's options list and "implementing them > > all". it'll never happen. instead - ask for the options you want and we'll > > see what we can do. frankly we can;'t spend the next N years adding every > > option on the planet in and not release. > > Acknowledged, and certainly reasonable; there's no point in re-adding options > that no one ever used (or, at least, ever cared about), at the very least. > > Is there any preferred way to "ask for the options I want"? Posts here on the > mailing list, "feature request"-type issues on the bug tracker, something > else? either here in email or via trac. > If nothing else, I'm not sure whether to > > A: list the elements of my preferred configuration (and point out the ones > which I haven't figured out how to achieve so far), or > > B: list specific E16 configuration options which I want/use and haven't found > (which might very well miss things, and/or be less effective at explaining > *why* I want them, and/or make it harder to spot good alternate ways of > achieving the same goal), or > > C: describe both "how I turn the default E16 layout into what I want" and "how > I've tried to turn the default E17 layout into what I want, and where it's > fallen short". > > Which one would be most useful/approachable from your perspective? just describe what it is you want to do. :) > > as such e17 has a boat-load of options already and is perfectly usable, and > > imho much more usable than e16. it simply needs polishing off of what is > > there (fix bugs, add in the absolutely most necessary options to make it > > function ok, and clean up up, labelling, config etc.) and release. we can > > (and will) add options over time and newer versions anyway as we are "option > > friendly". but note - some things will go away as options over time, e.g. > > compositor will stop being a module and be a core element. no option of > > turning it off anymore (which kills off dropshadow module too). > > Ergh. That's unpleasant for me; turning off compositing is one of the steps > which I've found necessary in getting E17 even as close to my preferred > configuration as I've managed. There are at least two behaviors which show up > when I turn it on (window translucency and a strange visual "size bounce" > effect when switching focus) which I find undesirable, and the latter at > least I've found no way to turn off without unloading the composite module. > > Hopefully there will still at least be an option to turn off the "compositing" > behavior, if not remove the module itself entirely? (Which I'd still prefer, > since it would also reduce e.g. memory footprint, but isn't absolutely > required.) no - there will be no option to turn it off. it will be baked in "take-it-or-leave-it". a massive rework of fundamental things inside e will mean its a one-way street. we will be removing windows all over the place to put the content into the compositor canvas directly as objects. here's why this is good: 1. your desktop wallpaper, shelf, menus, popups, everything, desklock etc. now will exist purely in the compositor canvas, not as actual windows - this means they wil be rendered with the engine in the compositor canvas... eg opengl, and thus accelerated. if not well then it isn't any WORSE that it is now... which is software. 2. this saves memory as now we don't need to keep in memory a pixmap of each of these windows IN addition to the content inside. they can get composed on the fly direct from source. as an example - your wallpaper. e will load the original and then render it and cache a scaled copy - ultimately dumping the original. this is rendered to the background window. but the bg window is ALSO stored in a pimxap (over on the video ram side of things - but if on integrated gfx its living in real ram, either way it consumes ram), so that's a whole framebuffer worth of pixmap storing almost exactly the same pixels that are the wallpaper too (except maybe with icons overlayed). so now we can get rid of this big pixmap and just rende3r from the wallpaper directly 3. if we now use gl for wallpaper etc. rendering the ability to do things like use emotion (videos) for wallpapers is perfectly feasible and can be entirely smooth even if fullscreen. of course it's an option - but it makes it sane and smooth. 4. even if not using opengl all of the above become more optimal/smoother as we cut out an indirection and a few copies and storages in the pipeline. actually for software we will save more memory now i think about it as we save both the bg pixmap AND the shm sgement used to store a client-side copy of the bg window pixmap.. 5. once compositing is in core things like shelf are no longer a window... that little zoom effect on icons that gets clipped by the window.. now doesn't get clipped anymore... bug-- 6. things like shelf etc. can have effects outside their window bounds (as $5) like a glow or something part of the design - more flexible 7. currently if u want a theme with just 1 pixel in the corner of a window border being "clear" so you can have rounded borders... you pay the price for the WHOLE window having an alpha channel and being argb since a window isnt split up into elements and is a whole pixmap/image on its own (at the x11 level and evas level) this makes for a large amount of overhead for this 1 tiny little nicety. moving compositing into core means we can also move window borders into the compositor canvas... and thus we can "cut up" a window frame into segments, some solid, some transparent, and thus massively reduce the cost of having just simple "rounded corners". 8. just like shelves - borders can now animate outside their bounds or do effects like shadowing, glows etc. 9. same with menus, everything etc. effects-wise. 10. this makes being a wayland compositor much easier as we now have a single unified canvas in which EVERYTHING lives :) 11. this makes e itself more mimic what efl apps do - they have single big canvases that are the whole app. now same for e. life is much easier/cleaner > -- > The Wanderer > > Warning: Simply because I argue an issue does not mean I agree with any > side of it. > > Every time you let somebody set a limit they start moving it. > - LiveJournal user antonia_tiger > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-users mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |