Reduce fman size / Qt, PyQt5 dependency, static linking, etc.

[nanoant]

Hello, congratulations for your effort bring new SublimeText like file manager 🍷 . I would normally comment on the blog but (1) it has no comments functionality (2) and anyways a ticket is better place for that. 😉

So I read and generally agree with conclusions in your blog post: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ but then I have a couple of remarks:

1. Choosing Qt and using shared libraries implies quite large app package size, this is exactly probably one of the reasons Sublime Text have chosen to have its own minimal (G)UI implementation (backed by Google's BSD licensed Skia). Then if fman is meant to be somehow Sublime Text counterpart, its size and portability (is there USB stick portable version of fman?) should be important, maybe more important that custom theming ability.

2. Then with Qt you might want to go for static linking (at least on these platforms you ship Qt with app) with stripping the final fman.exe binary, I believe this should cut the file size at least in half, but this requires commercial license for close-source project.

3. Another thing is PyQt5 dependency (which is moreover GPL or commercial only - thus all plugins relying on UI, even indirectly, may need to be open-sourced). So is it really necessary? Can the GUI be part of C++ only app core, and the python side be platform and UI kit independent? You could provide some minimal UI platform independent and widget kit independent API with pybind11, this would remove even more weight off the project and ensure that plugin maintainers will not depend on Qt, which may be bad choice for "futureproof" project, eg. you decide at some point to rewrite UI part with some other widget toolkit, but existing plugins still need Qt.

Cheers, Adam

[mherrmann]

Hey Adam, thank you for the kind words.

1. I believe Jon Skinner (ST's creator) chose the minimal GUI implementation mostly for performance reasons. I don't think he cared / cares much about executable size and portability. Or do you know of a source that says that he chose it for size / portability, not performance? There's an issue for creating a portable version of fman.
2. I don't think it necessarily, absolutely requires a commercial license. The LGPL does permit static linking, under certain conditions.
3. The PyQt5 dependency is absolutely necessary. Removing it would more or less require rewriting fman from scratch. Plugins are currently advised not to use the Qt API for precisely the reason you mention.

In short, I appreciate the input and the suggestion. But the last point in The Zen of fman specifically says:

Development speed matters more than program size.

The things you mention would all be nice. But there are so many (imho) more important issues that I don't have time to focus on program size right now.

[nanoant]

I believe Jon Skinner (ST's creator) chose the minimal GUI implementation mostly for performance reasons. I don't think he cared / cares much about executable size and portability. Or do you know of a source that says that he chose it for size / portability, not performance? There's an issue for creating a portable version of fman.

You are right, quoting the ST3's home page "Sublime Text uses a custom UI toolkit, optimized for speed and beauty, while taking advantage of native functionality on each platform." . While there's no certainty to claim that custom GUI toolkit was used for portability or executable size (corrected my post above), but reading: https://news.ycombinator.com/item?id=2822114 Also: https://forum.sublimetext.com/t/to-stay-or-to-leave-of-this-community/10354/3 https://forum.sublimetext.com/t/disassembling-sublime-text/24824

Gives kind of impression that the aim was to keep the code well optimized and lean as well (indirectly - using C++ for most of the stuff and creating only the widgets that are necessary), hence rather small dependencies and overall portability, in opposite to pulling all Qt (widgets) with shared libraries.

Development speed matters more than program size.

Okay, I missed that one. But on other hand I (personally) don't believe that program size must be necessarily in contradiction with development speed, even I know it usually is 😉 However, relaxing restriction on codebase and dependency size leads (often) to large unmaintanable and poorly optimized code. So I would lean more towards "Development speed matters as much as program size."

Of course all of that is just my own opinion, still I enjoy following fman's evolution and original ideas, as a long time Norton Commander then Total Commander, then sometimes Midnight Commander then macOS Forklift user.

[mherrmann]

Yes, I do think Jon cares a lot about code quality and leanness. The fewer dependencies the better. I very much agree with that. But if I were coding fman in C++ then I'd be nowhere near where I am today. It's already a big project. It would not be wise to make it even more complex. And in the case of C++, I'm about 10x slower developing in it than in Python.

I'm glad you like fman! I do appreciate all the points you make. I'm with you, and I believe fman's minimal approach also shows that I care about leanness. At the end of the day, it's a trade-off. Currently, I believe it's more important to make fman more usable (eg. by adding certain basic features that are still missing) than to spend time shaving off a few MBs.

(edit: removed suffix "from the download" from the last sentence.)

[anonymous1184]

Also Qt leaves garbage in Windows Registry HKCU\SOFTWARE\QtProject, see:

https://pastebin.com/qWSeWdDr