[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.

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