(old)Puppy Linux Discussion Forum

Posted: **Wed 08 Feb 2012, 16:05**

Hello,
@npierce,
Thank you a lot for replying.

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

This works great

and doesn't seem to slow anything down (let me further watch!)

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.

Is it to say that Lucid and Quirky have got GDK version older than Wary and Racy?
Very strange indeed!

Regards

Posted: **Wed 08 Feb 2012, 18:16**

Argolance,

You're welcome. I'm glad to hear that (so far) it is working for you.

Argolance wrote:Is it to say that Lucid and Quirky have got GDK version older than Wary and Racy?

Probably. I'm not sure what versions they have, but they were based upon an older version of Woof.

You can find out what you have:

Code: Select all

ls /usr/lib/libgdk-x11-2.0.so.0.*

Racy 5.2.2 reports:

Code: Select all

/usr/lib/libgdk-x11-2.0.so.0.2400.8

which is commonly known as 2.24.8, and was released last November.

Posted: **Wed 08 Feb 2012, 18:27**

Hello
by updating from 5.1.4.1 to 5.2.2, the seamonkey emails, profile and adressbooks got "lost" . Is there an easy way to restore them ?
goeran

Posted: **Thu 09 Feb 2012, 05:50**

There is a problem with ffmpeg :
ffmpeg -i 'http://api.jamendo.com/get2/stream/trac ... &id=859750'
gives : No such file or directory
Is it because http protocol is not included in compilation ( --disable-network) ?

Posted: **Thu 09 Feb 2012, 13:54**

http://api.jamendo.com/get2/stream/trac ... &id=859750'
gives : Hoovers ride with me.mp3
....???

Posted: **Sat 11 Feb 2012, 03:14**

Did you try that ffmpeg command in wary ? If no, why do you answer this ?

Posted: **Sun 12 Feb 2012, 04:48**

Monsie wrote:@linuxcbon:

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

I know this already but in wary, it's empty by default, so should we keep empty folders ?

Posted: **Sun 12 Feb 2012, 04:53**

- is openSP needed ?
- is ogle needed ?
- can you make .pls files open with pmusic by default ?

Posted: **Tue 14 Feb 2012, 14:26**

npierce wrote: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.

I found some time to look into this further.

Apparently it works the way I hoped that it would. By setting GDK_NATIVE_WINDOWS in /usr/local/apps/ROX-Filer/AppRun instead of earlier, it is affecting only ROX-Filer, not applications started by ROX-Filer. So other GTK/GDK applications will continue to use "client-side windows", and should not suffer any loss of speed when creating windows.

The effect of GDK_NATIVE_WINDOWS can be seen with help from xwininfo.

With the unmodified ROX-Filer and libgdk-x11-2.0.so.0.2400.8, running

Code: Select all

xwininfo -children

and clicking on the pinboard (desktop), will result in something like this:

Code: Select all

xwininfo: Window id: 0x800024 "ROX-Filer"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0xaa (the root window) (has no name)
     1 child:
     0x800025 (has no name): ()  1x1+-1+-1  +-1+-1

The "ROX-Filer" window has only one child. (Yes, it looks like a one pixel window -- I have no idea what it is for.

)

But after killing ROX-Filer, copying the modified AppRun from my earlier post to /usr/local/apps/ROX-Filer/AppRun, and running

Code: Select all

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

xwininfo will report something like this:

Code: Select all

xwininfo: Window id: 0x800024 "ROX-Filer"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0xaa (the root window) (has no name)
     32 children:
     0x800056 (has no name): ()  58x75+1219+91  +1219+91
     0x800055 (has no name): ()  58x75+1219+187  +1219+187
     0x800054 (has no name): ()  58x75+1219+2  +1219+2
     0x800053 (has no name): ()  58x75+131+91  +131+91
     0x800052 (has no name): ()  58x75+131+187  +131+187
     0x800051 (has no name): ()  58x75+259+2  +259+2
     0x800050 (has no name): ()  58x75+195+91  +195+91
     0x80004f (has no name): ()  58x75+323+2  +323+2
     0x80004e (has no name): ()  66x75+383+2  +383+2
     0x80004d (has no name): ()  58x75+3+91  +3+91
     0x80004c (has no name): ()  64x75+2+187  +2+187
     0x80004b (has no name): ()  58x75+131+2  +131+2
     0x80004a (has no name): ()  58x75+67+2  +67+2
     0x800049 (has no name): ()  58x75+3+2  +3+2
     0x800048 (has no name): ()  58x75+3+283  +3+283
     0x800047 (has no name): ()  68x75+2+379  +2+379
     0x800046 (has no name): ()  58x75+67+91  +67+91
     0x800045 (has no name): ()  58x75+67+187  +67+187
     0x800044 (has no name): ()  58x75+195+2  +195+2
     0x800043 (has no name): ()  58x75+67+283  +67+283
     0x800042 (has no name): ()  58x75+3+699  +3+699
     0x800041 (has no name): ()  58x75+67+699  +67+699
     0x800040 (has no name): ()  58x75+131+699  +131+699
     0x80003f (has no name): ()  58x75+195+699  +195+699
     0x80003e (has no name): ()  58x75+259+699  +259+699
     0x80003d (has no name): ()  58x75+323+699  +323+699
     0x80003c (has no name): ()  58x75+387+699  +387+699
     0x80003b (has no name): ()  58x75+451+699  +451+699
     0x80003a (has no name): ()  58x75+515+699  +515+699
     0x800039 (has no name): ()  58x75+579+699  +579+699
     0x800038 (has no name): ()  58x75+643+699  +643+699
     0x800025 (has no name): ()  1x1+-1+-1  +-1+-1

Now the "ROX-Filer" window still has the child it had before, plus it has a child for each of the icons on my desktop. This is exactly what "GDK_NATIVE_WINDOWS=true" is supposed to do.

If I then click on the "setup" icon and ask xwininfo for a report on the children of its window, I get this:

Code: Select all

xwininfo: Window id: 0x4400003 "Puppy Setup"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0x6b0ffc (has no name)
     1 child:
     0x4400004 (has no name): ()  1x1+-1+-1  +202+221

There is only one child despite all of those buttons. So this application is still using "client-side windows", even though it was launched from ROX-Filer, which is using native X windows.

Apparently, ROX-Filer does not export GDK_NATIVE_WINDOWS to the applications that it starts. So even if that variable is exported to the environment before X is started, it will not pass it along.

But if you launch an application with the JWM menu, or from a terminal that was launched with the JWM menu, GDK_NATIVE_WINDOWS will be exported to the application.

For instance, if instead of setting GDK_NATIVE WINDOWS=true in /usr/local/apps/ROX-Filer/AppRun it was exported to the environment before starting X, it would affect all GTK/GDK applications launched with the JWM menu, and the xwininfo report for "Puppy Setup" would look like this:

Code: Select all

xwininfo: Window id: 0x4400003 "Puppy Setup"

  Root window id: 0xaa (the root window) (has no name)
  Parent window id: 0x6b235e (has no name)
     12 children:
     0x4400032 (has no name): ()  32x24+300+317  +528+564
     0x4400031 (has no name): ()  26x26+306+286  +534+533
     0x4400030 (has no name): ()  26x26+306+255  +534+502
     0x440002f (has no name): ()  27x27+305+223  +533+470
     0x440002e (has no name): ()  28x28+304+190  +532+437
     0x440002d (has no name): ()  26x26+306+159  +534+406
     0x440002c (has no name): ()  26x26+306+128  +534+375
     0x440002b (has no name): ()  26x26+306+97  +534+344
     0x440002a (has no name): ()  26x25+306+67  +534+314
     0x4400029 (has no name): ()  26x26+306+36  +534+283
     0x4400028 (has no name): ()  26x26+306+5  +534+252
     0x4400004 (has no name): ()  1x1+-1+-1  +227+246

Now it shows a native X window for each button, plus that mystery one-pixel window. In the case of "Puppy Setup" I don't think that this would cause any problems, but this example shows that exporting GDK_NATIVE_WINDOWS=true before starting X could affect any GTK/GDK application, which could cause performance issues with some applications. It is safer to just set it for ROX-Filer, as done by the modified /usr/local/apps/ROX-Filer/AppRun.

Bottom line: It looks like the modified /usr/local/apps/ROX-Filer/AppRun should not affect anything other than ROX-Filer itself.

Posted: **Wed 15 Feb 2012, 17:38**

Remarks:
- ayttm is not updated anymore.
- can you add modprobe of all cpufreq and ondemand modules in init ?
- rm /bin/*NOTUSED*
- rm /sbin/*NOTUSED*
- /root/.config/cwallpaper/ needs to be removed to use wallpaper ? (had a Segmentation fault).
- for rox thumbnails , are these needed ?
/root/.thumbnails/
/root/.thumbnails/normal/

Posted: **Fri 17 Feb 2012, 22:09**

Barry,
In the new "testing" version of lucid pup 5.2.8, I addressed issues that keep frustrating new users of pupdial. I submit them for consideration to be included in woof/wary/racy.

When instructed to omit the login ID and password for wireless modem connections, new users encounter the error message from wvdial complaining about the absence of those items. The remedy is to select "Stupid mode", which is not something novices could infer by themselves. To eliminate that booby trap, I made these changes (copied for my original posting):

- In the pupdial modem dialer, changed the label of the "Stupid mode" checkbox to "Bypass log-in", which is what it does -- many new users get frustrated when they delete the login and password default, following their ISP's instructions, and cannot connect, only to be advised to turn on Stupid mode, which is not at all obvious.
- In pupdial, also ensured that a login and password are passed to wvdial (which requires them) by filling the empty fields with the default values.

My label fix in 2 places is:

Code: Select all

       <label>Bypass log-in</label>

The latter fix is implemented thusly:

Code: Select all

#111231 Ensure non-null logon info for wvdial...
[ ! ${ENTRYACC1USER} ] && ENTRYACC1USER="MYUSERNAME"
[ ! ${ENTRYACC1PASS} ] && ENTRYACC1PASS="MYPASSWORD"
[ ! ${ENTRYACC2USER} ] && ENTRYACC2USER="MY2USERNAME"
[ ! ${ENTRYACC2PASS} ] && ENTRYACC2PASS="MY2PASSWORD"

echo '[Dialer Defaults]' > /etc/wvdial.conf

All but the last line would be inserted into wary 5.2.2's pupdial after line 696.

Thanks for considering this.
Richard

Posted: **Sat 18 Feb 2012, 00:16**

Hello,
@ npierce

Apparently it works the way I hoped that it would. By setting GDK_NATIVE_WINDOWS in /usr/local/apps/ROX-Filer/AppRun instead of earlier, it is affecting only ROX-Filer, not applications started by ROX-Filer. So other GTK/GDK applications will continue to use "client-side windows", and should not suffer any loss of speed when creating windows.

Thank you a lot for test, explanations and solution: I feel much better now!

On my side, I think I can say that this doesn't slow anything down.

Best regards;

Posted: **Sat 18 Feb 2012, 01:38**

rerwin wrote:Barry,
In the new "testing" version of lucid pup 5.2.8, I addressed issues that keep frustrating new users of pupdial. I submit them for consideration to be included in woof/wary/racy.

When instructed to omit the login ID and password for wireless modem connections, new users encounter the error message from wvdial complaining about the absence of those items. The remedy is to select "Stupid mode", which is not something novices could infer by themselves. To eliminate that booby trap, I made these changes (copied for my original posting):
- In the pupdial modem dialer, changed the label of the "Stupid mode" checkbox to "Bypass log-in", which is what it does -- many new users get frustrated when they delete the login and password default, following their ISP's instructions, and cannot connect, only to be advised to turn on Stupid mode, which is not at all obvious.
- In pupdial, also ensured that a login and password are passed to wvdial (which requires them) by filling the empty fields with the default values.
My label fix in 2 places is:
Code: Select all
       <label>Bypass log-in</label>
The latter fix is implemented thusly:
Code: Select all
#111231 Ensure non-null logon info for wvdial...
[ ! ${ENTRYACC1USER} ] && ENTRYACC1USER="MYUSERNAME"
[ ! ${ENTRYACC1PASS} ] && ENTRYACC1PASS="MYPASSWORD"
[ ! ${ENTRYACC2USER} ] && ENTRYACC2USER="MY2USERNAME"
[ ! ${ENTRYACC2PASS} ] && ENTRYACC2PASS="MY2PASSWORD"

echo '[Dialer Defaults]' > /etc/wvdial.conf
All but the last line would be inserted into wary 5.2.2's pupdial after line 696.

Thanks for considering this.
Richard

Done. See blog post:
http://bkhome.org/blog/?viewDetailed=02696

Posted: **Sat 18 Feb 2012, 07:41**

npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.

It is working for me too!

Trying to recall back when I last tried GDK_NATIVE_WINDOWS=true, I think that I put it as a prefix to the running of rox in /root/.xinitrc.

I was using it back then and noticed lots of gdk critical error reports on stderr, although I don't recall if anything actually crashed.

Anyway, I reckon that I will put your solution into the rox-filer PET pkg -- in the 'common' repo, the PET that most x86 Puppy builds use.

Posted: **Sat 18 Feb 2012, 08:01**

BarryK wrote:
npierce wrote:You're welcome. I'm glad to hear that (so far) it is working for you.
It is working for me too!

Trying to recall back when I last tried GDK_NATIVE_WINDOWS=true, I think that I put it as a prefix to the running of rox in /root/.xinitrc.

I was using it back then and noticed lots of gdk critical error reports on stderr, although I don't recall if anything actually crashed.

Anyway, I reckon that I will put your solution into the rox-filer PET pkg -- in the 'common' repo, the PET that most x86 Puppy builds use.

Disaster!

Now I recall what went wrong before, because it has happened again. I was scrolling down a fairly large directory, when the scrollbar froze. The entire rox window froze, but other rox window still work.

/tmp/xerrors.log has this:

Code: Select all

XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0"
      after 11851 requests (11851 known processed) with 0 events remaining.

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

(ROX-Filer:12439): Gdk-WARNING **: Native children wider or taller than 65535 pixels are not supported

...the rox window is not bigger than 65535 pixels!

So, as before, I find setting GDK_NATIVE_WINDOWS=true is not a viable workaround. I will post this forum page to the rox-file mail list, though the maintainers don't seem interested in fixing it.

Note, I use that same large directory every day with rox, no problem, without the GDK_NATIVE_WINDOWS set.

Posted: **Sat 18 Feb 2012, 20:19**

I compiled and made a sfs file of Thunderbird-10.0.2 mail reader in
racy-5.2.2.
I tested it in both racy-5.2.2 and wary-5.2.2
EDIT: It works in Saluki too.

The download link is:

http://www.datafilehost.com/download-165680c4.html

Posted: **Sat 18 Feb 2012, 23:58**

zekebaby wrote: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:
Code: Select all
for MOUNTPOINT in `mount | grep ':' | cut -d  ' ' -f 3 | tr '\n' ' '`
do
  umount -f $MOUNTPOINT
done 
Edit: made code more generic to detect other types of network drives such as sshfs

I would like to understand this situation better before implementing this solution.

Could anyone who has this kind of network drives, please post output of "mount" command? (that is, type "mount" in a terminal then ENTER key)

EDIT: anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697

Posted: **Sun 19 Feb 2012, 02:39**

BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697

I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.
http://www.murga-linux.com/puppy/viewto ... start=1734

Code: Select all

#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done

Posted: **Sun 19 Feb 2012, 08:33**

shinobar wrote:
BarryK wrote:anyway, I have put zekebaby's patch into rc.shutdown:
http://bkhome.org/blog/?viewDetailed=02697
I would like to propose another solution based on pemasu's idea on the Dpup Exprimo.
http://www.murga-linux.com/puppy/viewto ... start=1734
Code: Select all
#120203 pemasu and shinobar: space in smb or cifs share causes hanging in shutdown
for T in cifs smbfs nfs sshfs; do
  umount -a -t $T
done

shinobar,
I reponded to your post to my blog. Here is my repy:

shinobar,
that looks like a good solution. I just looked in the umount docs, this also will work:

umount -a -t cifs,smbfs,nfs,sshfs

However, this requires the full umount. In Woof, umount is a script that currently only calls the busybox umount I think, which does not allow the -t option.

Posted: **Sun 19 Feb 2012, 08:36**

Regarding the GDK_NATIVE_WINDOWS=true being a bad solution, see my post previous page.

The ROX-Filer focus problem has now been fixed! See my blog post, with a PET:

http://bkhome.org/blog/?viewDetailed=02698

(old)Puppy Linux Discussion Forum

Wary Puppy 5.2.2, 18 Nov. 2011

Re: Wary Puppy 5.2.2, 18 Nov. 2011

Further notes on ROX-Filer & GDK_NATIVE_WINDOWS

Human factors mods to pupdial

Re: Human factors mods to pupdial

Wary Puppy 5.2.2, 18 Nov. 2011

Re: Shutdown hangs (SOLVED)

Re: Shutdown hangs (SOLVED)

Re: Shutdown hangs (SOLVED)