fluff v0.90 bugs

[MikeLockmoore]

Jur:  The Ctrl-Q and flicker issues will not be simple to address.  The TC Base editor is not the only app that will do this.  It seams that FLWM will pass up a keystroke event that should be "swallowed" completely by the child process back up to the parent.  There is another minor form of this issue within Fluff's windows... so I have a "Ignore next keystroke" variable to help sort it out.  However, I don't have a good method yet to distinguish between the Ctrl-Q events from a child process and from Fluff itself.  Maybe someone can suggest something or I can think of a better way. 

The flicker behavior now is by design, but maybe not universally acceptable.  Myself, I want Fluff to automatically update its display windows when the filesystem content changes.  Yes, it does cause some flicker, but I don't mind too much. I've worked a little at making the flicker less annoying by attempting to control the timing of it, but don't have a method that works well in all cases.  If many other people don't like this behavior,  I suppose I could provide an option where you must manually refresh anytime you want to see new content.

Guy: Did you start Fluff as the root user ("sudo fluff") or try using the "use sudo" option within Fluff? I will try to reproduce the issue with a dummy directory with the same ownership and permissions... I don't want to experiment with my PC's real boot directory. 

[Guy]

Guy: Did you start Fluff as the root user ("sudo fluff") or try using the "use sudo" option within Fluff? I will try to reproduce the issue with a dummy directory with the same ownership and permissions... I don't want to experiment with my PC's real boot directory.

I tried both methods. It does not work either way.

[Guy]

I recommend you remove "use sudo."

This makes it more child proof, idiot proof and mistake proof.

If you ever watch children on computers, they just click everything and see what happens. If it can be messed up, it will be. I have seen children make older versions of Windows unusable in a very short time.

Some adults are not much more clever.

All of us make mistakes sometimes.

A child can easily click "use sudo," then start deleting files. Most children would not think of opening the terminal and typing sudo fluff.

This reduces the likelihood of the operating system being messed up.

[jur]

Mike:

For the ctrl-Q bug, perhaps you can start a counter for every child editor process, decrementing the counter if any child process is ended.

For the flicker/focus issue, this is quite serious. For example, my default download location is ~HOME. This is also the default when opening fluff. So fluff becomes unusable for as long as a download is happening!

I would suggest a 3-pronged solution:

1. Do not let focus be lost when rescanning
2 Rescan for changes less frequently, say every 2s at most.
3. For a rescan, do not update the window unless something visible has changed.

[MikeLockmoore]

Guy:

I should have pointed out earlier that there is a config file option "AllowUseSudo" that has been part of Fluff for many releases now.  Someone during the TC 3.3 release candidate period made the same point as you (was it you?), so the option was added back then.  It's documented in the help file.  If you set the value to zero, the "use sudo" option completely disappears from the GUI.  I think I will update the help file so the special config file options are placed into their own section.

Jur:

I will see if I can do more to reduce flicker... probably as you say and repress multiple updates within a reasonable period.  And try to prevent any loss of selections during an update.  But I would like to prioritize a few other things like the unexpected closing from Ctrl+Q first. 

Right now, Fluff does not really track child processes.  To implement full tracking to know when child processes go away would require more code than I'd prefer to add at this time.  But I have another idea I hope to test later today.  I'll let everyone know if it works.

[MikeLockmoore]

Good news. The method I mentioned in the last reply to distinguish a spurious Ctrl+Q from a child program works!   I suspected there would be a GUI event related to focus that happens just before the keyboard event arrives.  I have fluff record an accurate version of the system time for each FL_ENTER gui event, and if it happens too soon (0.15 seconds or less) before a Ctrl+Q keyboard event, I have Fluff ignore it.  This fix is in Fluff version 0.9.4.

I also added code to inhibit automatic refreshing of the current directory's file list display if there are any selected items, or if there was already a recent (< 2sec. ago) refresh.  The method I used is not ideal, because some display changes might be inhibited indefinitely, but it should get rid of most of the annoying flicker and loss of selections that Jur posted.  Also in Fluff version 0.9.4.  Note: you can force a refresh with the F5 function key, or by clicking on a different directory then coming back to the original one.

I have posted version 0.9.4 to retrospectiva (links earlier in this thread).  I will also send it to the core team, but it looks like I missed the 3.6rc4 window today.  Since they are in a "feature freeze" I don't know if this will be considered for the official 3.6 release of TC or not.  Maybe there will be rc5 if there are some other fixes that need to be tested.

[roberts]

I will gladly upgrade fluff to 0.94 for 3.6 final.

[jur]

Looking forward to 0.94. I have resolved to avoid using rox as much as possible, both to get used to fluff as well as to try and expose bugs.

I can confirm the segfault and file type bugs are fixed in 0.93.

I have a few items for a wish list. I don't know of a wish list thread?

1. Either auto-mount drives when clicked on, or have a mount button for same.

2. Have a compact list mode - I am not that often interested in exactly what permissions, file size etc the files are, but rather to see more fils at once.

I also have a question of differing behaviour of the mount tool:

If I am running flwm, using mount tool just results in the drive being  mounted. But in openbox, another fluff instance opens in the newly mounted drive. Why this difference?

[Guy]

Either auto-mount drives when clicked on, or have a mount button for same.

I think the user needs a choice. Sometimes I click on a partition in the file manager to see if it is mounted. I don't want to mount it. I just want to know. For example, before removing a usb drive.

Having a mount button, or menu item is a good idea.


Hopefully I will have time to test it more when the new version comes out too.

[jur]

Here's another bug (?) or is it due to another extension that needs to be loaded?

With large files, the file properties are not listed. I was manipulating a 1.6GB file and noted there were no permissions, properties etc listed in the right panel.

[edit] the file is 2.7GB. All properties are shown as null in the dialog box, dates are 1/1/1970. Obviously the properties are not populated.

Rox showed the properties correctly, so it would seem another extension is not needed.

[MikeLockmoore]

Jur/Guy:  I have not wanted to overlap the functionality of the mount tool.  Maybe RobertS and I can make a way for Fluff to request a mount from the mount tool.  Maybe I can also figure out a simple and light way to display an "unmounted" status in the directory tree and/or file list explicitly.  No promises.  I've configured a crude form of click-to-mount in Fluff through file associations before, but that is not generally useful or friendly, admittedly.

Jur:  I've never tested files > 1 GB.  I get the file properties via highly standardized stat() and related API calls.  Was it only the really big file that had no properties populated?  Were there other files in the same directory (or at least volume) that _did_ show proper properties?  Reproducing this issue may be tricky for me... I don't have 2 GB spare on my main laptop's hard disk to create a test file or any USB sticks.    Let me think about that.

I've posted a wish list thread some time back.  Here are a few things I've considered:

a) User-customizable font size for buttons, view panes, etc.

b) Three-pane mode that would work more like MC

c) Thumbnail view (icons and/or thumbnail images)

d) Temporary command line for a selected file (works as a "one shot" file association)

e) Search through file names, or file content

I'm probably forgetting a good idea or two...

We can add the compact listing mode to the wish list.  I don't use that mode often in other file managers.  Coding it would require a different slection/highlighting method, but so will thumbnail mode, so if I implement one, the other may not be much more work.

One caution about new features: the CoreTeam is very committed to keeping the Tinycore base system very small and focused on common-denominator features that are appreciated by most users. I've added a few hundred bytes to Fluff fixing these recent bugs.  That is the right thing to do, but I'm sensitive to it.  Adding "nice to have" features will start to raise objections from the CoreTeam at some point.  5K more? 50K more? 500K more?  I'm not sure exactly as I don't have a specific size budget.  But I think it's already at a point that each update will require a fairly strong justification. 

Of course, perhaps some of these wish-list things could be added to a "Super Fluff" version that is loaded as an extension, maybe replacing the base version.  I took that approach with Fl-PicSee picture viewer back when it was included in the base, and I wanted to support slide show and a few other features. We shall see if I have time or support from other developers to do these wishlist items.

[curaga]

Mike, just create a sparse file. Assuming a linux fs you can just do:
dd if=/dev/zero of=testfile count=1 seek=2048000000

ls -lhn testfile
-rw-rw-r-- 1 1000 1000 977G 2011-04-26 20:41 testfile

Guess if I have 1tb free space

[MikeLockmoore]

curaga: Thanks.  Will that work even if I don't have that much RAM or backing storage?

[curaga]

That file will take exactly 512 bytes, regardless of its size.

[MikeLockmoore]

curaga: Cool!  I learn something new.