zzzFM file manager

Forum Forums General Software zzzFM file manager

  • This topic has 142 replies, 18 voices, and was last updated Oct 12-2:21 am by marcelocripe.
Viewing 15 posts - 31 through 45 (of 143 total)
  • Author
  • #58202

      Concerning the trash bin,
      I have gone 180 degrees. When I first started using antiX, I found it uncomfortable that there was no trash bin. Windows and Linux Mint have trash bins. As I use antiX more, I became more comfortable with no trash bin. Now I find that having a trash bin is not very efficient. My thinking is similar to @Xecure regarding the trash bin issue.


        mounting / automounting:
        Bizarre ~= can be maddening to troubleshoot, due to the number of permutations available.

        Attempting to determine which policy (set where? enforced how?) takes precedence can be an adventure.
        On a case-by-case basis, results will vary, dependent upon adjustments performed here:



          @Skidoo: because of my previous problem with merging the .po file, here is my latest version (only a few dozen entries left to translate to pt-pt)
          I like Xecure’s trash idea a lot!



          (PS: I added a number to the end of the extension, to keep track of the current version…)

          @Marcelo: according to my experience- spacefm only has problems with mounting drives if you are using rox-filer as default file manager- because rox monitors inserted drives and mounts them…

          @calciumsodium – I never saw a drive that I could not mount with the any of the file managers included in antiX- if you like zzzfm, you could try this: check out your thumb drive id/ mount point as created in Dolphin. Unmount it. Try to manually mount it using the data you took note, If that works, try to open the drive in zzzfm. If you can access it, then add a new command in the “tools” zzzfm toolbar menu. It should be something like:
          gksu mount [drive’s path/id] [mount point]

          I use that a lot to mount my old windows partition.


          • This reply was modified 3 years ago by PPC.

            By sidestepping transifex or other intermediary, we can achieve nearly real-time collaboration…
            but we lose the benefit of “nerfed” inbuilt error-checking provided by the intermediary service.

            Yesterday’s po.pt merge submission contained a (one character, among thousands of lines) “fatal” error. I quickly fixed, and did not mention because I did not want to dampen the contributor’s enthusiasm.

            cd po && intltool-update --dist --gettext-package=zzzfm --output-file=pt.po pt

            pt.po:1364: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:1372: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:1376: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:1380: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:1663: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:2298: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:2347: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:2517: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:2745: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:3322: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:3403: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:3935: 'msgid' and 'msgstr' entries do not both end with '\n'
            pt.po:3970: 'msgid' and 'msgstr' entries do not both end with '\n'
            msgfmt: found 13 fatal errors
            1347 translated messages, 36 fuzzy translations, 123 untranslated messages.

            I can probably sort out “WTF went sideways this time ’round?”
            but should I?
            If the submitter had tested, the WTF would be self-evident, right?
            Visit line 1364. The to-be-translated string did not contain a tailend \n,
            and the tranlator should not have “invented” such.
            Okay, fixed and added to the local sourcetree here.

            In reaction to reading “I’m overwhelmed” a few posts back…
            it’s my turn to say
            “Don’t overwhelm/burnout the package maintainer. Please TEST prior to submitting.”

            cd po && intltool-update --dist --gettext-package=zzzfm --output-file=pt.po pt

            If you are reading this and wondering “What is ‘intltool-update’?”
            sudo apt install intltool
            apropos intltool
            man intltool-extract
            man intltool-merge
            man intltool-prepare
            man intltool-update
            man intltoolize

            Also, please bear in mind that skidoo’s host system is google -free. Browsers are blocked from retrieving whatever google-provided captcha is erected at various random filehosting sites. I used a browser in VM to retrieve this .po file today but, as a precedent, I’m re-declaring that submissions to the project must arrive as gitlab merge requests.

            Someone (will not be me) probably should create a transifex or launchpad project to gather contributions from git -averse folks, and someone (not necessarily the the project owner, but some ONE person agreed to be the “point” or “lead” person) can periodically gather, and send git merge request for newly-translated strings.


              Trash (and “plugins”, in general):

              Not mentioned in debian/changelog (because as-yet untested by me),
              v1.0.7-1 should now “notice, and load, for systemwide use” any plugins placed in
              (redacted)(it currently also checks a few other locations, but let’s keep it simple(r) while testing)

              Toward precluding questions regarding plugins, asking “How do I…”
              I’ll mention:

              I never interacted with a SpaceFM plugin
              (well, okay, maybe one time… and she told me she was over 18, and…)

              Through the years, didn’t dolphin_oracle publish a “howto” video for the corbeille plugin?
              Through the years… is there an antiX “spacefm-goodies” (er “extras”?) package available which promised to provide easy-peasy corbeille installation?

              Last night, I revisited the spacefm “plugins” wiki page at github.
              The linked jpfleury “download English version” destination is now dead, as are many of the other links.
              I downloaded and extracted the hairball which reputedly would “build an English, or sv version”… but it contained no English strings. I grepped to find where + how many “spacefm” references would need to be replaced (by “zzzfm”), then perused the content of the scripts employed by the corbeille plugin. Geez, Louise!

              Set aside 8 of the 9 trashem -related scripts, and focus on just the “SendToTrash”.
              Yep, the “logic” must consider (among other details):

              Does the user have sufficient permission?
              Whatif the selected “file” is actually a symlink?
              If a symlink, does it cross filesystem boundries?
              Why else might the operation fail (immutable extended attribute is set, etc)
              What if a same-named file already exists in the “trash” destination ~~ How to handle that scenario?

              I have not tested what will happen (maybe nothing? maybe “go BOOM”?) if the content of this “hairball” is placed in /usr/local/share/zzzfm/included/ (after replacing the few “/spacefm/” substrings)

              I did check, and learned that spacefm//zzzfm does not specifically “know”, ahead of time, any of the exact “cmst_{5,1,4,8}xxxxxxxxxx” scriptnames”. Possibly Probably, the “cmst_1” (vs “cmst_5”, or “cmst_8”) prefix invokes differentiated handling… but good luck, have fun, if someone cares to investigate further.


                @Marcelo: according to my experience- spacefm only has problems with mounting drives if you are using rox-filer as default file manager- because rox monitors inserted drives and mounts them…

                @PPC I use Space-IceWM, or Space-JWM, or Space-Fluxbox and for computers with 1GB of RAM or less, Minimal JWM or Minimal Fluxbox and I configure SpaceFM as the default manager. Since I understood in one of your topics that “Space + Window Manager” makes SpaceFM the Desktop standard, since then I have prepared everything “Space + Window Manager”. I still recommend to the newcomers of antiX (ex Windows users) in the Telegram and WhatsApp groups the “Space + Windows Manager”, in a second moment I recommend your FT10 with Tint2. It makes no sense to transform the “Rox + Window Manager” options into a “Space + Window Manager”.

                What was described by @calciumsodium is exactly what happens to me, being on the Desktop controlled by Space-IceWM, when I need to mount the second hard drive that has NTFS or FAT32 partitions, it is always necessary to use Rox-Filler as root. SpaceFM as root does not mount the hard drive.

                On the subject “recycle bin” … Searching Google “what is the operating system recycle bin for”

                “The Recycle Bin provides security when files or folders are deleted in the operating system. When you delete any of these items from the hard drive, the file manager moves to the Recycle Bin” (I adapted the original text). We have to think of the recycle bin as a second chance for the user, so he does not regret having permanently deleted a file or folder.

                Regardless of whether it is decided to implement the zzzFM recycle bin or not, I will continue to use and prepare for others the antiX recycle bin that I install. So I can avoid complaints from users who use the trash as a “management process” of what will be permanently deleted and what can still be recovered. If @PPC hadn’t created the topics on how to create the trash for antiX, I certainly would have created a topic asking how to have the trash on antiX.

                (Original text in Brazilian Portuguese)


                @PPC eu utilizo Space-IceWM, ou Space-JWM, ou Space-Fluxbox e para computadores com 1GB de RAM ou menos, Minimal JWM ou Minimal Fluxbox e configuro o SpaceFM como gerenciador padrão. Desde que eu entendi em um dos seus tópicos que “Space + Gerenciador de Janelas” torna o SpaceFM como padrão da Área de Trabalho, desde de então eu preparo tudo “Space + Gerenciador de Janelas”. Eu ainda recomendo para os recém chegados do antiX (ex usuários de Windows) nos grupos de Telegram e WhatsApp o “Space + Gerenciador de Janelas”, em um segundo momento recomendo o seu FT10 com o Tint2. Não faz sentido transformar as opções “Rox + Gerenciador de Janelas” em um “Space + Gerenciador de Janelas”.

                O que foi descrito pelo @calciumsodium é exatamente o que acontece comigo, estando na Área de Trabalho controlada por Space-IceWM, quando preciso montar o segundo disco rígido que possui partições NTFS ou FAT32, sempre é preciso usar o Rox-Filler como root. O SpaceFM como root não monta o disco rígido.

                Sobre o assunto “lixeira” … Buscando no Google “para que serve a lixeira do sistema operacional”

                “A Lixeira fornece uma segurança quando arquivos ou pastas são excluídos no sistema operacional. Quando você exclui qualquer um desses itens do disco rígido, o gerenciador de arquivos move para a Lixeira” (adaptei o texto original). Temos que pensar na lixeira como uma segunda chance para o usuário, assim não se arrepende de ter apagado definitivamente um arquivo ou pasta.

                Independentemente do que for decidido sobre a implementação ou não da lixeira no zzzFM, eu continuarei utilizando e preparando para as outras pessoas a lixeira nos antiX que eu vier a instalar. Assim eu consigo evitar reclamações de usuários que utilizam a lixeira como um “processo de gestão” do que será apagado definitivamente e o que ainda pode ser recuperado. Se o @PPC não tivesse criado os tópicos sobre como criar a lixeira para o antiX, eu certamente teria criado um tópico perguntando como ter a lixeira no antiX.

                (Texto original em idioma Português do Brasil)


                  Hopefully testers will notice an improvement re MOUSE3 “I wanna CLICK dammit, not drag” desktop behavior.

                  (During my brief testing, the result of the changed code seemed inconclusive. “Sometimes” I still wound up with the unwanted draghand.)


                    Knowing “how measured” and “what scenario” would be necessary toward arriving at meaningful, comparative, memory usage stats

                    zzzFM 1.0.7 GTK2 version
                    vir virtual memory: 217 M
                    res physical memory: 42860
                    shr shared memory: 20540

                    Those were numbers reported by htop? If so, mine are quite different
                    details: Freshly launched zzzfm 1.0.7-1 gtk2, NOT managing the desktop, (and displaying 3 filemanager tabs restored from prior session), on antiX19 64bit…

                    IIRC, the reported “numbers” are even lower if the scenario is adjusted to “apples-for-apples match” the spacefm first-run scenario, by setting preferences to remove all except the “Name” column and suppressing from display any “hidden” files, and loading 1 tab (/home/demo/)

                    …but I’m content just generically knowing “is significantly lower than”, and that its memory usage is (as I had expected) now//again comparable to that of current version PCmanFM.


                      error occurs here:

                      Merging translations into zzzfm-folder-handler.desktop.
                      make[3]: *** No rule to make target ‘zzzfm-manual-en.html’, needed by ‘all-am’. Stop.
                      make[3]: Leaving directory ‘/<<PKGBUILDDIR>>/debian/build-gtk2/data’

                      Just after compiling the translations for zzzfm-folder-handler.desktop
                      Can you recommend what and where I need to look into to fix this so I can continue building?

                      FYI, using dpkg-buildpackage I too am currently encountering the same failed result after the source code has taken a round-trip to gitlab and back. Earlier, I had already been forced to take the extraordinary step of listing several files within a new (new to me) debian/not-installed file in order to achieve a successful build. Grrrr, those files are present and they do, in fact, wind up correctly installed…

                      Apparently I was too aggressive at performing “housecleaning” when transitioning the sourcepackage content from spacefm to zzzfm. Leano-meano, I removed many files which seemed to be “build artifacts” (regenerated during each build, if missing). Now I’m faced with figuring out which (aclocal?automake?) helper to call, and from which dh_override step withing the debian/rules file, to regenerate the missing prerequisite bit (which, I suspect, is src/Makefile.in). I’ll send a PM to let you know when I’ve fixed the problem.


                        Hi @skidoo,

                        I redid the test and took some screenshots comparing spaceFM 1.0.6-4 GTK2 vs zzzFM 1.0.7 GTK2 on my system: antiX 19.1 64bit.
                        Both were freshly launched, with one tab and show devices. Checked show devices include internal devices, empty devices, mounted networks, and mounted other. See screen shots for spaceFM and zzzFM.

                        Immediately launched, I opened htop and took screen shots. See “htop spaceFM screenshot” and “htop zzzFM screenshot.”

                        My numbers are:

                        spaceFM 1.0.6-4 GTK2 version
                        vir virtual memory: 440 M
                        res physical memory: 72988
                        shr shared memory: 40992
                        mem%: 4.5

                        zzzFM 1.0.7 GTK2 version
                        vir virtual memory: 251 M
                        res physical memory: 51096
                        shr shared memory: 24724
                        mem%: 3.1


                          Fantastic work fixing the right-click issue. I have been testing on all WM after installing the new version and NO right-click drag issue at all on zzzfm desktop. FANTASTIC!

                          left-click dragging occurs less than before (I think), but it is more than acceptable. Very good job fixing this particular issue which spacefm was dragging for years.

                          It would be great if olsztyn could also test this, to confirm it also on his system.
                          With just this I have no reason to go back to spacefm.

                          Hopefully we can figure out the building issue. After this, creating a transifex for antix-contribs or antix-community (whatever name is decided) should help organize translations for this.

                          antiX Live system enthusiast.
                          General Live Boot Parameters for antiX.


                            On RAM use, it depends a lot on graphic processor, kernel and screen resolution, so some machines will have a higher RAM use on idle.
                            On my system, with both spacefm and zzzfm running (and zzzfm managing the desktop!), same configuration as calciumsodium, ps_mem.py shows:

                             14.3 MiB +   2.6 MiB =  16.9 MiB	zzzfm
                             30.2 MiB +   7.7 MiB =  38.0 MiB	spacefm

                            And with NO desktop being managed:

                             13.3 MiB +   3.6 MiB =  16.9 MiB	zzzfm
                             30.2 MiB +   8.2 MiB =  38.3 MiB	spacefm

                            The same? Well, maybe I need to reboot to be sure.
                            EDIT: I am getting similar numbers with the desktop vs without the desktop, so ps_mem.py is not 100% reliable.

                            Anyways, the results are very good.

                            • This reply was modified 3 years ago by Xecure. Reason: more tests, same results

                            antiX Live system enthusiast.
                            General Live Boot Parameters for antiX.


                              As soon as possible I will test “zzzFM”, which could also be called “██████’s SpaceFM” or “██████ Filer Manager” or “SSFM” – First “S” from “██████” and “SFM” from “SpaceFM” .

                              We’re asked to avoid (rightly so, IMO) using a confusingly similar name

                              If you do distribute [..] please chose and use a different name for the program/your work.

                              As a user and programmer you have every right to do what you want with the code under GPLv3+, but this is more of a courtesy thing to clearly differentiate code for the future, in case multiple separate codebases become a problem.

                              and, in the context of the overall project

                              Language                      files          blank        comment           code
                              C                                61          10956          11136          70983
                              C/C++ Header                     64           1031           1321           3281

                              “skidoo” is just an insiginificant blip.
                              I insert no additional copyright claims and, aside from filling in a scant few “skidoo <email@redact.ed>” lines within the packaging files, skidoo creates only a faint footprint.

                               cd workdir && grep -inr skidoo | grep -v skidoo/zz | grep -v en[.]html | wc -l
                              ^---->    15
                              grep -irl [^\/]skidoo[^\/][^z] | grep -v en[.]html | grep -v po/

                              I had forked spacefm v1.0.5x instead of abiding the bloat introduced by later versions (and with an eye toward impending deprecation of GTK2). My central interest has been toward developing companion apps/components which would utilize its socket API. (Interest, not progress. It has been a back-burner, rainy day project.) I chose to “thrown a name on it, and release” in order to facilitate your translation efforts & will gladly handoff//handover the project if someone offers to maintain it.


                                The cons:

                                – The “home” bookmark points to “/home/demo”

                                Thanks for reporting this.
                                I’ve suspected that the shipped session file is a “dirty” copy (should not contain any lines mentioning “cstm_”, right?) but haven’t gotten around to investigating. We will need to collectively continue to investigate which lines should, and shoud NOT, be present within the packaged “first-run default” /etc/xdg/zzzfm/session file.

                                To test “whatif” first-run scenarios:
                                killall zzzfm
                                sudo cp /etc/xdg/zzzfm/session /etc/xdg/zzzfm/session_BAK
                                sudo <fave_text_editor> /etc/xdg/zzzfm/session
                                # Remove and/or insert lines…
                                rm -rf ~/.config/zzzfm
                                # …then launch zzzfm


                                  Fantastic work fixing the right-click issue. I have been testing on all WM after installing the new version and NO right-click drag issue at all on zzzfm desktop. FANTASTIC!

                                  left-click dragging occurs less than before (I think), but it is more than acceptable. Very good job fixing this particular issue which spacefm was dragging for years.

                                  It would be great if olsztyn could also test this, to confirm it also on his system.
                                  With just this I have no reason to go back to spacefm.

                                  This is a great news. This issue was quite annoying in the past for me.
                                  I will be glad to test if someone please could point me to the latest (fixed) deb… The original link results for me with 404 page not found…
                                  Although if Xecure says it is fixed, my testing is likely redundant…
                                  Also, just for me to understand: Right click with even a minute drag of mouse does not cause the drag hand to appear and antiX menu pops up at end of this movement, or still no menu in result?
                                  Thanks and Regards…

                                  Live antiX Boot Options (Previously posted by Xecure):

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