In 2009, shinobar solved a problem which caused the drive icons to pile up on top of each other at certain screen resolutions, such as 800x600, if ROX-Filer's grid step is set to Medium or Coarse. At that time drive icons were always displayed along the bottom edge of the pinboard.
Now drive icons may be displayed along any edge of the pinboard, and recently Ghost Dog ran into a problem when displaying icons along the right edge. (See forum thread:
Drive Icons All Bunched Up In The Corner.)
Ghost Dog has since verified that the resolution of the screen that exhibited this problem was 1366x768. This indicated that the problem was similar to the problem shinobar solved for drive icons along the bottom at 800x600.
The problem happens only when the screen width is not an exact multiple of ROX-FIler's grid step (just like the 2009 problem only happened when the screen height was not an exact multiple of the grid step). For more details, see my attempt at an explanation posted here:
http://www.murga-linux.com/puppy/viewto ... 520#705520
After Ghost Dog verified that this problem occurred on a 1366x768 screen, I was able to borrow a PC that supported that resolution and so test my theory. Now I have a suggested fix.
Actually, I am attaching
four versions of pup_event_frontend_d that correct this problem. One is based on the single-script version of pup_event_frontend_d, as included with recent Puppies. But Barry has been busy and developed a new and improved modular version for use in future Puppies. So I also ported my changes to the appropriate modules of that version. Those two versions contain the fix (based on shinobar's code) as well as some other minor improvements (inspired partly by other contributors to the above thread). Then I decided to make a version of each of those which have just the minimal changes needed to fix the problem, without the minor improvements.
Attached are four versions of the daemon:
1. Drop-in replacement for Precise 5.5, 5.6, 5.6.1, Slacko 5.5, Racy 5.5.
Minimal changes.
2. Drop-in replacement for Precise 5.5, 5.6, 5.6.1, Slacko 5.5, Racy 5.5.
Some of the math moved out of free_coord().
3. Based on current Woof.
Minimal changes.
4. Based on current Woof.
Some of the math moved out of free_coord().
In #1 and #3 I simply added a few lines so that the X coordinates receive the same correction that the Y coordinates have received since shinobar fixed them in 2009.
In #2 and #4 I have added that correction but moved it and much of the related math out of the free_coord() function. This was inspired by posts from Karl Godt and MinHundHettePerro, both of whom pinpointed the problem, and suggested code to fix it which also moved needlessly repetitive code out of the function so that it wasn't repeated for every icon.
Among the stuff moved in #2 and #4, was the code that reads ROX-Filer's Options file. At first I wondered if that might be a bad thing since this daemon would no longer be aware of changes to "pinboard_grid_step", unless it was restarted. Looking closer I realised that this wasn't really a problem because it doesn't really matter if the daemon is aware of changes to "pinboard_grid_step" or not, since after that value is changed, correct icon placement cannot be guaranteed until the daemon is restarted (usually by restarting the X server).
Although there is no guarantee that icons will be placed correctly if "pinboard_grid_step" is changed unless this daemon is restarted, in most cases they will be placed properly. The only time they won't be is when the user wants the icons along the bottom edge of the pinboard (the default) and has a screen resolution with a height which isn't an exact multiple of 32, such as 800x600, or when the user wants the icons along the right edge of the pinboard and has a screen resolution with a width which isn't an exact multiple of 32, such as 1366x768.
In other words, since the daemon should be restarted anyway after changing "pinboard_grid_step" by any user who uses one of the screen resolutions just mentioned, the behavior that occurs if the daemon isn't restarted isn't really worth describing.
But I like to be complete, so will do so anyway.
Feel free to skip this part.
(-- Start of exceedingly boring stuff --)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(The "pinboard_grid_step" values that I mention below are limited to the three values available through the ROX-Filer Options menu: 2 (Fine), 16 (Medium), and 32 (Coarse).)
Current daemon:
- Height not a multiple of 32, and icons along bottom edge:
- After changing "pinboard_grid_step", plugging in a new drive may cause its icon to appear on top of preexisting drive icons, but not on top of icons for other drives added since the grid step was changed.
- Width not a multiple of 32, and icons along right edge:
- This doesn't work at all with current daemon if grid step is changed from "fine" (the default) -- even if the daemon is restarted.
- Any other combination:
- Icons will be displayed correctly.
Daemons #1 or #3 above:
- Height not a multiple of 32, and icons along bottom edge, or width not a multiple of 32 and icons along right edge:
- After changing "pinboard_grid_step", plugging in a new drive may cause its icon to appear on top of preexisting drive icons, but not on top of icons for other drives added since the grid step was changed.
- Any other combination:
- Icons will be displayed correctly.
Daemons #2 or #4 above:
- Height not a multiple of 32, and icons along bottom edge, or width not a multiple of 32 and icons along right edge:
- After changing "pinboard_grid_step" to a larger value than it was when this daemon was started, plugging in a new drive may cause its icon to appear on top of other new drives that were added since the grid step was changed, but not on top of preexisting drive icons.
After changing "pinboard_grid_step" to a smaller value than it was when this daemon was started, plugging in a new drive will cause its icon to be displayed correctly.
- Any other combination:
- Icons will be displayed correctly.
Again, it is important to remember that the above describes what could happen only if the daemon is
not restarted after the grid step is changed. If it
is restarted, daemons #1, #2, #3, and #4 will display the icons correctly in all cases, and the current daemon will also display the icons correctly in all cases except the one case where icons are on the right and the screen width is not a multiple of 32.
(Actually, I should point out that a screen height or width that is not a multiple of 32, but
is a multiple of 16 will always work correctly with a grid step of 16 (Medium). But I have lumped 16 together with 32 in the above description because life is too short to spend trying to describe each possible case. Suffice it to say that in some cases above which cause incorrect icon placement when the grid step is 32, there would not be a problem with a grid step of 16, if the appropriate screen dimension was a multiple of 16. Note that neither height at 800x600, nor the width at 1366x768 is a multiple of 32
or 16, so in those cases it is appropriate to lump 32 and 16 together.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(-- End of exceedingly boring stuff --)
(Resumption of moderately boring stuff.
)
In my #4 daemon, free_coord() SCRN_X and SCRN_Y are no longer used. They are still used in frontend_startup, but the only function currently using them is the first, unused definition of free_coord. If that unused definition was eliminated, there would probably no longer be a need to pass SCRN_X and SCRN_Y to the other scripts. But I've not tested that, so have left that as-is for now.
By the way, in the current Woof version, I noticed that frontend_change didn't source gettext.sh (needed for call to create_icon_func() ), so I've added that and defined TEXTDOMAIN and OUTPUT_CHARSET.
Please note that in the .tar.gz for the modular version, #3 and #4 below, I've only included the modules that I changed. The other modules are also needed for it to run (see Barry's blog:
new pup_event_frontend).