On Sun, 13 Dec 2009 13:35:46 -0600, Jeremy Hankins wrote: > --- > | A | > --- > ------- > | B | > ------- > -> > -------------- > | A | > | | > --------------| > | B | > ------- > Or: > ------ > | | > | A | > | |------- > | | B | > --------------
True. There's no natural way to choose which. So, if you want the latter case, the the buttom border of *un* max'd window A has to be well below. If the patch brings what Chris wants, then in fact it forces the latter, and bans the former case, so it's not the fix. On Sat, 12 Dec 2009 07:46:59 +0100, Christopher Roy Bratusek wrote: > MAX_HORZ + MAX_VERT != MAX I don't agree with this logic that it solves the Chris' problem. If A is *not* max'd horiz, then A does not bump to B: _ | | |A| ----- | | | B | - ----- So what Chris really needs must be both horiz and vert max, isn't it? But again: > MAX_HORZ + MAX_VERT != MAX the patch submitter in bugzilla says the above inequality is correct in ewmh, and Sawfish is wrong, so we have to consider it. (I failed to understand the related ewmh part. ;) Anyway, if what Chris wants can be done correctly if it's done interactively (= by human operation, with clicking max button or pressing a key), and not by matcher or history code, then there're two separate problems; matcher/history part needs rework. Chris refers to toggle variants. My impression is that: * max-vert/horiz are functions, and maybe adding "#:key strict" solves. If strict is non-nil, then horiz/vert are exclusive to each other. wm-spec functions will be able exploit it. * There're also commands, max-vert/horiz. But user can expect both, so we need max-vert/horiz-strict. Distinguish by name. * Toggles are commands by nature. So distinction by name like above solves. I'm not sure. It's a mere starting point of the discussion. One thing I care is that there seem to be too many max'n funcs / commands. At least functions whose only raison d'être is the command backend can be made obsolete, moved to compat.jl. (Read command section in info how to do it.) There're other glitches in max'n. I came across with: On Tue, 17 Nov 2009 09:44:41 +0100, Janek Kozicki wrote: > On positive side [of error-handler deletion], after sawfish restart > a vertically maximized window does not overlap rox-panel *most of > the time*. I wonder how those two might be connected? I mean - it > happened once per 10 tries or such. On Tue, 17 Nov 2009 07:56:53 -0600, Jeremy Hankins wrote: > Could it have to do with system load or something? On my tests I > noticed that my maximized emacs windows were much less likely to overlap > the panel than maximized xterms. Jeremy asks: > What determines the order by which windows are taken up by sawfish? Rule lacks, and that's the very problem. Furthermore, matcher sets rules for one by one window. But when maximization is involved, then first it should set "avoided" property for all windows, and maximization have to succeed that. I don't know the case of window-history, but I guess it's similar to matcher. Regards, Teika (Teika kazura)
