Barry, I've run into an unusual intermittent x starting problem (I think) in Wary 5.2.2. Most of the time, it works perfectly, but about 1 in 5 times just as x usually starts, the screen goes blank, a "no signal" message appears briefly; then hangs with no command line, requiring a manual power reboot.

In Wary 5.2.2, I noticed a problem with shutdown hanging if I don't manually unmount NFS or SSHFS mounted drives before shutting down. Poking around rc.shutdown, I found that //network drives are unmounted, but the grep does not pick up host:dir mounted drives.

Adding the following 4 lines in rc.shutdown near Line 190 solves the problem:

Although I primarily see this problem in Wary 5.1.1, I have observed the following behavior in Wary 5.2 when I was testing it for possibly upgrading my version of Wary. I have observed this undesired behavior on 4 different computers. Streaming YouTube videos for a long period eventually ends in the streaming function becoming corrupted. It is difficult to point to a single event that causes the streaming function to become corrupted, as I have experienced the sudden degradation of streaming into a closed loop during the playing of a video. There is a good likelihood that burdening a uniprocessor system with multiple streaming threads accelerates the corruption. To reproduce this behavior, the user has to be constantly connected to YouTube with multiple streams and multiple instances of SM. The video(s) can already have played through. It helps to let the computer fall into rest mode and be revived. After 5 or 6 hours, all streaming becomes corrupted, and the only solution is to reboot the computer, which cures the problem. It all may be a Flash issue. Although this is something I can live with, I expect better of Puppy. The loss of streaming can be very inconvenient, and rebooting risks loss of data unless one is prepared and accustomed to it.

Boots up with 1680x1050 resolution.
Use Xorgwizard to set resolution to 1280x800.
Xorg restarts- still 1680x1050.
Use Menu>shutdown>restart X
Still 1680x1050
BUT XORG.CONF SAYS 1280x800
Reboot, still 1680x1280, but xorg.conf has gone back to 1680x1280.

Xorg is using the radeon driver.
EDIT: Live cd with savefile.Edited_time_total

Anyways that'd be a good idea to include SDL, if it doesn't take too much space.

- User session works great! Actually it's awesome to see that working on an official Puppy.

Main issue with it:

"Ok" button on the root authorization window (that appears when trying to do something that needs root access) doesn't work with the keyboard. Have to click with the mouse everytime, which is a bit of a pain. No big deal.

The empty opt directory is not an artifact or a bug. Some third party applications choose to install to this directory rather than /local and in my case I see that qt4 is installed in the opt directory.

Monsie_________________My username is pronounced: "mun-see". Derived from my surname, it was my nickname throughout high school.

Root Menu
The root menu in JWM is the primary way of starting programs. It also provides a way to restart or exit the window manager. Note that multiple root menus are possible. See the onroot attribute for more information. The outer-most tag is RootMenu. This tag supports the following attributes:

onroot
Determine which buttons on the root window activate the menu. This is a list of integers specifying buttons. The default is 123. Multiple root menus may be used by specifying different buttons to activate them. Valid values in this list are 0 to 9. The usual mouse buttons are 1 for the left button, 2 for the middle button, 3 for the right button, and 4 and 5 for the scroll wheel. Therefore, accessing root menus that are assigned to buttons 0, 6, 7, 8, or 9 will typically require the use of a tray button or key binding.

=> JWM Configuration.
This works fine running Puppy 4.x, Lucid 5.x, Quirky 1.4.2 but does not with Wary/Racy 5.x, something is going wrong:

This occurs whatever the versions of JWM or ROX-Filer are (I tested with 2.9, 2.10, and fresh self compiled 2.11 releases). Neither the filer nor window manager seem to be the reason of the problem!
If running

Code:

rox -p /root/Choices/ROX-Filer/PuppyPin

or getting back to the classical single Puppy MENU, all works well again!

Note: I noticed this issue on several PCs.
Very very annoying indeed, cause this bug disables part of an important script of the next French Toutou LINUX (based on Wary 5.x) .

I have attached a modified version of /usr/local/apps/ROX-Filer/AppRun which may get you going.

Back-up your original, then gunzip and copy this one to /usr/local/apps/ROX-Filer/AppRun, and restart the X server.

Please note that this has been briefly tested OK in Racy-5.2.2, so it is likely to work in Wary-5.2.2, but I can make no guarantees.

This may be more of a work-around than a true fix. Or it may be all that is needed. Either way, it should point you in the right direction.

The problem results from a change to GDK. Until sometime around 2009, GDK made an X11 window for each GDK window. That is not necessarily the case anymore. Now GDK makes what it calls "client-side windows". So now, an application that was designed to interact with an X11 window corresponding to one of its GDK windows may be disappointed to find that no such X11 window exists.

I think something like that is happening with ROX-Filer.

One way around that problem is to set an environmental variable, GDK_NATIVE_WINDOWS, true. Then GDK will create a native X11 window for each GDK window, making the application happy again.

This is all that my modified /usr/local/apps/ROX-Filer/AppRun does.

There is a potential downside to this: An application that uses "client-side windows" may have a speed advantage, and create windows slower if GDK_NATIVE_WINDOWS is set true for it.

I have not yet determined if setting GDK_NATIVE_WINDOWS=true will affect only ROX-Filer, or will affect every GTK/GDK application it opens.

The reason that I set it in /usr/local/apps/ROX-Filer/AppRun instead of /root/.xinitrc or earlier, is to, hopefully, limit its effect to ROX-Filer. But it is certainly possible that, once set, all GTK/GDK applications will be affected. I have noticed that when I use ROX-Filer to run urxvt, GDK_NATIVE_WINDOWS does not appear in the environment. So maybe I got lucky.

Admittedly, I have more success predicting the weather than the mysteries of GDK and GTK behavior.

I need to test some with GTK/GDK apps, but I thought that I would send this off to you so that you can try it out, rather than waiting for me to get around to doing more tests.

Let me know if this seems to slow anything down. Of course, unless an application has been optimized for "client-side windows", it should not run any slower than it did in early 2009.