On 07/29/2012 08:09 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 29 Jul 2012 10:43:27 -0400 The Wanderer <wande...@fastmail.fm> 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
------------------------------------------------------------------------------
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
