Fluff beta version(s) leading to new Version 1.1

[MikeLockmoore]

jls: maybe a segfault.    I don't plan to install Enlightenment anytime soon, but would be willing to try to make a fix if you can help me isolate the area of Fluff that is not working properly and retest the possible fix.  Here are two things to try first:

1) Uncomment some of the printf() statements, rebuild, and run from the the command-line, especially line 3566 at the top of the main window event handler and maybe insert at line 6550 a new printf() before the return statement:

Code: [Select]

printf("\nFluff exited normally.\n");
With this we can compare the event sequence sent to Fluff by FLWM versus the sequence sent by Enlightenment during the window minimize action.

2) Make a "debug" build Fluff and run it in gdb debugger.  gdb will tell us if it is exiting normally or because of a segfault or some other exception.  If it does crash, use the 'bt' command in gdb to print a back-trace and send a copy to me so I can see the execution path that lead to the crash.

[jls]

I did what u wanted but it looks like there is no crash, anyway I've attached to this post the backtrace.
I've splitted the log in 2 parts because the file was too big as attachment

[jls]

I made the tests with fluff 1.0.3

[MikeLockmoore]

Thanks jls.  I agree is does not look like a crash.  I will need to compare the GUI event codes and their sequence in your log to the same scenario in FLWM and see how they differ.  Am I correct in assuming you clicked on the minimize window control just before Fluff exits?

[jls]

Am I correct in assuming you clicked on the minimize window control just before Fluff exits?

yes, you are correct, if I'm not wrong fluff exits also if I change desktop

[MikeLockmoore]

jls: try to comment out the "Running = 0" statement at about line number 3677 so it looks like this:

Code: [Select]

        case FL_HIDE:
            //Running = 0;
            return 1;

Then recompile and try it in Enlightenment. 

I'm not seeing the FL_HIDE event appear when using Fluff in FLWM, but that event is in the log you posted.  I'm don't remember right now why I have Fluff exiting when FL_Hide appears, but I'm sure I had a reason in the past. 

Assuming this fixes the problem for you and it also seems to work in FLWM now (why not before?) I'll put this fix into the official Fluff release.

EDIT:  If Fluff does not minimize after the change, also try to comment out all three lines shown above.

[jls]

no change, also commenting all the 3 lines.
I was wrong, fluff doesn't closes if I change desktop, only if I minimize it.
I found another bug:
if I open a generic file, it opens with vi, but when I close vi it opens it again, then I close and it's ok.
I mean it opens vi twice

[MikeLockmoore]

jls: I found a fix for the minimize issue, but could not reproduce your double instance of vi bug.  I tested it by moving my current .fluff.conf file to a new name so the when Fluff starts it uses default parameters.  I used the edit command on a text file.  It opened vi and I could use the :q command to quit it, and it closed without opening a second time.  I don't know why you have two instances.  Maybe check your .fluff.conf file for multiple entries in the associated app settings?

all: The attached source package for version 1.0.5 has the following fixes/changes in response to recent issues:

1) After a file move or copy, the file details (right side) window will remember your scroll position so you can continue from the same location. (Thanks to coreplayer2 for suggestions.)

2) When the mouse pointer moves over the separation between left (tree) and right (list) panes, the cursor shape changes to a double arrow (<-->) to help users notice that the panes can be resized.  (Thanks to jls_legalize for the suggestion.)

3) When the user clicks on the minimize button, Fluff only minimizes, not exits (as it does in e17 and perhaps other window manager/desktop besides FLWM).  (Thanks to jls_legalize for the bug report)

4) "Fluff" or "Fluff File Manager" is now in the window title instead of the generic "FileMgr" - isn't branding key? 

If you can, please download this latest version, build, test, and report any further issues here.  Thanks everyone for your interest and feedback!

[jls]

ok mike
now on minimizing fluff doesn't closes.
The double opening happens when double clicking on a file, not if I press enter.

[MikeLockmoore]

jls: I understand the problem better now but don't have an acceptable fix.  FLTK in my opinion ( ) has a bug, because a parent window will often receive an event that should have been consumed by a child window that is closing.  For example, when you close the vi session with :q[enter] or even when the application presents a FLTK message box that you close with the enter key.  The parent window gets the Fl_Enter keypress event, although it logically was intended to go to the child window (e.g. the vi session in a separate terminal window).  Who wants the parent window to _also_ respond to the same key press?     To make matters works, e17 and FLWM seem to be somewhat different in the event sequence and other details. 

I have a hacky way of ignoring extra key press events from the FLTK warning/info message boxes I use in Fluff, but so far I don't have a good way to manage the enter key event that comes from a file-associated application.  There are times you would like to select a file and press [enter] in Fluff, so [enter] is sometimes valid, and so I can't just ignore it all the time.  I will try to keep working on a good fix.

Maybe the FLTK dev's forum has some ideas on this.  It seems like a huge quirk if not outright bug, and it's hard for me to believe an acceptable fix or way to manage this behavior is not yet known.

[Rich]

Hi MikeLockmoore

a parent window will often receive an event that should have been consumed by a child window that is closing.

I guess you don't have access to the do-not-propagate-mask?

[MikeLockmoore]

Hi Rich.  Is that is something that comes from X?  I'm far from an expert in X fundamentals.   

The issue jls has posted happens when we use aterm in a child process to execute vi editor, and the final enter key press that closes vi is getting replicated up to the parent (Fluff).  Where and how does one set a mask for that?  Fluff doesn't always directly create the child window.  For the aterm window, it's invoked through a call like system("aterm -e vi ...").  For the little message boxes used in Fluff, its called through the FLTK functions like fl_message("..."), so I don't have direct access to an event mask then either, as far as I know.  But I'm willing to learn more, if you have a good reference or can 'splain a thing or two here.

[Rich]

Hi MikeLockmoore
Although far from being an expert, I have been playing around with some X programming. You can use the
do-not-propagate-mask to prevent mouse clicks or key presses from propagating up to that windows parent.

Code: [Select]

XSetWindowAttributes xswa;
xswa.do_not_propagate_mask=ButtonPressMask | KeyPressMask;
XChangeWindowAttributes(display, window, CWDontPropagate, &xswa);
http://tronche.com/gui/x/xlib/window/XChangeWindowAttributes.html

[Rich]

Hi MikeLockmoore
This may also be of some use:
http://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html
Assuming you have access to the event loop and the window IDs of the windows you create for Fluff, you might
be able to filter out events that did not originate in one of your windows. Unfortunately, the structure lists three
different window IDs:

Code: [Select]

Window window; /* ``event'' window it is reported relative to */
Window root; /* root window that the event occurred on */
Window subwindow; /* child window */so you would need to figure out which field is the relevant one.

[MikeLockmoore]

Thanks Rich.  I'll see if I can make some use of that info.