Future Fluff features (after version 1.1)

[coreplayer2]

Another glitch I noticed with fluff;

When ever I copy a file name into a rename space, I usually end up with an extra file (copy) of the original file where the name originated. 

I often create new files then copy the name from an existing file to it then modify it like +1 etc.  Unfortunately after pasting the name into the yellow (name change) space and pressing enter, the name change succeeded but we also get a copy of the original file, which now need deleting.

?

Please if you get a minute to track that one down would be much appreciated.

[coreplayer2]

While we're here, 

there is another glitch where at least 50-70% of the right window is lost when resizing with the intent to enlarge the viewable area.  Which kinda defeats the purpose.   Once the fluff window has been coarsely re-sized to the desired position (this is when the window is lost) it requires only a couple very small re-size adjustments to fix the viewable area.

[MikeLockmoore]

coreplayer2: Thanks for posting your feedback and suggestions. 

I can see that doing a Ctrl+V to paste a name during renaming also triggers a file copy to happen.  I will try to fix this.

The refresh behavior is so that you can see the fact that the dropped/pasted files quickly in the window.  I made an effort in my most recent code to preserve selection and current scroll position in the destination directory window after the updates.  I'm not sure I understand why do you need to search with the scroll bars.  Can you provide a little more detail?  Are you dropping a large number of files?  I'd like to better limit the amount of flicker that window refresh causes, but I think you are having a more substantial issue.

What do you mean that "at least 50-70% of the right window is lost when resizing"?  That part of the window is completely blank?  So far, I can't reproduce it.  Are you using the FLWM window manager or something else?

[coreplayer2]

Well this is 100% reproducible on all 20+ machines I use, both VM and real PC's.     fluff is the only app effected.   Ctrl+Alt+M does not share this effect.  Occurs when dragging the right side window edge, lower right corner or window divider bar in a rightwards direction.
Note the effect occurs less in real PC's and is more often reproduced when moving the divider bar to the right.

Anyhow this is only a minor issue.


and from another pc



other really awkward effects also only associated with fluff is the use of a Bluetooth mouse + keyboard on a live machine in which the mouse only controls are reversed, ie: selecting and holding a mouse button down brings up the desktop menu, then one has to scroll to the desired menu item then release the button for selection.  holding down the mouse button while finding the menu item is required or the menu will vanish.  lol   really confusing to use i can assure you.

am using  flwm_topside almost exclusively (albeit a copy of Fluxbox around here somewhere).

Note:  Updated with corrected info.

[MikeLockmoore]

coreplayer2: Thanks for the pictures and extra information.  I may have seen that window size issue before, but I don't think it happens nearly so often for me.  I will try to reproduce and troubleshoot it however.

Also, do you have any more description about losing your place after a drag-n-drop or copy-and-paste?  Such as a list of steps I might try so I can reproduce the behavior that is frustrating you?

Good news on the renaming / copying issue:  I have implemented a fix that seems to work.  It will be in the next public release.  Do you compile Fluff from source or do you run it as an extension?  If you are willing to beta-test the next version before it's posted to the repository, PM me and we can make some arrangement.