Drive Icons All Bunched Up In The Corner

Using applications, configuring, problems
Message
Author
User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#21 Post by Ghost Dog »

Ok, so I'm trying this on Slacko 5.3. I opened up the sfs, and dropped Karl's new file in to replace the old pup_event_frontend_d.

It definitely spaces out the drive icons nicely on the screen. Only thing is, I have the drive icons on the "right" in eventmanager, but the new script ignores that and places the icons on the left. It also seems to ignore the ICON_PLACE_EDGE_GAP variable, so that the tray at the top covers over part of the first drive icon.

Is there any way to fix these last two issues?

And thanks! :D
The Way of the Samurai

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#22 Post by Karl Godt »

Nice to hear :D ! Had not tested the file myself :oops:
Just took it out of the wary .sfs and edited it .

The pup_event* files I have running are messed up in terms of script cleanlyness and code but are working more or less .

Hmmm .. About that the icons are overlapped by the jwm tray, we need to know the output for

Code: Select all

xwininfo -root | tail
(last 10 lines)
Last or 2nd last line should look like
-geometry 1600x1200+0+0

and

Code: Select all

grep -r pinboard_grid_step $HOME/.config/*
which should look like
/root/.config/rox.sourceforge.net/ROX-Filer/Options: <Option name="pinboard_grid_step">16</Option>

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#23 Post by Ghost Dog »

I've got my tray at the top of the screen. Have to make ICON_PLACE_EDGE_GAP variable work again, or change it to 48 or something.

Also, the icons are on the left vertically when they are supposed to be on the right. I don't think the new script is reading the info from eventmanager.
The Way of the Samurai

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#24 Post by Ghost Dog »

Know what I mean, Karl?
The Way of the Samurai

User avatar
Smithy
Posts: 1151
Joined: Mon 12 Dec 2011, 11:17

#25 Post by Smithy »

A bit radical, but after trying edge gap stuff and not having much luck with it, I decided to stick the regular Icons in a taskbar.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#26 Post by npierce »

Hi Ghost Dog,

I am trying to get my head around this problem, and hoping to reproduce the problem on my PC. It would be helpful if you could post your /etc/eventmanager file, so that I will know what the settings are when you see the bunched-up drive icons.

At what screen resolution(s) do you see the problem?

And, not absolutely necessary, but since a picture can be worth a thousand words, a screenshot would help me to know if I understand just what the problem is. Just the corner where the drive icons congregate is enough.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#27 Post by Karl Godt »

Know what I mean, Karl?
First was BIG QUESTION MARK .

Now have fired up Slacko-5.3.0

and this was missing :oops: :

Code: Select all

PIN_GRID_STEP=`grep "pinboard_grid_step" $HOME/.config/rox.sourceforge.net/ROX-Filer/Options | sed -e "s/ *<[^>]*>//g"`
[ ! $PIN_GRID_STEP ] && PIN_GRID_STEP=16 #16=medium.
[ $PIN_GRID_STEP -eq 0 ] && PIN_GRID_STEP=16 #precaution.
PIN_GRID_STEP2=`expr $PIN_GRID_STEP \/ 2` 
MAX_X=`expr $SCRN_X - 96`
MAX_Y=`expr $SCRN_Y - 96`
from shinobar's nifty pin grid step code .
He put it inside the function, so these 6 lines would have been executed for every singe partition , but these values need to be read only once .
Just place the above code over the free_coord_simple(){ line .
Otherwise COORD_Y would be always empty and rox would assign the icons slightly unexpected :D

Will replace the attachment later ..

EDIT > done .

User avatar
Chili Dog
Posts: 161
Joined: Tue 20 Dec 2011, 11:17

#28 Post by Chili Dog »

Cool. :D

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#29 Post by Ghost Dog »

Hi npierce, sorry I don't know at the moment what the resolution is, I'm working out of town and don't have access to my laptop. In a couple of weeks I should be able to provide more information.

That also means I can't try Karl's new changes yet. Looking forward to trying it, though. Hopefully it sees the stuff in eventmanager about the spacing from the edge and putting the icons on the right!

Thanks guys. :D
The Way of the Samurai

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#30 Post by Karl Godt »

npierce wrote: And, not absolutely necessary, but since a picture can be worth a thousand words, a screenshot would help me to know if I understand just what the problem is. Just the corner where the drive icons congregate is enough.
Really messed up drive icons :D
Attachments
Icons-bunched-up-in-the-corner.jpg
(11.78 KiB) Downloaded 217 times
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#31 Post by npierce »

Ghost Dog,
Ghost Dog wrote:. . . sorry I don't know at the moment what the resolution is, I'm working out of town and don't have access to my laptop. In a couple of weeks I should be able to provide more information.
O.K. We can pick this up when you return. Although it looks like Karl has already found the cause, and probably a solution.

I am guessing that your problem occurs at a screen resolution of 1366x768 (other possibilities might be 854x480, 1400x1050, or 1680x1050).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Karl,

Thanks for the screenshot. What settings caused that?

/etc/eventmanager:
ICON_PLACE_EDGE_GAP
ICON_PLACE_START_GAP
ICON_PLACE_SPACING

/root/.config/rox.sourceforge.net/ROX-Filer/Options:
<Option name="pinboard_grid_step">

What root window size?

And pup_event_frontend_d was from which Puppy version?

Thanks.


Great detective work on your part for tracking down the cause of this!

User avatar
MinHundHettePerro
Posts: 852
Joined: Thu 05 Feb 2009, 22:22
Location: SE

#32 Post by MinHundHettePerro »

npierce,

I used to have difficulties with drive-icons piling up when I was using a vertical screen resolution of 600 (now, that I'm on a screen height of 1024, the problem is moot).

It was a long time ago now, but the problem involved, iirc, the grid-step in Rox and pup_event's "screen-height minus whatever bottom-clearance not being equal to top-clearance plus a multiple of vertical grid-steps - when rounded off to Rox's grid step".

Puppy's solution involved, iirc, setting the grid step in Rox to fine, i.e. 2, ......

Anyway, searching back (in memory, as well as in the forum), I seem to have posted something that might provide some clues ...

Don't know if that old post contains the solution for all situations, though. Just from the very back of my memory - there might have been some issue with the "standard" JWM panel height growing from 26 to 28 ...


Cheers :)/
MHHP
[color=green]Celeron 2.8 GHz, 1 GB, i82845, many ptns, modes 12, 13
Dual Xeon 3.2 GHz, 1 GB, nvidia quadro nvs 285[/color]
Slackos & 214X, ... and Q6xx
[color=darkred]Nämen, vaf....[/color] [color=green]ln -s /dev/null MHHP[/color]

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#33 Post by Karl Godt »

npierce , this stacking was a fault in my experimental code, trying to add some jwm tray values into it, which did not succeed as it depends on the many possible screen resolutions .

The icon theme fault had been a /root/file $HOME/file mismatch in frontend_d and /etc/rc.d/functions4puppy4 as HOME was '/' that time launching xwin without PATH and HOME adjustments from /etc/inittab .

I suspect something like a
vga= setting like 1280x1024 , modeset=1 for the kernel and xorg.conf preferred mode=1024x768 mismatch
might causes such behavior ie rox gets XY values passed that are below the current xorg screen resolution ,

Seems that xwininfo -root shows the kernel screen, not the xorg screen .

Might be also that the kernel driver has a bug in these regards, modesetting the kernel console to something biggger, than the chip is capable to draw .
Such can be observed if the prompt vanishes at the bottom and shows some commandline output only if you hit 10x return.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#34 Post by npierce »

MHHP,

Thanks for the information.

Yes, I believe Ghost Dog's problem is similar to yours from 2009.

The problem that you solved for yourself in 2009 (or before) was solved for official Puppies that October when Barry included in Puppy 4.3.1 a fix from shinobar that shinobar had already included in one of his Puppies (possibly Puppy v4.20p1JP).
MinHundHettePerro wrote:It was a long time ago now, but the problem involved, iirc, the grid-step in Rox and pup_event's "screen-height minus whatever bottom-clearance not being equal to top-clearance plus a multiple of vertical grid-steps - when rounded off to Rox's grid step".
Yes, that's a good description of the problem (although I don't think there was any "top-clearance" involved). In modern Puppy terms, the script placed the bottom row of icons at a Y coordinate equal to screen height minus $ICON_PLACE_EDGE_GAP. Back then what is now $ICON_PLACE_EDGE_GAP was hard-coded in the script at 64 (which is still its default value today). So 600 - 64 = 536, which is not an exact multiple of 16 or 32, the "Medium" and "Coarse" "pinboard_grid_step" values. The script would think it placed the icons at 536, but ROX-Filer would snap them to the grid at 544, which was the closest grid line at either of those two settings.

(There was a little bit of a fudge factor built into pup_event_frontend_d. It could often find an existing icon even if the coordinates were close but not exactly the same. It did this by ignoring the least significant digit when comparing the values. So an icon with a coordinate of 320 could match when looking for a coordinate with the value of 328, since it actually just compares 32 to 32. But in this case, that fudge factor wasn't good enough, since it compared 54 to 53.)

MinHundHettePerro wrote:Puppy's solution involved, iirc, setting the grid step in Rox to fine, i.e. 2, ......
Right. That would work for any even-numbered screen height. Also, a grid step of 4 or 8 would have worked for a screen height of 600 (and for some, but not all, of the other screen heights that gave trouble with steps of 16 or 32).

In addition to 600, other existing screen heights that might have shown the problem when ROX-Filer's "pinboard_grid_step" was set to "Medium" (16) would be 200, 854, 900, 1050, and 1080. All of those screen heights might also have shown the problem with a "pinboard_grid_step" of "Coarse" (32), and additionally these heights might have shown the problem: 240, 720, and 1200.


The fix from shinobar worked fine when placing drive icons along the bottom of the desktop, and that was all that was needed at the time, since the bottom of the desktop was the only place that Puppy placed them in Puppy 4.3.1 and before. Then in December of 2009, Barry added the ability for the user to place them along the other edges of the desktop.

That change opened the door to a similar problem if a user chose to have the drive icons arranged vertically along the right edge of the desktop. Again, using the default values (now in /etc/eventmanager), the problem would only appear with certain screen resolutions. For instance, a resolution of 1366x768, when used with the default $ICON_PLACE_EDGE_GAP of 64, would cause the X coordinate for the first drive icon to be 1366 - 64 = 1302. If the user set the ROX-Filer icon grid steps to "Medium" (16) or "Coarse" (32), ROX would not place the icon at X coordinate 1302 since that is not a multiple of 16 or 32, but would place it at 1296 (if "Medium" grid) or 1312 (if "Coarse") grid. This is currently only theory on my part, since I don't have any 1366x768 hardware to test it on.


If, as I suspect, the width of the resolution that exhibits a problem for Ghost Dog is 1366 or one of the other widths that I mentioned in my previous post, then this is likely the reason why.

One answer would be to calculate the X coordinate for drive icons along the right side using the same method that shinobar used to calculate the Y coordinate for drive icons along the bottom.

Another answer is the one that Karl devised and used in the code he posted in this thread on May-02 (http://www.murga-linux.com/puppy/viewto ... 461#701461). Rather than use a calculation to predict the value that ROX will use, his code looks at the PuppyPin file to see what value ROX actually did use.

Of course, yet another answer would be to use the method that you used in 2009, and set the X coordinate initially to an appropriate multiple of ROX-Filer's "pinboard_grid_step" based upon the screen-width and $ICON_PLACE_EDGE_GAP, rather than first setting it exactly to screen-width minus $ICON_PLACE_EDGE_GAP and then trying to predict where ROX will move it to, or looking to see where ROX did move it to.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#35 Post by npierce »

Hi Karl,

Thanks for the reply.
Karl Godt wrote:. . . this stacking was a fault in my experimental code . . .
Oh good. Since that problem of stacking for drive icons along the bottom (but not the equivalent problem for drive icons along the right side) should have been fixed by shinobar's fix in 2009, I feared that there might be yet another bug. I'm glad that is not the case.

Anyway, your method should work for the problem of stacking for drive icons along the right side. When Ghost Dog returns home, we will find out if this was indeed the problem he was having. It probably is.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#36 Post by BarryK »

I have never had this problem.

My everyday workhorse laptop is 1366x768.

Smithy reported having this problem with plugging a usb pup into a different computer, so I tried that.
On my 1366x768 laptop, installed Precise 5.6 to a usb stick, rebooted and created a save-file on it.

I then booted up the usb stick on an older laptop, 1024x768, and the drive icons were laid out nicely.

I have just now booted the usb stick on a desktop pc with 1280x1024 screen, icons laid out ok, except the usb-partition icon is near the middle of the screen -- ok, that needs fixing.

Yes, as npierce mentioned, the code in pup_event_frontend_d only works with the rox fine (2) granularity setting. Yes, there is a little fudge in there.

It would be good if there could be some steps that will always reproduce the overlapping problem, that I could follow.
[url]https://bkhome.org/news/[/url]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#37 Post by npierce »

Hi Barry,

For all common screen resolutions, and using the default values in /etc/eventmanager (including ICON_PLACE_ORIENTATION='bottom'), the current pup_event_frontend_d will work fine at any of the three grid step settings that ROX gives as options in its Options dialog window: "Fine" (2), "Medium" (16), and "Coarse" (32).

In theory, this problem only appears when ICON_PLACE_ORIENTATION='right', and the user has changed ROX's grid step setting. And then it only occurs for screen widths that are not an exact multiple of ROX's grid step setting. Such is the case for a width of 1366, if the grid step is 16 or 32.

And even some widths that are not an exact multiple of ROX's grid step setting will probably also work fine, thanks to the fact that the script ignores the least significant digit of the coordinates when looking for existing icons.

BarryK wrote:It would be good if there could be some steps that will always reproduce the overlapping problem, that I could follow.
1. Use screen resolution of 1366x768.
2. In /etc/eventmanager, set ICON_PLACE_ORIENTATION='right'.
3. In ROX-Filer->Options...->Pinboard dialog, change Icon grid step to "Medium" or "Coarse".
4. echo ICONWIPE > /var/local/pup_event_icon_change_flag
5. Restart the X server.

Alternatively, since I'm often in the middle of something and don't want to restart X, I replace step 5 with these commands:

5a. killall pup_event_frontend_d
5b. killall ROX-Filer
5c. clean_desk_icons
5d. rox -p ~/Choices/ROX-Filer/PuppyPin
5e. pup_event_frontend_d &


As mentioned in my post from yesterday, this problem with the 1366 width is still just a theory, since I have no 1366x768 hardware, and Ghost Dog is away from his 1366x768 laptop for a couple of weeks. If you choose to test this, that would be great. If you would rather not spend time testing something that might just be a crazy theory on my part, I will understand perfectly.


The line from shinobar's fix that corrects the Y coordinate and fixed a similar problem for drive icons along the bottom of the desktop is this:

Code: Select all

   COORD_Y=`expr \( $COORD_Y + $PIN_GRID_STEP2 \) / $PIN_GRID_STEP '*'  $PIN_GRID_STEP`
It is repeated for each of the four cases (bottom, top, left, and right) in the last definition of the free_coord() function. (For some reason there are two definitions of that function.)

I suspect that adding four similar lines to correct the X coordinate would solve the current problem. Alternative ideas are presented by Karl in his May-02 post, and MinHundHettePerro at the link he supplied in his post above.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#38 Post by Karl Godt »

Alternatively, since I'm often in the middle of something and don't want to restart X, I replace step 5 with these commands:

5a. killall pup_event_frontend_d
5b. killall ROX-Filer
5c. clean_desk_icons
5d. rox -p ~/Choices/ROX-Filer/PuppyPin
5e. pup_event_frontend_d &
could look like

Code: Select all

PIDPROG=$$
CASEPARAM="$1"
[ -z "$1" ] && CASEPARAM="start" #gives default value
[ "$CASEPARAM" != "start" ] && [ "$CASEPARAM" != "restart" ] && [ "$CASEPARAM" != "stop" ] && exit #precaution

case "$CASEPARAM" in

stop)

##+++2013-03-29
PIDS=`pidof ${0##*/} |tr ' ' '\n'`
PIDS=`echo "$PIDS" | grep -v -w "$PIDPROG"`
for pid in $PIDS; do
ps -p $pid && kill -9 $pid
sleep 0.1
done
exit

;;

restart)

##+++2013-03-29
PIDS=`pidof ${0##*/} |tr ' ' '\n'`
PIDS=`echo "$PIDS" | grep -v -w "$PIDPROG"`
for pid in $PIDS; do
ps -p $pid && kill -9 $pid
sleep 0.1
done

;;

start) : ;;

esac

pidof -o $$ -o %PPID "${0##*/}" && { echo "$0 : Already running." ; exit 1 ; }

at the very top
and

Code: Select all

clear_desk_icons_func(){
 PROBEDISK=`probedisk2`
 BlockDrives=`echo "$PROBEDISK" | cut -f 1 -d '|' | cut -f 3 -d '/' | sort -r`
 if [ "$BlockDrives" != "" ] ; then
  for DRV_NAME in $BlockDrives ; do
 remove_pinboard_func
  done
 fi
 FloppyDrives=`ls /sys/block 2>/dev/null | grep -w -e 'fd[0-9]*'`
 FDRV=`echo "$FloppyDrives"`
 if [ "$FDRV" != "" ]; then
      for DRV_NAME in $FDRV
      do
      remove_pinboard_func
      done

 fi
}
clear_desk_icons_func
somewhere before the #stuff to setup at entry... #build the desktop icons... code block

PLUS a trap line PLUS wmexit,wmpoweroff,wmreboot could need a kill line instead of the wmexitmode.txt block of code in these :) .

EDITED
BlockDrives=`echo "$PROBEDISK" | cut -f 1 -d '|' | cut -f 3 -d '/' | sort -r`
was
BlockDrives=`echo "$PROBEDISK" | cut -f 1 -d '|' | sort -r`
.

User avatar
Ghost Dog
Posts: 163
Joined: Fri 27 Jan 2012, 04:29

#39 Post by Ghost Dog »

Hi,

As Barry and npierce (and others) have said here, the problem was that I had set Rox-Filer to "coarse" icon placement. Setting it back to fine appears to have solved the problem. :)

Big thanks to everybody who responded to this thread!

Very much appreciated!
The Way of the Samurai

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#40 Post by npierce »

Hi Ghost Dog,

You're welcome.

Yes, setting the ROX-Filer "icon grid step" to fine does eliminate the problem for screen resolutions of any even-numbered width (and I've never run across a screen resolution with an odd-numbered width). And I'm happy that you got it working.

I'd like to fix Puppy so that someone else doesn't trip over this same problem. After all, ROX-Filer allows you to set the icon grid step to coarse, so you should be allowed to do so without it messing up your icons. Years ago, shinobar fixed a similar problem with certain resolutions for drive icons along the bottom of the desktop. A similar fix should allow drive icons along the right edge with no problems at a coarse icon grid step.

I have a fix in mind, but in order to test it properly, it would help me to know the screen resolution of the laptop that exhibited the problem.

If you are unsure, the top line of the output from this command should give you the current resolution.

Code: Select all

xrandr
Or you can find it by going to Menu -> System -> HardInfo hardware information and clicking Display in the column on the left.

Post Reply