[Bf-committers] Re: Re: [Bf-blender-cvs] CVS
commit: blender/source/blender/src
editscreen.c ghostwinlay.c blender/source/creator creator.c
Campbell Barton
cbarton at metavr.com
Sun Apr 15 15:28:59 CEST 2007
GSR wrote:
> Hi,
> djcapelis at gmail.com (2007-04-14 at 1717.10 -0700):
>> Absolutely. Install windowmaker or a similarly broken WM on another
>> platform and it should do the exact same thing. It works fine in all
>> modern window managers, on all platforms.
>
> Some WM are less restrictive than others, like allowing bigger than
> screen windows (not so rare with large scrolling desktops, which the
> spec mentions), and some are more (some never allow frameless windows,
> not matter what the app asked for). Or is there a part in which the
> spec declares windows must be limited in size for all cases? I just
> found refs to maximize and panels. OTOH, many apps never go for huge
> window as default size.
>
> Let me be skeptic about "fine in all plataforms", it is not the first
> time I see MacOSX users talking about strange behaviour like putting
> the window below the top menu. And looking at MSWindows code, it seems
> to ask for the frame size or client bounds in some cases, so I would
> say in that OS it works cos Blender does something about it (tho I am
> no expert on such plataform, but the calls were "intriguing" to see
> there).
>
> Before things keep on changing at random, we need a set of rules about
> what the app is going to do based in params (-w vs -W, -p vs nothing,
> etc), config options, system policies (what to do when a vendor
> declares something as must, should, etc, maximize hint or similar
> avaliable everywhere? meaning the same? etc)... then we can go on
> changing things and finding workarounds.
>
> GSR
Windowmaker 0.92 works fine for be before and after the window patch.
fullscreen and with my maximize patch.
Chris, can you provide a screenshot?
More information about the Bf-committers
mailing list