Re: [e-users] E16/E17 feature parity

[Carsten H. (T. R. <ra...@ra...>]

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...