On Tue, 30 Oct 2012 at 17:55:52 -0700, Iain Patterson wrote: > Quoth Carlos R. Mafra, > > >wmaker(wScreenUpdateUsableArea(screen.c:762)): warning: usableArea[0]: 0 > >1920 0 1080 > > The problem is that there's an infinite loop. > > wScreenUpdateUsableArea() calls wArrangeIcons(). The icons move > so we call wIconUpdateStruts() to set struts and that calls > wScreenUpdateUsableArea() again. > > When you suggested using struts for docks and icons I thought it > would be quick and easy to do but it's getting complex in a big > hurry and I'm not convinced that we're actually getting any benefit > from it. > > The code to avoid covering the dock and icons worked well and as > long as we are still using the existing placement rules we still > can't place "under" a vertical stack of icons or "next to" a > horizontal stack. If we revamped the placement rules we could fill > that empty space without needing struts.
Ok, but do you think that having partial struts only for the dock might be worth? It does not have the infinite loop problem in this case. And regarding the wArrangeIcons()-induced infinite loop, one way to perhaps avoid it is if one simply counts how many icons there are, so the particular ordering of icons is not important, just how much space they occupy as a whole. And apart from that, I didn't have any icons on the workspace. When I fired one application with an appicon, is it really necessary to call wArrangeIcons() in this case? Ie, aren't we calling this function too much? Rodolfo, any thoughts on this? My first impression is that wArrangeIcons() should be called when appicons are removed (because they can leave a hole). But when they are created, why do we care? Aren't they simply supposed to be appended (eg to the right) of the existing appicons? > I think we should revert commit > 2cc982fb4bfeef196dd1daaa2d3db98d76e9676c and I'll look into a new > placement method instead further complicating this experiment. The > commits leading up to that one could still be useful and should be > safe to keep. Done. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
