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" <yo...@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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
