From: The W. <wan...@fa...> - 2012-07-29 13:16:18
|
I am a long-time user of E16. From time to time, I've tried out E17 to see whether it might be suitable, on the grounds that A: why not, and B: if E16 ever does "go away" for lack of maintenance, a suitable substitute would be needed. However, I have never been able to configure E17 into anything suffiiciently close to my preferred configuration. On the most recent attempt, rather than just playing around with the E17 options and trying to find ways to match my preferred setup, I decided to take a more methodical approach: to go through the E16 configuration options in detail and try to identify, from a user's perspective, how to achieve the same effect in E17. I expected that most of them would turn out to be fairly simple and straightforward - essentially the same options (by whatever names), just cleaned up and reorganized. Instead, I was rather disturbed to discover that even at what appears to be a rather late stage of E17 development, something on the order of two-thirds of the options from the E16 "Settings" dialog do not seem to have functioning equivalents in E17, so far as I can find - and in all but a very few of those cases, do not even seem to exist in E17 at all. Is it really intended that E17 lack much of the customizability and/or configurability which was present in E16? If not, is that customizability really still so far from being fully implemented (despite the years of E17 development), or have I simply not managed to find the vast majority of the customizability which does already exist? -- 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-29 13:35:03
|
On Sun, 29 Jul 2012 09:16:09 -0400 The Wanderer <wan...@fa...> said: 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. 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. 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). 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 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. 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). > I am a long-time user of E16. From time to time, I've tried out E17 to see > whether it might be suitable, on the grounds that A: why not, and B: if E16 > ever does "go away" for lack of maintenance, a suitable substitute would be > needed. However, I have never been able to configure E17 into anything > suffiiciently close to my preferred configuration. > > On the most recent attempt, rather than just playing around with the E17 > options and trying to find ways to match my preferred setup, I decided to > take a more methodical approach: to go through the E16 configuration options > in detail and try to identify, from a user's perspective, how to achieve the > same effect in E17. I expected that most of them would turn out to be fairly > simple and straightforward - essentially the same options (by whatever > names), just cleaned up and reorganized. > > Instead, I was rather disturbed to discover that even at what appears to be a > rather late stage of E17 development, something on the order of two-thirds of > the options from the E16 "Settings" dialog do not seem to have functioning > equivalents in E17, so far as I can find - and in all but a very few of those > cases, do not even seem to exist in E17 at all. > > > Is it really intended that E17 lack much of the customizability and/or > configurability which was present in E16? If not, is that customizability > really still so far from being fully implemented (despite the years of E17 > development), or have I simply not managed to find the vast majority of the > customizability which does already exist? > > -- > 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... |
From: The W. <wan...@fa...> - 2012-07-29 14:43:34
|
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. > 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? 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? > 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.) -- 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 |
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... |
From: The W. <wan...@fa...> - 2012-07-30 00:57:13
|
On 07/29/2012 08:09 PM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 29 Jul 2012 10:43:27 -0400 The Wanderer <wan...@fa...> said: >> 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. Understood. As I said, practicality. >> 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. :) The trouble is that there are a few different ways to interpret that. However, I think option A is probably closest; I'll see what I can do (though probably not tonight). >> 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. Does the picture change if I mention that I don't use pretty much any of that except the menus? Aside from memory usage (which you've presented good arguments on), my main concern about "fancy visual effects" in window managers is what might be called "baseline processing load" - the minimum CPU(/GPU/etc.) activity necessary even for just sitting idle, and for basic tasks like e.g. moving the pointer around the screen. I have the impression, possibly unfounded, that such requirements are going to be higher for anything centered around "eye candy" than for something otherwise comparable which isn't. I reflexively consider "compositing" pure eye candy, I think since the initial benefits touted from things like Compiz were AFACT entirely in the eye-candy field. You've presented good arguments as to why memory consumption shouldn't be increased and might even be decreased by switching over to a compositing-only model, and that's reassuring. Are there comparable arguments on other resource usage, such as CPU (and other processor) load? Or is that still essentially 100% negligible regardless? Or is it in fact a potentially legitimate concern? Snipping the other points, as I don't have anything to say to them - I do like the sound of it overall, and I do agree that it's probably the best approach. I just have my standing concerns about baseline resource consumption, from what I think might be called a "minimalist" perspective. -- 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-30 03:06:38
|
On Sun, 29 Jul 2012 20:57:03 -0400 The Wanderer <wan...@fa...> said: > On 07/29/2012 08:09 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Sun, 29 Jul 2012 10:43:27 -0400 The Wanderer <wan...@fa...> said: > > >> 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. > > Understood. As I said, practicality. > > >> 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. :) > > The trouble is that there are a few different ways to interpret that. > However, I think option A is probably closest; I'll see what I can do (though > probably not tonight). > > >> 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. > > Does the picture change if I mention that I don't use pretty much any of that > except the menus? you use the wallpaper - like it or not. it's always there. :) > Aside from memory usage (which you've presented good arguments on), my main > concern about "fancy visual effects" in window managers is what might be > called "baseline processing load" - the minimum CPU(/GPU/etc.) activity > necessary even for just sitting idle, and for basic tasks like e.g. moving > the pointer around the screen. pointer is not done by a wm - it's done by x itself and either is software emulated (rather hackishly in fact - sw cursors in x are horrible - don't get me started on that/ i'd sooner kill of cursors in x11 entirely and do them client-side in the compositor if i could that rely on x cursors), and hw cursors are literally overlayed by specialised hardware and cursor moves just reconfigure where the overlay is on the screen. they involve no redraws. (except sw emulated cursors ad above, and those are - so horrible, i'd rather gouge my eyes out than look at them). > I have the impression, possibly unfounded, that such requirements are going to > be higher for anything centered around "eye candy" than for something > otherwise comparable which isn't. I reflexively consider "compositing" pure > eye candy, I think since the initial benefits touted from things like Compiz > were AFACT entirely in the eye-candy field. enlightenment exists *BECAUSE* of eye candy. it exists BECAUSE i wanted a wm that has better eyecandy. that is it's reason for living. so yes - eye candy costs something. that's life. :) if i wanted to make a wm that was purely focused on minimal mem/cpu footprint it'd be totally different to e. this is something you'll need, i guess, to accept. that eyecandy is in e's DNA from day 1. of course we try and get the eyecandy so we pay a low price for it, or as low as we can get, but we still pay for it. that's life. > You've presented good arguments as to why memory consumption shouldn't be > increased and might even be decreased by switching over to a compositing-only > model, and that's reassuring. Are there comparable arguments on other resource > usage, such as CPU (and other processor) load? Or is that still essentially > 100% negligible regardless? Or is it in fact a potentially legitimate concern? mem consumption won't go up from current COMPOSITED e17. it's still more than non-composited. but that is a trade-off i'm willing to make. as such a compositing wmm is always involved in all rendering. any app drawing in its window will involve the wm having to re-composite. so it will always cost something cpu-wise. cpuload won't change really from current composited e. from non-composited, it will be more. > Snipping the other points, as I don't have anything to say to them - I do like > the sound of it overall, and I do agree that it's probably the best approach. > I just have my standing concerns about baseline resource consumption, from > what I think might be called a "minimalist" perspective. just a point here - e was NEVER a minimalist wm. it never aimed to be one or make minimalists happy. minimalists are not e's target audience or goal. it just so happens as a bit-product of caring about efficiency that we HAPPEN to make some minimalists happy by consuming less in the way of cpu/ram etc. than most equivalent wm/de's (in terms of features) out there. moving to compositing-only is actually an efficiency thing. if we accept the future that 90% of people will use compositing, then we make things more efficient for the 90% but unfortunately hurt the 10% who don't want compositing. the alternative is we maintain a more complex codebase with more codepaths, fewer of which now get tested, causing overhead in development time, maintenance, more bugs, uglier code, etc. - if it was a 50-50 split, it may not be worth moving to comp-only, but... it's not . it's really 90%+ use compositing. > -- > 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... |
From: Wido <wi...@gm...> - 2012-07-29 15:13:02
|
On Sunday July 29 2012 11:43:27 The Wanderer escribió: > 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. > > > 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? > > > 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? > > > 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. To change how the comp works, go to control panel -> composite -> effects tab. In styles you can change the behaviour (I have everything and and windows don't 'wobble' when selected) > > 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.) > > -- -- Wido |
From: The W. <wan...@fa...> - 2012-07-29 15:59:11
|
On 07/29/2012 11:12 AM, Wido wrote: > On Sunday July 29 2012 11:43:27 The Wanderer escribió: > >> On 07/29/2012 09:35 AM, Carsten Haitzler (The Rasterman) wrote: >>> 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. > > To change how the comp works, go to control panel -> composite -> effects > tab. In styles you can change the behaviour (I have everything and and > windows don't 'wobble' when selected) I did find that, yes. Unfortunately, none of the settings in the Effects tab seem obviously related to the "bounce" / "wobble" effect, and most of them seem to have cryptic names which don't seem to be explained anywhere nearby. I do see what looks like the same "bounce" in the cyclic animations of some of the things which look like "previews" on the Default sub-tab of the Effects tab, but I can't find any way to edit any of those. (I see what look like the same objects on the Style tab of the Edit dialog of each of the entries in the Over sub-tab, but I don't see any way to change any of them from there, either.) I do think I see how to change among the listed "styles" (I presume is what they're called" on the "Default" sub-tab, by clicking on one and then selecting Apply, but I don't see any clear indication of what each style actually includes; the preview animation isn't especially helpful there, given that all of them seem nearly identical aside from one or two little details. I'll be honest: I don't see why *anyone* would actually want this "bounce" behavior, at least to such an extreme degree. As such, I would think it would be far better to have it disabled by default, if indeed present at all. However, even if it is desired enough to justify its being the default, the way to disable it needs to be far more obvious than it appears to be. Beyond that, I think that the entire Effects tab needs to be much more comprehensible, or at the very least to come with a pointer to documentation - "if you don't understand this section of the configuration, go read about it here". However, it does seem plausible that this lack might be because Composite isn't complete or isn't "ready for prime time" yet. (None of that addresses the "memory footprint" and related arguments, which do matter to me if only for reasons of principle, but I'm not planning to argue that one in depth without trying to get some actual data to back myself up with; it's entirely possible that my impression of E17's relative resource usage is far out of sync with reality.) -- 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 |
From: Robert K. <ro...@sp...> - 2012-07-29 17:22:17
|
----- Original Message ----- From: "The Wanderer" To: enl...@li... Sent: Sunday, July 29, 2012 6:59:00 PM Subject: Re: [e-users] E16/E17 feature parity On 07/29/2012 11:12 AM, Wido wrote: > On Sunday July 29 2012 11:43:27 The Wanderer escribió: > >> On 07/29/2012 09:35 AM, Carsten Haitzler (The Rasterman) wrote: >>> 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. > > To change how the comp works, go to control panel -> composite -> effects > tab. In styles you can change the behaviour (I have everything and and > windows don't 'wobble' when selected) I did find that, yes. Unfortunately, none of the settings in the Effects tab seem obviously related to the "bounce" / "wobble" effect, and most of them seem to have cryptic names which don't seem to be explained anywhere nearby. I do see what looks like the same "bounce" in the cyclic animations of some of the things which look like "previews" on the Default sub-tab of the Effects tab, but I can't find any way to edit any of those. (I see what look like the same objects on the Style tab of the Edit dialog of each of the entries in the Over sub-tab, but I don't see any way to change any of them from there, either.) I do think I see how to change among the listed "styles" (I presume is what they're called" on the "Default" sub-tab, by clicking on one and then selecting Apply, but I don't see any clear indication of what each style actually includes; the preview animation isn't especially helpful there, given that all of them seem nearly identical aside from one or two little details. I'll be honest: I don't see why *anyone* would actually want this "bounce" behavior, at least to such an extreme degree. As such, I would think it would be far better to have it disabled by default, if indeed present at all. However, even if it is desired enough to justify its being the default, the way to disable it needs to be far more obvious than it appears to be. Beyond that, I think that the entire Effects tab needs to be much more comprehensible, or at the very least to come with a pointer to documentation - "if you don't understand this section of the configuration, go read about it here". However, it does seem plausible that this lack might be because Composite isn't complete or isn't "ready for prime time" yet. (None of that addresses the "memory footprint" and related arguments, which do matter to me if only for reasons of principle, but I'm not planning to argue that one in depth without trying to get some actual data to back myself up with; it's entirely possible that my impression of E17's relative resource usage is far out of sync with reality.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. ------------------------------------------------------------------------------ I have no real answers, however as best as I can tell, the first sheet on the compositing options are preconfigured defaults. Every time I have used the compositor, I just go to the options and select the "none" on the default screen. This disables transparencies and the wobble. I do however also want to vote against "forcing" the compositor. It has never really worked for me, both performance wise, and random weird graphical issue wise. |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-30 00:16:52
|
On Sun, 29 Jul 2012 20:22:05 +0300 (EEST) Robert Krambovitis <ro...@sp...> said: > ----- Original Message ----- > From: "The Wanderer" > To: enl...@li... > Sent: Sunday, July 29, 2012 6:59:00 PM > Subject: Re: [e-users] E16/E17 feature parity > > On 07/29/2012 11:12 AM, Wido wrote: > > > On Sunday July 29 2012 11:43:27 The Wanderer escribió: > > > >> On 07/29/2012 09:35 AM, Carsten Haitzler (The Rasterman) wrote: > > >>> 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. > > > > To change how the comp works, go to control panel -> composite -> effects > > tab. In styles you can change the behaviour (I have everything and and > > windows don't 'wobble' when selected) > > I did find that, yes. > > Unfortunately, none of the settings in the Effects tab seem obviously related > to the "bounce" / "wobble" effect, and most of them seem to have cryptic names > which don't seem to be explained anywhere nearby. how are they cryptic? they are named after usage. eg things used for menus, popup. there is a "still" one that is totally still... another used for everything. etc. choose the one u prefer. it shows it right there animated as a preview visually so someone who is totally illiterate can even see what they do :). ever tries just selecting one and seeing if u like it or not? > I do see what looks like the same "bounce" in the cyclic animations of some of > the things which look like "previews" on the Default sub-tab of the Effects > tab, but I can't find any way to edit any of those. (I see what look like the > same objects on the Style tab of the Edit dialog of each of the entries in > the Over sub-tab, but I don't see any way to change any of them from there, > either.) they are all provided by the theme. if you want to edit - break out your text editor and make a theme. these effects are not implemented in code anywhere, they are defined by the theme as whole already done packaged "looks", thus you don't edit them - you just select. > I do think I see how to change among the listed "styles" (I presume is what > they're called" on the "Default" sub-tab, by clicking on one and then > selecting Apply, but I don't see any clear indication of what each style > actually includes; the preview animation isn't especially helpful there, > given that all of them seem nearly identical aside from one or two little > details. that is all that is different. they are all just subtly different. > I'll be honest: I don't see why *anyone* would actually want this "bounce" > behavior, at least to such an extreme degree. As such, I would think it would > be far better to have it disabled by default, if indeed present at all. > However, even if it is desired enough to justify its being the default, the > way to disable it needs to be far more obvious than it appears to be. if you had updated e in the past we weeks u'll notice default doesnt fade or wobble anymore - it only zooms+fades in and out on show/hide and has a shadow. but again - it always has been configurable so always fixable to whatever tickles your fancy. > Beyond that, I think that the entire Effects tab needs to be much more > comprehensible, or at the very least to come with a pointer to documentation - > "if you don't understand this section of the configuration, go read about it > here". However, it does seem plausible that this lack might be because > Composite isn't complete or isn't "ready for prime time" yet. why don't you just try select one and hit apply? "no - don't like that.. try another"... keep trying until u are happy. it isn't an exam where u have to get it right and you are graded on your first and only answer. :) there is a very short lit of available styles by default... choose one. :) > (None of that addresses the "memory footprint" and related arguments, which do > matter to me if only for reasons of principle, but I'm not planning to argue > that one in depth without trying to get some actual data to back myself up > with; it's entirely possible that my impression of E17's relative resource > usage is far out of sync with reality.) by moving compositing into corer we actually reduce memory footprint compared to it being in a module. we'll save at a MINIMUM 1x the size of your framebuffer (eg if 1920x1080 then that's 8mb). just to start. we'll save even more in reality (if using gl for compositing then something like about 16-18mb will get saved given the 1080p screen) and then when things like desklock appear we save an additional 8mb etc. for software compositing savings are a bit lower - 8-10mb normally with 8mb saved while desklock is up etc. > -- > The Wanderer > > Warning: Simply because I argue an issue does not mean I agree with any > side of it. > > ------------------------------------------------------------------------------ > > > I have no real answers, however as best as I can tell, the first sheet on the > compositing options are preconfigured defaults. Every time I have used the > compositor, I just go to the options and select the "none" on the default > screen. This disables transparencies and the wobble. > > I do however also want to vote against "forcing" the compositor. > > It has never really worked for me, both performance wise, and random weird > graphical issue wise. > > ------------------------------------------------------------------------------ > 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... |
From: The W. <wan...@fa...> - 2012-07-30 01:39:07
|
On 07/29/2012 07:50 PM, Carsten Haitzler (The Rasterman) wrote: [that on 2012-07-29 at 16:59, The Wanderer wrote:] >> On 07/29/2012 11:12 AM, Wido wrote: >>> To change how the comp works, go to control panel -> composite -> effects >>> tab. In styles you can change the behaviour (I have everything and and >>> windows don't 'wobble' when selected) >> >> I did find that, yes. >> >> Unfortunately, none of the settings in the Effects tab seem obviously >> related to the "bounce" / "wobble" effect, and most of them seem to have >> cryptic names which don't seem to be explained anywhere nearby. > > how are they cryptic? they are named after usage. eg things used for menus, > popup. there is a "still" one that is totally still... another used for > everything. etc. First, I don't actually know what "everything" is even yet, and I think the default understanding of the term is going to be as the literal compound word "every-thing" rather than as the name of the E-related "subprogram" or whatever it actually is. (It's only now, as I'm editing this message after writing, that I figured out that Wido meant that he is using the "everything" style, not that he has "all of the things" turned on.) I have a vague understanding, from having played around with other E17 configuration options, that the "popup" refers to the "window list" which appears when switching focus (unless you turn that off) and/or to the little "you are here now" window which appears when switching desktops. ...I'll cut myself off there before I go off on what could turn out to be a complete tangent. You see, I'm still confused as to whether what's listed in the "Styles" tab are A: "global styles" which, if selected, will change the behavior of E17 as a whole, or B: "domain-specific styles" which will change the behavior of only the domain which they are assigned to (e.g., the "popup" style only affecting that pop-up "window list", et cetera). I think it's probably A, since B would seem to require being able to edit the style which is going to be applied (as opposed to just selecting it) - but if it's A, why do they seem to be named after these other existing elements? I'm quite sure it all makes sense from the perspective of someone who knows E17 inside and out, but it doesn't at first (or second or third) glance from mine. > choose the one u prefer. it shows it right there animated as a preview > visually so someone who is totally illiterate can even see what they do :). > ever tries just selecting one and seeing if u like it or not? No, because it wasn't obvious for some time that these could actually be "selected" (as opposed to "highlighted", which can have multiple meanings, including none at all) in any meaningful way. In addition, the animated previews are so small, and so very similar to one another (at least in the default theme and configuration), that I didn't even notice at first that they weren't all displaying exactly the same thing. (I think most of them *do* display the exact same thing in at least some of the "phases" of the animation, which only exacerbates the problem.) I think the main problem was that I came to this window expecting to be able to actually configure the visual results which would be displayed, when what it appears to be intended to do instead is to let you switch among a set of pre-configured profiles defined by the theme. That's far less accessible and usable for anyone who wants to do actual hands-on configuration, and is different from any of the other E17 configuration dialogs I've seen; all of the others seem to let you change options directly, rather than just choosing among sets of predefined options. If nothing else, I think it would be helpful to be able to see - for any given "style" - exactly what settings are being applied, even if you can't change them. It wouldn't have been enough to satisfy me given what I went in there expecting, but it would be more useful, and it might have been enough to give me the hint of what was actually going on. >> I do see what looks like the same "bounce" in the cyclic animations of some >> of the things which look like "previews" on the Default sub-tab of the >> Effects tab, but I can't find any way to edit any of those. (I see what >> look like the same objects on the Style tab of the Edit dialog of each of >> the entries in the Over sub-tab, but I don't see any way to change any of >> them from there, either.) > > they are all provided by the theme. if you want to edit - break out your text > editor and make a theme. these effects are not implemented in code anywhere, > they are defined by the theme as whole already done packaged "looks", thus > you don't edit them - you just select. And that's the problem. I'm probably going to *have* to create my own theme, if only because there doesn't seem to be a BlueSteel analogue for E17 yet. However, I do find this a bit... user-unfriendly. Someone who likes most of the characteristics of the theme they're using (which may be the default), but wants to tweak one or two things, will apparently have to create an entire separate theme in order to do that - and doing so will require learning the "theme language" or other syntax, whatever that may be. And that's far less user-friendly than being able to simply adjust the options in a configuration dialog. I'm relatively technically competent, but even I don't "already know" how to do that, and find the idea of having to do so something of a chore. A more ordinary user is likely to be even more put off by this (or even unable to understand the idea at all), but may well still legitimately want to tweak things. I understand that there are probably technical reasons why it "works better", in terms of maintainability and perhaps even of bigger-picture customizability, to do it this way. But I still think that it's a bad approach from a user-friendliness perspective. >> I'll be honest: I don't see why *anyone* would actually want this "bounce" >> behavior, at least to such an extreme degree. As such, I would think it >> would be far better to have it disabled by default, if indeed present at >> all. However, even if it is desired enough to justify its being the >> default, the way to disable it needs to be far more obvious than it appears >> to be. > > if you had updated e in the past we weeks Unfortunately, I'm running E17 from the Debian package, which means I'm probably well further behind than that. The package version is 0.16.999.70492-2, which probably means SVN revision 70492. (If you're using SVN - for some reason my default expectation nowadays is for any random project to be using git, even though I know most of them don't.) If I do end up getting into this, I will very likely start compiling from current up-to-date source on a somewhat regular basis, at least for VM-based testing purposes. > u'll notice default doesnt fade or wobble anymore - it only zooms+fades in > and out on show/hide and has a shadow. but again - it always has been > configurable so always fixable to whatever tickles your fancy. But only by manually editing the theme in a text editor, I presume? For your "ordinary" user, I'm not remotely sure that that's good enough. >> Beyond that, I think that the entire Effects tab needs to be much more >> comprehensible, or at the very least to come with a pointer to >> documentation - "if you don't understand this section of the configuration, >> go read about it here". However, it does seem plausible that this lack >> might be because Composite isn't complete or isn't "ready for prime time" >> yet. > > why don't you just try select one and hit apply? "no - don't like that.. try > another"... I may well do so, now that I understand that that's what is going on in that settings window. Given the conflicting-assumptions-based confusion that was going on initially, though, it didn't even occur to me that this might be something to potentially be able to try; I was expecting the things listed in the settings window to be editable, not simply selectable. >> (None of that addresses the "memory footprint" and related arguments, which >> do matter to me if only for reasons of principle, but I'm not planning to >> argue that one in depth without trying to get some actual data to back >> myself up with; it's entirely possible that my impression of E17's relative >> resource usage is far out of sync with reality.) > > by moving compositing into corer we actually reduce memory footprint compared > to it being in a module. we'll save at a MINIMUM 1x the size of your > framebuffer (eg if 1920x1080 then that's 8mb). just to start. we'll save even > more in reality (if using gl for compositing then something like about > 16-18mb will get saved given the 1080p screen) and then when things like > desklock appear we save an additional 8mb etc. for software compositing > savings are a bit lower - 8-10mb normally with 8mb saved while desklock is up > etc. You've gone into this in considerably more detail elsewhere, and my concerns are well on their way to being relieved. Thank you. (FWIW, I'm running at 2650x1600, so the baseline savings would be rather higher.) >> I have no real answers, however as best as I can tell, the first sheet on >> the compositing options are preconfigured defaults. Every time I have used >> the compositor, I just go to the options and select the "none" on the >> default screen. This disables transparencies and the wobble. >> >> I do however also want to vote against "forcing" the compositor. >> >> It has never really worked for me, both performance wise, and random weird >> graphical issue wise. I note that you actually replied to the message posted by Robert Krambovitis (and the attribution above is somewhat screwed up as a result, due to the nonstandard way his reply quoted me), but didn't say anything in direct response to what he wrote; was that intentional? -- 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-30 03:06:45
|
On Sun, 29 Jul 2012 21:38:56 -0400 The Wanderer <wan...@fa...> said: > On 07/29/2012 07:50 PM, Carsten Haitzler (The Rasterman) wrote: > > [that on 2012-07-29 at 16:59, The Wanderer wrote:] > > >> On 07/29/2012 11:12 AM, Wido wrote: > > >>> To change how the comp works, go to control panel -> composite -> effects > >>> tab. In styles you can change the behaviour (I have everything and and > >>> windows don't 'wobble' when selected) > >> > >> I did find that, yes. > >> > >> Unfortunately, none of the settings in the Effects tab seem obviously > >> related to the "bounce" / "wobble" effect, and most of them seem to have > >> cryptic names which don't seem to be explained anywhere nearby. > > > > how are they cryptic? they are named after usage. eg things used for menus, > > popup. there is a "still" one that is totally still... another used for > > everything. etc. > > First, I don't actually know what "everything" is even yet, and I think the > default understanding of the term is going to be as the literal compound word > "every-thing" rather than as the name of the E-related "subprogram" or > whatever it actually is. (It's only now, as I'm editing this message after > writing, that I figured out that Wido meant that he is using the "everything" > style, not that he has "all of the things" turned on.) > > I have a vague understanding, from having played around with other E17 > configuration options, that the "popup" refers to the "window list" which > appears when switching focus (unless you turn that off) and/or to the little > "you are here now" window which appears when switching desktops. > > > ...I'll cut myself off there before I go off on what could turn out to be a > complete tangent. You see, I'm still confused as to whether what's listed in > the "Styles" tab are A: "global styles" which, if selected, will change the > behavior of E17 as a whole, or B: "domain-specific styles" which will change > the behavior of only the domain which they are assigned to (e.g., the "popup" > style only affecting that pop-up "window list", et cetera). > > I think it's probably A, since B would seem to require being able to edit the > style which is going to be applied (as opposed to just selecting it) - but if > it's A, why do they seem to be named after these other existing elements? > > I'm quite sure it all makes sense from the perspective of someone who knows > E17 inside and out, but it doesn't at first (or second or third) glance from > mine. they were named this way because those elements of e are pre-configured to use those styles. if u look at "apps, e, over, menus" u'll see a list of things and that list is a list of "window matchers" that match a given window to a style - u can select the style used fro that match. it's like saying *.jpg -> be pink *.png -> be green *.gif -> be blue *.txt (except for A*) -> be yellow everything else -> be gray the default style list is editing the "everything else" that isn't a specific match. it's complicated because trying to use different compositing styles for different windows etc. is a complicated setup to try and identify which one is which. > > choose the one u prefer. it shows it right there animated as a preview > > visually so someone who is totally illiterate can even see what they do :). > > ever tries just selecting one and seeing if u like it or not? > > No, because it wasn't obvious for some time that these could actually be > "selected" (as opposed to "highlighted", which can have multiple meanings, > including none at all) in any meaningful way. it's a list like all other lists in e. they all look the same - like lists, with the selected item in a different color etc. :) like every list in every widget set and app for the past few decades. :) > In addition, the animated previews are so small, and so very similar to one > another (at least in the default theme and configuration), that I didn't even > notice at first that they weren't all displaying exactly the same thing. (I > think most of them *do* display the exact same thing in at least some of the > "phases" of the animation, which only exacerbates the problem.) they are every similar because the compositor style affects just the shadowing and animation when showing, hiding, or going in and out of focus, thus its cycling between these to show you. > I think the main problem was that I came to this window expecting to be able > to actually configure the visual results which would be displayed, when what > it appears to be intended to do instead is to let you switch among a set of > pre-configured profiles defined by the theme. if you knew how edje works - you'd realize this isnt possible or how it works. it's not a profile with just a bunch of boolean checkboxes on or off with the wobble, fade, zoom etc. pre-built in effects. its like a html/css thing - where the whole effect is a pre-made website. u dont like the design? well write some css of your own. too hard? well live with the limited set of css's provided with the previews. :) > That's far less accessible and usable for anyone who wants to do actual > hands-on configuration, and is different from any of the other E17 > configuration dialogs I've seen; all of the others seem to let you change > options directly, rather than just choosing among sets of predefined options. but its not how its implemented. it saves us lots of code in the wm to do it this way AND makes it massively more flexible as someone can design a new animation and look without ever editing a single line of code. > If nothing else, I think it would be helpful to be able to see - for any given > "style" - exactly what settings are being applied, even if you can't change > them. It wouldn't have been enough to satisfy me given what I went in there > expecting, but it would be more useful, and it might have been enough to give > me the hint of what was actually going on. there are no "settings" like u think there are. it's showing you visually by literally running through the scenarios and "emitting" events to the object and letting it react as it sees fit. its reactions to such events are basically like script - they are not options of "wobble on/off" "fade on/off" etc. > >> I do see what looks like the same "bounce" in the cyclic animations of some > >> of the things which look like "previews" on the Default sub-tab of the > >> Effects tab, but I can't find any way to edit any of those. (I see what > >> look like the same objects on the Style tab of the Edit dialog of each of > >> the entries in the Over sub-tab, but I don't see any way to change any of > >> them from there, either.) > > > > they are all provided by the theme. if you want to edit - break out your > > text editor and make a theme. these effects are not implemented in code > > anywhere, they are defined by the theme as whole already done packaged > > "looks", thus you don't edit them - you just select. > > And that's the problem. > > I'm probably going to *have* to create my own theme, if only because there > doesn't seem to be a BlueSteel analogue for E17 yet. However, I do find this a > bit... user-unfriendly. e16 was the same - u have to make a theme if u didn't like bluesteel and nothing else appealed. its the exact same thing. > Someone who likes most of the characteristics of the theme they're using > (which may be the default), but wants to tweak one or two things, will > apparently have to create an entire separate theme in order to do that - and > doing so will require learning the "theme language" or other syntax, whatever > that may be. And that's far less user-friendly than being able to simply > adjust the options in a configuration dialog. correct. this is actually doable. much more disable than if u dont like an aspect of the wm and u ask the developers to change it or u have to learn c. its much more accessible. it also opens up changes to be a nice selection of pre-made themes which come as packages looks and feels. a designer decides what they think is nice and makes it - if u don't like it - choose another. if you're ambitious - make your own. :) the alternative is pulling look and feel into code and code is much LESS modifiable than a theme is for most people. > I'm relatively technically competent, but even I don't "already know" how to > do that, and find the idea of having to do so something of a chore. A more > ordinary user is likely to be even more put off by this (or even unable to > understand the idea at all), but may well still legitimately want to tweak > things. > > I understand that there are probably technical reasons why it "works better", > in terms of maintainability and perhaps even of bigger-picture > customizability, to do it this way. But I still think that it's a bad > approach from a user-friendliness perspective. it's the same one E16 had - and E15, and E14.. all the way back to E01... if you love E16 but hate E17 your complaint is not with the approach. it's just with something unfamiliar that you haven't bothered learning, or that you never want to learn it, but it just doesn't happen to be a verbatim copy of what you already like. E17 is taking the design philosophy behind all previous E's and making it even more powerful and extensible with better design behind it and features. > >> I'll be honest: I don't see why *anyone* would actually want this "bounce" > >> behavior, at least to such an extreme degree. As such, I would think it > >> would be far better to have it disabled by default, if indeed present at > >> all. However, even if it is desired enough to justify its being the > >> default, the way to disable it needs to be far more obvious than it appears > >> to be. > > > > if you had updated e in the past we weeks > > Unfortunately, I'm running E17 from the Debian package, which means I'm > probably well further behind than that. The package version is > 0.16.999.70492-2, which probably means SVN revision 70492. (If you're using > SVN - for some reason my default expectation nowadays is for any random > project to be using git, even though I know most of them don't.) > > If I do end up getting into this, I will very likely start compiling from > current up-to-date source on a somewhat regular basis, at least for VM-based > testing purposes. > > > u'll notice default doesnt fade or wobble anymore - it only zooms+fades in > > and out on show/hide and has a shadow. but again - it always has been > > configurable so always fixable to whatever tickles your fancy. > > But only by manually editing the theme in a text editor, I presume? For your > "ordinary" user, I'm not remotely sure that that's good enough. yes - but this isn't code, and its the SAME as E16. if you didn't like the color of the titlebar in bluesteel - u'd have to edit the theme. exactly the same. :) > >> Beyond that, I think that the entire Effects tab needs to be much more > >> comprehensible, or at the very least to come with a pointer to > >> documentation - "if you don't understand this section of the configuration, > >> go read about it here". However, it does seem plausible that this lack > >> might be because Composite isn't complete or isn't "ready for prime time" > >> yet. > > > > why don't you just try select one and hit apply? "no - don't like that.. try > > another"... > > I may well do so, now that I understand that that's what is going on in that > settings window. Given the conflicting-assumptions-based confusion that was > going on initially, though, it didn't even occur to me that this might be > something to potentially be able to try; I was expecting the things listed in > the settings window to be editable, not simply selectable. its much simpler than u think it is. or thought it was. just select and try. :) > >> (None of that addresses the "memory footprint" and related arguments, which > >> do matter to me if only for reasons of principle, but I'm not planning to > >> argue that one in depth without trying to get some actual data to back > >> myself up with; it's entirely possible that my impression of E17's relative > >> resource usage is far out of sync with reality.) > > > > by moving compositing into corer we actually reduce memory footprint > > compared to it being in a module. we'll save at a MINIMUM 1x the size of > > your framebuffer (eg if 1920x1080 then that's 8mb). just to start. we'll > > save even more in reality (if using gl for compositing then something like > > about 16-18mb will get saved given the 1080p screen) and then when things > > like desklock appear we save an additional 8mb etc. for software compositing > > savings are a bit lower - 8-10mb normally with 8mb saved while desklock is > > up etc. > > You've gone into this in considerably more detail elsewhere, and my concerns > are well on their way to being relieved. Thank you. > > (FWIW, I'm running at 2650x1600, so the baseline savings would be rather > higher.) yup. it helps even more there. :) i wish i could find 2560x1600 monitors.. these days its 2560x1440 which is as good as it gets... and the bloody thing had a dead pixel on it! ( grrrrrr waiting for it to be fixed. > >> I have no real answers, however as best as I can tell, the first sheet on > >> the compositing options are preconfigured defaults. Every time I have used > >> the compositor, I just go to the options and select the "none" on the > >> default screen. This disables transparencies and the wobble. > >> > >> I do however also want to vote against "forcing" the compositor. > >> > >> It has never really worked for me, both performance wise, and random weird > >> graphical issue wise. > > I note that you actually replied to the message posted by Robert Krambovitis > (and the attribution above is somewhat screwed up as a result, due to the > nonstandard way his reply quoted me), but didn't say anything in direct > response to what he wrote; was that intentional? i was totally confused by who was saying what too - so i gave up and just replied to the text that looked like it was written by you :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Robert K. <ro...@sp...> - 2012-07-30 07:16:31
|
----- Original Message ----- From: "Carsten Haitzler" To: "Enlightenment users discussion & support" <enl...@li...> Sent: Monday, July 30, 2012 5:59:42 AM Subject: Re: [e-users] E16/E17 feature parity > >> I have no real answers, however as best as I can tell, the first sheet on > >> the compositing options are preconfigured defaults. Every time I have used > >> the compositor, I just go to the options and select the "none" on the > >> default screen. This disables transparencies and the wobble. > >> > >> I do however also want to vote against "forcing" the compositor. > >> > >> It has never really worked for me, both performance wise, and random weird > >> graphical issue wise. > > I note that you actually replied to the message posted by Robert Krambovitis > (and the attribution above is somewhat screwed up as a result, due to the > nonstandard way his reply quoted me), but didn't say anything in direct > response to what he wrote; was that intentional? i was totally confused by who was saying what too - so i gave up and just replied to the text that looked like it was written by you :) ------------------------------------------------------------------------------ My email client doesn't stick ">" in front of the replied text... Adding them myself would be retarded... Top posting is a no-no... Only real option I think is to stick text at end, or not reply at all... Sorry about the mess, |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-30 09:49:28
|
On Mon, 30 Jul 2012 10:16:19 +0300 (EEST) Robert Krambovitis <ro...@sp...> said: > ----- Original Message ----- > From: "Carsten Haitzler" > To: "Enlightenment users discussion & support" > <enl...@li...> Sent: Monday, July 30, 2012 > 5:59:42 AM Subject: Re: [e-users] E16/E17 feature parity > > > >> I have no real answers, however as best as I can tell, the first sheet on > > >> the compositing options are preconfigured defaults. Every time I have > > >> used the compositor, I just go to the options and select the "none" on > > >> the default screen. This disables transparencies and the wobble. > > >> > > >> I do however also want to vote against "forcing" the compositor. > > >> > > >> It has never really worked for me, both performance wise, and random > > >> weird graphical issue wise. > > > > I note that you actually replied to the message posted by Robert Krambovitis > > (and the attribution above is somewhat screwed up as a result, due to the > > nonstandard way his reply quoted me), but didn't say anything in direct > > response to what he wrote; was that intentional? > > i was totally confused by who was saying what too - so i gave up and just > replied to the text that looked like it was written by you :) > > ------------------------------------------------------------------------------ > > > My email client doesn't stick ">" in front of the replied text... > Adding them myself would be retarded... > Top posting is a no-no... > Only real option I think is to stick text at end, or not reply at all... > > Sorry about the mess, what email client do you use? hmmm your email clients say... zimbra webmail? just do top-posting. it's easier to handle if you don't use the >'s :) :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: The W. <wan...@fa...> - 2012-07-30 13:55:19
|
On 07/30/2012 03:16 AM, Robert Krambovitis wrote: > My email client doesn't stick ">" in front of the replied text... According to your headers, you're using Zimbra. According to http://www.zimbra.com/docs/user_guide/latest/wwhelp/wwhimpl/js/html/wwhelp.htm (for the Web client) and http://www.zimbra.com/desktop/help/en_US/reading_mail/replying_to_mail_messages.htm (for the desktop client), Zimbra can be configured to insert angle brackets when quoting, though it doesn't seem to be completely clear on how. > Adding them myself would be retarded... Why? I do it, when I have to use that sort of E-mail client (e.g. Outlook or GroupWise). It's a pain, yes, but IMO actually sending mail with that sort of quoting would be worse. > Top posting is a no-no... While true, it has the advantage that it doesn't risk confusion over attribution, at least not in the same way. I'm not entirely sure which of the two I'd prefer. > Only real option I think is to stick text at end, or not reply at all... > > Sorry about the mess, <shrug> It's not a huge deal, at least not in this context. -- 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 |
From: Robert K. <ro...@sp...> - 2012-07-30 17:41:16
|
----- Original Message ----- > From: "The Wanderer" > To: "Enlightenment users discussion & support" <enl...@li...> > Sent: Monday, July 30, 2012 4:55:10 PM > Subject: Re: [e-users] E16/E17 feature parity > > On 07/30/2012 03:16 AM, Robert Krambovitis wrote: > > > My email client doesn't stick ">" in front of the replied text... > > According to your headers, you're using Zimbra. > > According to > http://www.zimbra.com/docs/user_guide/latest/wwhelp/wwhimpl/js/html/wwhelp.htm > (for the Web client) and > http://www.zimbra.com/desktop/help/en_US/reading_mail/replying_to_mail_messages.htm > (for the desktop client), Zimbra can be configured to insert angle > brackets when > quoting, though it doesn't seem to be completely clear on how. > I didn't really look into the links you said, I just use the standard client behaviour. I have located the option, however it's global and will also affect my work emails. Ah well :) I personally prefer top posting :) Thx |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-31 06:46:30
|
On Mon, 30 Jul 2012 20:41:08 +0300 (EEST) Robert Krambovitis <ro...@sp...> said: > ----- Original Message ----- > > From: "The Wanderer" > > To: "Enlightenment users discussion & support" > > <enl...@li...> Sent: Monday, July 30, 2012 > > 4:55:10 PM Subject: Re: [e-users] E16/E17 feature parity > > > > On 07/30/2012 03:16 AM, Robert Krambovitis wrote: > > > > > My email client doesn't stick ">" in front of the replied text... > > > > According to your headers, you're using Zimbra. > > > > According to > > http://www.zimbra.com/docs/user_guide/latest/wwhelp/wwhimpl/js/html/wwhelp.htm > > (for the Web client) and > > http://www.zimbra.com/desktop/help/en_US/reading_mail/replying_to_mail_messages.htm > > (for the desktop client), Zimbra can be configured to insert angle > > brackets when > > quoting, though it doesn't seem to be completely clear on how. > > > > I didn't really look into the links you said, I just use the standard client > behaviour. I have located the option, however it's global and will also > affect my work emails. Ah well :) > I personally prefer top posting :) well top post then if u arent going to use >'s - i dont mind top posting. it saves a lot of scrolling, especially for short messages. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: The W. <wan...@fa...> - 2012-07-30 14:00:18
|
On 07/29/2012 10:59 PM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 29 Jul 2012 21:38:56 -0400 The Wanderer <wan...@fa...> said: > >> On 07/29/2012 07:50 PM, Carsten Haitzler (The Rasterman) wrote: >> ...I'll cut myself off there before I go off on what could turn out to be a >> complete tangent. You see, I'm still confused as to whether what's listed >> in the "Styles" tab are A: "global styles" which, if selected, will change >> the behavior of E17 as a whole, or B: "domain-specific styles" which will >> change the behavior of only the domain which they are assigned to (e.g., >> the "popup" style only affecting that pop-up "window list", et cetera). >> >> I think it's probably A, since B would seem to require being able to edit >> the style which is going to be applied (as opposed to just selecting it) - >> but if it's A, why do they seem to be named after these other existing >> elements? >> >> I'm quite sure it all makes sense from the perspective of someone who knows >> E17 inside and out, but it doesn't at first (or second or third) glance >> from mine. > > they were named this way because those elements of e are pre-configured to > use those styles. if u look at "apps, e, over, menus" u'll see a list of > things and that list is a list of "window matchers" that match a given > window to a style - u can select the style used fro that match. it's like > saying > > *.jpg -> be pink *.png -> be green *.gif -> be blue *.txt (except for A*) -> > be yellow everything else -> be gray > > the default style list is editing the "everything else" that isn't a specific > match. it's complicated because trying to use different compositing styles > for different windows etc. is a complicated setup to try and identify which > one is which. That makes sense given what I've learned since originally looking at this. I still think it would be helpful if this were more explicit in the settings UI itself, but I don't offhand have any suggestions of how to make it so. >>> choose the one u prefer. it shows it right there animated as a preview >>> visually so someone who is totally illiterate can even see what they do >>> :). ever tries just selecting one and seeing if u like it or not? >> >> No, because it wasn't obvious for some time that these could actually be >> "selected" (as opposed to "highlighted", which can have multiple meanings, >> including none at all) in any meaningful way. > > it's a list like all other lists in e. they all look the same - like lists, > with the selected item in a different color etc. :) like every list in every > widget set and app for the past few decades. :) Not like most others that I remember... but I can't point out how off the top of my head. Barring further re-investigation, I'll have to concede that most likely my expectations of "there must be some what to edit this from here" got in the way. (Hmm. Any chance of a way to trigger some sort of "theme editor", e.g. a custom-purpose IDE specialized for E17 themes, from the relevant parts of the GUI? Presumably it would default to creating a new theme with all the same settings as the current one except for whatever was changed, rather than editing the current theme under your feet and risking fatal breakage. That would definitely have helped with my confusion, and would help with my other objections as well. You would still need to know the relevant syntax in order to edit the theme, but at least you could get at it from the relevant parts of the GUI, and that in turn means that there would be an indication in the GUI of where to go to actually change the settings.) >> In addition, the animated previews are so small, and so very similar to one >> another (at least in the default theme and configuration), that I didn't >> even notice at first that they weren't all displaying exactly the same >> thing. (I think most of them *do* display the exact same thing in at least >> some of the "phases" of the animation, which only exacerbates the problem.) > > they are every similar because the compositor style affects just the > shadowing and animation when showing, hiding, or going in and out of focus, > thus its cycling between these to show you. Yes, I figured that out, mostly. However, the fact remains that because they're so small (and because of the delay between any actual changes, since I believe at least a couple of them are literally identical except for one single point), seeing what the differences are is still difficult. I honestly haven't actually managed to see any differences among them except for the fact that the first one shows the "bounce" I was objecting to, and the second (like, I think, all of the others) does not. >> I think the main problem was that I came to this window expecting to be >> able to actually configure the visual results which would be displayed, >> when what it appears to be intended to do instead is to let you switch >> among a set of pre-configured profiles defined by the theme. > > if you knew how edje works - you'd realize this isnt possible or how it > works. Almost certainly true. However, that's part of the user-unfriendliness of it; not everyone coming to E and wanting to change the configuration is necessarily going to be familiar with how the internals work, nor should they need to be. > it's not a profile with just a bunch of boolean checkboxes on or off with the > wobble, fade, zoom etc. pre-built in effects. its like a html/css thing - > where the whole effect is a pre-made website. u dont like the design? well > write some css of your own. too hard? well live with the limited set of css's > provided with the previews. :) And from a design perspective, that's not unreasonable - nor is it terribly unreasonable, past a certain point, when well enough explained. However, as far as I can see it is *not* explained anywhere in the WM itself, nor is the user given any reason to expect the "Composite Settings" dialog to be different from any of the other settings dialogs - and yet, in all of the others individual settings can be changed individually, whereas here you can only switch among groups of pre-defined settings (without even getting to see what they all are, short of making the switch). >> That's far less accessible and usable for anyone who wants to do actual >> hands-on configuration, and is different from any of the other E17 >> configuration dialogs I've seen; all of the others seem to let you change >> options directly, rather than just choosing among sets of predefined >> options. > > but its not how its implemented. it saves us lots of code in the wm to do it > this way AND makes it massively more flexible as someone can design a new > animation and look without ever editing a single line of code. I recognize and acknowledge the high-end customizability advantages of this arrangement. I just don't think it's sufficiently well conveyed to prevent people from reasonably having other expectations, and thus being frustrated when those expectations are not met. (A lot does depend, of course, on how easy it is to manually tweak a theme. For many people, having to use a text editor to do it will be absolutely prohibitive, but that doesn't apply to me directly; how readily comprehensible - and therefore easily editable - the theme-definition files are is a much more important matter.) >> If nothing else, I think it would be helpful to be able to see - for any >> given "style" - exactly what settings are being applied, even if you can't >> change them. It wouldn't have been enough to satisfy me given what I went >> in there expecting, but it would be more useful, and it might have been >> enough to give me the hint of what was actually going on. > > there are no "settings" like u think there are. it's showing you visually by > literally running through the scenarios and "emitting" events to the object > and letting it react as it sees fit. its reactions to such events are > basically like script - they are not options of "wobble on/off" "fade on/off" > etc. ...but then how does the theme define these? Unless it actually includes its own (presumably E-specific) code to produce these effects, it must be drawing on pre-coded things that E can already do, and just telling E when and where to do them... and it would seem to me that, having parsed the theme files and figured out what things the theme is telling it to do, E should be able to report to the user what those things are. And if there really *is* actual graphics-processing code in the theme (to provide things like that "bounce"), as opposed to in E itself, then there's absolutely no way the theme definition files (which would therefore include that code) can be easily understandable and editable. >> I'm probably going to *have* to create my own theme, if only because there >> doesn't seem to be a BlueSteel analogue for E17 yet. However, I do find >> this a bit... user-unfriendly. > > e16 was the same - u have to make a theme if u didn't like bluesteel and > nothing else appealed. its the exact same thing. Except that in E16, as far as I've seen over years of using it, the properties affected by a theme were limited to: * Window decorations. * Colors of WM elements (e.g., the pager, and desktop menus). * "System default" colors (for fallback use by other programs). * Default backgrounds (which can be overridden if you want to). In other words, just a set of color definitions, and a few relatively small image files. In E17, from what I've seen so far, a theme apparently affects one hell of a lot more than that. >> Someone who likes most of the characteristics of the theme they're using >> (which may be the default), but wants to tweak one or two things, will >> apparently have to create an entire separate theme in order to do that - >> and doing so will require learning the "theme language" or other syntax, >> whatever that may be. And that's far less user-friendly than being able to >> simply adjust the options in a configuration dialog. > > correct. this is actually doable. much more disable than if u dont like an > aspect of the wm and u ask the developers to change it or u have to learn c. > its much more accessible. it also opens up changes to be a nice selection of > pre-made themes which come as packages looks and feels. a designer decides > what they think is nice and makes it - if u don't like it - choose another. > if you're ambitious - make your own. :) the alternative is pulling look and > feel into code and code is much LESS modifiable than a theme is for most > people. True, pulling these elements into code is less modifiable than putting them into a text-editable theme file. But requiring you to open up a theme file (located where? how does the user even find out where the files for the current theme are?) in a text editor to make any changes is significantly less accessible and convenient than making it possible to make those changes through the GUI. Now, I'm not a GUI sort of person much myself; aside from Web browsing and E-mail, I use X mainly as a means of switching among xterms. But if you're going to do most of your configuration through the GUI (which E17 certainly does seem to), requiring people to jump out of it for one particular area of configuration is at the very least going to be unexpected. Providing a much more explicit heads-up in the GUI itself that "you can't customize everything through this GUI, you'll have to manually modify the theme in a text editor" would at least preclude some of that potential confusion. >> I'm relatively technically competent, but even I don't "already know" how >> to do that, and find the idea of having to do so something of a chore. A >> more ordinary user is likely to be even more put off by this (or even >> unable to understand the idea at all), but may well still legitimately want >> to tweak things. >> >> I understand that there are probably technical reasons why it "works >> better", in terms of maintainability and perhaps even of bigger-picture >> customizability, to do it this way. But I still think that it's a bad >> approach from a user-friendliness perspective. > > it's the same one E16 had - and E15, and E14.. all the way back to E01... if > you love E16 but hate E17 your complaint is not with the approach. it's just > with something unfamiliar that you haven't bothered learning, or that you > never want to learn it, but it just doesn't happen to be a verbatim copy of > what you already like. E17 is taking the design philosophy behind all > previous E's and making it even more powerful and extensible with better > design behind it and features. ...I'm sorry; aside from manual menu editing, when did E16 ever require you to use a text editor (or anything other than the GUI) to change interface elements? Yes, you had to use a text editor to modify a theme - but given how relatively few things the theme actually controlled (and the large number of existing available themes), actually doing that never felt mandatory. Given how much seems to have been moved into the theme with E17, I'm not sure that hasn't changed. (The accusation that I may just be wanting a verbatim copy of what I already like may not be unfounded. However, I'm trying to be open-minded, and to consider alternate ways of achieving the same goal. I'm quite willing to listen to counters to my objections, but I reserve the right to maintain those objections where I feel they remain valid.) >>> u'll notice default doesnt fade or wobble anymore - it only zooms+fades >>> in and out on show/hide and has a shadow. but again - it always has been >>> configurable so always fixable to whatever tickles your fancy. >> >> But only by manually editing the theme in a text editor, I presume? For >> your "ordinary" user, I'm not remotely sure that that's good enough. > > yes - but this isn't code, and its the SAME as E16. if you didn't like the > color of the titlebar in bluesteel - u'd have to edit the theme. exactly the > same. :) Except that, since more things have been moved into the theme than were in it in E16, the theme seems to have a significantly broader reach. I never had to go beyond the GUI to change the window-manager *behavior* in E16, just certain limited elements of its appearance. (I do consider things like that "bounce" to be the former, not the latter.) I don't know exactly how far the theme's control does reach in E17, but I think that just what I've seen so far is enough to be a significant difference. >> (FWIW, I'm running at 2650x1600, so the baseline savings would be rather >> higher.) > > yup. it helps even more there. :) i wish i could find 2560x1600 monitors.. > these days its 2560x1440 which is as good as it gets... and the bloody thing > had a dead pixel on it! ( grrrrrr waiting for it to be fixed. You have my sympathies. Mine is a Dell UltraSharp 3008WFP. Cost me $1700 with tax and shipping, but I haven't regretted it yet; last time I checked, it was still the absolute top-end monitor on the market. (That exact model may not be available anymore, but its close siblings are still on the market AFAIK.) >> I note that you actually replied to the message posted by Robert >> Krambovitis (and the attribution above is somewhat screwed up as a result, >> due to the nonstandard way his reply quoted me), but didn't say anything in >> direct response to what he wrote; was that intentional? > > i was totally confused by who was saying what too - so i gave up and just > replied to the text that looked like it was written by you :) You got it right, fortunately, just in the wrong message. ^_^ -- 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-31 06:46:21
|
On Mon, 30 Jul 2012 10:00:06 -0400 The Wanderer <wan...@fa...> said: > On 07/29/2012 10:59 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Sun, 29 Jul 2012 21:38:56 -0400 The Wanderer <wan...@fa...> said: > > > >> On 07/29/2012 07:50 PM, Carsten Haitzler (The Rasterman) wrote: > > >> ...I'll cut myself off there before I go off on what could turn out to be a > >> complete tangent. You see, I'm still confused as to whether what's listed > >> in the "Styles" tab are A: "global styles" which, if selected, will change > >> the behavior of E17 as a whole, or B: "domain-specific styles" which will > >> change the behavior of only the domain which they are assigned to (e.g., > >> the "popup" style only affecting that pop-up "window list", et cetera). > >> > >> I think it's probably A, since B would seem to require being able to edit > >> the style which is going to be applied (as opposed to just selecting it) - > >> but if it's A, why do they seem to be named after these other existing > >> elements? > >> > >> I'm quite sure it all makes sense from the perspective of someone who knows > >> E17 inside and out, but it doesn't at first (or second or third) glance > >> from mine. > > > > they were named this way because those elements of e are pre-configured to > > use those styles. if u look at "apps, e, over, menus" u'll see a list of > > things and that list is a list of "window matchers" that match a given > > window to a style - u can select the style used fro that match. it's like > > saying > > > > *.jpg -> be pink *.png -> be green *.gif -> be blue *.txt (except for A*) -> > > be yellow everything else -> be gray > > > > the default style list is editing the "everything else" that isn't a > > specific match. it's complicated because trying to use different > > compositing styles for different windows etc. is a complicated setup to try > > and identify which one is which. > > That makes sense given what I've learned since originally looking at this. I > still think it would be helpful if this were more explicit in the settings UI > itself, but I don't offhand have any suggestions of how to make it so. other than moving code out of theme into the wm, which just adds to our workload and removes power from designers, there isn't much to be done. it's a choice to put it into edje because edje is design TO do these things. > >>> choose the one u prefer. it shows it right there animated as a preview > >>> visually so someone who is totally illiterate can even see what they do > >>> :). ever tries just selecting one and seeing if u like it or not? > >> > >> No, because it wasn't obvious for some time that these could actually be > >> "selected" (as opposed to "highlighted", which can have multiple meanings, > >> including none at all) in any meaningful way. > > > > it's a list like all other lists in e. they all look the same - like lists, > > with the selected item in a different color etc. :) like every list in every > > widget set and app for the past few decades. :) > > Not like most others that I remember... but I can't point out how off the top > of my head. > > Barring further re-investigation, I'll have to concede that most likely my > expectations of "there must be some what to edit this from here" got in the > way. they did. in e17 lots of things moved to abstracted layers and libraries totally outside of the wm. edje is one of these. > (Hmm. Any chance of a way to trigger some sort of "theme editor", e.g. a > custom-purpose IDE specialized for E17 themes, from the relevant parts of the > GUI? Presumably it would default to creating a new theme with all the same > settings as the current one except for whatever was changed, rather than > editing the current theme under your feet and risking fatal breakage. good luck - making an edje editor or theme editor is a mountain of work. think something approaching the scale of gimp or inkscape - ok not quite, but its much more in that ballpark. i assume u are driving at a gui edje editor... if its just editing the text... just what changed - u can do just that. make a theme that only provides the modified things u want to change and select that as your theme. it'll overlay on default (elm is better at this fyi - we'll make e better at layering). you can run e in xephyr and try it out there if u like - i don't see why we need to do that for u - we already wrote scripts for u to run xephyr and e17 inside of it... it's there in the e src tree. > That would definitely have helped with my confusion, and would help with my > other objections as well. You would still need to know the relevant syntax in > order to edit the theme, but at least you could get at it from the relevant > parts of the GUI, and that in turn means that there would be an indication in > the GUI of where to go to actually change the settings.) > > >> In addition, the animated previews are so small, and so very similar to one > >> another (at least in the default theme and configuration), that I didn't > >> even notice at first that they weren't all displaying exactly the same > >> thing. (I think most of them *do* display the exact same thing in at least > >> some of the "phases" of the animation, which only exacerbates the problem.) > > > > they are every similar because the compositor style affects just the > > shadowing and animation when showing, hiding, or going in and out of focus, > > thus its cycling between these to show you. > > Yes, I figured that out, mostly. However, the fact remains that because > they're so small (and because of the delay between any actual changes, since > I believe at least a couple of them are literally identical except for one > single point), seeing what the differences are is still difficult. > > I honestly haven't actually managed to see any differences among them except > for the fact that the first one shows the "bounce" I was objecting to, and the > second (like, I think, all of the others) does not. others do or dont have a shadow, others dont fade out on losing focus. others zoom in from the top (menu style) others zoom out to begin with, etc. their names are where they are currently used - eg for menus, or for popups or for everything etc. but in t he time taken to writs just this paragraph you could have tired out every style there and messed with it to see which one u like. :) (select, apply - mess, select, apply - mess, etc.) > >> I think the main problem was that I came to this window expecting to be > >> able to actually configure the visual results which would be displayed, > >> when what it appears to be intended to do instead is to let you switch > >> among a set of pre-configured profiles defined by the theme. > > > > if you knew how edje works - you'd realize this isnt possible or how it > > works. > > Almost certainly true. However, that's part of the user-unfriendliness of it; > not everyone coming to E and wanting to change the configuration is > necessarily going to be familiar with how the internals work, nor should they > need to be. then you get5 the pre-packaged looks made for u. thats what themes (edje files) are. they are pre-made and packaged sets of look (ui/theme/layout/animation) that you select from. this is central to how e17 nd beyond work. > > it's not a profile with just a bunch of boolean checkboxes on or off with > > the wobble, fade, zoom etc. pre-built in effects. its like a html/css thing > > - where the whole effect is a pre-made website. u dont like the design? well > > write some css of your own. too hard? well live with the limited set of > > css's provided with the previews. :) > > And from a design perspective, that's not unreasonable - nor is it terribly > unreasonable, past a certain point, when well enough explained. However, as > far as I can see it is *not* explained anywhere in the WM itself, nor is the you read documentation? what? *GASP*... you're like the first user in YEARS i have encountered who reads docs! :) seriously though - we have written docs before. lots of them. only to have them never be read and users complain/ask anyway. i gave up documenting things as a result. > user given any reason to expect the "Composite Settings" dialog to be > different from any of the other settings dialogs - and yet, in all of the > others individual settings can be changed individually, whereas here you can > only switch among groups of pre-defined settings (without even getting to see > what they all are, short of making the switch). its the same. the theme selector dialog works the same. wallpaper selector. the profile selector... i can go on. its the same as these. its the same list there too. same styling and functionality. you select 1 item in the list. it has a preview of it as an "icon' on the left. > >> That's far less accessible and usable for anyone who wants to do actual > >> hands-on configuration, and is different from any of the other E17 > >> configuration dialogs I've seen; all of the others seem to let you change > >> options directly, rather than just choosing among sets of predefined > >> options. > > > > but its not how its implemented. it saves us lots of code in the wm to do it > > this way AND makes it massively more flexible as someone can design a new > > animation and look without ever editing a single line of code. > > I recognize and acknowledge the high-end customizability advantages of this > arrangement. I just don't think it's sufficiently well conveyed to prevent > people from reasonably having other expectations, and thus being frustrated > when those expectations are not met. > > (A lot does depend, of course, on how easy it is to manually tweak a theme. > For many people, having to use a text editor to do it will be absolutely > prohibitive, but that doesn't apply to me directly; how readily > comprehensible - and therefore easily editable - the theme-definition files > are is a much more important matter.) the expectation is - u'll take a theme as-is - if u want to tweak it, learn edje or talk to the designer of the theme. themes are pre-packaged looks all done already and compiled into a compact binary file. > >> If nothing else, I think it would be helpful to be able to see - for any > >> given "style" - exactly what settings are being applied, even if you can't > >> change them. It wouldn't have been enough to satisfy me given what I went > >> in there expecting, but it would be more useful, and it might have been > >> enough to give me the hint of what was actually going on. > > > > there are no "settings" like u think there are. it's showing you visually by > > literally running through the scenarios and "emitting" events to the object > > and letting it react as it sees fit. its reactions to such events are > > basically like script - they are not options of "wobble on/off" "fade > > on/off" etc. > > ...but then how does the theme define these? Unless it actually includes its > own (presumably E-specific) code to produce these effects, it must be drawing > on pre-coded things that E can already do, and just telling E when and where > to do them... and it would seem to me that, having parsed the theme files and > figured out what things the theme is telling it to do, E should be able to > report to the user what those things are. E doesnt do these. Edje does. edje is a library - separate from e. it hides all these details. e never knows what the theme does. al it knows is "i place the client window in this slot and i send it a signal like "show" or "hide" or "focused" or "unfocused" ". that's it. everything else inside is hidden by edje. it's meant to be hidden. it's opaque to those that use the file SO that you can flexibily design anything u like except for a few specific attributes that are expected of you (eg to respond to specific signals). WHAt you do to respond is basically script (or a sequence of basic events chained to eachother that modify the state of something - eg the wobble is done by 5 states chained so u transition to the first state (bigger by 20 pixels) then over N time to the next state (smaller by 10 pixels), then over M time to the next state (bigger by 5 pixels) then over O time to "smaller by 2 pixels) then over P time to the final correct size. E has no clue this is going on. it just says "focus" ands then the theme goes off on this little event chain path on its own to do the wobble. The same for fade in and out and zoom to show or hide etc. a designer could wobble as above,, or wobble with rotation, zoom and rotate, zoom + flip in 3d and rotate. they could make little pink unicorns run around the edges of your window instead and have sparkly rainbows flowing from the titlebar. E has no clue what the ejde object is doing - it could do just about anything a designer can imagine. > And if there really *is* actual graphics-processing code in the theme (to > provide things like that "bounce"), as opposed to in E itself, then there's > absolutely no way the theme definition files (which would therefore include > that code) can be easily understandable and editable. it seems designers manage it. they more resemble css stuff + some javascript and some html bits (then some stuff these dont even have). these are understandable and editable. edc (the source of edje files) is too. > >> I'm probably going to *have* to create my own theme, if only because there > >> doesn't seem to be a BlueSteel analogue for E17 yet. However, I do find > >> this a bit... user-unfriendly. > > > > e16 was the same - u have to make a theme if u didn't like bluesteel and > > nothing else appealed. its the exact same thing. > > Except that in E16, as far as I've seen over years of using it, the properties > affected by a theme were limited to: > > * Window decorations. > * Colors of WM elements (e.g., the pager, and desktop menus). > * "System default" colors (for fallback use by other programs). > * Default backgrounds (which can be overridden if you want to). > > In other words, just a set of color definitions, and a few relatively small > image files. > > In E17, from what I've seen so far, a theme apparently affects one hell of a > lot more than that. yup. themes are now very powerful beasties. given enough imagination, effort on the art and design and the edje file work you can make E17 totally different to the point you wont recognise it as E17. themes now handle a hell of a lot of stuff. > >> Someone who likes most of the characteristics of the theme they're using > >> (which may be the default), but wants to tweak one or two things, will > >> apparently have to create an entire separate theme in order to do that - > >> and doing so will require learning the "theme language" or other syntax, > >> whatever that may be. And that's far less user-friendly than being able to > >> simply adjust the options in a configuration dialog. > > > > correct. this is actually doable. much more disable than if u dont like an > > aspect of the wm and u ask the developers to change it or u have to learn c. > > its much more accessible. it also opens up changes to be a nice selection of > > pre-made themes which come as packages looks and feels. a designer decides > > what they think is nice and makes it - if u don't like it - choose another. > > if you're ambitious - make your own. :) the alternative is pulling look and > > feel into code and code is much LESS modifiable than a theme is for most > > people. > > True, pulling these elements into code is less modifiable than putting them > into a text-editable theme file. > > But requiring you to open up a theme file (located where? how does the user > even find out where the files for the current theme are?) in a text editor to > make any changes is significantly less accessible and convenient than making > it possible to make those changes through the GUI. > > Now, I'm not a GUI sort of person much myself; aside from Web browsing and > E-mail, I use X mainly as a means of switching among xterms. But if you're > going to do most of your configuration through the GUI (which E17 certainly > does seem to), requiring people to jump out of it for one particular area of > configuration is at the very least going to be unexpected. when its in the theme - its intended that way. it's meant to be a DEISGNED unit. when its DESIGNED... its an edje file. E doesn't go giving u "checkboxes" for it as none exist. > Providing a much more explicit heads-up in the GUI itself that "you can't > customize everything through this GUI, you'll have to manually modify the > theme in a text editor" would at least preclude some of that potential > confusion. i don't see how to do this cleanly other than simply it not being there. > >> I'm relatively technically competent, but even I don't "already know" how > >> to do that, and find the idea of having to do so something of a chore. A > >> more ordinary user is likely to be even more put off by this (or even > >> unable to understand the idea at all), but may well still legitimately want > >> to tweak things. > >> > >> I understand that there are probably technical reasons why it "works > >> better", in terms of maintainability and perhaps even of bigger-picture > >> customizability, to do it this way. But I still think that it's a bad > >> approach from a user-friendliness perspective. > > > > it's the same one E16 had - and E15, and E14.. all the way back to E01... if > > you love E16 but hate E17 your complaint is not with the approach. it's just > > with something unfamiliar that you haven't bothered learning, or that you > > never want to learn it, but it just doesn't happen to be a verbatim copy of > > what you already like. E17 is taking the design philosophy behind all > > previous E's and making it even more powerful and extensible with better > > design behind it and features. > > ...I'm sorry; aside from manual menu editing, when did E16 ever require you to > use a text editor (or anything other than the GUI) to change interface > elements? ever since. since i designed e16's theme setup - you needed to edit theme text fiels to change the images used for titlebars, and colors of text etc. etc. you complain u need to use a solid color image for wallpaper, but u DONT complain u cant change the color or font of title text. or color of the titlebar when selected (in the gui) etc. etc. > Yes, you had to use a text editor to modify a theme - but given how relatively > few things the theme actually controlled (and the large number of existing > available themes), actually doing that never felt mandatory. Given how much > seems to have been moved into the theme with E17, I'm not sure that hasn't > changed. see above. e17 allows u to change color of these (via colorclasses) AND fonts without editing a theme (edje support an indirection mechanism via classes). as i said. E17 is a different wm. it draws the line in the sand differently. that's how it works when u write a new piece of software. :) > (The accusation that I may just be wanting a verbatim copy of what I already > like may not be unfounded. However, I'm trying to be open-minded, and to > consider alternate ways of achieving the same goal. I'm quite willing to > listen to counters to my objections, but I reserve the right to maintain those > objections where I feel they remain valid.) sure! and i don't see a problem with wanting "what u already have" you have it - keep using it. don't change to e17. that's fine. but be aware - development is coming to a close on E16 - it wont change or advance anymore. you're on your own there. :) you either do what i did - and learn something (i learned c and xlib in order to be able to write a wm because i disliked the ones there) and pick up work on e16, or you move on. :) moving on will necessitate adapting to change. in this case e17 is vastly different and ins almost all ways, it is vastly better. the few things that can't be done in e17 that can be in e16 are few .. and far between and imho that's a pretty good achievement given the amount of new code, design and libraries made for this project. think of it this way. we've gone and parked a new rover on mars, launched from earth... and you're complaining that the tires are blue, not black. :) well that's what they sound like. :) i'm looking at all the work gone into getting a robot rover built, made to be autonomous, get it off the planet earth and sent all the way to mars, landed safely and doing its job really well with more features than any previous mission to the moon (e16) was, and the problem is the tires are blue. :) > >>> u'll notice default doesnt fade or wobble anymore - it only zooms+fades > >>> in and out on show/hide and has a shadow. but again - it always has been > >>> configurable so always fixable to whatever tickles your fancy. > >> > >> But only by manually editing the theme in a text editor, I presume? For > >> your "ordinary" user, I'm not remotely sure that that's good enough. > > > > yes - but this isn't code, and its the SAME as E16. if you didn't like the > > color of the titlebar in bluesteel - u'd have to edit the theme. exactly the > > same. :) > > Except that, since more things have been moved into the theme than were in it > in E16, the theme seems to have a significantly broader reach. > > I never had to go beyond the GUI to change the window-manager *behavior* in > E16, just certain limited elements of its appearance. (I do consider things > like that "bounce" to be the former, not the latter.) I don't know exactly > how far the theme's control does reach in E17, but I think that just what > I've seen so far is enough to be a significant difference. *behaviour* still is governed by code. ANIMATION is mostly not. its governed by theme. i consider bounce to be theme - to be skin. its fluff. animation. its not core behaviour. i guess this is a fundamental issue here. animations i consider fluff and not behaviour. thus theme handles these. it's part of the look and goes along with skin and coloring etc. > >> (FWIW, I'm running at 2650x1600, so the baseline savings would be rather > >> higher.) > > > > yup. it helps even more there. :) i wish i could find 2560x1600 monitors.. > > these days its 2560x1440 which is as good as it gets... and the bloody thing > > had a dead pixel on it! ( grrrrrr waiting for it to be fixed. > > You have my sympathies. > > Mine is a Dell UltraSharp 3008WFP. Cost me $1700 with tax and shipping, but I > haven't regretted it yet; last time I checked, it was still the absolute > top-end monitor on the market. (That exact model may not be available > anymore, but its close siblings are still on the market AFAIK.) well i'm tired of my screen being hot (glowing heat in my face). led backlit ones are much cooler, so i thought i'd upgrade... damned dead pixel. > >> I note that you actually replied to the message posted by Robert > >> Krambovitis (and the attribution above is somewhat screwed up as a result, > >> due to the nonstandard way his reply quoted me), but didn't say anything in > >> direct response to what he wrote; was that intentional? > > > > i was totally confused by who was saying what too - so i gave up and just > > replied to the text that looked like it was written by you :) > > You got it right, fortunately, just in the wrong message. ^_^ yeah. :) btw - don't take this debate as a bad thing. it's good. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: David S. <on...@gm...> - 2012-07-31 07:16:21
|
I'll jump into this thread now, but cut out all the verbiage, just want to make a simple point. Wanderer is correct about how hard the composite settings are to use. I've been an e17 and EFL developer for many years, and I have no clue what almost all of the stuff in that settings dialog does. Shadows and maybe smooth scaling is about all the average user will make sense of, the rest is entirely meaningless, even to experienced developers like me. It's easy for raster to say "just try them", but there's six panes with 22 controls, not counting the first panes sub pane. That sub pane has five panes itself, each with a list, and all but one with five buttons. I wont go into all the panes with controls when you hit one of the edit/add buttons. That's one scary big lot of options (tens of millions of combinations, not counting sliders, the sub pane, and the edit options), 99% of which are completely meaningless to your average user. 98% are completely meaningless to your average E17 developer. Most people will open that up, say WTF, then close it and think it's all too hard. Exactly what Wanderer did, and he seems to be a more advanced user. No one can even tell which particular small number of things they should "just try". Nothing about that settings dialog is easy, except to raster. Well, OK, "Shadows" is easy, the rest is scary complicated. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-31 08:27:37
|
On Tue, 31 Jul 2012 17:16:38 +1000 David Seikel <on...@gm...> said: he's complaining about lack of features in e17 vs e16... and the comp dialog hasnt split advanced vs basic - its all advanced. all options there. > I'll jump into this thread now, but cut out all the verbiage, just want > to make a simple point. Wanderer is correct about how hard the > composite settings are to use. I've been an e17 and EFL developer for > many years, and I have no clue what almost all of the stuff in that > settings dialog does. Shadows and maybe smooth scaling is about all the > average user will make sense of, the rest is entirely meaningless, even > to experienced developers like me. > > It's easy for raster to say "just try them", but there's six panes with > 22 controls, not counting the first panes sub pane. That sub pane has > five panes itself, each with a list, and all but one with five > buttons. I wont go into all the panes with controls when you hit one > of the edit/add buttons. That's one scary big lot of options (tens of > millions of combinations, not counting sliders, the sub pane, and the > edit options), 99% of which are completely meaningless to your average > user. 98% are completely meaningless to your average E17 developer. > Most people will open that up, say WTF, then close it and think it's > all too hard. Exactly what Wanderer did, and he seems to be a more > advanced user. > > No one can even tell which particular small number of things they > should "just try". Nothing about that settings dialog is easy, except > to raster. Well, OK, "Shadows" is easy, the rest is scary complicated. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > 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... |
From: David S. <on...@gm...> - 2012-07-31 08:34:29
|
On Tue, 31 Jul 2012 17:27:27 +0900 Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > On Tue, 31 Jul 2012 17:16:38 +1000 David Seikel <on...@gm...> > said: > > he's complaining about lack of features in e17 vs e16... and the comp > dialog hasnt split advanced vs basic - its all advanced. all options > there. The composite settings dialog is just one of the things he brought up in this thread, but I don't think there was one in e16, so E16 is irrelevant to this part of the conversation. It's not advanced, it's so far past advanced it's silly. That's my point. Even advanced users can't use it. > > I'll jump into this thread now, but cut out all the verbiage, just > > want to make a simple point. Wanderer is correct about how hard the > > composite settings are to use. I've been an e17 and EFL developer > > for many years, and I have no clue what almost all of the stuff in > > that settings dialog does. Shadows and maybe smooth scaling is > > about all the average user will make sense of, the rest is entirely > > meaningless, even to experienced developers like me. > > > > It's easy for raster to say "just try them", but there's six panes > > with 22 controls, not counting the first panes sub pane. That sub > > pane has five panes itself, each with a list, and all but one with > > five buttons. I wont go into all the panes with controls when you > > hit one of the edit/add buttons. That's one scary big lot of > > options (tens of millions of combinations, not counting sliders, > > the sub pane, and the edit options), 99% of which are completely > > meaningless to your average user. 98% are completely meaningless to > > your average E17 developer. Most people will open that up, say WTF, > > then close it and think it's all too hard. Exactly what Wanderer > > did, and he seems to be a more advanced user. > > > > No one can even tell which particular small number of things they > > should "just try". Nothing about that settings dialog is easy, > > except to raster. Well, OK, "Shadows" is easy, the rest is scary > > complicated. > > > > -- > > A big old stinking pile of genius that no one wants > > coz there are too many silver coated monkeys in the world. > > > > ------------------------------------------------------------------------------ > > 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 > > > > -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-31 09:57:45
|
On Tue, 31 Jul 2012 18:34:43 +1000 David Seikel <on...@gm...> said: > On Tue, 31 Jul 2012 17:27:27 +0900 Carsten Haitzler (The Rasterman) > <ra...@ra...> wrote: > > > On Tue, 31 Jul 2012 17:16:38 +1000 David Seikel <on...@gm...> > > said: > > > > he's complaining about lack of features in e17 vs e16... and the comp > > dialog hasnt split advanced vs basic - its all advanced. all options > > there. > > The composite settings dialog is just one of the things he brought up in > this thread, but I don't think there was one in e16, so E16 is > irrelevant to this part of the conversation. > > It's not advanced, it's so far past advanced it's silly. That's my > point. Even advanced users can't use it. then don't touch what u don't understand. those settings exist because that's how comp works. several of them exist due to faults in drivers and for fine tuning optimizations. if you don't know - then don't touch. > > > I'll jump into this thread now, but cut out all the verbiage, just > > > want to make a simple point. Wanderer is correct about how hard the > > > composite settings are to use. I've been an e17 and EFL developer > > > for many years, and I have no clue what almost all of the stuff in > > > that settings dialog does. Shadows and maybe smooth scaling is > > > about all the average user will make sense of, the rest is entirely > > > meaningless, even to experienced developers like me. > > > > > > It's easy for raster to say "just try them", but there's six panes > > > with 22 controls, not counting the first panes sub pane. That sub > > > pane has five panes itself, each with a list, and all but one with > > > five buttons. I wont go into all the panes with controls when you > > > hit one of the edit/add buttons. That's one scary big lot of > > > options (tens of millions of combinations, not counting sliders, > > > the sub pane, and the edit options), 99% of which are completely > > > meaningless to your average user. 98% are completely meaningless to > > > your average E17 developer. Most people will open that up, say WTF, > > > then close it and think it's all too hard. Exactly what Wanderer > > > did, and he seems to be a more advanced user. > > > > > > No one can even tell which particular small number of things they > > > should "just try". Nothing about that settings dialog is easy, > > > except to raster. Well, OK, "Shadows" is easy, the rest is scary > > > complicated. > > > > > > -- > > > A big old stinking pile of genius that no one wants > > > coz there are too many silver coated monkeys in the world. > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > > > > > > > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > 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... |
From: David S. <on...@gm...> - 2012-07-31 10:30:16
|
On Tue, 31 Jul 2012 18:52:56 +0900 Carsten Haitzler (The Rasterman) <ra...@ra...> wrote: > On Tue, 31 Jul 2012 18:34:43 +1000 David Seikel <on...@gm...> > said: > > > On Tue, 31 Jul 2012 17:27:27 +0900 Carsten Haitzler (The Rasterman) > > <ra...@ra...> wrote: > > > > > On Tue, 31 Jul 2012 17:16:38 +1000 David Seikel > > > <on...@gm...> said: > > > > > > he's complaining about lack of features in e17 vs e16... and the > > > comp dialog hasnt split advanced vs basic - its all advanced. all > > > options there. > > > > The composite settings dialog is just one of the things he brought > > up in this thread, but I don't think there was one in e16, so E16 is > > irrelevant to this part of the conversation. > > > > It's not advanced, it's so far past advanced it's silly. That's my > > point. Even advanced users can't use it. > > then don't touch what u don't understand. those settings exist > because that's how comp works. several of them exist due to faults in > drivers and for fine tuning optimizations. if you don't know - then > don't touch. Which is the exact opposite of the advice you gave to "just try it and see". You can't have both. I'm pointing out that those parts you are saying to "just try it and see" are just as hard to figure out as the parts you are now saying "don't touch what you don't understand". No one understands any parts of it, this is the problem. That dialog really needs a major overhaul, and it seems that the only people that understand enough of it to do that overhaul are the people that wrote it. This makes it almost entirely useless for every one else. Face it raster, it's a raster only settings dialog, and you can't tell people "just try it and see" and also tell them "don't touch what you don't understand". Coz they don't understand any of it, and are telling you they don't understand any of it. You just can't have it both ways raster. I can see that there are parts that MIGHT be easy to understand if only they where done a little differently, but I can only see that after some experimentation and what you have described here. If a very experienced E17 developer does not understand it, then the 99.9999% of people that are less experienced non-E17 developers have no hope in hell, and it might as well not be there. It needs work, plain and simple. I suggest a basic dialog, which would likely be just "Shadows". Then an advanced dialog which might be "choose stuff from the current theme", though perhaps if that was actually easy to understand (it isn't now) then it could go into "Basic". Then a "fix faulty drivers" dialog, though perhaps that could be disabled if those faulty drivers are not being used? A "fine tuning" dialog. Finally, a "debug" dialog, which you got already. Oddly enough, "debug" implies "for developers only", yet it's the only part that's almost entirely understandable for most people. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. |
From: Carsten H. (T. R. <ra...@ra...> - 2012-07-31 10:51:59
|
On Tue, 31 Jul 2012 20:30:31 +1000 David Seikel <on...@gm...> said: > On Tue, 31 Jul 2012 18:52:56 +0900 Carsten Haitzler (The Rasterman) > <ra...@ra...> wrote: > > > On Tue, 31 Jul 2012 18:34:43 +1000 David Seikel <on...@gm...> > > said: > > > > > On Tue, 31 Jul 2012 17:27:27 +0900 Carsten Haitzler (The Rasterman) > > > <ra...@ra...> wrote: > > > > > > > On Tue, 31 Jul 2012 17:16:38 +1000 David Seikel > > > > <on...@gm...> said: > > > > > > > > he's complaining about lack of features in e17 vs e16... and the > > > > comp dialog hasnt split advanced vs basic - its all advanced. all > > > > options there. > > > > > > The composite settings dialog is just one of the things he brought > > > up in this thread, but I don't think there was one in e16, so E16 is > > > irrelevant to this part of the conversation. > > > > > > It's not advanced, it's so far past advanced it's silly. That's my > > > point. Even advanced users can't use it. > > > > then don't touch what u don't understand. those settings exist > > because that's how comp works. several of them exist due to faults in > > drivers and for fine tuning optimizations. if you don't know - then > > don't touch. > > Which is the exact opposite of the advice you gave to "just try it and > see". You can't have both. I'm pointing out that those parts you are > saying to "just try it and see" are just as hard to figure out as the > parts you are now saying "don't touch what you don't understand". the thing i was talking about was the 1 and only list "style -> default" and the selector. how is that not clear u are selecting the default style? u can play with all (but indirect rendering) settings without any problem. it wont hurt to hit and try. if you are of the opinion its all so complicated for you - then leave it alone and be happy. i just dont get it - the same selection mechanism is used in theme and wallpaper selectors, but somehow at least you 2 have a mental block thinking that this has to be somehow different. > No one understands any parts of it, this is the problem. That dialog > really needs a major overhaul, and it seems that the only people that > understand enough of it to do that overhaul are the people that wrote > it. This makes it almost entirely useless for every one else. > > Face it raster, it's a raster only settings dialog, and you can't tell > people "just try it and see" and also tell them "don't touch what you > don't understand". Coz they don't understand any of it, and are telling > you they don't understand any of it. You just can't have it both ways > raster. try settings and see what happens. if u find this too scary then dont try anything and leave them alone. that goes for EVERY SINGLE settings value in any and every app everywhere. if u are scared of selecting "delete" when a file is selected... then DONT. if that confuses you - then dont do it. if you are happy with trying it and seeing what happens then try - go for it. your complain was one of complete bewilderment at almost anything in the dialog - then don't touch the bits u don't understand if it scares you to touch them. not everything in e has been dumbed down to hide all the options. i didn't want to bother doing much more of it until we were using elm for dialogs. > I can see that there are parts that MIGHT be easy to understand if only > they where done a little differently, but I can only see that after > some experimentation and what you have described here. If a very > experienced E17 developer does not understand it, then the 99.9999% of > people that are less experienced non-E17 developers have no hope in > hell, and it might as well not be there. you haven't touched e17 since 2007. :) and never compositing. you have done mountains more with efl (of late), but i wouldn't say you're a "very experienced E17 developer". :) especially in the last 5 years so. :) > It needs work, plain and simple. > > I suggest a basic dialog, which would likely be just "Shadows". Then > an advanced dialog which might be "choose stuff from the current > theme", though perhaps if that was actually easy to understand (it > isn't now) then it could go into "Basic". Then a "fix faulty drivers" > dialog, though perhaps that could be disabled if those faulty drivers > are not being used? A "fine tuning" dialog. Finally, a "debug" dialog, > which you got already. Oddly enough, "debug" implies "for developers > only", yet it's the only part that's almost entirely understandable for > most people. lol i made a basic one. if u don't understand the one that's there now.. u need to see a shrink. it's so utterly basic. if u need the advanced dialog - deal with it. it's advanced. if it scares you don't touch it and live with the fact u wont change what u wanted to change, unless its in basic. > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > 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... |