Two versions of DSL

Forum: DSL Ideas and Suggestions
Topic: Two versions of DSL
started by: meo

Posted by meo on Oct. 06 2007,19:22

Hi!

Since it seems kind of hard to make both window managers work without snags and hinches I suggest the making of two versions of DSL. One with the Fluxbox window manager and the other one with Jwm. Just a suggestion because I always use Fluxbox and don't have any interest in Jwm. I guess that others do though but this is my personal opinion. I think that DSL would benefit from this approach.

Have fun Y'all,
meo

Posted by mikshaw on Oct. 06 2007,19:44

If we're talking about personal opinions here, I think it would be easier for DSL development if there was simply no wm-specific behaviors included in DSL base. I can think of only a couple of things that might be causing troubles, though...one being the slit in Fluxbox and the other being desktop menus. If both of these compatibility issues were simply ignored and left up to the user (as is the case in most distros anyway), it wouldn't matter what wm was being used. The wm in DSL base could change arbitrarily, or the user could pop in something entirely different, and the only incompatibility issues might be from wm-specific files in the user's backup (again, something I'd consider the user's responsibility).

Ultimately, though, I don't see how developing 2 different DSLs simply for WM choice could be any simpler than the current situation. It would likely be more complicated.

Posted by spotslayer on Oct. 07 2007,12:41

Quote (mikshaw @ Oct. 06 2007,14:44)

I concur.

D :cool:

Posted by meo on Oct. 07 2007,14:00

Hi again!

Well it was only a suggestion as I mentioned. But I never mentioned the problems that made me give this suggestion. In the most rescent versions of DSL firefox has become "suicidal" again. It shuts down without any obvius reasons. That has made that I currently use the 3.3 version of DSL in which this isn't a problem (3.4 also works fine in this aspect). Since I'm selflearned when it comes to computers, (a trial and error guy) I just started this thread with only good intentions for this distro. What I want is a rock solid DSL that works fine all the time and is reliable in all that I use it for. I use it as my "production environment" and I just thought that future releases of DSL would stand up to those criterias better following the suggestion I provided in the beginning. I might very well be wrong but as I mentioned, it was just a suggestion with the reliability of DSL in mind.

Have fun with DSL any way you use it,
meo

Posted by stupid_idiot on Oct. 07 2007,17:43

Cool!
How frequent are the Firefox crashes?
Yes, I have experienced this problem for years with this build of Firefox. It does not happen often, but it does happen. In terms of frequency, I'd estimate about once every 1-2 weeks. This kind of once-in-a-while crash seems to have nothing to do with the WM - I am currently running Fluxbox on Debian Etch and I still get these (rare) crashes.
Note: The build of Firefox currently in DSL has been around since at least 2005.
There is one reason that will certainly cause Firefox to crash - this is when Firefox's cache is set too high. When Linux runs low on RAM, it automatically kills the process that tries to allocate more RAM (Firefox). To avoid this, make sure your cache is not set too large, in proportion to your RAM.

Posted by meo on Oct. 07 2007,19:56

Thanks for the input stupid_idiot!

I'm kind of aware of what you are saying and that also might explain why firefox never dies in some older versions of DSL. It seems to me that they require less RAM. By the way I scarcely use the firefox that comes with DSL. I use the most rescent version almost always. When it comes to the frequenzy of firefox dying on me it could be several times a day so you can understand that I'm using the version of DSL that works best for my purposes.

Have fun,
meo

Posted by roberts on Oct. 09 2007,19:25

Quote (mikshaw @ Oct. 06 2007,12:44)

I actually like the idea of making DSL base smaller by only providing hooks to any window manager. I could start by making jwm and fluxbox both be available as extensions. Having wm extensions write into .desktop. Have .xinitrc 'include' the needed start instructions. Have the extension create any needed menus, from main menu to mydsl and optional menu. Of course the main menu would have to be generated after all autoloaded extensions. This sounds doable and interesting. It would result in a much smaller DSL base. Wouldn't need a wm switcher as you pick the one (wm) that you want.

Posted by kuky on Oct. 09 2007,20:55

Put into expenses...

i think that firefox can be a loadable program uci or ucn in diferent languages its does more easily to translate dsl to diferent languages.. i think that have the more mb program in dsl basis...

Posted by spotslayer on Oct. 09 2007,22:21

Beautiful Roberts!!

Posted by mikshaw on Oct. 10 2007,00:32

Quote

Have the extension create any needed menus, from main menu to mydsl and optional menu.

I guess the thing I'd be curious about here is how would you do that? I suppose you'd probably need to prevent mydsl-install from extracting .fluxbox files into /home/dsl in the event that the user doesn't want to use fluxbox? My own desire is to remove any files from my home directory that I don't want or need, so having a .fluxbox directory created every time an extension was installed (if I wasn't using fluxbox) would be a little annoying. Maybe extract those files to /tmp/mydsl.menu instead? I guess the problem there would be needing extra code to check the archive rather than simply extracting it in /

Posted by roberts on Oct. 10 2007,03:27

Yes /tmp/mydsl.menu for extensions, and /etc/skel/ for main menu.
Of course the default standard would be flux style menu as that is what is in all the extensions. I would want to maintain backwards compatibity with DSL v3.x. I already have scripts to generate menus for jwm and fluxbox. I agree not to have extra directories in /home unless used by the window manager should be the goal.

Posted by WDef on Oct. 10 2007,15:15

Just to be sure I follow - you're talking about still shipping dfm with the base, but not fluxbox or jwm?

Posted by roberts on Oct. 10 2007,15:47

Yes. DSL would still have a fully functional X desktop.

Posted by mikshaw on Oct. 10 2007,18:49

Hmmm...now I'm starting to find it hard to follow. Even though you have desktop icons to lauch programs with dfm, wouldn't you still need a window manager of some kind so you can use more than one application at a time?

As far as I can tell, having no window manager would mean all applications will open at their default sizes, and all at top left, with no way to move, resize, or switch between them.

Or is dfm closer to a window manager than I suspect?
If it does provide the ability to focus and move application windows, that would be a perfect way to have a desktop base that isn't dependent on any particular window manager. It could be brilliant.

EDIT: checking out the dfm website, it looks promising. I'm going to install this doggy and try it out by itself and with a handful of window managers...fluxbox 1.0, just released, will be the first, and yes it has moved to the top of my mydsl priority list =o)

Posted by roberts on Oct. 10 2007,20:00

The base would be the 26k menuless swm and the drag-n-drop dfm that are currently in the base of 4.0. Fully functional. The larger menu driven window managers would be easily accomodated as extensions via hooks.

Posted by mikshaw on Oct. 10 2007,20:14

Ok! That makes complete sense to me now, thanks.
I think I already have swm around here somewhere...just never tried it in DSL before.

It's my opinion that Fluxbox 0.1.14 has been showing its age, as there seems to be an increase over the last few years in the number of window managers that provide a more robust environment while remaining relatively small or even smaller. Newer versions of Fluxbox are sadly suffering from both a much larger size and noticeable slowdown. It is still among my favorites, but I no longer consider it suitable for old hardware.

I'm looking forward to seeing how well dwm and dfm play together. I didn't care for the way xtdesk worked with dwm, but I don't care for xtdesk in itself =o)

EDIT: So far I like dfm much better than xtdesk, which is probably an obvious conclusion. There are things that really bug me about it, though, so I will probably use it only in a pinch (e.g. no extensions available at the moment), and for vanilla testing of extensions.
<bombast>
I have no love for desktop icons; the way I tend to work (fullscreen apps in a tiled wm or several overlapping apps in a non-tiling wm) forces me to have to move windows all the time in order to access the icons. This is pointless delay and effort when hotkeys and menus are generally always accessible regardless of what is on the desktop. Fortunately you don't have to use the desktop icons with dfm. There are still several useful features in this program.
I'm having a problem, at least in my personal dfm build, with opening directories in structure view. It worked the first time, and then again once a bit later, but every other time I've tried it the view flashed and disappeared. There was no error message to help find the trouble. Maybe this isn't a problem with the DSL version?
There is no documentation on the use of hotkeys. I had to push some random keys before discovering that Ctrl+q will close a window.
There doesn't seem to be any way to edit the right-click menu, as in adding application launchers to it?
Also doesn't seem to be a way to navigate directories using a single window. I haaate that behavior. Maybe I just haven't found the right switch yet.
I was going to complain about .dfminfo being an unreadable binary format, but i just discovered it's gzipped, so that's cool =)
</bombast>

I need to experiment with it more before I make a final opinion, but so far my personal choice would be to keep my current setup of using dwm, aterm, and mc for my desktop environment. The dfm/swm combo is still an excellent choice for a small but usable starting point in DSL, though. I really think it will be an improvement over fluxbox-0.1 and xtdesk

Posted by roberts on Oct. 11 2007,01:01

I would suggest that you download 4.0rc5 and at the minimum read the getting started doc. It has much information about the shortcuts, minimizing number of windows opened and general use of dfm currently in DSL. Much of which has been contributed by many who have already been using the release candidates.

I am planning to modify some of dfm's default behavior.

I know that some will always prefer tiling window managers and no icons.

Personally I use dfm/swm and use the Ctrl-Tab to switch to different desktops, so I have easy access to icons in a minimal 20 processes running upon boot system.

FYI swm is 26k, jwm is 113k and fluxbox 589k + fluxter 86k + /usr/share/fluxbox

Posted by mikshaw on Oct. 11 2007,01:28

Quote

Personally I use dfm/swm and use the Ctrl-Tab to switch to different desktops

That's the way I've been using dfm with dwm. At this time I'm still debating whether or not keeping the icons is worth it when I can access applications more quickly with hotkeys or dmenu.

One important thing I forgot to mention, though...
It's been so long since I've used drag-and-drop for *anything* that I forgot that it can be a very useful feature. I haven't quite figured out how it handles dragging one file onto another yet, but I'm sure that will come.

I feel like I'm needing to relearn the mouse-driven approach I left behind a few years ago =o)

Posted by humpty on Nov. 04 2007,19: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:

Posted by roberts on Nov. 05 2007,20:30

Eariler in this thread I wrote about making DSL more open to other window managers. If I had the luxury of only supporting unionfs it would be quite easy. In fact, I am showing my frustration of supporting so many features, editions, and operating modes of DSL.

Nevertheless, starting with v4.1 I am making the window manager a more open process. I have gotten rid the the restrictive case statment in dsl-config and .xinitrc. I have created support for a window manager include file processed by .xinitrc. I have tested this with a simple pwm.dsl loaded at boot time with only using desktop=pwm and it is working fine. Of course the included window managers work the same as before. I did remove swm.

This new process should make it easier to boot into other window managers without overwriting .xinitrc.

[EDIT] I should add the include is not required. Only need it the wm needs a mouse pointer, or starts slit or dockapps or other specifics.

Posted by ^thehatsrule^ on Nov. 05 2007,21:19

Quote (humpty @ Nov. 04 2007,14:34)

Use arrange? Or did you mean an option to auto arrange everytime the icon arrangement was changed?

Posted by mikshaw on Nov. 05 2007,21:45

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.

Posted by roberts on Nov. 06 2007,07:09

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?

Posted by ^thehatsrule^ on Nov. 06 2007,16:52

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.

Posted by curaga on Nov. 06 2007,17:08

I agree with ^hats^. I never use the run-time switching anyway.

Posted by roberts on Nov. 07 2007,22:05

OK. I am going to process only one mydsl menu for the current wm. Then upon switching managers, rebuild the mydsl menu for the newly selected wm. This should complete the opening of the mydsl menu processing code.

Posted by curaga on Nov. 08 2007,16:07

Is that done by having each wm specific code inside DSL, or by having the script in the extension under a standard name like "create-menu" or something?

Posted by roberts on Nov. 08 2007,16:28

I am supporting it all under /opt. This way it supports legacy mode.
You are correct to assume a common single simple name of the scripts that code in the core DSL will look for and process.

/opt/.mydsl_menu/jwm/ directory contains:

make - the code to make the mydsl menu include
restart - the code needed to restart/refresh to make the menu updates visible
menu_template - the "empty" or starting menu usually has a placeholder used as the target of insertion for the make script.

I did not use any extension (.lua, .sh, .pl) on the script names so that you can write your scripts in any supported language.

To remain backward compatible the default remains fluxbox menu specifications.

/opt/.mydsl_menu/fluxbox directory contains the same three named files but with content specific to fluxbox.

This way a .tar.gz (legacy able) extension can write to /opt/.mydsl_menu and the dynamic mydsl menu creation, update, and cleanup will all work.

For the main system menu ((static)) I am now using a bash include
to there is a fluxbox.inc and a jwm.inc. This include file is the code snippet that would have been needed inside the .xinitrc case statement.

Posted by curaga on Nov. 08 2007,17:07

Nice.

So all new wm extensions (with menus) would have to have those?

You should also post this in the sticky "Note to extension builders" thread..

Posted by humpty on Nov. 10 2007,04:19

Does this mean i can get back those retro 48x48 icons again? that would be way cool!

And what would the live cd default to ?

Posted by roberts on Nov. 10 2007,05:33

Quote (curaga @ Nov. 08 2007,09:07)

Nice.

So all new wm extensions (with menus) would have to have those?

You should also post this in the sticky "Note to extension builders" thread..

What is means is that wm extensions can seemlessly integrate with DSL.

No overwriting .xinitrc, or any of the mydsl scripts that process the dynamic mydsl menu, whether at boot time, runtime, or uci unloading (unmounting) the core scripts call code by wm reference to /opt/.mydsl-menu/wm_name

I will post a sticky when I post 4.1

Posted by roberts on Nov. 10 2007,05:51

Quote (humpty @ Nov. 09 2007,20:19)

Does this mean i can get back those retro 48x48 icons again? that would be way cool!

And what would the live cd default to ?

I am talking about window managers and their application menus.
This has nothing to do with the icon/file manager dfm used in v4.x

4.1 default will look much the same as 4.0, the only default being changed in the wm application menu defaults to being the right-click root menu. The default window manager for v4.x remains JWM.

The dfm menu can be called by right clicking any icon and the user has the choice whether to set dfm as the root menu. I have removed any switching changing the default root menu as was in 4.0. It gets out of sync and is confusing with the many entry points of wm selection and overrides.

4.1 was delayed as I added both the new user=name option as well as the refactoring of the mydsl processing code.

I have also made dfm's .dmfinfo as plain text ascii file. This will allow me to more easily make changes moving forward.

If you goal is 48x48 icons, note that you can use any size in dfm, but with so many icons it would take up too much space. And a collection of many sizes would break a consistent look.

Leaving xtdesk is what is allowing me to finally add the user=name option.

I understand that there will be those slow to accept change, that is why there is a 3.4 that is still be maintained (3.4.6, published today). But there will be a feature that will be the impetus to accept change. Perhaps it will be the user-name capability then again perhaps not. For the moment you have a choice of 3.x or 4.x, which ever suits your fancy.

Posted by roberts on Jan. 24 2008,18:37

I bring this topic back up because DSL v3.x is currently maxed out.
If you look at the byte count of the default iso it is 51200KB or 52,428,800.

I am thinking of dropping JWM from 3.x and dropping fluxbox from 4.x. As there are two planned updates that will need more space.

One can always use an extension to host their favorite widow manager.

Comments?

Posted by chaostic on Jan. 25 2008,06:39

Quote (roberts @ Jan. 24 2008,13:37)

I bring this topic back up because DSL v3.x is currently maxed out.
If you look at the byte count of the default iso it is 51200KB or 52,428,800. �

I am thinking of dropping JWM from 3.x and dropping fluxbox from 4.x. As there are two planned updates that will need more space.

One can always use an extension to host their favorite widow manager.

Comments?

Since I would have needed to remove jwm for my recompile, I welcome the work being done for me :P