1. Run LXDE 0.5.0
2. Right-click the desktop and choose Desktops > Add new desktop
3. Play around with neap and OpenBox's internal desktop switching

Neap should at least notice and regenerate its state when the current desktop's index exceeds the known number of desktops.

As is, neap 0.5 simply ignores the new desktops... though, because of how I coded it, my scroll-wheel patch does still behave properly.

Also, for reasons unknown to me, not even exiting and restarting neap will remove "desktop 5" from the context menu... though, again, my patch behaves as expected.

My suggested solution would simply be to retrieve the desktop count on each switch and compare it to the stored data as a staleness test. It wouldn't catch desktop renaming, but it'd keep things behaving sanely.

I'd whip up a patch for this problem, but I'm still not quite familiar with how your code handles state information. (Among other things, I'm unsure why you cache so much in situations where, in my experience, the big potential problem is stale data, not performance issues)

Hi Stephan,

you are right. When I started working on neap, I intended a fixed size for the desktop grid, mainly to let people with two desktops choose between horizontal/vertical layout. But now you are the second person who complains, so it might be time to re-think the current approach.

There are some problems though. First of all, desktops can actually be arranged in rows and columns, not just by supplying a desktop count (see setlayout.c for details). It would be nice if neap could handle such situations. And for "linear" arrangements, there's the problem of determining how to properly display desktop arrangements where the desktop count is not a square number, i.e. should we use 3x2 or 2x3 for a layout with 6 desktops.

I will think about this, and I generally agree with what you have said regarding the mostly useless caching. The easiest approach is probably to not cache anything at all and let the layout automatically adjust to newly added/removed desktops, thus completely sacrificing the fixed layout. I don't think that there will be a considerable performance loss, since querying the WM is about the same overhead as moving the mouse by 1px.

Thanks for your comments (and again for your scroll wheel patch). I hope that by the weekend, I will find the time to start hacking on this.

Greets, Philip

Glad to know I could help.

For the layout issues, my advice would be to treat cache-removal and layout handling as separate problems and architect accordingly. That way, you don't have to solve two problems at once.

As for solving the dimension-specification issue, here are the approaches which come to mind: 1. Use ceiling division, divide entries by a user-specified row count to get columns. 2. Same, let the user specify columns instead. 3. x, y = math.ceil(math.sqrt(count)), round(math.sqrt(count))

Given that you're working with a space guaranteed to be square, #3 would, at the very least, be a good default behaviour for linear workspace sets.

Hi Stephan,

I completely removed caching, neap now fetches everything from the WM when needed.

As for the problem regarding the dimension-specification issue, here's my current approach:

(1) if config variables "rows" and "columns" are both set to values >0, enforce them (2) else if the WM has been configured to use rows and columns (setlayout.c), use these values (3) else compute nice defaults using something along the lines of your "x, y = math.ceil(math.sqrt(count)), round(math.sqrt(count))"

So in the most probable case where (2) is false, simply set rows and columns in .neaprc both to 0, and you get a dynamically adjusting desktop layout in neap.

I will prepare a new package, neap-0.5.2, and put it online.

Again, thanks for your valuable input. While removing all references to cached stuff, I even found two bugs and fixed them on the way.

Greets, Philip