zzzFM file manager

Forum Forums General Software zzzFM file manager

  • This topic has 104 replies, 10 voices, and was last updated May 10-6:58 pm by Xecure.
Viewing 15 posts - 91 through 105 (of 105 total)
  • Author
  • #58555

    appeal so many users

    would require creation of a “for mere mortals” User Guide, covering only BASIC usage… peppered generously with annotated screenshots (language-agnostic arrows, and numbers), and video tutorials links to demonstrate any operation which requires more than “2 clicks” to accomplish.

    I saw it crash is when inserting a thumb-drive, when spacefm is the default file manager

    “when spacefm is the default file manager”
    ^—– and dozens of other variables are in play.
    But hey, let’s blame the file manager cuz it’s supposedly the arbiter for mount operations?

    Yeah, gave me a knot in my stomach when I read, a few posts back (#58358)

    I had some trouble in the past with some exfat or ntfs USB device, but
    skidoo should be able to point us in the right direction

    noooo, skidoo is not an expert on “mounting, and… udevil|pmount|eudev|devmon|”


    why not also correct it to display Gb instead of G, Mb instead of M, etc?

    Well, if I’m not mistaken, there is an user definable option in settings to chose whether G stands for GiB or GB. So G can stand for both here. (Default display unit is GiB, as long as you don’t check the box to use SI units).


    But hey, let’s blame the file manager cuz it’s supposedly the arbiter for mount operations?

    Sorry if what I said came out the wrong way – I wasn’t “blaming” zzzfm or spacefm- but just commenting that fact as the only couple of exceptions to the rock like solidity of zzzfm!
    It happened twice, in two different computers, running the same OS, using the same FM, with another FM as file manager- lots of stuff could have gone wrong with any part of the OS, not necessarily with zzzfm or spacefm- the fact still remains that me doing that caused zzzfm to crash… I have absolutely no basis for my hypothesis that it can be some problem with spacefm launching automatically and crashing zzzfm… I was just thinking out loud, I have no programming skills at all that can point me to that conclusion…
    I’m trying to recall if spacefm had the same problem in my computers when I was using rox-filer as my default file manager, but I’m not really sure…

    You got me on that GB vs Gb detail – it’s stupid, because I’m staring right at my tint2 toolbar indicator (that I wrote/adapted myself), that’s staring back at me telling me that I’m using 1197 MB of my PC’s RAM 🙂

    PS: reading “skidoo is not an expert on “mounting and…” made me chuckle so hard that I had to read the line twice to finish it… On a more serious note- you may not be an expert, but know far more than me or most people on that subject.

    @Robin- nice catch, on that option… I checked it out, I translated it, and never noticed it says “1000” and “k”


    • This reply was modified 1 week, 2 days ago by PPC.
    • This reply was modified 1 week, 2 days ago by PPC.

    so maybe there’s a conditionally-triggered problem that I haven’t yet discovered.

    dug deeper here. Result:

    and/or possibly reading from slow USB or network devices.

    Turned out this is part of the solution. Under some circumstances (haven’t found out what exactly triggers this) the obviously existing cache (usb devices don’t always power up for re-reading) of entries from external drives is emptied. This causes external mechanical hdds to power up from sleep and reread the complete directory (snooooooooooze…), waiting with a blank tab until power up and reading process has finished. When the connection is slow (like USB 1.x) this may take 10 or more seconds each tab, depending on the number of items and speed of drive and connection. In case connection gets lost for some more time the display of content in a specific tab will wait indefinitely, keeping you from reaching the other end of the tab-bar at all.
    You will be able to trigger this by creating a connection to a directory stored on an external Samba server using “connectshares” via WLAN and opening a tab for this device (shouldn’t I really say protocol here?) in zzzFM amidst some more local devices tabs. Now chose another tab and cut off Wlan connection using the hardware wlan switch of your computer. And now try to cross over the tab containing a folder on this device. It’ll stop you until you power up your wlan hardware again, waiting for automatically reestablishing the server connection and until rereading the complete list of items from the resource is done, before allowing you to move to the next tab. If you don’t use wlan you could probably trigger this effect by unplugging a network cable instead, faking a slow or lost connection condition this way, and replugging it to see what happens. Stay calm while waiting, display content of the tab will come back somewhen after connection is re-established, allowing you to proceed.

    I believe this is the main reason for the behaviour observed. The need for real re-rendering graphics display content for each tab here on the way from one end of tab bar to the other is probably neglectable compared to this.

    What I didn’t found out until now was the reason for exhausting the single core 1,7GHz CPU to 100% while only switching across some tabs in this program, which really shouldn’t be a task like compiling some code. Since a dedicated GPU is installed here, this probably isn’t caused by the redraw of display content in the tabs.

    Again, I had to perform all my testing still using SpaceFM, so maybe zzzFM reacts differently already.

    So long


    When the connection is slow

    You might retest to determine whether (for you) the sloooow is avoided by using zzzfm-gtk3 instead.

    read here for another suggestion which may (for your specific case) avoid the sloooow :

    so maybe zzzFM reacts differently already

    I would (do) expect it will react identically, compared to spacefm.
    That’s why I’m trawling through (and linking to) the open/closed memorylane spacefm bug tickets.

    It’s possible that you are experiencing an unresolvable, egde-case, hardware-specific situation like ghostie here:


    But hey, let’s blame the file manager cuz it’s supposedly the arbiter for mount operations?


    Whoops, earlier I neglected include a cheekysarcastic smilie
    and PPC wound up reading it as grumpydefensive.


    I believe we have to differenciate two separate items:

    1.) Firstly, I don’t have any problem having to wait some time for spinning up a rotational USB hdd, before its contents get displayed in a tab. This is hardware specific and typical. Nothing to fix here. But: Taking this common behaviour into account, it would be desirable to change the behaviour of tabbar to what I originally suggested: If you can, please make the tabbar slidable from end to end by clicking on the arrows right and left to it (instead of switching from tab to tab), so you can see which tabs it contains, and simply click the desired one only. This way merely one tab would need to get loaded… If you’d like to see an example what it could look like: the tabbar in firefox. It looks similar to the one from zzzFM, but you don’t need to display the content of each single tab when you only want to switch to a tab at the hidden ends of the bar.

    2.) The second thing is what happens to zzzFM if a connection to a device it keeps in a tab is lost (temporarily or permanent):
    Please take into account meanwhile many people do use NAS devices most frequently, and also want to access them via WLAN. So I believe you’d really need to harden zzzFM against lost connections in open tabs, preventing it to freeze completely until connection is back. It should handle this gracefully instead, whatever the reason of the unavailability is. I’ve described in detail a test case you could use. This is a case not specific to my hardware or so. zzzFM should simply display a blank tab content and in status line e.g. ”reading…”, while allowing user to switch to next tab. Or consider a message like “resource doesn’t respond, retry later or close tab?” after some seconds. But it really should not freeze on this. What I try to render clear is: I am quite sure this is not a rare or exotic use case, concerning specific hardware only. The workarounds you pointed at in ignorantgurus issues don’t cope with this: (from #694)“The only problem that still might freeze the UI is if you have a tab currently opened in an unexisting NFS mount and inadvertedly switch to it.” This is something I believe should never happen to a file manager. Replace ‘unexisting’ by ‘temporarily unavailable’, which is quite common when using WLAN connections to NAS devices.


    make the tabbar slidable
    an example what it could look like: the tabbar in firefox

    howabout… try RIGHT clicking on (mouse3) the left/right arrow widgets.
    Does this not, already, provide what you are describing?
    (AFAIK, this is the already the default behavior of the gtknotebook arrow_widget button)


    Your point is clear: “This is something I believe should never happen to a file manager”

    However, the following is an, accurate, definitive statement. Although not pleasant to hear… skidoo is trapped between a rock and a hard place ~~ wishful idealism, vs limitations imposed by the structure of the program’s design.


    IgnorantGuru commented Nov 16, 2017

    In general, SpaceFM’s extensible UI thread does interact with the filesystem directly for real-time filesystem context, etc. This means on slower or laggy filesystems (and NFS is about as bad as they get), this may affect the UI. This isn’t for lack of trying, and it has been minimized, but an asynchronous i/o layer would need to be developed to avoid this completely. SpaceFM by design doesn’t use a third-party API/cache/etc for filesystem access, so it’s bolted to the kernel, for better and worse.

    On fast filesystems (and a lighter GTK theme), SpaceFM feels very fast and responsive. On filesystems that hang frequently, it can be frustrating to use. It’s always possible to use another lightweight file manager in parallel with SpaceFM to help with laggy filesystems.



    skidoo is trapped between a rock and a hard place

    I wish you could sit at least a bit more comfortable 😉

    limitations imposed by the structure of the program’s design.

    It’s sad to read this. Since file manager is kind of central institution in an operating system, at least in users perception. So when it crashes (or freezes, which makes no difference for standard user) on everyday tasks, they will probably not consider antiX as a rock stable and reliable replacement for e.G. MS Windows (which it actually is). Well, when this can’t get helped by some kind of workaround, there is nothing to say here anymore. We’ll have to live with it simply.

    I’ve checked this right mouse button feature on arrows (actually I didn’t know this, so thank you!). It is nice, but not sufficient for a good workflow: It only jumps from one end to the other. This is enough when only few tabs are opened. But for power users with 17…20 Tabs open at once it is not sufficient. You can reach directly the four outermost tabs from the left, and the four outermost tabs from the right only. The 12 Tabs in between are still out of reach. Moreover it is difficult to keep track of the position of tabs when jumping this way only, even when they are sorted by dragging them with the mouse within the line to a position you like most. If this right click function could be changed to move the line of tabs instead of jumping to the ends it would be really great.


    power users with 17…20 Tabs open at once

    Yes, and the usage scenario can even be more complex than that.
    {space,zzz}fm is not a singleton; a user may have concurrent instances running, spanning multiple workspaces (in addition to an optional daemon instance managing the desktop eyesores eyecons). This presents complexity in successfully meeting feature requests such as “an unmount event should trigger closure of all tabs, in all windows, for now-unavailable browsed directories”.

    So when it crashes (or freezes, which makes no difference for standard user) on everyday tasks, they will probably not consider antiX as a rock stable and reliable replacement for e.G. MS Windows (which it actually is).

    Right, I hear ya and (but) in antiX, spacefm is not the default desktop manager, nor the default file manager… and I did not propose setting zzzfm (nor spacefm) as the antiX default desktop manager. I just published my forked project in order to facilitate the stymied translation effort.


    EDIT: I will be building skidoo’s new .deb with the new translations in a bit.

    • This reply was modified 3 days, 16 hours ago by Xecure.

    Built new zzzfm .debs from today’s changes in skidoo’s upstream source. Its should also include most of the translation contributions from transifex.

    zzzfm 1.0.7-4 Changes:
    * increased mainwindow initial size request dimensions
    * removed from preseeded zzzfm session file the hardcoded “home/demo” strings
    * vfs-file-task.c: increased smart queue copy/move limit, to 100 MB (and the delete limit, to 10 GB)
    * store thumnail files in a/the XDG-compliant directory
    * ptk-handler.c: add android-file transfer support (aft-mtp-mount )
    * find files: larger initial dimensions of results window
    * item-properties: suppress ability to edit timestamps (doc now advises use of ‘touch -m %F’ custom command)
    * toolbar displays a blueCube icon; redCube instead for AsRoot window
    * suppress main_help_opt, pending implementation of a safer xset_open_url()
    * (pending followup) limit exposure to main_open_network_location
    * suppress availability of hand_net_http, aka webdav, aka davfs
    until I find time (if ever) to assess the significance of
    “One thing I don’t like about this solution is that it momentarily opens a terminal to open a
    regular http link in the user’s web browser, which is why I used terminal conditionally in the original.
    I think it would be better to only run the terminal for udevil if possible.”
    * adjustments within the /etx/xdg/session file
    * first-run, display tree to left panel by default (gauge feedback on this)

    • This reply was modified 3 days, 13 hours ago by Xecure. Reason: adding that it includes translations

    EDIT: I will be building skidoo’s new .deb with the new translations in a bit.

    Thank you very much, Xecure.
    Muito obrigado, Xecure.


    I tested, over the weekend, version 1.0.7, localized to pt- everything looks ok ( the “cut” string that comes up in the contextual menu was changed, and appears untranslated in this compiled version, since then, I finished all zzzfm’s localization to ptpt, so it should come up 100% localized in the next compiled version)

    About the changes: I personally dislike the “file tree” on the panel… I think that may help some users migrating from windows 98, the rest could be a bit confused…
    I think that turning on by default the “devices”, with the “show internal drives” feature on, would be useful, so folks can use zzzfm out of the box to, well, access their stuff (partitions from others distros, etc)
    I quite like the “bookmarks” feature on, but I grant that may not appeal to everyone (despite being a common feature on modern File Managers).

    I noticed that the menu entry that allows to change the html manual location is absent from this latest build. Is that by design? (the related strings are available in transifex)

    I made zzzfm my default file manager and, during the week end, I found no problems of it “crashing” when plugging in pendrives. [May be completely unrelated to having it as default fm, I dunno…]

    Zzzfm runs as fast and light as always.

    Suggestion: (re)add a “version” menu (like spacefm has)? It can even use zzzfm’s dialog to display the contents of the command “zzzfm –version”, maybe?…

    Edit: sorry, I forgot to post how I did add a “version” menu entry, if someone wants to test how it looks – click the “help” menu on the toolbar, then right click the empty space at the end of the menu > Click the “+” menu entry > choose the name for the menu entry (something like “ZZZfm version” > Use this command:
    version=zzzfm –version&& zzzfm -g --title "ZZZfm" --label "$version"
    In the “options” tab, uncheck the “run as task” option…


    • This reply was modified 2 days, 7 hours ago by PPC.

    The interface can change using the settings file (be it with a package that installs it or share the file and store it in /etc/skel), so no need to play so much with the default configuration if we later create a zzzfm-desktop-defaults as antiX has for spacefm.

    From time to time, with heavy use, zzzfm crashes for me, but that already happened to me with spacefm. I just open it again and it continues exactly in the same place I left, so nothing to worry about. I still get strange dragging issues with normal click on the desktop, but that is probably because I am trying to produce them myself to see if they are gone (hahahaha).

Viewing 15 posts - 91 through 105 (of 105 total)
  • You must be logged in to reply to this topic.