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
------------------------------------------------------------------------------
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
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
