On Sun, 29 Jul 2012 21:38:56 -0400 The Wanderer <wande...@fastmail.fm> 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) ras...@rasterman.com ------------------------------------------------------------------------------ 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