On Mon, Apr 2, 2012 at 1:52 AM, Uli Schlachter <psyc...@znc.in> wrote: [...] > _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a > Window Manager would keep such windows on top of all other windows. > >> Oops! Had forgotten to attach patch. > > Patch 1: > >> - or c.type == "dock" >> + or dockable.get(c) > > Uhm, the one kind of dock (see above) doesn't have anything to do with the > other > kind of dock. client.dockable.get() is for clients which "stick" to the corner > of the workarea when they are moved near to it (the client has to be floating > for this to work). That client then always stays in that position and makes > the > workarea smaller. I use that e.g. for gimp's utility windows, so that they are > always visible even though they are floating.
I guessed dockable.set was a glorified way to set a client as a 'dock' (the kind you explained above) from within awesome -- since you can't say c.dock = true from Lua code -- even if the client doesn't request a _NET_WM_WINDOW_TYPE_DOCK -- which would automatically cause c.dock to be set to true, (right?). I say glorified because dockable.get included 'utility' and 'toolbar' to be sort of dock; a nice abstraction, I thought. But why doesn't the code elsewhere use it then? Shouldn't all docks (toolbar, utility) behave the same, i.e. skip taksbar and be unfocussable? Of course, the code mustn't have been updated after dockable.get/set was written, I answered my own questions :P. Hence the patch. > Oh, now that I looked at dockable.get(): This would make gimp's utility > windows > unfocusable. With my assumptions, that was expected behavior (why call it dock otherwise?). I am not arguing a case for the patch, but rather what I was thinking when sending it. I realize the patch isn't really required :). Hard way to learn the use of a feature/function, eh? -- Anurag Priyam -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
