On Wednesday 03 August 2005 19:35, Havoc Pennington wrote:
> If you're arguing there should not be a fixed set of window types, I'd
> argue go join the flat earth club, because as long as the X architecture
> stays as it is, and we don't implement uploading Lisp scripts to the WM,
> there's going to be a fixed set of window types.
I'm not arguing that, at all. I agree that semantic types are basically the
only tractable way of specifying window behaviour.
> So my argument #2 is that TYPE_NORMAL_BUT_UNDECORATED is probably wrong.
>
> For your example app, my guess is that most "typical" window managers
> (kwin? metacity?) already do screw up some of the details of how this
> app works; and the more unusual window managers (ion?) would hose it
> entirely.
Actually once you can get the damned decs off it pretty much Just Works. You
may or may not want your simulation windows to float above docks, but
STATE_ABOVE handles that. And then the toolkit catches clicks and will
circulate the group of windows to the top, and some chorded drag or other
(control+middle maybe) allows you to reposition the group.
> It also sounds like the app could be much _improved_ with WM support. If
> you're tiling the windows together, the WM could guarantee they stay
> that way and stick together in the stacking order, for example.
That's a possibility, though I think on group raise the app will reposition
the windows to be tiled, and then preserve that on control+drag, and really
without the decs how else would you move them (yeah yeah, clever pagers;
doctor, it hurts when I do this). I'm not particularly familiar with MPK, I
was just asked how you're supposed to get the decs off now that we're using
netwm everywhere. And netwm doesn't say anything nice about the mwm hints,
so, clearly you're not supposed to use them, right?
> I'm not sure I understand exactly what the app is from your description,
> though, and to decide what its type is we would need you to spell it out
> in more detail with all the behaviors. Once it was spelled out that way,
> we know how to extend the spec, possibly with
> TYPE_NORMAL_BUT_UNDECORATED.
Think of it in this instance as a toolkit for spreading OpenGL over multiple
windows, and therefore over multiple screens, without the braindamage
associated with Xinerama. The app you write with that is then your model
viewer or physics simulation or whatever else it is that requires more than
one screen to see all of. So the big-display-wall use case is (say) six
windows over six monitors, but then since you may not have that big of a
system to develop on, you simulate with six windows on one monitor.
So the semantic type here is, say, TYPE_MINISCREEN, and as above you might
want some grouping hints to keep them tiled together with WM assistance but
it's really not mandatory. It's a bit of a corner case, but I could see
(say) Xdmx wanting the same type.
> My argument is that the WM specs must encode any type you want to have,
> whether by semantic type or by variations on them (like all the
> _NET_WM_STATE flags for stacking, etc.)
>
> You imply that there's some alternative, and there isn't. The "apps can
> do whatever they want" way _doesn't work_ as a matter of engineering.
I'm not advocating that though. I'm arguing that "please don't decorate me"
might be close enough to correct for enough apps that you'd very rarely need
to add new semantic types. That plus the layer control netwm already has are
basically all MPK wants. xmms is TYPE_NORMAL with no decs (and
non-integrated window snapping logic, but in principle that's something you
{c,sh}ould standardize through root window properties, right?).
> > and you still haven't documented
> > the canonical way to get rid of the decorations. They're nearly
> > orthogonal issues, but I would like to see at least one of them resolved.
>
> There's a way to get rid of decorations now, which is the MWM hint. I'm
> not being purist; I implemented the hint along with everyone else. The
> short-term fix is in place. Great.
It. Isn't. In. The. Spec.
If I need to get my app out the door and I don't have time to wait for
metacity to turn around and deliver support, then I want a standard method
that gets me to 90% _now_. Perfect being the enemy of done and all that.
And you can say "but we have the mwm no-decoration hint everywhere anyway" all
day long, but while this list now knows that, no one would discover this
feature by reading the spec. If wm-spec.html is not for documenting the
standard interactions with the window manager, what is it for?
> One of the reasons I'd like to avoid the MWM-hint approach is that it
> keeps us from narrowing down TYPE_NORMAL; I'd like to really make this
> type mean "main app window" and push things like XMMS into a separate,
> clearly-marked type. This allows the WM to do nicer things with
> TYPE_NORMAL since TYPE_NORMAL becomes more meaningful.
Wandering slightly OT here, but what nicer behaviour for TYPE_NORMAL would you
want?
- ajax
Attachment:
pgp0L29P0Ed4U.pgp
Description: PGP signature