Russell Shaw wrote:
Sasha Vasko wrote:
Russell Shaw wrote:
Sasha Vasko wrote:
Russell Shaw wrote:
Sasha Vasko wrote:
An X app might open a grid of top-level windows, and rearrange them
as more windows are added or removed.
No application should ever rely on being able to do that.
No app for use by general users should expect that. However, for a
developer making a program for a specific platform can do anything
they like, using any assumptions they know to be true.
Yes and one of this assumption is that app has no control over its
position on the screen. On X Window platform that is.
That's *your* assumption. Whoever writes an app can assume anything
they like. If they say their app works best under a WM with specific
settings, then so be it.
Yeah, and I can assume that I could freely drive on the left in US. Not
for long though.
Forcing app writers to conform to the lowest common denominator of
"uniform" policy across all apps will only lead to fragmentation and
rebellion if app writers object to their app looking like Gimp with
its top-level windows spread all over.
Such apps may exist primarily for embedded systems without a window
manager, but it is still useful to be able to use those apps where
a WM is running. In that case, the WM must have a policy setting that
allows the app to run as designed, or in a semi-managed way.
Yes, that is what I'm saying - user (via window manager
configuration) determines how windows are placed. Not the client
application.
In fact I suggest that we explicitely state the opposite: "Clients
MUST NEVER EVER include x and y in ConfigureRequests" Although
most smart and responsibly implemented clients already know that,
and those who suffer from delusion of grandeur, will always ignore
such statements anyways, so really there is no point in amending
specs.
Clients should only be able to change size of the top level
windows and then let window managers reposition them in accordance
to its policies. Which is were gravity comes into play ( from
WM_NORMAL_HINTS ). And again, this gravity should be choosen by
clients based on user request of initial geometry, and should not
be mangled by the client itself.
Window managers have no place in dictating how an application manages
its top-level windows.
Last time I checked Window Managers are REQUIRED to intercept
ConfigureRequest. It is my humble guess that WM does have a
responcibility of placing windows as it sees fit.
It is the responsability of the window manager to place windows as
the *user* has specified it should be done.
That is correct: *user*, but not a client app.
The user may tell the WM to not modify the actions of one app that they
may be testing for use on a platform that has no WM.
If you are testing an app for platform without WM - then run it in
server without WM
Impractical when normal desktop is needed for other test-harness tools
and things.
It's no use restricting what a user or app writer wants from their apps
or desktop. Doing so only frustrates them, forcing them to write a
replacement
to obsolete them all;)
Window managers exist solely for the purpose of the *user* to specify
how top-level windows should be managed.
Yes and that is why window managers have THEIR OWN CONFIGURATION
settings. And this is why there are so many window managers available!
But after user has selected particular window manager and configured
it how it wants windows to be placed - client have no business
whatsoever interfering with that!
Clients will do whatever they have been designed to do. A few clients
may be designed to function well with or without any WM, so when a WM
is running, it will modify the clients actions according to the users
settings.
Its not difficult at all for a client to recognize that there is no WM
running and take over responsibilities of its own placement in such
case. Somehow I don't see any noticeable number of applications
worreing about running without WM though.
That's because most users don't do that. It doesn't mean that *no* users
do that. Hard coding these kinds of assumptions is why i find practucally
all linux desktops and gui toolkits so crappy. They're designed for
clueless
casual users migrating from mediocre windoze boxes, and are useless for
doing
anything non-trivial. Ok, so a few desktops have all kinds of configurable
parameters. However, they're still very unintuitive to configure for my
kinds
of things, and hard work to make them do what i want.
Well, I'm afraid you don't have much choice anyways .
If a user wants to disable automatic window management for one app,
then so be it. A WM that doesn't allow this is broken.
ConfigureRequest is still handled by WM anyway you go about it.
Clients CANNOT possible determine appropriate x and y as they could
never precisely determine the size of the decorations at the time of
request. There may not even be a decoration! There could not even be
such thing as free placement of the window - WM may tile them all
together, or use tabs, and allow only one window on screen at a
time. There could be all kinds of placement policies out there, and
no client will ever be able to account for all of them.
For a client that is designed to run multiple top-level windows even
with
no WM running, the client just needs to do its measurements on the root
window (which could be just inside a WM frame, if a WM is running).
Note that this is for clients specifically designed for WM-less
operation, which are very few, but not non-existant. A developer will
>> need to emulate WM-less operation in their WM to test or use these apps
>> on their desktop system.
Well telling WM to pretend that does not exist is an idiotic way of
testing such apps - you can never be sure that it really does that.
It's easy to be sure. I write the apps i test. Unlike other WMs, i can
specify whatever i want for how the WM should treat the app.
Run nested X server if you really need to test that,
Xnest has limitations compared to the real thing, and it's unneccessary
when a few WM settings are so simple.
or run a second head without a WM. Whats so complicated about it ?
Already using a second head. Unneccessary to reconfigure all that
when a few WM settings are so simple.
Simple example: a terminal application.
You start it like so: xterm -geometry 100x25-0-0
Terminal then gets placed at the bottom-right corner of the
screen. Now what would happen if user decided to change font size
in it ? Do you really want xterm to try and calculate what its x
and y should be for ConfigureRequest??? I don't. And I doubt that
xterm developers differ with me on that one.
If an application was designed with the assumption that a WM is always
running, then the offset calculation isn't required.
If the app was designed assuming a WM may not be present for a
significant time, then i *would* expect the app to do the offset
calculation.
Then this must not be part of Extended WINDOW MANAGEMENT specs, if
your goal is to account for when WM is not running.
It doesn't need to be a part of the Extended WINDOW MANAGEMENT specs,
because it is just a matter of the user setting their WM to switch
off or modify handling of a certain client they wish to.
The point is that some clients *do* need to set their size and position
>> on the root window (as opposed to clients having no business setting
their
position).
When a WM is running, the positioning can be ignored if desired, by
the users
WM settings.
If its ignored then its not taking effect - ConfigureRequest just gets
discarded.
What i meant is that ConfigureRequests are passed thru unaltered.
Well, if client is reparented into a frame window - you don't wanna know
what will happen if you pass them through unaltered :)
> But if it is not discarded, and honored, any but the most
primitive of window managers will have to take into consideration all
kinds of different thing, such as AvoidCover windows, Struts, limits
of desktop area available, virtual desktop size, tiling with other
windows, decorations, all kinds of garbadge like that, end result of
which is that final position is almost always different from what
client has requested.
The solution is exceedingly simple. I tell the WM that this application
should have its screen origin at a specifed point on my desktop screen
(i just click the mouse somewhere inside a clear area to place its first
window when it starts). So whenever the app moves one of its top-level
windows, it will be relative to this point. All the top-level windows have
group-leader hints, so they're all treated similarly. I also tell the WM
(with a
simple right-click menu) that this is a self managed app. Another way is
to tell
the wm to create a virtual desktop window that the app can manage itself
in, and
the whole thing gets a WM border around it.
Dude, all you need it OverrideRedirect window. Manage it yourself all
you want.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
