On Mon, 23 Aug 2010 12:09:34 -0700 "Aaron J. Seigo" <ase...@kde.org> said:
> On Saturday, August 21, 2010, Carsten Haitzler wrote:
> > On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin
> > (btw - e17 has had a gl and software compositor for a little while now :)
> > if you include bling - a xrender one for many years, so i'm in the
> > same/similar boat with you guys, but with a difference - same compositor
> > works in both software fallback client-side mode, opengl, with and without
> > texture-from-pixmap AND works in opengl-es2.0 so in some ways. just for
>
> this isn't much different from kwin.
aaah ok. cool.
> > 1. properties on root listing what is supported. fine - but big hole. no
> > way to know if properties are valid. if cm crashes/exits and leaves them
> > there, they will be stale and invalid. need a validity check mechanism
> > much like netwm - or stick them on the validity check window (see netwm
>
> good point..
:)
> > 2. i pretty much have to say no to most of the spec - it's HIGHLY specific.
>
> probably because the apps that need these effects have highly specific needs
> knowable only from witin the app.
that's generally a problem for a general spec... generally... :)
> > 3. the "slide" interaction imho is way too basic and limiting. let's stand
> > back and think. what you are asking is for the cm to become a generic
> > effects engine with a bunch of apis for very specific effects that you
> > control in pretty raw detail. the api is a property on a window as such.
> > let's stand back here and turn this into something doable. let's combine
> > this with the above visual hints atom. let's add another type atom to the
> > visual hints list:
> > TRANSITION <- highly suggested you transition this window in (or out on
> > hide) somehow (fade, zoom, flip, slide, whatever). in additionally an
> > extra property will provide a suggested "source" for the transition.
> > discussed next.
>
> while i'm fine with making the animations more semantic ("transition in")
> rather than specific ("slide in"), we then end up with issues of
> configuration. "transition in" would have to be a one-size-fits-all-windows
> effect otherwise we end up with windows requesting what kind of transition,
> client-side configuration of these things ... not good.
>
> this would give us a way to implement a requested feature: that panels fade
> in rather than slide in, without annoying the rest of the world who prefers
> sliding. i'm not sure it really matters all that much, though, to be honest.
> i suppose this is mostly for different window managers to do things
> differently from each other.
well - i think that you CAN do this with a combo of both. use cm hints as a "do
an effect at all" and use netwm hints (eg netwm window type, combined with
name, class and a bunch of rules to "match stuff") to get all the specific
effects you want your your desktop env. what i'd like is to not have this spec
blow out from "well now we have slide in" then in 6 months "well add zoom in"
then a "flip and fade in" then a "rotate in" then a "explode in" and the list
goes on. i 'd like to stop going down the specific effect path and leave that
up to the cm decide precisely what effects they are, how they work etc. etc.
and have more of a coarse-grained switch to say "but noooooooooooooo dont do
any of your fancy goop on me!" for example. if it does do "fancy goop" there is
more than enough information in name+class+title+netm window type+wm role and
so on to do this there.
> > 4. a transition source property on the client window. TRANSITION_SOURCE is
> > a hint as to a "source window id + optional rectangle within that window
> > that this one may come from. property format is CARD32 with the elements
> > being: [SOURCE WINDOW ID] <- required. may be root window id or any other
> > window id on screen. the geometry of this source window id is used as the
> > source of the transition hint UNLESS another 4 members of the property (5
> > CARD32's instead of 1 total) are provided.
> > [[X],[Y],[WIDTH],[HEIGHT]] <- optional extra 4 CARD32 members that define
> > a rectangle (top-left at 0,0 in source window id, all CARD32's are signed
> > 32bit integers and width and height must be greater or equal to 0 (values
> > less than 0 are reserved for future meanings).
>
> in which circumstances would a rectangular part of the window be a sensible
> thing to apply an effect to? in my experience, it's either the whole window
> or a shape, but rarely if ever an internal rectangle.
>
> the only time we currently use such a target rect is for effects on other
> windows, such as to animate a window on minimize/restore to/from the relevent
> tasks widget.
ooh i think you mis-understood me. the rect region within the source window is
optional.. and it is the "source" for the effect. eg IF you slide, or soom or
rotate + zoom in - the window as a WHOLE appears to transition "from" this rect
within the source window on screen to its final resting position. so slide can
be accomplished by just placing a rect, size of the final window just off the
edge of the screen from which the app would "like" to transition from with root
window as the source window id. if the app "launches" from the "taskbar/panel"
and this taskbar/panel is a window id - the window id provided is the panel
window with the rect region maybe being the taskbar button or icon region on
the panel. cm msay honor this source rect or it may not. it may fade or not
fade to and from. it may actually honor the location but not "Scale" (lets say
you do compositing and your cm uses some old 2d hw that is not capable of
scaleblit - just basic 2d blit and maybe blend - no scaling, so you avoid
rescaling windows for performance and just slide and fade them - then the cm
may look at the rect and adjust accordingly to get roughly the kind of effect
that was intended). so it's not affecting a region of the composited window -
it's providing some source location/geometry that may be on or off the screen
and is tied to a window id and its geometry as well, with cm now having 2
geometries. a source geometry and a destination (the window current geometry).
> > 5. EFFECT_NOW atom property. this is a property on a window that contains 0
> > or more values of type ATOM (32bit) that request an effect to be applied
> > on the given client window. highlight, unimportant, urgent etc. etc - yes
> > i know this overlaps netwm. i'm not totally done thinking this over, but
> > it's me trying to do your "highlight windows" thing in a more generic way
> > where a client requests to be made visually prominent (or the opposite) at
> > some point.
>
> highlight windows is currently used by things like the window listing / tasks
> widgets / taskbar to show specific windows. it's not actually related to the
> netwm behaviours. perhaps the naming could be better, or documented clearer.
hmmm well to me it looks more like a desire to have 1 or more windows
specifically become "hilighted" (compared to others). maybe its useful anyway
separately.
> > 6. present windows... i think this just is better left to be entirely up to
> > the cm+wm to do at its leisure. the only thing i'd suggest here is perhaps
> > the cm being nice to external processes that want to do ushc "task
> > manager" things - same with window preview etc. etc. - cm sets a property
> > on the frame window with the current pixmap id of the
> > composited/redirected pixmap. any client can pick up this property and the
> > pixmap id, and follow the property as it changes to implement this
> > themselves in whatever way they want using the pixmap id. (the window its
> > on itself provides for visual id and thus argb vs traditional "solid"
> > pixmaps).
>
> and then we end up implementing placement and movement logic in multiple
> places. i'd rather see this remain completely inside the window manager where
> the logic already is so that it is consistent and code duplication is
> eliminated.
oh no - this is for just implementing a "window selector" popup and the likes.
you have pixmap id's - you can use them and render any window picker of your
own that you like.
> > 2. client-side pixmaps. instead of forcing a window to be redirected by
> > xcomposite a client can already be composite-aware and just allocated and
> > render its own pixmap. it can set this as a property on its window. this is
>
> this would be really nice for toolkits that already do internal buffering of
> entire window surfaces.
>
> > 4. the ability for cm to tell app "you are transitioning now" vs "you have
> > now finished transitioning and are now visible/invisible". this is
>
> this would also be useful in various cases as you note... i like it :)
goodie :)
> > 5. cm provided window backgrounds. this one is controversial. this means
> > that toolkit and wm and cm have to all agree. but the idea is so that you
> > can have consistent frame + window backgrounds and transitions (ie smooth
> > title+menubar etc. etc.). the client now always provides an argb window
> > that has no background at all - always transparent where it used to have
> > the base window background. it lets the cm provide this and the cm
> > composits the client app window on top. problems here are: a) agreeing on
> > background color and texture etc. so it doesn't interfere with widgets (eg
> > text labels etc.). up for discussion but some kind of hint here with
> > "light", "dark" or specific rgb colors that the cm or the app use to say
> > "keep clear of these please if you want to be readable".
>
> ... a global color scheme, in other words. all the toolkits already have
> these, of course, but standardizing this would be a great step forward.
yes - though a highly simplified one - were we are pretty much just agreeing on
a single boundary - the window background having a contrast to some of its
immediate child contents (probably primarily only needed for labels). if this
is just a small subset like this - i think it's doable as we get rid of all the
cases where everyone disagrees ... i'd hope. up for discussion of course.
> > not sure which
> > way around it should go (ie should cm define the "keep clear" colors and
> > toolkit obey, or vice-versa).
>
> if the cm defined the color scheme, then the toolkits could use their
> existing color scheme support to read that, no? as long as things don't
> overly complicated (like a background texture that requires different color
> schemes in different parts of the window) then it shouldn't be a problem,
> afaics.
yes - so if the cm set the rules of "bg color is X, fg color is Y" and then
toolkits merged that in as part of their own theme/colorscheme parsing on
startup for "immediate children of window widget" colors... then that'd work
well as most toolkits should have some ability to do this sanely. if they don't
at worse you end up with "black text on black backgrounds" symptoms and people
simply saying "well dont use that theme, or that toolkit then".
> > this opens up a can of other worms - like cm
> > and app agreeing on the cm providing things like resize handles on the
> > bottom-right that the app "keeps clear of" when filling content or..
> > vice-versa? maybe some kind of hints the app can provide as to the edges
> > of its inner window and how much u'd like "frame" to stretch into the app
> > by (to make sure the menubar or statusbar etc. are always nicely filled in
>
> would it be enough to define a set of well-known "zones" in a window that can
> be used by the client to define where these things are in the window? it
> would be really nice if the client could provide sets of regions tagged with
> different semantics ("menus/controls", "status area", "toolbox", etc.) as
> this would prevent getting stuck with "menus are a rectangular region at the
> top; status bars a rectangular region at the bottom; etc." forever. perhaps
> this would be too complex, however.
a bunch of well known "zones" that are simple enough to render/handle in the
background sound fine to me - i guess i was aiming for the edges of the window
there. we could throw in corners too and maybe a center region. you want this
to be sanely implementable as a generic style/theme from the cm side as well.
but all doable. at worse if the cm ignores these regions you get a boring
single "cm provides that grey gradient bg for the whole window - if u like it
or not" vs "it can tune the shading to be gradiented at the top only and then
flat in the middle with just the right gradient at the bottom to give a curled
effect". so i'd hope it has a subtle yet graceful degrade.
> > like the title would be) etc. etc. up for debate. this also opens up the
> > can of worms that was canonicals "window indicators" - but providing a
> > nice clean protocol for these in much the same vein as a proper systray
> > spec, would be nice.
>
> agreed, though i'm not really sure what the real world benefits of these
> "windicators" will be; for them to be really compelling, imho, a good amount
> of design work is still left un-done so that such add-ons to the title bar
> can gain access to "the document this window is showing" in ways that aren't
> full of assumption and limitation. we're working on these kinds of issues
> slowly, with a few groups working on things like "how to expose the
> relationship of a window and the document(s) it is presenting"; this is
> something we (KDE) are working on in combination with Nepomuk and Plasma's
> activities. there's a lot of cooperation between different processes required
> to really make these things compelling, and i don't think we fully understand
> all of what's involved in real-world practice yet to start building specs
> around such things.
>
> eventually, though, yes :)
sure. ok - we can push this off into "some other day" then. agreed - its
non-trivial.
> > though at this point i think we may have exited the
> > cm spec and entered a netwm spec.
>
> yep :)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
