Updating fluff, flit, and flpicsee updates to fltk-1.4

[Leee]

I tried renaming fluff.conf, just to make sure there wasn't something funky there and it still does the same thing.
Also, I went even further down the file list and it eventually went to highlighting the item 3 lines above where I clicked and then to 4 above - looks like about every twenty lines or so.

[Leee]

@MikeLockmoore - just to be thorough, I updated all my extensions and rebooted... and it still does the offset thing.
Does it matter that I'm using jwm and not flwm?

[MikeLockmoore]

@MikeLockmoore - just to be thorough, I updated all my extensions and rebooted... and it still does the offset thing.
Does it matter that I'm using jwm and not flwm?

Thanks for the earlier updates.  I have not run with JWM lately.  It could well be something getting out of sync with that.  I don't have time tonight to try JWM myself.  I hope I would not not need WM-specific code in Fluff.

FLTK_SCALE_FACTOR is not set
No use of CTRL-PLUS or CTRL-MINUS
I don't remember ever having explicitly set Xft.dpi - but I don't know where to check it.
I did resize the window before starting my test.

Xft.dpi is in  ~/.Xdefaults.  in your home directory, just $ cat .Xdefaults

[Leee]

@MikeLockmoore - just to be thorough, I updated all my extensions and rebooted... and it still does the offset thing.
Does it matter that I'm using jwm and not flwm?

Thanks for the earlier updates.  I have not run with JWM lately.  It could well be something getting out of sync with that.  I don't have time tonight to try JWM myself.  I hope I would not not need WM-specific code in Fluff.

FLTK_SCALE_FACTOR is not set
No use of CTRL-PLUS or CTRL-MINUS
I don't remember ever having explicitly set Xft.dpi - but I don't know where to check it.
I did resize the window before starting my test.

Xft.dpi is in  ~/.Xdefaults.  in your home directory, just $ cat .Xdefaults

Thanks.   Xft.dpi is set to 96.0
I'll pkill jwm and run flwm and let you know if anything changes

[Leee]

@MikeLockmoore - just to be thorough, I updated all my extensions and rebooted... and it still does the offset thing.
Does it matter that I'm using jwm and not flwm?

Thanks for the earlier updates.  I have not run with JWM lately.  It could well be something getting out of sync with that.  I don't have time tonight to try JWM myself.  I hope I would not not need WM-specific code in Fluff.

FLTK_SCALE_FACTOR is not set
No use of CTRL-PLUS or CTRL-MINUS
I don't remember ever having explicitly set Xft.dpi - but I don't know where to check it.
I did resize the window before starting my test.

Xft.dpi is in  ~/.Xdefaults.  in your home directory, just $ cat .Xdefaults

Thanks.   Xft.dpi is set to 96.0
I'll pkill jwm and run flwm and let you know if anything changes

The offset still happens when using flwm.
I'm not changing any scaling or text size or anything like that but I note that if I work my way down the file list clicking each file once but always clicking near the top of the file name (at the cross bar of a letter "t" if the file name has one) then when the offset first occurs (click a file name, highlight remains on the one above), if I click near the bottom of the file name it highlights the correct file name.  Then, further down the list, even that doesn't prevent the offset.  This pretty much what I expected, but I took a moment to verify it just now.

[MikeLockmoore]

Thanks.   Xft.dpi is set to 96.0
I'll pkill jwm and run flwm and let you know if anything changes

The offset still happens when using flwm.
I'm not changing any scaling or text size or anything like that but I note that if I work my way down the file list clicking each file once but always clicking near the top of the file name (at the cross bar of a letter "t" if the file name has one) then when the offset first occurs (click a file name, highlight remains on the one above), if I click near the bottom of the file name it highlights the correct file name.  Then, further down the list, even that doesn't prevent the offset.  This pretty much what I expected, but I took a moment to verify it just now.

This totally seems like my code thinks the text is a different size than what is being used to size and space the names of the files in the file list widget, but somehow this does not happen when running Fluff on a non-JWM window manager.    I can give JWM a try myself to debug it.  Might take  a days.. I don't want to mess with JWM tonight.

[Leee]

Thanks.   Xft.dpi is set to 96.0
I'll pkill jwm and run flwm and let you know if anything changes

The offset still happens when using flwm.
I'm not changing any scaling or text size or anything like that but I note that if I work my way down the file list clicking each file once but always clicking near the top of the file name (at the cross bar of a letter "t" if the file name has one) then when the offset first occurs (click a file name, highlight remains on the one above), if I click near the bottom of the file name it highlights the correct file name.  Then, further down the list, even that doesn't prevent the offset.  This pretty much what I expected, but I took a moment to verify it just now.

This totally seems like my code thinks the text is a different size than what is being used to size and space the names of the files in the file list widget, but somehow this does not happen when running Fluff on a non-JWM window manager.    I can give JWM a try myself to debug it.  Might take  a days.. I don't want to mess with JWM tonight.

You probably don't have to mess with JWM, since the problem did appear in flwm as well.

[Rich]

Hi MikeLockmoore
Maybe there's some difference in font settings between you and Leee?

[Leee]

Hi MikeLockmoore
Maybe there's some difference in font settings between you and Leee?

FWIW, I just checked to make sure all of my extensions are current, and they are, then used baregui.lst instead of onboot.lst:

Code: [Select]

graphics-KERNEL.tcz
Xorg-7.7.tcz
Xprogs.tcz
aterm.tcz
flwm.tcz
wbar.tcz
Then I tce-loaded fluff_testing and tested it.  Same results as discussed above.

I tce-loaded firfox after the test so as to make sure it and its deps weren't causing the issue.

If there are any configs or diagnostic outputs I can post that would help, I can do that, too.

[MikeLockmoore]

Hi MikeLockmoore
Maybe there's some difference in font settings between you and Leee?

FWIW, I just checked to make sure all of my extensions are current, and they are, then used baregui.lst instead of onboot.lst:

Code: [Select]

graphics-KERNEL.tcz
Xorg-7.7.tcz
Xprogs.tcz
aterm.tcz
flwm.tcz
wbar.tcz
Then I tce-loaded fluff_testing and tested it.  Same results as discussed above.

I tce-loaded firfox after the test so as to make sure it and its deps weren't causing the issue.

If there are any configs or diagnostic outputs I can post that would help, I can do that, too.

Rich - good thinking.  I do have some extra fonts installed.  Not sure if one from my onboot.lst is being used for Fluff.  I'll try to simplify my extension load and see if I can replicate it. 
Leee - thanks for testing that setup!  i'll try to pare mine down too.  Since I'm running on an old ThinkPad, I have the thinkpad extension installed that enables full native screen resolution.  Might take until tomorrow to really look into this.

[MikeLockmoore]

Rich: I believe your speculation that I have different fonts that can cause a difference is very much relevant. 

Leee: I'm able to reproduce your issue or something very similar if I boot TC without my extra font extensions loading onboot.   

I'm going to rework the code in Fluff that uses item height and see if that will fix it.  The code for the file list widget currently starts with a hard-coded value (16), but should be getting updated with the current value dynamically whenever the window is filled with directory contents.  Perhaps the value retrieved is not accurate or cannot be used the way I'm using, maybe due to fractional scaling that we have now with FLTK 1.4.  Hopefully this won't be too difficult to fix now, assuming this is the basic cause.

[Rich]

Hi MikeLockmoore

Rich: I believe your speculation that I have different fonts that can cause a difference is very much relevant. ...

It seemed like a likely suspect. 2 fonts differing by about 1 pixel in
unaccounted height sounds like it could create this kind of weirdness.

[MikeLockmoore]

Hi MikeLockmoore

Rich: I believe your speculation that I have different fonts that can cause a difference is very much relevant. ...

It seemed like a likely suspect. 2 fonts differing by about 1 pixel in
unaccounted height sounds like it could create this kind of weirdness.

Yes, this was good insight by you and helped me zero in on the issue, although it's sort of amazing that my extra fonts seemed to compensate in just the right way to cover up the general bug.

The fix was trickier than I was hoping, since FLTK does not have a good member function of the FL_Multi_Selection list browser widget to give you the item index for a given coordinate (e.g. mouse click).  You can iterate through the list and query each item's height in pixels and accumulate that to figure out which list item is at a given coordinate, which is what I do now.  There was a subtle difference in item height for bold items versus normal, which breaks the assumption I had that all items are the same height as well.  The column headers in row 1 and any directory item in the list is filled in with bold text, while normal files are filled in with normal (not bold) text.   

Fixed code that does the iteration accumulating size seems to run OK for default and my custom fonts, for interactive fractional scaling (Ctrl+Plus) above and  below 100%, as well as fractional scaling initialized from the .Xdefaults Xft.dpi setting.  I'm fairly hopeful it will work for Leee and everyone! 

Fix was sent via email.  Please post to the test apps repo folder when you have a chance.  Thanks!

[Rich]

Hi MikeLockmoore

... Fix was sent via email.  Please post to the test apps repo folder when you have a chance.  Thanks!

Posted.

http://tinycorelinux.net/16.x/x86_64/tcz/testing

[MikeLockmoore]

Hi MikeLockmoore

... Fix was sent via email.  Please post to the test apps repo folder when you have a chance.  Thanks!

Posted.

http://tinycorelinux.net/16.x/x86_64/tcz/testing

Thank you Rich!