shr-contacts/messages/dialer: window size and further issues

[Rui Miguel Silva Seabra]

On Thu, Sep 17, 2009 at 09:01:49PM +1000, Carsten Haitzler wrote:
> On Thu, 17 Sep 2009 09:49:26 +0400 "Nikita V. Youshchenko" <yoush at debian.org>
> said:
> > > > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS):
> > > > > > >         program specified minimum size: 198 by 350
> > > > > > >         program specified maximum size: 198 by 350
> > > > > > > ...
> > > > > >
> > > > > > the way the contents are specified for the window, it isnt
> > > > > > resizable. the app
> > > > > > is in control of this.
> > > > >
> > > > > All SHR apps have these values defined as above.
> > > >
> > > > That means that all SHR apps will get non-resizable 198x350 windows
> > > > under any stardards-compliant window manager.
> > > >
> > > > This is definitly a bug that should be fixed.
> > >
> > > not all standards compliant wm's. e+illume will be fine. matchbox
> > > probably too. the "standards" allow the wm to happily ignore min/max
> > > window size hints if the wm wants to. :)
> > 
> > WM hints is *the* standard way for app to request it's size constraints.
> > So if app sets hints, while not wanting to get these size constraints, it 
> > is a bug in app.
> 
> i have said that several times. but the standards do not REQUIRE that a wm MUST
> keep a window between its min and max sizes. it is an optional behavior. thus
> they may be resizable under standards compliant wm's. it's up to the wm.

Which is why they are called *hints* (to everyone else but Carsten who who knows
this way, way better than I do) :)

Actually there's a huge security design flaw in Windows in great part because their
windows work in a dramatically different way than X's (IIRC).

Oh, and the only way to fix it requires a fatal retrocompatibility breakage.

Rui