Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: MikeLockmoore on March 16, 2025, 12:51:05 AM
-
Hello testers... I've made many moderate changes to Fluff (file manager) and FLPicSee (image viewer) to work better with FLTK 1.4. Would any of you like to test these new versions? What's a good mechanism to do that these days? -Mike
P.S. screenshot is set up a bit weird, but it's hard to keep the image file size within the 200K limit when showing much content on my 1920x1080 screen.
-
Hi MikeLockmoore. I'd be happy to take a look at them. I'm on x86_64, but could switch to 32 bit for this purpose if needed.
@Rich - is there a prescribed way to share new extensions for testing via the repo?
-
Hi MikeLockmoore
... P.S. screenshot is set up a bit weird, but it's hard to keep the image file size within the 200K limit when showing much content on my 1920x1080 screen.
The first thing I would do is convert from .png to .jpg:
tc@E310:~$ ls -l Downloads/screenshot_0315224859.png
-rw-r--r-- 1 tc staff 195902 Mar 16 06:51 Downloads/screenshot_0315224859.png
tc@E310:~$
tc@E310:~$ PicFormat -i Downloads/screenshot_0315224859.png -o Downloads/screenshot_0315224859.jpg
Input=Downloads/screenshot_0315224859.png Fmt=png W=1920 H=1080 AR=16:9
Output=Downloads/screenshot_0315224859.jpg Fmt=jpg W=1920 H=1080 AR=16:9 Rotate=0
tc@E310:~$
tc@E310:~$ ls -l Downloads/screenshot_0315224859.jpg
-rw-r--r-- 1 tc staff 172874 Mar 16 07:17 Downloads/screenshot_0315224859.jpg
A small reduction in image size yields a significant file size reduction.
Using a nice binary fraction like 7/8 (.875) reduces the image to 1680x945:
tc@E310:~$ PicFormat -i Downloads/screenshot_0315224859.png -o Downloads/screenshot_0315224859.jpg -w 1680
Input=Downloads/screenshot_0315224859.png Fmt=png W=1920 H=1080 AR=16:9
Output=Downloads/screenshot_0315224859.jpg Fmt=jpg W=1680 H=945 AR=16:9 Rotate=0
tc@E310:~$
tc@E310:~$ ls -l Downloads/screenshot_0315224859.jpg
-rw-r--r-- 1 tc staff 137362 Mar 16 07:26 Downloads/screenshot_0315224859.jpgTo my eyes, the reduced version looked just as good as your original.The text is
crisp, just slightly smaller (see attached image).
PicFormat is something I wrote a few years ago. It's 8k in size and depends on imlib2.tcz.
It's a simple command line program that does format conversion, rotation, size
conversion, and aspect ratio adjustment if desired.
Details of its used are included in the .info file:
http://tinycorelinux.net/16.x/x86/tcz/PicFormat.tcz.info
http://tinycorelinux.net/16.x/x86_64/tcz/PicFormat.tcz.info
-
Hi MikeLockmoore
Hello testers... I've made many moderate changes to Fluff (file manager) and FLPicSee (image viewer) to work better with FLTK 1.4. Would any of you like to test these new versions? What's a good mechanism to do that these days? -Mike ...
If you like, I can setup a testing directory under http://tinycorelinux.net/16.x/x86_64/tcz/.
Email me a tarball (or 2) with the .tczs to test and I'll post them there.
I sent you an email so you'll have my address.
You might want to give the .tczs unique names so they don't clash
with official versions.
-
Hi, I saw the bulk of discusion going to fltk-1.4 for 64 bits. There are the main appls ctrl-panel & friends, fluff and flwm.
IMHO also these (not in the base, but nice to have as a minimum useful distro) should be updated:
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flaxpdf.tcz.dep =PDF viewer
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flburn.tcz.dep =CD/DVD burner
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flit.tcz.dep =sound/battery
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flnotify.tcz.dep
BTW: dillo 3.2 depending on fltk-1.4 :)
and few others (not much used / commented in the forum):
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/pinentry-fltk.tcz.dep
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/moonfltk.tcz.dep =lua
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/webkitfltk-dev.tcz.dep =maybe MIA missing in action (no appl using it).
-
Hi, I saw the bulk of discusion going to fltk-1.4 for 64 bits. There are the main appls ctrl-panel & friends, fluff and flwm.
IMHO also these (not in the base, but nice to have as a minimum useful distro) should be updated:
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flaxpdf.tcz.dep =PDF viewer
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flburn.tcz.dep =CD/DVD burner
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flit.tcz.dep =sound/battery
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/flnotify.tcz.dep
BTW: dillo 3.2 depending on fltk-1.4 :)
and few others (not much used / commented in the forum):
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/pinentry-fltk.tcz.dep
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/moonfltk.tcz.dep =lua
https://mirrors.dotsrc.org/tinycorelinux/16.x/x86_64/tcz/webkitfltk-dev.tcz.dep =maybe MIA missing in action (no appl using it).
Good to consider these. Flit is an app I created and definitely want to fix, and not just for FLTK reasons. The battery monitor does not work with the current power management sys/ filesystem stuff. Probably also needs some changes for the sound control side as well, if not more! :P
Not sure to what extent I can work on the others. Would be nice to have a native FLTK web browser so I don't need FF, which has a ton of local files that are getting backed up on TC exit.
Hi MikeLockmoore
Hello testers... I've made many moderate changes to Fluff (file manager) and FLPicSee (image viewer) to work better with FLTK 1.4. Would any of you like to test these new versions? What's a good mechanism to do that these days? -Mike ...
If you like, I can setup a testing directory under http://tinycorelinux.net/16.x/x86_64/tcz/.
Email me a tarball (or 2) with the .tczs to test and I'll post them there.
I sent you an email so you'll have my address.
You might want to give the .tczs unique names so they don't clash
with official versions.
Excellent! I will try to email. Can we just rename the .tcz file to things like fluff_testing.tcz and flpicsee_testing.tcz?
Here's a screenshot showing FlPicsee's spiffy new icon.
- Mike
-
Hi Leee
fluff_testing and flpicsee_testing .tcz and .tcz.dep available at:
http://tinycorelinux.net/16.x/x86_64/tcz/testing
If you have fluff or flpicsee loaded, reboot without loading them before
attempting to load fluff_testing and/or flpicsee_testing.
Source tarballs can be found in:
http://tinycorelinux.net/16.x/x86_64/tcz/testing/src
-
Thanks Rich.
-
Hi Leee
You are welcome. :)
-
Short update... I got a version of Flit building with FLTK 1.4.x, and some of the basics are working. ;D
However, the batt/power monitor needs a big overhaul to work right with current Linux kernels (which I started working on in 2023, but lost that file, bit it shouldn't be too hard to re-create). It does the fractional scaling thing with Ctrl+Plus / Ctrl+Minus, but I want to have it automatically pick up the default/configured scaling factor from FLTK like I did for FLWM as a whole. Sound can be controlled but I think there are some quirks about it (maybe because I have PulseAudio installed to get sound working right with FireFox / Youtube. It's displaying the WiFi signal strength OK, but I don't know if it can fully substitute for the WiFi.tcz extension yet.
-
@MikeLockmoore, re fluff_testing
I'm seeing an issue where clicking/double clicking an item in the file list affects (and highlights) the item above instead of the item clicked.
So I thought. "hmmm... what if I click the top item in the list?". Tried that and it selected the correct item.
Fooled around with it for a bit, then resized window to show 43 items. Exited then restarted fluff.
clicked each item in turn
1 ( ./ ) OK (highlighted Item #1)
2 OK
3 OK
4 OK
5 OK
6 OK
7 OK
8 OK
9 OK
10 OK
11 OK
12 OK
13 OK
14 OK
15 OK
16 OK
17 OK
18 OK
19 * * * highlight stays on #18
20 highlighted #19
21 OK
22 OK
23 * * * highlight stays on #22
24 highlights #23
25 highlights #24
26 highlightd # n-1 until...
27 .
28 .
29 .
30 .
31 .
32 .
33 .
34 .
35 .
36 .
37 .
38 .
39 .
40 .
41 .
42 .
43 this item was not completely within the window, soclicking it caused the window to scroll by 1 line, then #43 was highlighted correctlyOn a second test, the same basic thing happened but starting at slightly different item numbers and it did not correct after the list scrolled.
-
@MikeLockmoore, re fluff_testing
I'm seeing an issue where clicking/double clicking an item in the file list affects (and highlights) the item above instead of the item clicked.
So I thought. "hmmm... what if I click the top item in the list?". Tried that and it selected the correct item.
Fooled around with it for a bit, then resized window to show 43 items. Exited then restarted fluff.
clicked each item in turn
1 ( ./ ) OK (highlighted Item #1)
2 OK
...18 OK
19 * * * highlight stays on #18
20 highlighted #19
21 OK
22 OK
23 * * * highlight stays on #22
24 highlights #23
25 highlights #24
26 highlightd # n-1 until...
27 .
28 .
...
42 .
43 this item was not completely within the window, soclicking it caused the window to scroll by 1 line, then #43 was highlighted correctlyOn a second test, the same basic thing happened but starting at slightly different item numbers and it did not correct after the list scrolled.
Hi Leee. Thanks for the detailed issue report! I think I've noticed a similar problem with the click event effect not aligning with the physical location of the pointer myself, but not consistently enough to debug it yet. Your info should help me reproduce the issue and troubleshoot it.
Can you tell me whether you are using any of the fractional scaling options when this happens for you... did you use Ctrl+Plus or Ctrl-Minus to adjust the fractional scaling as Fluff was running? Or do you have Xft.dpi set to something besides 96.0 or have the FLTK_SCALE_FACTOR environment variable set before launching Fluff?
Hopefully my code just assumes a fixed size of the file list item rows and now it is different, or sometimes different. I probably just need to compensate appropriately. Hope to get to this later today or tomorrow! -Mike
-
@MikeLockmoore, re fluff_testing
I'm seeing an issue where clicking/double clicking an item in the file list affects (and highlights) the item above instead of the item clicked.
So far I have not been able to duplicate the item click/selection issue on my build 1.1.2. Can you verify you have loaded and are running that version? (Click on the [A] button in the toolbar or open Help to see the version number). Note I have configured Xft.dpi to 120.0 (125% of the normal size) by default, but I tried to Ctrl+Plus and Ctrl+Minus to change the scaling interactively in Fluff at did not see any cases of not highlighting the clicked-on item in the file list.
P.S. Flit is now showing my battery power status again! Plus it can show the WiFi signal strength, but as of now, I still need to use WiFi.tcz to make the connection with a passphrase. The sound control can adjust the sound volume, but sound is disabled after reboot unless I re-enable the output device it in PAVUcontrol. Little by little. At some point, I'd like to switch to the newish SVG icon support in FLTK and use some more polished icons for Flit.
-
@MikeLockmoore, re fluff_testing
I'm seeing an issue where clicking/double clicking an item in the file list affects (and highlights) the item above instead of the item clicked.
So I thought. "hmmm... what if I click the top item in the list?". Tried that and it selected the correct item.
Fooled around with it for a bit, then resized window to show 43 items. Exited then restarted fluff.
clicked each item in turn
1 ( ./ ) OK (highlighted Item #1)
2 OK
...18 OK
19 * * * highlight stays on #18
20 highlighted #19
21 OK
22 OK
23 * * * highlight stays on #22
24 highlights #23
25 highlights #24
26 highlightd # n-1 until...
27 .
28 .
...
42 .
43 this item was not completely within the window, soclicking it caused the window to scroll by 1 line, then #43 was highlighted correctlyOn a second test, the same basic thing happened but starting at slightly different item numbers and it did not correct after the list scrolled.
Hi Leee. Thanks for the detailed issue report! I think I've noticed a similar problem with the click event effect not aligning with the physical location of the pointer myself, but not consistently enough to debug it yet. Your info should help me reproduce the issue and troubleshoot it.
Can you tell me whether you are using any of the fractional scaling options when this happens for you... did you use Ctrl+Plus or Ctrl-Minus to adjust the fractional scaling as Fluff was running? Or do you have Xft.dpi set to something besides 96.0 or have the FLTK_SCALE_FACTOR environment variable set before launching Fluff?
Hopefully my code just assumes a fixed size of the file list item rows and now it is different, or sometimes different. I probably just need to compensate appropriately. Hope to get to this later today or tomorrow! -Mike
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.
-
@MikeLockmoore, re fluff_testing
I'm seeing an issue where clicking/double clicking an item in the file list affects (and highlights) the item above instead of the item clicked.
So far I have not been able to duplicate the item click/selection issue on my build 1.1.2. Can you verify you have loaded and are running that version? (Click on the [A] button in the toolbar or open Help to see the version number). Note I have configured Xft.dpi to 120.0 (125% of the normal size) by default, but I tried to Ctrl+Plus and Ctrl+Minus to change the scaling interactively in Fluff at did not see any cases of not highlighting the clicked-on item in the file list.
P.S. Flit is now showing my battery power status again! Plus it can show the WiFi signal strength, but as of now, I still need to use WiFi.tcz to make the connection with a passphrase. The sound control can adjust the sound volume, but sound is disabled after reboot unless I re-enable the output device it in PAVUcontrol. Little by little. At some point, I'd like to switch to the newish SVG icon support in FLTK and use some more polished icons for Flit.
Verified: I'm using fluff version 1.1.2
Just now I tried using Ctrl-PLUS to run it up to 120% and the cursor offset still occurred. When I scrolled the screen and continued single clicking each file down the list, it eventually went to an offset of minus two (the highlight would appear two lines above where I clicked.
-
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.
-
@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 - 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
-
@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
-
@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.
-
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.
-
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.
-
Hi MikeLockmoore
Maybe there's some difference in font settings between you and 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: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.
-
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: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.
-
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. :D
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.
-
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.
-
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! :D
Fix was sent via email. Please post to the test apps repo folder when you have a chance. Thanks!
-
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
-
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!
-
I've tried the new fluff_testing.tcz both with my baregui.lst config (using flwm) and with my regular onboot.lst that loads tons of other stuff (using jwm) and the problem appears to be gone.
I also tried it with fluff zoomed in to 150% and still no problems.
-
I've tried the new fluff_testing.tcz both with my baregui.lst config (using flwm) and with my regular onboot.lst that loads tons of other stuff (using jwm) and the problem appears to be gone.
I also tried it with fluff zoomed in to 150% and still no problems.
Great! ;D
-
@MikeLockmoore - not "bugs" in fluff, but some suggestions:
On the fluff button bar, there are the "Action 1" and Action 2" buttons, right next to the "Quit" button, with actions tat vary depending upon the type of the selected file...
Is there any chance you could add one or two (or several) additional buttons, similarly programmable via .fluff.conf, that -don't- change with the file type but which could be used to run any arbitrary command or script against the selected files and/or directories? Given that extra buttons would crowd the button bar a bit, maybe the quit button could be much smaller, or even removed completely.
Separately, whenever an external process removes a highlighted file, a warning dialog pops up with "One or more selected items have been either moved or deleted!" and requires a click of its "Close" button to dismiss. This seems pointless, especially in as much as there's nothing you can do about it at that point anyway.
-
@MikeLockmoore - not "bugs" in fluff, but some suggestions:
On the fluff button bar, there are the "Action 1" and Action 2" buttons, right next to the "Quit" button, with actions tat vary depending upon the type of the selected file...
Is there any chance you could add one or two (or several) additional buttons, similarly programmable via .fluff.conf, that -don't- change with the file type but which could be used to run any arbitrary command or script against the selected files and/or directories? Given that extra buttons would crowd the button bar a bit, maybe the quit button could be much smaller, or even removed completely.
Separately, whenever an external process removes a highlighted file, a warning dialog pops up with "One or more selected items have been either moved or deleted!" and requires a click of its "Close" button to dismiss. This seems pointless, especially in as much as there's nothing you can do about it at that point anyway.
Leee: Thanks for the suggestions. The "moved or deleted" warning should be easy... I agree, it really doesn't serve much purpose.
I suppose Quit is a bit redundant, I guess I was following the "bigger targets are easier to hit" approach. Non-type-specific options would be nice I suppose at least for multi-file selections (e.g. "compress this group of files into a .tar.gz").
I do want to add at least two small buttons for going back to a previous directory and up in the folder hierarchy, maybe forward too if we can go back. I can use the FLTK button symbol codes to make these look like little triangle shapes (like PLAY and REWIND buttons on a media player) instead of using a full text word, so they won't take up much space.
-
In other updates, I've modified Flit to only use the FLTK fractional scaling and removed the custom fractional scaling code I had put into it in previous (perhaps unreleased) versions. I've redone the WiFi symbol and the sound volume control to look cleaner and better take advantage of current FLTK features, although not going as far as using SVG icons ... my first experiment did not go well ... maybe not all SVGs are created equal(ly compatible).
Screenshots attached of a a very zoomed-up Flit with two of the "tooltip" pop-up text messages.
-
@MikeLockmoore - not "bugs" in fluff, but some suggestions:
... whenever an external process removes a highlighted file, a warning dialog pops up with "One or more selected items have been either moved or deleted!" and requires a click of its "Close" button to dismiss. This seems pointless, especially in as much as there's nothing you can do about it at that point anyway.
Leee: I've removed this warning in my current WIP version (1.1.4). I've also removed some references to things that perhaps used to exist but do not now (e.g. /opt/.tce_dir), which can cause error messages on the console if you start fluff that way.
I'm going to work on some command button stuff. First the general navigation buttons, then perhaps the generic file action buttons that you suggested. I think I will also re-order the position of the buttons so that Home is the farthest to the left.
-
@MikeLockmoore - not "bugs" in fluff, but some suggestions:
... whenever an external process removes a highlighted file, a warning dialog pops up with "One or more selected items have been either moved or deleted!" and requires a click of its "Close" button to dismiss. This seems pointless, especially in as much as there's nothing you can do about it at that point anyway.
Leee: I've removed this warning in my current WIP version (1.1.4). I've also removed some references to things that perhaps used to exist but do not now (e.g. /opt/.tce_dir), which can cause error messages on the console if you start fluff that way.
I'm going to work on some command button stuff. First the general navigation buttons, then perhaps the generic file action buttons that you suggested. I think I will also re-order the position of the buttons so that Home is the farthest to the left.
Thanks, Mike. I'm ready to test whenever you have an update.
-
Hi MikeLockmoore
fluff_testing (1.1.5) and flit_testing (1.5.2) .tcz and .tcz.dep have been posted to:
http://tinycorelinux.net/16.x/x86_64/tcz/testing
-
Hi Leee and other testers
If you have fluff or flit loaded, reboot without loading them before
attempting to load fluff_testing and/or flit_testing.
Source tarballs can be found in:
http://tinycorelinux.net/16.x/x86_64/tcz/testing/src
Those tarballs also contain .tcz.info and others if interested.
MikeLockmoore will be traveling starting tomorrow and will not
be able to respond to feedback until he returns, so:
Please be patient. :)
-
Hi MikeLockmoore
fluff_testing (1.1.5) and flit_testing (1.5.2) .tcz and .tcz.dep have been posted to:
http://tinycorelinux.net/16.x/x86_64/tcz/testing
Thanks Rich!
Hi Leee and other testers
If you have fluff or flit loaded, reboot without loading them before
attempting to load fluff_testing and/or flit_testing.
Source tarballs can be found in:
http://tinycorelinux.net/16.x/x86_64/tcz/testing/src
Those tarballs also contain .tcz.info and others if interested.
MikeLockmoore will be traveling starting tomorrow and will not
be able to respond to feedback until he returns, so:
Please be patient. :)
True... I only have a little time this evening US time if anything pops up immediately. I'll try to monitor the forum but may not be able to directly reply for several days starting tomorrow.
@Leee: I don't have your "general" file/directory action button(s) idea implemented yet, but did drop the unneeded warning.
I did receive some suggestions from another TC user privately have have been incorporated. Not too much drastic in Fluff besides the button layout, dropping Quit button and adding the path history navigation buttons. Hope people like the updates! Both these applications are working much better for me with the updates over the past two weeks. -Mike
-
Hi MikeLockmoore
fluff_testing (1.1.5) and flit_testing (1.5.2) .tcz and .tcz.dep have been posted to:
http://tinycorelinux.net/16.x/x86_64/tcz/testing (http://tinycorelinux.net/16.x/x86_64/tcz/testing)
Thanks Rich!
Hi Leee and other testers
If you have fluff or flit loaded, reboot without loading them before
attempting to load fluff_testing and/or flit_testing.
Source tarballs can be found in:
http://tinycorelinux.net/16.x/x86_64/tcz/testing/src (http://tinycorelinux.net/16.x/x86_64/tcz/testing/src)
Those tarballs also contain .tcz.info and others if interested.
MikeLockmoore will be traveling starting tomorrow and will not
be able to respond to feedback until he returns, so:
Please be patient. :)
True... I only have a little time this evening US time if anything pops up immediately. I'll try to monitor the forum but may not be able to directly reply for several days starting tomorrow.
@Leee: I don't have your "general" file/directory action button(s) idea implemented yet, but did drop the unneeded warning.
I did receive some suggestions from another TC user privately have have been incorporated. Not too much drastic in Fluff besides the button layout, dropping Quit button and adding the path history navigation buttons. Hope people like the updates! Both these applications are working much better for me with the updates over the past two weeks. -Mike
Thanks #MikeLockmoore.
I'll grab the latest and beat it up some.
It's late here right (I'm still running on Saturday evening's coffee) now so I probably won't do much tonight.
---
(20 minutes later)...
Got it. Tried it. At first glance, it looks great. More testing tomorrow.
-
Thanks #MikeLockmoore.
I'll grab the latest and beat it up some.
It's late here right (I'm still running on Saturday evening's coffee) now so I probably won't do much tonight.
---
(20 minutes later)...
Got it. Tried it. At first glance, it looks great. More testing tomorrow.
That’s good to hear. I figured out the login from my phone, so I can reply if questions pop up.
@Rich- I understand about the moving the extension talk here. Thanks for linking it from the RC thread.
-
Thanks #MikeLockmoore.
I'll grab the latest and beat it up some.
It's late here right (I'm still running on Saturday evening's coffee) now so I probably won't do much tonight.
---
(20 minutes later)...
Got it. Tried it. At first glance, it looks great. More testing tomorrow.
That’s good to hear. I figured out the login from my phone, so I can reply if questions pop up.
@Rich- I understand about the moving the extension talk here. Thanks for linking it from the RC thread.
In the latest fluff, there's an issue with not resetting the file list display when using the back button. For instance, I...- start with the window sized big enough to display a couple dozen items in the file list
- navigate to /home/ where there are three user directories
- descend into /home/tc/ where there are a hundred or so items
- scroll down a page or two
- click the back button to return to /home/
At this point the file list is trying to show the correct directory contents but the few items in /home/ are scrolled up above the top of the window so the window appears to be empty. If I click on the scroll bar handle and slide it up, the "list" scrolls up until the contents become visible and then the scroll bar disappears.
I think when the back button is clicked it should either re-select the previously selected file in the target directory or should reset the file list display to the to the first file in the list (as determined by the sort order).
-
In the latest fluff, there's an issue with not resetting the file list display when using the back button. For instance, I...- start with the window sized big enough to display a couple dozen items in the file list
- navigate to /home/ where there are three user directories
- descend into /home/tc/ where there are a hundred or so items
- scroll down a page or two
- click the back button to return to /home/
At this point the file list is trying to show the correct directory contents but the few items in /home/ are scrolled up above the top of the window so the window appears to be empty. If I click on the scroll bar handle and slide it up, the "list" scrolls up until the contents become visible and then the scroll bar disappears.
I think when the back button is clicked it should either re-select the previously selected file in the target directory or should reset the file list display to the to the first file in the list (as determined by the sort order).
Thanks for the report, I’ll look to fix this when I can work on the code again in a day or two! (It will take a bit more “bookkeeping” to remember scroll positions, so maybe I will just make sure position is reset to show first item.)
-
Looking good, a few comments:
Maybe the configuration files would be better saved in ~/.config/name (i.e. ~/.config/flit/flit.conf) rather than ~/?
If there is no sound enabled (the default for me) saving the flit config results in a seg fault and an empty conf file
If I open a large image in flpicsee it selects 25% zoom, but the title bar is off the screen with 1366x768 using flwm classic and I need to use <ctrl-m> x2 to get it back.
-
Looking good, a few comments:
Maybe the configuration files would be better saved in ~/.config/name (i.e. ~/.config/flit/flit.conf) rather than ~/?
If there is no sound enabled (the default for me) saving the flit config results in a seg fault and an empty conf file
If I open a large image in flpicsee it selects 25% zoom, but the title bar is off the screen with 1366x768 using flwm classic and I need to use <ctrl-m> x2 to get it back.
Thanks for your feedback! I agree the ~/.config location would be better housekeeping. I can move to that for both Fluff and Flit.
I'll try to troubleshoot your 'no sound' configuration crash.
Are you saying that a really big image is just going with 25% zoom in FlPicsee, even if that is not zoomed out enough to keep the full frame on-screen? What happens if you use the right-click menu and select "nice" or whole-image, or fill zoom levels? How big is the original image?
I'll try to investigate your issues and work on your suggestions in coming days.
-
In the latest fluff, there's an issue with not resetting the file list display when using the back button. ...
I think when the back button is clicked it should either re-select the previously selected file in the target directory or should reset the file list display to the to the first file in the list (as determined by the sort order).
Leee, I've implemented the "reset the file list display to the first file in the list" approach and it seems to work. However, I noticed during testing that some filess have properties that are difficult to access, leading to 'stat64( )' warnings on the console if you start Fluff from the command-line, and even worse, Fluff will crash if displaying the File Properties dialog box for one of these bad files and then click the "Info" button. I need to investigate that and develop a more robust way of handling that situation.
-
In the latest fluff, there's an issue with not resetting the file list display when using the back button. ...
I think when the back button is clicked it should either re-select the previously selected file in the target directory or should reset the file list display to the to the first file in the list (as determined by the sort order).
Leee, I've implemented the "reset the file list display to the first file in the list" approach and it seems to work. However, I noticed during testing that some filess have properties that are difficult to access, leading to 'stat64( )' warnings on the console if you start Fluff from the command-line, and even worse, Fluff will crash if displaying the File Properties dialog box for one of these bad files and then click the "Info" button. I need to investigate that and develop a more robust way of handling that situation.
I tried looking at properties on a few files in my home directory but the Info button wasn't enabled for any of them.
Eventually, I selected a symlink ( /etc/sysconfig/tcedir ) and the Info button was enabled on the properties dialog.
Clicking the Info button did not crash fluff (and no messages had been generated on the console) but the only visible action was that, in the file list, fluff navigated to the tce directory as if I had double clicked on the symlink. Is this the expected behavior,
-
I tried looking at properties on a few files in my home directory but the Info button wasn't enabled for any of them.
Eventually, I selected a symlink ( /etc/sysconfig/tcedir ) and the Info button was enabled on the properties dialog.
Clicking the Info button did not crash fluff (and no messages had been generated on the console) but the only visible action was that, in the file list, fluff navigated to the tce directory as if I had double clicked on the symlink. Is this the expected behavior,
The files I was having trouble with were things like /proc/16/cwd and /proc/16/root. The libc function stat64() to look up file properties like file ownership and access permissions can sometimes fail, so in recent versions of Fluff you can see "stat64(): permission denied" messages or similar on the command-line, and you get blank line in the file details window besides the file name for the affected particular files. But apparently these files are links to other directories, so the info button gets enabled. I'm not sure what I intended at this point with the info button... but jumping to the linked folder seems weird and probably not what I intended before. I'll look at this in more detail in the next day or so. I may remove the button or rename it. Thanks again for testing and providing feedback!
- Mike
-
Short, but exciting update... I've been working with the Core Team to host more of my FLTK projects in the Tiny Core Linux github repos! The latest work-in-progress version of Fluff is available here, if you want to download and build it yourself and maybe even make pull requests for changes you would like to contribute:
https://github.com/tinycorelinux/fluff
Flit and FlPicsee are also setup, but I've not merged my latest code updates yet, so I don't recommend pulling down these apps just yet. Watch this space for updates!
Before I request adding a new version of Fluff to the official TinyCore extensions repo, I want to add the "any file" button as Leee suggested and also make some of the recent changes to work with fractional scaling and FLTK 1.4 conditionally compileable so that a usable version of Fluff with the UI updates and some robustness fixes can be available in the 32-bit FLTK 1.3-based Tiny Core system, as well as support building for ARM64 RaspPi TC, although I'll need a partner to test on PiCore since I don't have that kind of hardware.
-
New version 1.1.7 of Fluff is available in the github repo (https://github.com/tinycorelinux/fluff (https://github.com/tinycorelinux/fluff)). This version has a build script updates to support additional TC platforms such as PiCore, and brings many version 1.1.6 features to the 32-bit i686 version of TinyCore that is still using FLTK 1.3 graphics rather than the 1.4.
What does this mean? The biggest difference is that FLTK 1.3 does not support built-in fractional scaling of GUI applications, so you can't zoom the size of Fluff in the 32-bit version like you can the 64-bit version, but other recent changes to the button layout, history navigation, and config file location are all the same.
If you build and run this new version and notice issues, you are welcome to report them here or post it on the github repo. If it seems working well for people, I'll request official update of the Fluff extension in the TCE repos in the next few weeks.
-
Since there wasn't a fluff extension previously, posted to the piCore-16.x repo
-
The piCore64 version of fluff is significantly smaller if
aarch64)
CXXFLAGS="$FLTO -march=armv8-a+crc -mtune=cortex-a72 $OPTIMIZE $SYMBOLS -pipe -Wall -Wextra -fno-exceptions -fno-rtti"
LDFLAGS="-z max-page-size=16384"
;;..is used.
Is there a way to list folders before files in fluff?