Drive Icons All Bunched Up In The Corner

[Smithy]

+1 on a fix for this, It really lets Puppy down when you stick a stick in another computer and the icons are all bunched up!

[Jasper]

Hi,

I use desksetup-.0.4.pet from 01micko so that when I have
my icons as I want I cam easily save them and restore them
if necessary (which I have personally only needed after a
Puppy version number upgrade).

However, I haven't experienced the bunching problem, but
perhaps someone with the problem might try it.

My regards

[Ghost Dog]

Hi npierce,

It doesn't seem to just be on remasters, but also on standard Puppies, maybe just certain resolutions?

Karl Godt replied to the PM I sent him, saying:

"of course there is no free_coord_normal" ..

there are two or three free_coord functions and ash seems to pick the latest one south if something calls free_coord .

I would suggest to rename the free_coord 's to uniqe names like
free_coord_orig ,
free_coord_2 and
free_coord_normal

and put in my free_coord function with whatever uniqe name underneath the closing bracket of the latest free_coord function and call it with the name given .

I haven't gotten around to exploring this. But it really sounded like he had fixed the problem for a minute there...

[Ghost Dog]

Come on, you guys! This has the potential to benefit all Puppies!

If Karl is right (Karl, where did you go?), then the problem of drive icons all bunching together on top of each other (and making Puppy look bad) might be fixed.

Don't let this die, just because I'm not smart enough to understand the implementation. I never said I was smart, so you can't expect much from me. I just pointed out a problem that I would like to see fixed, and will help if I can.

Others have joined this thread adding their support for such a solution.

Karl, can you make a working version of /sbin/pup_event_frontend_d for us to play with? I would very much appreciate it, and I know some of the others here would, too.

[Karl Godt]

This is from wary-5.5 .

free command output is different from older Lupu Puppies.
path to /tmp/pup_event_icon_change_flag has changed.

EDIT > Fixed missing PIN_GRID_STEP, PIN_GRID_STEP2, MAX_X, MAX_Y

[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!

[Karl Godt]

Nice to hear ! Had not tested the file myself
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>

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

[Ghost Dog]

Know what I mean, Karl?

[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]

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.

[Karl Godt]

Know what I mean, Karl?

First was BIG QUESTION MARK .

Now have fired up Slacko-5.3.0

and this was missing :

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

Will replace the attachment later ..

EDIT > done .

[Chili Dog]

Cool.

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

[Karl Godt]

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

[npierce]

Ghost Dog,

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

[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

[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]

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

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

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]

Hi Karl,

Thanks for the reply.

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