DSL Ideas and Suggestions :: Two versions of DSL



Quote (humpty @ Nov. 04 2007,14:34)
unless somebody knows of another way, i've been thinking of processing .dfminfo to grid-align the desktop icons. i was thinking of
a c binary but much rather somebody else talented do in lua.
. come to think of it, much rather somebody else do it period. :laugh:

Use arrange?  Or did you mean an option to auto arrange everytime the icon arrangement was changed?
Using "arrange" will rearrange all your icons. Personally I don't like that behavior, since I have an unusual setup (when actually using icons): several application launchers lined up long the right side, with empty icons so only the label is visible. In addition to that are a few icons that get removed or replaced on a fairly regular basis. With a grid-snap feature, these icons could simply be lined up neatly rather than mixed in with the text-only icons.
Trying to keep this thread on topic of fluxbox, jwm & the support of other window managers.

I have opened up the process to better support alternate window managers. Elimination of the case statement in both dsl-config and .xinit as well as moving the mydsl menu includes to /opt both mydsl menu and script to create/update the menu. The process is driven by the contents of the .desktop wm field.

But now I am thinking not to have dynamic switching. Doing so implies that for each wm the dynamic mydsl menus would have to all be updated and would slow as more window managers were added. Currently two menus are updated everytime one loads an extension, whether it is boot time or runtime. To take advantage of this new open process imples at minimum a third or fourth wm. Hence a big impact on performance. Even if I don't update all wm installed, then to support switching, would imply that the target of the switch would have to have its complete mydsl menu rebuilt. Slow down again.

If I fully support the boot option for a window manager then only one dynamic menu needs to be built and would be even faster than the current method while being more open to easily support wm extensions driven soley by the boot option desktop=xxx.

Does one really need to be switching back and forth between various window manager during run time? Is it worth it given the process overhead?

I would vote for building the menu just for the current wm, and if another is chosen, upon startup of that one it would be generated.  I think this would benefit most because I don't think users change their wm preference.  But if different users that use the same system would use a different wm, their startup would be slower, but I think it would still be preferable to do it this way and maybe make it customizable to which wm menus to update.

Quote
Does one really need to be switching back and forth between various window manager during run time? Is it worth it given the process overhead?
My opinion would be no, due to the same reason as above.
I agree with ^hats^. I never use the run-time switching anyway.
Next Page...
original here.