Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 30 Sep 2014, 08:29
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Wary Puppy 5.2.2, 18 Nov. 2011
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 21 of 25 [361 Posts]   Goto page: Previous 1, 2, 3, ..., 19, 20, 21, 22, 23, 24, 25 Next
Author Message
Argolance


Joined: 06 Jan 2008
Posts: 1830
Location: PORT-BRILLET (Mayenne - France)

PostPosted: Tue 07 Feb 2012, 08:06    Post subject:  JWM multiple root MENUS problem with Wary/Racy 5.2
Subject description: Activating MENUS using mouse buttons make pinboard crash!
 

Hello,
Quote:
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:

    Arrow Buttons (3) inside the task bar... This is OK!
    Arrow Clicks on desktop display MENUS 1, 2, 3... This is OK! But...
    As soon as clicked on desktop ('root window') to display MENUS, Pinboard doesn't work properly anymore: desktop shortcuts, drives icons, files/directories listed inside Rox windows don't react to mouse events. This error message is found in /tmp/xerrs.log:
Quote:
** (ROX-Filer:5535): CRITICAL **: pinboard_pin_with_args: assertion `current_pinboard != NULL' failed
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) .

http://www.murga-linux.com/puppy/viewtopic.php?p=601697#601697

Regards

_________________

Back to top
View user's profile Send private message Visit poster's website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Tue 07 Feb 2012, 23:14    Post subject: JWM multiple root MENUS problem with Wary/Racy 5.2  

Argolance wrote:
As soon as clicked on desktop ('root window') to display MENUS, Pinboard doesn't work properly anymore: desktop shortcuts, drives icons, files/directories listed inside Rox windows don't react to mouse events.

Argolance,

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. Smile

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.
AppRun.gz
Description  Modified version of /usr/local/apps/ROX-Filer/AppRun
gz

 Download 
Filename  AppRun.gz 
Filesize  799 Bytes 
Downloaded  251 Time(s) 
Back to top
View user's profile Send private message 
Argolance


Joined: 06 Jan 2008
Posts: 1830
Location: PORT-BRILLET (Mayenne - France)

PostPosted: Wed 08 Feb 2012, 12:05    Post subject:    

Hello,
@npierce,
Thank you a lot for replying.
Quote:
I have attached a modified version of /usr/local/apps/ROX-Filer/AppRun which may get you going.
This works great Very Happy and doesn't seem to slow anything down (let me further watch!)
Quote:
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

_________________

Back to top
View user's profile Send private message Visit poster's website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Wed 08 Feb 2012, 14:16    Post subject:  

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:
ls /usr/lib/libgdk-x11-2.0.so.0.*

Racy 5.2.2 reports:
Code:
/usr/lib/libgdk-x11-2.0.so.0.2400.8

which is commonly known as 2.24.8, and was released last November.
Back to top
View user's profile Send private message 
goeran

Joined: 20 May 2005
Posts: 5

PostPosted: Wed 08 Feb 2012, 14:27    Post subject:  

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
Back to top
View user's profile Send private message 
linuxcbon

Joined: 09 Aug 2007
Posts: 762

PostPosted: Thu 09 Feb 2012, 01:50    Post subject:  

There is a problem with ffmpeg :
ffmpeg -i 'http://api.jamendo.com/get2/stream/track/redirect/?streamencoding=mp31&id=859750'
gives : No such file or directory
Is it because http protocol is not included in compilation ( --disable-network) ?
Back to top
View user's profile Send private message 
goeran

Joined: 20 May 2005
Posts: 5

PostPosted: Thu 09 Feb 2012, 09:54    Post subject:  

http://api.jamendo.com/get2/stream/track/redirect/?streamencoding=mp31&id=859750'
gives : Hoovers ride with me.mp3
....???
Back to top
View user's profile Send private message 
linuxcbon

Joined: 09 Aug 2007
Posts: 762

PostPosted: Fri 10 Feb 2012, 23:14    Post subject:  

Did you try that ffmpeg command in wary ? If no, why do you answer this ?
Back to top
View user's profile Send private message 
linuxcbon

Joined: 09 Aug 2007
Posts: 762

PostPosted: Sun 12 Feb 2012, 00:48    Post subject: Re: Wary Puppy 5.2.2, 18 Nov. 2011  

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 ?
Back to top
View user's profile Send private message 
linuxcbon

Joined: 09 Aug 2007
Posts: 762

PostPosted: Sun 12 Feb 2012, 00:53    Post subject:  

- is openSP needed ?
- is ogle needed ?
- can you make .pls files open with pmusic by default ?
Back to top
View user's profile Send private message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Tue 14 Feb 2012, 10:26    Post subject: Further notes on ROX-Filer & GDK_NATIVE_WINDOWS  

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:
xwininfo -children

and clicking on the pinboard (desktop), will result in something like this:
Code:
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. Smile )

But after killing ROX-Filer, copying the modified AppRun from my earlier post to /usr/local/apps/ROX-Filer/AppRun, and running
Code:
rox -p  /root/Choices/ROX-Filer/PuppyPin

xwininfo will report something like this:
Code:
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:
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:
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.
Back to top
View user's profile Send private message 
linuxcbon

Joined: 09 Aug 2007
Posts: 762

PostPosted: Wed 15 Feb 2012, 13:38    Post subject:  

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/
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1517
Location: Maine, USA

PostPosted: Fri 17 Feb 2012, 18:09    Post subject: Human factors mods to pupdial  

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:
       <label>Bypass log-in</label>

The latter fix is implemented thusly:
Code:
#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
Back to top
View user's profile Send private message 
Argolance


Joined: 06 Jan 2008
Posts: 1830
Location: PORT-BRILLET (Mayenne - France)

PostPosted: Fri 17 Feb 2012, 20:16    Post subject:  

Hello,
@ npierce
Quote:
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! Cool
On my side, I think I can say that this doesn't slow anything down.

Best regards;

_________________

Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Fri 17 Feb 2012, 21:38    Post subject: Re: Human factors mods to pupdial  

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:
       <label>Bypass log-in</label>

The latter fix is implemented thusly:
Code:
#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

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 21 of 25 [361 Posts]   Goto page: Previous 1, 2, 3, ..., 19, 20, 21, 22, 23, 24, 25 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1416s ][ Queries: 12 (0.0084s) ][ GZIP on ]