Fluff beta version(s) leading to new Version 1.1

[Rich]

Hi MikeLockmoore
Well, I got curious, so I decided to examine the values returned by those three Window fields.
The window field is the ID of the window where the event occurred.
The root field is the ID of the root window, which is the parent of all windows on the system.
The subwindow field was always zero.

[MikeLockmoore]

Rich: Thanks for the additional info.  I don't think FLTK makes it easy to look at the raw X event info, but if I need to, perhaps I can figure out a way.  Based on some feedback on the FLTK developer's forum, I may be able to re-do some event criteria in Fluff so it avoids the little problems jls has been helping to point out. 

I think one key (sorry about the pun  ) observation is that FLTK, like many (all?) GUI toolkits sends both a KEY-DOWN (pressing) and KEY-UP (releasing) events.  The vi session in aterm in the situation that jls posted closes on the key-down event in the aterm window.  Then, when the user releases the key, the focus is probably back on Fluff, so the key-up is sent there (aterm no longer exists).  But I've coded most of the keyboard shortcuts to act on key-up.  So if I can switch things to mostly reacting on key-down, it may work out better.  I don't know yet if there will be many other side effects, but there could be some.  Hopefully fewer and easier to manage overall, and will let me clean up some uglier parts of the Fluff code. 

[MikeLockmoore]

Sorry for the long absence. 

I have reworked the keyboard handling stuff in Fluff to take action on key-down events, which seems to eliminate (most of?) the weirdness we had before.  This seems to be fundamentally better, and I was able to delete all of the "Ignore next key" stuff that I kludged in the earlier versions.

So I think this new version 1.0.6 will be better-behaved, especially in relation to keyboard use, but please be aware that some keyboard behavior may be a little different than you are used to if you are a habitual Fluff user. 

jls: I did a quick test in E17 (Elightenment) and I think Fluff is now well-behaved.

all: If you have any feedback on this new version, please post!  Thanks for your patience.  -Mike

[coreplayer2]

Thanks, we really appreciate all your efforts working out the gremlins and enhancements to our favorite file manager

[jls]

the explore button opens another instance positioned in the root of the file system.
Thanx for the archive button.
If I press the TCE button I see: no TCE drive defined...

[MikeLockmoore]

jls: thanks again for more testing and feedback.  New version 1.0.7 handles the TCE directory better and should find the TCE directory at the place pointed to by /opt/.tcedir (for Tiny Core versions 3.x), or at /etc/sysconfig/tcedir/, or at /tmp/tce.  If all of those fail, then you might see the message about setting up a TCE directory.

I also changed the way a terminal is opened.  The command is now "cd [directory]; aterm &".  I hope this works better for you. Please let me know if it works.  If not, perhaps I can set up a way to have a custom terminal command string read from the .fluff.conf file. 

[jls]

Thanks for the update.
The TCE button now works, but the explore no, it still opens the root dir.
Maybe better to change aterm to xterm since xterm it's just a link to aterm and if one use another terminal I think it should change the xterm link.

[MikeLockmoore]

jls: Could you try to modify your copy of the fluff.cpp to call xterm and let me know if it can open a terminal in the appropriate directory?  The line numbers to change are 588, 589, 596, 5030, 5328, and 6359.  It works for me either way.

[curaga]

Yikes, someone needs to #define "xterm"

[MikeLockmoore]

Yikes, someone needs to #define "xterm"

The proper way would be to use/check the environment variables, no?  And as I mentioned, maybe I can set up a .conf file option to provide the terminal startup command of your choice. 

But first I was hoping we could try a few hacks to see if we can get the terminal opening in the currently-viewed directory in e17.  If anyone could explain why it seems to be always defaulting to the root directory, I'd like to hear it!

[Rich]

Hi MikeLockmoore
If the current working directory of fluff is root while it's running, and the cd command in  "cd [directory]; aterm &"
fails, that will cause that behavior.

     [EDIT:] Sorry, that's wrong, I didn't pay close enough attention.

[curaga]

Oh, just commented on having to change it in six places instead of one

[jls]

I was sayng hat the explore button always opens the root dir, while the terminal works, opening the current dir

[MikeLockmoore]

jls: ?  I did not understand your comment.  Maybe I still don't understand.  Is the "explore" button doing something wrong?  If you think so, it would help me if you could provide some more explanation.  Perhaps a screen capture would help too.

Curaga: Yes, perhaps, but several places have the aterm/xterm as part of a longer literal string, so factoring out the "aterm"-only part to a #define would require inserting it into various other stings, so it's not a clear advantage here.  I do use #defines in other situations of course.

[Rich]

Hi MikeLockmoore

The proper way would be to use/check the environment variables, no?

That's what I would have thought, however, the env command lists:

Code: [Select]

COLORTERM=rxvt
TERM=rxvtby default instead of aterm. I see this under TC3.4 and TC4.1 even though rxvt is not installed.