Wary 1.0.2 (102) feedback

[emil]

I am here with a reminder for new xgamma-gui.
It looks the same but it is completly rewritten under the hood.
detailed description here

[ravensrest]

I just verified rjbrewer's results for two PS/2 mice, one optical, one mechanical. If I hold either very still, I can push the right button all I want without causing any icons to disappear. BTW, another apparent related effect is that if I right click anywhere on the screen to call up the menu, it sometimes just appears briefly and then goes away. Again, if I hold the mouse very still, this does not happen. Or just keep the right button depressed until I make a menu selection.

I was convinced it was a bounce problem, but now not so sure.

I addition, Gyle, I don't think processing time is any longer a major consideration in "debouncing" a mouse. I know I have had systems that do so. Further, many systems let you input a double click to calibrate the mouse driver. This is an indication it can't take much time.
BS

[Gyle]

BTW, another apparent related effect is that if I right click anywhere on the screen to call up the menu, it sometimes just appears briefly and then goes away. Again, if I hold the mouse very still, this does not happen. Or just keep the right button depressed until I make a menu selection.

I think it is clearly a different issue, related to the movement of your hand not to the mouse or the soft. Look at very precisely what happens:
when you Right click on the pinboard, the cursor is at the extreme left top corner of the menu, a very small area, like the point of a needle. When you relax the Right button nothing happens because the cursor is always on the menu, but, if in the same time than you relax, you move just a tiny bit toward the pinboard (out of the menu = you are now on the pinboard) the pinboard is activated by the relax and you loose the menu. The "problem" is what I have said in a previous post, that the programmer of the mouse routine in X has not desactivated the relax of the button after the first Right clich which opens the menu or whatsoever.

Edit: it is above the median line of the screen that we find the cursor at this spot. The problem is less sensible along the vertical edge of the menu when the cursor is in the low area of the screen.

I was convinced it was a bounce problem, but now not so sure.

You are right, doubt is a very good "fuel". We must investigate further.

I addition, Gyle, I don't think processing time is any longer a major consideration in "debouncing" a mouse. I know I have had systems that do so. Further, many systems let you input a double click to calibrate the mouse driver. This is an indication it can't take much time.

Yes, a debouncing routine is just a loop to count, a timer. The complexity is where to bind this routine, when to trigger it, by what means (e.g.interruption ?), how long time the ticket in a round robin, priority, etc...
Cheers

[Gyle]

I

just verified rjbrewer's results for two PS/2 mice, one optical, one mechanical. If I hold either very still, I can push the right button all I want without causing any icons to disappear.

You have put an emphasis on the word "still" several times in your posts.
You are thus sensitive to the fact that the mouse has to set a certain resistance. This resistance depends mainly on its weight when skates are new and the surface is good.
This resistance opposes in fact to the tiny shivers of your hand and your fingers. These micro shivers are the cause of the bounces. If you can look on a scope at the unsticking of the contacts, you will notice that it is about an oscillation which weakens and stops The goal of the debouncing is to not acquire a new information from the contact till a predefined count (in millisecond) is over. It's a delay during which nothing is acquirred, and long enough to tell to the program that the scan of the buttons is now relevant.
When Sage and I have spoken of the qualities of mice, the weight is a very important one. But weight has a price (commercially..he he).
Second, Sage spoke of the quality of the springs of the microswitches.
They play the role to unsticking the contact the quickest possible, etc...
I stop here, you understand that new soft, OS etc.. need more quality from the hard and vice-versa.

Edit: of course bounces exist when there is no human input. The contacts of a relay are subjects to bounce,this is a crucial problem in automotive, because the small bounces between contacts creates small electrical arcs which are very destructive for the quality of the surface. This quality has a price.

kind regards

[smokey01]

would be nice if you had an option to edit the iso image on the fly and rebuild the iso image straight away
ttuuxxx

ttuuxxx a man of your talent should be able to knock something up in no time flat.

[BarryK]

For those of you that wish to remove pre-installed packages before remastering, I threw together this little script with a very basic gui and reverse dependency checking (only informational - it does not automatically select the reverse dependencies for removal). It should work with most if not all recent woof-built variants.

Code: Select all

#!/bin/sh
D=$HOME/.packages/builtin_files
PKGS=`ls -1 $D`
PKG=`Xdialog --stdout --combobox "select package to remove" 0 0 $PKGS`
[ $PKG ] && Xdialog --yesno "Reverse dependencies:
`cat $HOME/.packages/woof-installed-packages |grep +$PKG |cut -d "|" -f2`

Continue?" 0 0 && [ $? ] && for x in `cat $D/$PKG`; do [ -d $x ] && cd $x || rm $x; done && rm $D/$PKG && $0

Note:pasted from an XP machine => may need dos2unix

Great! I have jazzed it up a bit...

Have put 'remove_builtin' into /usr/sbin in Woof, also created a menu entry.

Just tried it then did a remaster, works a treat. Have to remember to run fixmenues though.

Thanks for this.

Good idea. I have added code that sees if there is a .desktop file in pkg, if so then runs fixmenus, and if jwm running then restarts it.

[BarryK]

I am here with a reminder for new xgamma-gui.
It looks the same but it is completly rewritten under the hood.
detailed description here

Wary is frozen, as just about to release RC. That applies to Woof as well. Will consider upgrades after Wary final is out.

[scheck.r]

Two irksome effects:

First, it appears that sometimes the first mouse click doesn't count when activating an application from the desktop even if "Single-click to open" is set in the pinboard configuration. I think this was reported for Wary 098 also. In addition the same effect sometimes seems to occur if single click navigation is not set and one double clicks on a file or directory in RoxFiler; it takes three clicks. This seems to happen when focus has been elsewhere even if focus is first transferred back to RoxFiler by clicking on it somewhere.

Second, sometimes a quick right click on a drive icon will cause it to disappear. Or, if I change the settings for the disk icon manager, it does not necessarily refresh. I can cause it to do so by rebooting, restarting X, or running pup_event_frontend_d from the console. Would in make sense to add a "Restart frontend" to the shutdown menu or when exiting the eventmanager?

BS

A single click solution from 098:

http://murga-linux.com/puppy/viewtopic. ... 682#468682

This solution works great, thanks !

[technosaurus]

Great! I have jazzed it up a bit...

Have put 'remove_builtin' into /usr/sbin in Woof, also created a menu entry.

Barry

When you "jazzed up" my script, you replaced my reverse dependency checking code (which is useful info when removing a package to keep from breaking other packages) with dependency checking code which is really only useful when _installing_ a package, not removing it.

here is the code

EDIT: added empty directory removal - to remove directory trees left behind such as /usr/share/programX/,,,

Code: Select all

for x in `tac $D/$PKG`; do [ -d $x ] && [ ! "`ls $x`" ] && rmdir $x; done

add before:
rm $D/$PKG

[scsijon]

deleted, found wanted packages

(dbus is not in by default and doesn't seem to be in ppm either)

[01micko]

Have found that there seems to be no dbus and libdbus in wary102.

Was this an error or is there pets out there I can make a dependancy.

thanks
scsijon

I think it's meant to be that way scsijon...

Barry usually compiles seamonkey with "--disable-dbus" as an option. I'm pretty sure the quirky versions are fine if you require dbus.

The rationale is that a daemon is removed, making wary faster on older kit.

hth, cheers

[BarryK]

I have uploaded Wary 104, Release Candidate, new forum thread:

http://murga-linux.com/puppy/viewtopic.php?t=63226

[smokey01]

Great! I have jazzed it up a bit...

Have put 'remove_builtin' into /usr/sbin in Woof, also created a menu entry.

Barry

When you "jazzed up" my script, you replaced my reverse dependency checking code (which is useful info when removing a package to keep from breaking other packages) with dependency checking code which is really only useful when _installing_ a package, not removing it.

here is the code

EDIT: added empty directory removal - to remove directory trees left behind such as /usr/share/programX/,,,

Code: Select all

for x in `tac $D/$PKG`; do [ -d $x ] && [ ! "`ls $x`" ] && rmdir $x; done

add before:
rm $D/$PKG

technosaurus I was wondering if it had a failsafe built in. I used the script to remove gnome-player and installed vlc as I prefer it. I then added skype and pidgin. Neither skype or pidgin would run as they were missing libXss.so.1. I then used the edit-sfs script to put libXss.so.1 back in /usr/lib and all worked fine.

Does the script you now posted prevent dependencies being deleted if they are required by another package?

Thanks

[technosaurus]

It only warns you about the reverse dependencies (provided that the dependencies are correct in that package) - the user is completely free to ignore the warning though (in case they want to delete the reverse deps as well, or plan to install an alternative package)

What becomes difficult is when a package has multiple libraries and only one or two provide a dependency (this is why debian splits up their packages so much) That seems to be what you have done ... no point in crippling advanced users from taking an action that they know how to mitigate, but we need to be prudent and at least warn about possible breakages (and also inform about other packages that could be eliminated) This should serve as a caution to packagers not to include library dependencies in their packages and instead split them off as a separate package (and remember to add the dependency info).

[ravensrest]

OK, this is NOT a contact bounce or "chatter" problem. BTW, chatter is a function almost exclusively of the switch materials and construction, not motion of the mouse (except perhaps during extreme acceleration like by dropping or throwing). It can be cured by wetting the contacts, or filtering the switch output in either hardware or software. I presume almost all modern mice (mine are Logitech) impliment some form of debouncing.

The problem we have is in the way the mouse handler functions, and occurs with any pop-up menu in Puppy at least as far back as Pupp431**, the earliest I have installed. What happens is this: pressing the right mouse button causes a pop-up menu to appear. If the cursor is over empty desktop, the main menu. If over an icon, the menu appropriate to that icon. Selection of a menu item takes place whenever the next "mouse button released" event occurs. Doesn't matter if it is right or left. If the cursor at time of release is over an executable selection, that selection is implimented. You can verify this; pop up the main menu by pressing and releasing the right button. Now move the mouse cursor to an empty spot on the desktop. Press and hold a button. Nothing happens. Then release the button. Menu disappears. While holding the button depressed you could also have moved the cursor over an executable item before releasing it, and that item would have been selected. On my Puppy 431, for instance, the drive icon menus appear with the cursor almost over the "Edit Item" selection. Occasionally that dialog box does appear when I right click on a drive icon if the mouse was in motion when the right button was clicked and released. With Wary xxx drive icons, the selection almost under the cursor when the right button is pressed is "Remove Item(s)", so if the mouse is moving just a bit towards that selection when the button is released, the icon is removed. This also explains why my "work around" of holding the right button depressed until I make my desired selection works -- the "mouse button open" event doesn't occur until I finally release the button. Now, if you hold your mouse very still, and then press and release the right button on the empty desktop, the cursor is at the extreme upper left corner of the main menu. This is not quite on the empty desktop, nor on the sensitive area of the "Desktop" selection. That is, there is no executable selection under the cursor, so the main menu just remains on screen and nothing happens. You can find other areas of the main menu that are not sensitive too, for instance the dividing line between menu selections. If you press and hold the right button and move the cursor to one of these areas before releasing it, again nothing happens. One solution to this problem without changing the mouse handling routine would simply be to make the non-senstive areas of the menus larger. With Wary in particular as concerns the drive icons, reordering or moving the menu selections or the icons themselves would probably work (in fact, gjuhasz suggested moving the icons in his "work around"). Another work around to prevent deleting the drive icons would be to line the icons up the side of the screen rather than the bottom; then the cursor comes up on "Edit Item".

**It also happens with other OS. I tried the same mouse and computer with PCLinuxOS, DSL, Fedora, and OpenSUSE. PCLinuxOS is the only OS that actually waits for the next "mouse button closed" event before selection occurs. The other three all use the next "mouse button open" event for selection. Fedora either uses a bigger border around the sensitive areas or impliments a delay before selection can occur because no matter how hard I tried, I could not duplicate this problem in Fedora. With OpenSUSE and DSL, I can. DSL is about as sensitive as Puppy, and OpenSUSE appears a bit less so.

BS

[Shep]

Most puppies have mimencode for base64 encoding. Wary gets around a missing mimencode by allowing uuencode to take the -m option to handle base64 encoding. Fair enough.

But how to decode base64 in Wary? Busybox's uudecode does not know about a -m option.

Code: Select all

# uudecode --help
BusyBox v1.17.2 (2010-09-28 21:52:28 GMT-8) multi-call binary.

Usage: uudecode [-o OUTFILE] [INFILE]

Uudecode a file
Finds outfile name in uuencoded source unless -o is given

[npierce]

But how to decode base64 in Wary? Busybox's uudecode does not know about a -m option.

If the file was encoded by uuencode -m, uudecode will recognize that it is base64, because uuencode indicates that it is base64 in the first line of the encoded file.

If the file was encoded by mimencode, things are not as simple, since mimencode doesn't indicate the type of encoding in the file.

If you have such a file, you can supply that information by using the following one-line command (although it might get wrapped to two lines in your browser window) to give uudecode something that it recognizes:

Code: Select all

echo -e "begin-base64 644 decoded_file\n`cat encoded_file`\n====" | uudecode

The above command decodes a file named "encoded_file" to a file named "decoded_file", and gives it permissions 644.

If you do this a lot, you may want to write a short script -- something like this:

Code: Select all

#!/bin/bash

if [ -f "$1" ] && [ -r "$1" ] && [ -n "$2" ] ; then

echo -e "begin-base64 `stat --printf %a "$1"` $2\n`cat "$1"`\n====" | uudecode

elif [ -e "$1" ] && [ -r "$1" ] && [ -n "$2" ] ; then

echo "$1: not a regular file"

elif [ -e "$1" ] && [ -n "$2" ] ; then

echo "$1: Read permission denied"

elif [ -n "$2" ] ; then

echo "$1: file not found"

else

echo -e "Usage:\n\t$0 <encoded_file> <decoded_file>"

fi

I've double-spaced to make clear the individual lines, despite how they might wrap in your browser window.

The script decodes the file named in the first argument to the file named in the second argument, and gives the decoded file the same read, write, and execute permissions as the encoded file.

Of course it might be easier to install mimencode, and would be easier still if it was included with the distro.

[Shep]

But how to decode base64 in Wary? Busybox's uudecode does not know about a -m option.

If the file was encoded by uuencode -m, uudecode will recognize that it is base64, because uuencode indicates that it is base64 in the first line of the encoded file.

Thank you for the trouble you went to in answering my question. A week after posting I remembered I should just copy the binary from another puppy (TXZ) and it runs just fine in Wary. I now store it outside the save file so I can call it from whatever puppy is lacking that binary.

The most logical solution would be for uudecode to accept the -m argument. Or couldn't it simply interpret the differing line lengths as indicative of UU or base64?

Most often I copy the block of base64 stuff out of an email, without headers, and need to decode it.

Again, thanks.

[npierce]

Shep,

You're welcome.

I'm glad to hear that you now have a mimencode binary that your Puppies can share -- a good solution.

I would think that the need to decode base64 e-mail attachments would be common enough to justify the little 9 kB footprint that mimencode would require in Wary. Although I enjoyed looking into finding a way to do it with uudecode, many users won't want to go to that length.

Of course, if uudecode had an option for this, as you suggested, that would be a space-saving alternative.

[ttuuxxx]

Hi Barry I also spent 2 days on trying to get the wxgtk email client going and well its a no go, lol
So I went on a hunt for another email, client for your repo.
Well I found one its a Gnome email client called Balsa, I made just about all the deps static, lol only esmtp needed to be shared, It needed Gconf,Orbit, Dbus, etc. I manually removed Dbus from Gconf, what a pain that was, I'll post the sources for Gconf-No-Dbus later. I managed to get them to compile statically. Anyways here's a package its not 100% complete yet, I need to workout which gnome icons it needs, But it would be good to get it tested by users. Spellcheck works, I statically compiled gtkspell, Pop3 works for Gmail, I need to figure out what's being called when you click a url in a message, because It doesn't find the handler, probably yelp or ghelp.
I'll keep working on it.
ttuuxxx