Re: resizing with gravity

[Sasha Vasko <sasha aftercode net>]

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.