On Tue, Mar 12, 2013 at 7:06 AM, Uli Schlachter <[email protected]> wrote: > Hi, > > On 11.03.2013 06:50, Campbell Barton wrote: > [...] >> However from looking through the awesome codebase I couldn't see what >> determines when a new window is floating, >> Since from what I can tell this isnt a 1:1 mapping with a NETWM >> property or something blender may have set incorrectly. > > If nothing is set explicitly, awful.client.floating.get() applies some sane > defaults: > > if c.type ~= "normal" > or c.fullscreen > or c.maximized_vertical > or c.maximized_horizontal > or client.isfixed(c) then > return true > end > return false > > So blender is being floated because it is maximized. Having a window maximized > means that it should cover most of the screen and that pretty much conflicts > with being tiled. Thus it has to be "un-tiled" aka made floating. > >> I would hope this is something that can be resolved without a custom >> configuration or setting hints in a configuration file, since opening >> a maximized window is not such a strange thing to want to do. > > Well, this bug reports boils down to "blender is started in fullscreen mode" > and > awesome obeys. > >> Bug report here; >> http://projects.blender.org/tracker/index.php?func=detail&aid=34580&group_id=9&atid=498 > > I planned to look into this issue myself, but Sebastian Parborg (bug reporter) > pinged me on IRC first. Thanks to him I noticed the obvious. > > Together, we also figured out the following sub-issue: > > So for example if I launch the pref window in blender I have to minimize > blender before I can see it because blender is floating and maximized and > thus the pref window is spawned behind the main blender window. > > In Sebastian's config, floating windows get "ontop = true" and thus the pref > window is forced to be behind Blender's main window. (Main window is ontop, > the > pref window isn't) > > The following rule should work around this (if the WM_TRANSIENT_FOR of a new > window has _NET_WM_STATE_ONTOP set, also set the new window ontop): > > { rule = {}, callback = function(c) > if c.transient_for and c.transient_for.ontop then > c.ontop = true > end > end } > > (However, this is untested) > > Cheers, > Uli > -- > "Why make things difficult, when it is possible to make them cryptic > and totally illogical, with just a little bit more effort?" -- A. P. J.
To follow up on this issue, seems like there were no bugs on either side, but since starting maximized is not common behavior, blender now starts at a fixed size (clamped by desktop size), from whay I can tell this is common practice (firefox does this for example). -- - Campbell -- To unsubscribe, send mail to [email protected].
