mounting with xfe under flwm causes malfunction

[Guy]

When using jwm, you can open xfe, click mnt, then right click a partition, and click mount, to mount it.

Since flwm has been introduced, this causes xfe to malfunction.

I have mentioned this before.

I am currently using tc2.4rc3. This also occured in tc2.3.

See if this can be reproduced. I always wonder if some things may be unique to particular computers.

[MikeLockmoore]

When I tried it, I see Xfe hang, showing a wrist-watch (wait) icon.  If I use the TC mount tool, I can mount and unmount a memory device, and automatically see the Xfe view of its content update, so that works, and should be used as the work around.  Is the source to Xfe readily available?  I may be able to poke around a bit.  Perhaps the way Xfe performs the mount is not optimal for TC and/or flwm.

I think I only tried to use Xfe once briefly.  I must say, I rather like it now compared to Rox.  Of course, I still imagine a *really* small, FLTK-native file manager.  But if I make it, it would look and work a lot like Xfe! 
--
Mike

[Guy]

Be aware, it works with jwm.

There may be some compatibility issue with flwm.

[MikeLockmoore]

Be aware, it works with jwm.

This point was already understood.  It's not as if flwm has code that says "hang Xfe if it tries to mount a drive." 

flwm is very simple, so it may be lacking some kind of notification infrastructure provided by other WMs like jwm.  So Xfe ends up waiting for an event that does not happen in flwm.  But I think it will take code review of the mount/unmount feature of Xfe (or maybe how it handles spawning of all external apps) to understand in detail why it does not work in flwm and whether there is a more general way that will work with flwm plus the others.  If nothing else, maybe it can be patched to recognize TC+flwm and handle the mount request as a special case.
--
Mike L.

[Jason W]

Mike, the source for xfe is in the source area:

http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tce/src/xfe/

As mount/umount calls on a popup window, if that window does not pop up I reckon it will just hang.

With appbrowser and flwm, I do not see the popup that displays download status.  The extensions get loaded, evedently not waiting on the download status to operate for it to function.  But xfe evedently waits on that poput to mount/umount. 

[perthie]

As mount/umount calls on a popup window, if that window does not pop up I reckon it will just hang.

I am seeing a similar situation with a Java app I have installed. When the app launches, it pops up a window that must be dealt with before the main screen can become active. However, flwm pops up the window underneath the main screen. So the program hangs until you bring up the flwm menu and terminate the popup.

[MikeLockmoore]

Jason:  I actually see a window very briefly appear when I invoke the mount/umount in Xfe.  The spawned mount or umount command actually works, but Xfe still seems to get hung after popen(" ... mount ...") is called.

perthie: The "pop-under" window behavior may not be helpful (and maybe something that can be improved in flwm), but I don't see anything in the current Xfe code that would get messed up by window stacking order.

The File::mount member function has the following code:

Code: [Select]

...
// Perform the mount/unmount command
FILE *pcmd=popen(cmd.text(),"r");
if(!pcmd)
{
MessageBox::error(this,BOX_OK,_("Error"),_("Failed command: %s"),cmd.text());
return -1;
}

// Get error message if any
char text[10000]={0};
FXString buf;
while(fgets(text,sizeof(text),pcmd))
buf+=text;
snprintf(text,sizeof(text)-1,"%s",buf.text());

// Close the stream
if(pclose(pcmd))
{
MessageBox::error(this,BOX_OK,_("Error"),"%s",text);
return -1;
}
// Hide progress dialog
hide();
// Success message, eventually
if(mount_messages)
{
if (op==MOUNT)
MessageBox::information(this,BOX_OK,_("Success"),
                                              _("Folder %s was successfully mounted."),dir.text());
else
MessageBox::information(this,BOX_OK,_("Success"),
                                             _("Folder %s was successfully unmounted."),dir.text());
}
return 1;

We know the popen is doing what it is intended to do.  We also know the wait cursor is not changing after invoking the command.  Right after this code returns, the wait cursor should be cleared, and if there was an error, an error box would be displayed.  So the only thing in the code I see that could possibly cause a hang is the while loop, which collects any output from the spawned mount/umount command.  I think for end-of-file condition, fgets( ) may return the address of the buffer passed to it, while on a true error, it returns null.  It might be a worthwhile test to compile it with the following while condition:

Code: [Select]

           while(fgets(text,sizeof(text),pcmd) && strlen(text) > 0)

Alternatively, the command string that contains "mount " could be changed to "mount -v " so that some text will come back on the file handle opened with popen( ).

If it is not the while loop, I guess I don't understand the code enough to say yet what is going on. 
--
Mike L.

[MikeLockmoore]

Guy:  Which version of TC were you using with jwm when you saw Xfe be successful with mount and unmount?  Have you loaded jwm on a current (2.3.1 or 2.4rcX) TC and tried it?  I'm wondering if the fgets( ) implementation in libc has changed behavior somewhere along the line.

EDIT: I tried the while loop change I mentioned above and it did not work...    Back to the bit forge...
--
Mike L.

[MikeLockmoore]

I have a fix! 

The problem was not the while loop or the fgets( ).  It was the call to hide( ) immediately followed by a MessageBox::information( ).  The File class is subclass of dialog box, and it acts as the parent window for the result status info message box.  So when the File dialog box is hidden in flwm, the result info message box is too (but not in jwm?  Or maybe this particular message has been configured off in working system?) .  Essentially, the app is waiting for you to click "OK", but you can't see it, so everything hangs.

The solution is to not use "this" as the parent window for the info message boxes.  I replaced the "this" pointer with a call to getRoot( ), since the root window should not be hidden.  This should be at line 2008 in File.cpp:

Code: [Select]

if (op==MOUNT)
MessageBox::information(getRoot(),BOX_OK,_("Success"),
                                                           _("Folder %s was successfully mounted."),dir.text());
                                                               // ML: getRoot() so flwm won't hide message box
else
MessageBox::information(getRoot(),BOX_OK,_("Success"),
                                                            _("Folder %s was successfully unmounted."),dir.text()); // ML: ditto

Apply the attached patch and rebuild.  In this patch file, I also updated the version string to "1.19.2.1", so we can distinguish this patched version from the original.

I grepped the source tree and see a bunch more calls to hide( ), but I have to imagine that most of these are harmless.  However, there may be a few that ought to get the same treatment.

Jason: can you issue an updated .tcz built with this patch for the repo?
--
Mike Lockmoore

[Jason W]

Mike -

Rebuilt and tested with Icewm and FLWM and all seems good here.  It is in the repo now.

Thanks
JW

[MikeLockmoore]

Jason:

Hmm.  I'm using TC 2.4rc4 with flwm, and after deleting the old copy, rebooting, and reinstalling the .tcz, I don't have a wbar icon or flwm menu entry for Xfe.      I can launch it fine from the command prompt.  I did a mount -o loop on the .tcz and see that there is nothing included under /usr/local/tce.---

I tested it anyway, and it seems to mount particians fine.  However, I don't see the extra .1 in the version number in the about box.  Was the version string update not included in your build?

Would you please consider re-doing the .tcz to include the icon/menu entries when you have time?
--
Mike L.

[Jason W]

The extension that was uploaded was meant to be a test one, but since it worked well I uploaded it but forgot to add in the menu/icon.  I had other things going on and overlooked it.  It is fixed.

Your patch was applied without any alteration.  I rebuilt it again with the patch to make sure and "about" does not show the .1 version number.  I put the .1 in the info file along with attribution for the patch, but if the "about" box needs to display different than it does feel free to rebuild and submit the extension.

[vinnie]

In my stable version of tinycore xfe moun and dismount correctly but the interface freezes

[MikeLockmoore]

Jason:  I know you are busy!  I, and I think many others, appreciate the bazillion things you do to make TC a very capable system.  I've had my share of things overlooked too - maybe you noticed the number of versions of Flit I put out there before I got it to version 1.0.0  .

The .1 I added to the version number is not a big deal, and I don't really care if does not appear in the Xfe app, so I'm not going to prioritize submitting my own version of the .tcz.  But it seems strange since it definitely shows up in the about box for my local build.  

Thanks for the fast turn-around!!

Vinnie: Which version of TC?  Are you sure you got the very latest version of the xfe.tcz?  The behavior you describe sounds just like the old (> 2 days ago) version.
--
Mike L.

[Jason W]

Mike,

Thanks for your fix and what you are doing for TC and the improvements to flwm and it's usage across the selection of apps in the repo.  I am happy to apply the improvements to extensions I maintain.  I should have caught the fact that I didn't add the menu/icon before I uploaded the final xfe. 

I saw whare the VERSION was patched in the file, and I am also curious as to why my build does not reflect that in the about box since yours does.  I will revisit it to make sure that I applied the patch correctly. 

JW