[HN Gopher] Electron vs. Qt for a new open-source project? Looki...
___________________________________________________________________
Electron vs. Qt for a new open-source project? Looking for advice
Author : x0054
Score : 29 points
Date : 2021-06-12 15:41 UTC (7 hours ago)
(HTM) web link (www.zynath.com)
(TXT) w3m dump (www.zynath.com)
| Nextgrid wrote:
| Regardless of the GUI framework I would suggest separating the
| business logic from the GUI.
|
| The business logic could run as a daemon in the background or a
| shared library and can be implemented in whatever language you're
| most proficient in for writing system services and that matches
| the performance requirements of the task, and the GUI can be
| written in whatever language you're most proficient with for GUIs
| (so you can _start_ with Electron and switch down the line if
| needed).
|
| I would've said Electron is a bad idea for this (for the reasons
| you mention in the post), but if the "business logic" is
| decoupled from it then Electron's task is to merely display
| information at which point it becomes more viable.
| mrtesthah wrote:
| Why bother shipping an entire separate browser? What would you
| actually gain vs bundling the daemon with a tiny launcher that
| just opened a new browser tab with "http://localhost:4855" or
| whatnot?
| johannes1234321 wrote:
| This adds another layer of potential security flaws. Other
| applications might try to connect to that daemon via network
| and exploit it. In turn you have to do all the security
| things in it, treating your frontend as potentially
| malicious. In an electron app you have secure communication
| channels. (Still have to be careful on data by the user, but
| all you get in the backend from the frontend is from your
| code)
| rapsey wrote:
| Also various local firewalls and anti virus software are
| going to block it by default.
| nitrogen wrote:
| I ran a bootstrapped non-IoT home automation startup from
| 2009 to ~2014. The hardware UI was presented as a web
| interface over the local network (backend was a mix of Ruby
| and C, some of which I have open sourced).
|
| Some customers had problems because they had malware browser
| toolbars installed that rewrote/altered the HTML.
| MattGaiser wrote:
| That is going to look strange and suspicious to anyone who is
| not a tech worker.
| fock wrote:
| why? The installer could clearly show a picture that this
| is how it works? People are not that stupid.
| jakelazaroff wrote:
| I would much rather use a tool that works similarly to
| most other tools on my computer, rather one that works
| totally differently but it's cool because the installer
| explains it.
| tacotacotaco wrote:
| "Users spend most of their time on other sites. This
| means that users prefer your site to work the same way as
| all the other sites they already know."
|
| https://lawsofux.com/jakobs-law/
|
| Jakob Nielson is a founding member of Nielson Norman
| Group that has studied UX for decades.
|
| https://www.nngroup.com/
| MattGaiser wrote:
| Except this is a file system, so to users it shouldn't be
| a site at all.
| tacotacotaco wrote:
| This applies to all interactions. E.g.
|
| "Users spend most of their time _opening_ other _door
| handles_. This means that users prefer your _door handle_
| to work the same way as all the other _door handles_ they
| already know."
| dragonwriter wrote:
| This is somewhat sensitive to application posture [0]
| (sites are, for this purpose, effectively apps, even if
| they aren't the kind of site that would be described that
| way usually.)
|
| A site that is effectively a _sovereign app_ has more
| freedom to defect from general interaction patterns,
| whereas one that is more of a _transient app_ has less.
|
| [0] https://en.m.wikipedia.org/wiki/Application_posture
| jitix wrote:
| It's not about stupidity. Infact it'll be the people who
| are proficient with computers but don't work in tech that
| will find this fishy and lose trust over the software.
| Installation and management UX is a core part of any
| software.
|
| It's the same as us programmers driving cars or using
| kitchen gadgets. If something is out of the ordinary or
| the UX is difficult, we'll think it's fishy and lose a
| bit of confidence.
| stu2b50 wrote:
| Some things will be pretty annoying to implement because
| pages in browsers are sandboxed and limited in how they're
| allowed to interact with the OS. You are also running that
| daemon so theoretically nothing is stopping you from doing
| those things by having the daemon do it.
|
| But it's pretty annoying that even things like a file path
| picker would need to be custom made and done via the daemon.
| egeozcan wrote:
| For one, you have a better control on the GUI (native file
| pickers, app actions, your own icon etc.). Don't get me
| wrong, I actually ship the tools I build also as little
| servers (example: https://github.com/egeozcan/json-tail) but
| there are also disadvantages to this.
| ravenstine wrote:
| The best compromise would be to open a web view. Though it's
| a concept often neglected, most languages have a package that
| does this.
| krapp wrote:
| What if it were possible to host Electron apps on a remote
| server? That way, instead of shipping a browser, the user
| could use their preferred browser to somehow load the app
| from the remote server, and run it on their local machine?
|
| The only major technical hurdle I can think of would be a way
| to locate and classify remote assets and resources, so one
| knows what belongs to what. We'd need to come up with an
| address system, something like a "universal resource locator"
| that could assign an app to a "domain" (think Java
| namespaces) that maps to one or more IP addresses. Instead of
| installing the app, you could just type the "domain" into the
| browser and access the application.
|
| It could be a revolution in the way Electron apps are
| distributed. Someone write this down!
| amelius wrote:
| > I would suggest separating the business logic from the GUI.
|
| If only there existed a GUI library which did that for us ...
| jjnoakes wrote:
| Which GUI libraries don't let you separate the two? I usually
| don't have a problem but maybe I'm missing something.
| mwcampbell wrote:
| I suggest Electron for accessibility (e.g. with screen readers)
| if nothing else. In my experience, Chromium's accessibility
| support is much more mature than Qt's, at least on Windows. See
| also this thread: https://news.ycombinator.com/item?id=27303503
| slightwinder wrote:
| > I generate a lot of files for various projects. Some of my
| projects are professional software and hardware development
| projects, or marketing and design projects, for ongoing or one-
| off customers. Others are personal video, welding, making,
| building, etc projects. Lot's of stuff to keep organized!
|
| Funny, I have the same problem, and use a similar solution for a
| long time now.
|
| > What we need is a cross platform, cross UI (GUI and CLI
| interface), and cross file system solution. It has to work on
| thumb drives with ExFAT filesystem.
|
| Why cross platform and cross filesystem? Why specifically ExFAT?
| Is this a personal Project or something Community-driven?
|
| > Bin Pointers - Pointers live in one part of the tree and point
| to a Bin in another part of the tree. Just like Aliases on MacOS,
| Shortcuts on Windows, or Soft Links on Linux, but cross platform
| and automatically self updating! If you move the target Bin, the
| Pointer will find where you moved it and update itself!
|
| Many Buzzzwords. Also, are Windows-Shortcuts and Symbolic Links
| really the same? AFAIK Shortcuts are on desktop-level, while
| Symbolic Links are on Filesystem-Level. And Windows&MacOS have
| links on Filesystem-Level too.
|
| > The base file organization unit in Bin Finder is a File Bin. A
| Bin is just a folder with a Bin Description File > Because a File
| Bin is just a special type of folder, it can contain any number
| of files and sub-folders inside of it, including other Bins and
| Pointers to other Bins! > If you need to tag or point to an
| individual file, it can be wrapped individually in a Bin. Since
| most human endeavors of any substance produce multiple files,
| this use case is relatively uncommon
|
| Looks kind complicated... What's the point of nested bins?
|
| My own solution is similar, but simpler. I use a central folder
| $HOME/HUB were I collect my sources (Local Drive, USB-Stick,
| NAS...). Each source has a subhierachy according to some personal
| reasons, with Content-Folders being on a fixed level. Each
| content-folder has #Tags in their name, and I use a simple script
| with rules to generate Hierachies of filesystem-links in my home-
| folder. I run the script occasionally when I change something,
| and thats it.
|
| I also have a handful scripts and build a little GUI for managing
| code-projects, but overall it a very stable and straighforward
| solution. I mostly use a filemanager for 10+ years now, and
| overall it works very well. Though, I use it on Linux, were such
| things are common and easy. Having certain fixed paths for
| certain is also preferable, so my solution must be working on
| it's own, without a gui.
|
| > When you click on a Pointer to the Project Bin you just moved,
| the system will first check where it has seen the bin last. If
| the system can't find the Bin in that location, it will quickly
| rescan all of your Trees. If the Bin is found in another
| location, the system will update the pointer and open the Bin
|
| This is pretty much the same as what Windows Shortcuts are doing.
|
| This overall reads like you reimplement Windows Shortcuts, but
| for Multi-sourcesand with a focus on Project-Workspaces-Handling?
| How would this work on CLI? You can't click them there?
|
| > I have most of the UI and workflows worked out in my head
| pretty well, but I find myself in a "paralysis by analysis"
| situation.
|
| So you have not used it yet? Then why not start using it? Start
| as simple as possible an experience the basic concept in your
| daily life. I know from my own system that things evolved over
| many years and adapted to certain demands from my own life and
| work. Organizing is very personal an i won't be always work as
| plannend.
|
| > GUI vs. CLI - I want to support both. But should it be a CLI
| first application that's then wrapped with GUI?
|
| What is the purpose of the GUI? How would you use it daily?
| What's the purpose of CLI, How do you aim to use that? Waht
| ability do you even have? Are you a coder and could implement
| something fast? Or would you start by zero and would invest a
| juge a mount of time for this?
|
| > Language / UI Library Selection - Here the choices appear to be
| Electron with JS vs. QT plus either Python, C++, or Go.
|
| I use Python and Qt. It's working well for this, as Python has a
| good focus on filesystem and cli-tooling, while PyQt allows fast
| growth into frontends. I would at least start with this for your
| first generation, till you have figured out what you really need.
| Start with cli, evolve into a lib, and build the GUI. Then you
| can still optimize with Go or Electron, depending on how it goes.
| Fergusonb wrote:
| Maybe look at tauri?
|
| You can write the cli in rust and the gui in html js css
|
| Binary will probably end up around 6MB
| x0054 wrote:
| Rust has been on my ToDo list. I played with it, but haven't
| written anything proper in it. This would be a really cool
| option, and I'll get to learn something new! So, basically I
| can use any HTML/JS framework I want for the UI?
| kyleee wrote:
| Cool project, what are some of the "cons" (if you or anyone
| else happen to know of any)? I've read through the website and
| github readme so I have a sense of the "pros"
| k__ wrote:
| I guess, that you have to write (some?) Rust.
| x0054 wrote:
| It appears that you don't really have to write any Rust
| unless you need to do some heavy lifting. In this case Rust
| would be grate for file tree scanning, the rest can be done
| in JS. I am having trouble finding any really grate
| examples of what has been built in Tauri. I kind of want to
| play with a fully featured app to see how it performs.
| SXX wrote:
| Advantage of using Electron is that you have easy to deploy web
| version as well as easy build / install / update process for
| Linux users (though less native).
|
| Qt is amazing due to much smaller memory footprint, but cross
| platform builds, packaging and CI still gonna take a lot more
| effort to maintain.
| lazypenguin wrote:
| The original post describes a desktop application to manage
| local files. Having a web version is not a design consideration
| here.
| x7777 wrote:
| This does not dismiss the rest of his argument. Cross-
| platform is still an issue even if you don't target the web.
| detaro wrote:
| Qt makes it also easy to build the app cross-platform, so
| no, it's not really an argument.
| SXX wrote:
| If your Qt app has single C++ line of code cross platform
| builds become much harder. Also regardless you still have
| to solve packaging and updates for Windows, macOS and
| Linux. Also it's much harder to do QA and it's take much
| more effort to maintain cross platform Qt app in general.
|
| For Electron apps it's all much easier because all native
| code is heavily tested by other commercial software and
| there is even on-the-fly updates possible.
|
| PS: I shipped C++ apps built using Qt and cross-platform
| part is huge time sink.
| Nicksil wrote:
| How often and to what extent did you build using Qt? Your
| arguments against using Qt don't align with its actual
| capabilities. Qt has an extensive API so perhaps you
| weren't aware Qt possesses such capabilities which would
| be understandable if your exposure to Qt was transient.
|
| >If your Qt app has single C++ line of code cross
| platform builds become much harder.
|
| As I mentioned, Qt has an extensive cross-platform API;
| indeed that API is Qt's value prop. If you've the need to
| write arch/platform-specific UI code, then it's very
| likely you'll find the solution to that problem somewhere
| within Qt's docs. If not, then you cannot expect to be
| able to write such code using Electron/JavaScript.
|
| >Also regardless you still have to solve packaging and
| updates for Windows, macOS and Linux.
|
| What's to solve? Qt has had these capabilities. If you
| describe a specific issue, you may have an argument,
| otherwise this statement makes no claim.
|
| >Also it's much harder to do QA and it's take much more
| effort to maintain cross platform Qt app in general.
|
| How so? This is such a broad and unspecific claim to the
| extent it isn't possible to form a counter argument.
| State specifically the issues making it much harder to
| complete these tasks using Qt.
|
| >For Electron apps it's all much easier because all
| native code is heavily tested by other commercial
| software
|
| Qt's testing suite is extensive. Qt is and has been
| deployed and "heavily tested" around the world for years.
| Qt is also deployed as an embedded technology.
|
| >PS: I shipped C++ apps built using Qt and cross-platform
| part is huge time sink.
|
| I'm not sure you spent much time doing this because Qt
| makes shipping cross-platform software so simple it
| sometimes feels like I'm cheating (there are exceptions
| when dealing with very specific platform/arch-specific
| items as I mentioned above; there is no solution in
| JavaScript.). There must be some specific issue(s) you
| came across, but without specifying what specifically
| made you perceive using Qt a huge time sink, the
| statement makes no claim.
| makomk wrote:
| Also, I suspect the main cross-platform portability
| issues you're likely to run into with an app like that
| are differences in filesystem behaviour, and developing
| it as web app doesn't really help there.
| x7777 wrote:
| That's a good point - still you'd be sacrificing product
| development speed for the low level fs access, so the
| author should really make sure they know how much of it
| they'll need.
| x0054 wrote:
| Given that BinFinder only needs the ability to read/write
| files and scan directories, it should be relatively cross
| platform out of the box. No real platform specific
| features, such as soft links, tags, etc necessary. On
| MacOS the app will likely need to ask for permission to
| access the disk, that's the only cross platform file
| system issue I see at the moment.
| paulryanrogers wrote:
| It depends on how dynamic the UI will be.
| x0054 wrote:
| I was hoping to design something where on the left side
| there would be a tree of all the Bins (folders) and user
| would be able to click check boxes next to the folders
| they care about and the UI would instantly update with a
| list of matching Bins on the right side of the UI. Data
| would be pulled from cache stored in SQLite DB.
|
| Can you see any issues with this on either Electron or
| QT? At first glance it feels like both should ok.
| SXX wrote:
| Desktop applications that manages local files can still use
| web UI. There is plenty of reasons why it's can be nice to be
| able to access it through web.
| ivanmontillam wrote:
| I invite you to try Sciter[0], it allows you to write your
| frontend in HTML, CSS and JS, but the backend of the app can be
| anything native you want (C++, C#, Python perhaps). The events in
| the HTML DOM interface with methods in the native code, so your
| button actually runs the fastest, because the business logic of
| the app is native.
|
| Some of the most performant products use it, like antivirus
| products. Yet, you see antivirus products have a nice GUI and
| that's the reason. You can see it in the showcase.
|
| I know Sciter is not mainstream, but you don't have to deal with
| Qt's API nor with making your business logic in Javascript with
| Electron and shipping the greatest overhead that an embedded
| browser implies.
|
| To me, it's the best of both worlds. Flexible do-as-you-see-fit
| GUI and native performance because of compiled languages.
|
| [0]: https://sciter.com
| adamnemecek wrote:
| I have been recently rolling my own Rust GUI framework using this
| rendering crate I'm invovled with
| https://github.com/femtovg/femtovg and I'm pretty happy with it.
|
| I recently added a wgpu backend
| https://github.com/adamnemecek/femtovg.
|
| Combine that with the Flutter layout (check out the Druid
| implementation), and you have a GUI framework.
|
| Join the discord https://discord.gg/V69VdVu
| anaisbetts wrote:
| Just write it in the framework you're most familiar and most
| likely to get something working in. You can always rewrite it
| later.
| SavantIdiot wrote:
| I've built with Qt and Electron combined for over a dedcade.
|
| Electron has entire libraries that are portable cross-OS. It is
| literally write once, deploy on Ubuntu, Mac, Win10. I've never
| had an issue, even using serial ports and USB interfaces. Qt is
| just a GUI, you will still need to write native hardware
| interface code. As a bonus, with Electron you also get ALL of the
| modern frameworks and templates. If you choose Qt you will always
| feel "behind".
|
| EDIT: Based on this thread I need to re-examine Qt. They now have
| cross-platform USB endpoint classes that are of interest. But I'm
| not giving up my frameworks.
| Nicksil wrote:
| >But I'm not giving up my frameworks.
|
| Why would you dig your heels in if you've found a superior
| alternative fulfilling all your requirements?
| SavantIdiot wrote:
| Because I'm a rational human being. If something comes along
| that is better, I'll jump ship. If Qt native meets my USB
| needs I'll move to the next barrier: frameworks. If Qt solves
| that hurdle, why stay with Electron?
|
| I was being funny but you took it seriously.
| Nicksil wrote:
| I understood your statement as saying you are not giving up
| Electron if you found Qt fulfills your requirements (USB).
| That's was I was questioning: Why continue to use Electron
| if Qt does all the things you need to do.
|
| Perhaps I misunderstood; text isn't the best medium to
| convey tone.
| laurent123456 wrote:
| In Qt, isn't it just a matter of finding a cross-platform C++
| lib for whatever hardware support you need? Just like you'd
| look for an npm package for Electron?
| [deleted]
| slobotron wrote:
| Last time I used Qt, it had classes to abstract hardware.
|
| Stuff like QSerialPort worked fine across platforms for my
| usage. YMMV
| dmytroi wrote:
| Web and Electron could be good if you're willing to deal with
| Chromium Embedded Framework (CEF) directly, like Spotify desktop
| client does, it's fairly snappy and feels good. That would mean
| that UI is web based, but everything else is native, and there is
| FFI of sorts in between. Though it probably only makes sense for
| a company of >1000 people as at that scale issues like being able
| to hire specialists become more prominent (pool of web devs is
| simply larger than pool of Qt devs).
|
| Qt is amazing, though only downside is near absence of ready-made
| 3rdparty widgets. Which limits the development speed quite a bit,
| while in other technologies you have an option to throw $$$ at
| the problem at get a widget of ok quality to solve your problem,
| there is very little of that available for Qt. So before
| venturing there I would recommend checking if built-in are
| covering everything you need, otherwise be prepared for a long
| road of making native-feeling widget that works with all
| platforms UI guidelines.
|
| I would give .NET ecosystem a try, they cover both developer
| velocity (coding in Rider is amazing) and 3rdparty widgets
| (plenty available), albeit it's not _that_ crossplatform just
| yet, .NET MAUI is only getting ready for .NET 6, so there be
| dragons :)
| x0054 wrote:
| I was considering experimenting with .NET, but wasn't sure how
| good GUI support is on MacOS and Linux. It's worth a look as
| well. Thanks!
| x7777 wrote:
| If you want to prototype quickly and reuse a component
| libraries/be able to attract contributors go with Electron. if
| you need to run your app on low-power devices consider QT but it
| will require a lot more investment from your end.
| jakelazaroff wrote:
| Broadly speaking, I would not make this decision based on the
| technical merits of either option. Instead, choose based on your
| high level goals for this project.
|
| Is the point to build and support this project for the medium to
| long term? Choose the one with which you're more familiar, or for
| which there is more available help and resources.
|
| As a sub-consideration, do you expect others to work on this
| project with you? Choose the one with which contributors are more
| likely to be familiar.
|
| Is the point to learn a new UI framework? Choose the one in which
| you're most interested.
|
| Is the point to burnish your resume? Choose the one that is more
| in demand by the opportunities you're seeking.
|
| That's assuming that both technologies can meet your requirements
| (e.g. if you might want to use this on resource-constrained
| devices, choose Qt; if you want a web version, choose Electron).
| But all else being equal, you need to figure out your goals
| before you can make this decision.
| CarVac wrote:
| Qt QML is really great for making GUIs.
| blueprint wrote:
| https://proton-native.js.org ?
| legutierr wrote:
| I wonder, how does this compare to Microsoft's React Native for
| desktop?
|
| https://microsoft.github.io/react-native-windows/
| DecoPerson wrote:
| > 1. GUI vs. CLI - I want to support both. But should it be a CLI
| first application that's then wrapped with GUI? Or perhaps it's
| better to build it as a GUI first application, and add a CLI
| interface to it? Or just have a core library, and use it in
| independent CLI and GUI tools? I never wrote a cross-platform
| tool, so I am not sure what's the best approach.
|
| Don't be GUI-first or CLI-first; be API-first. You can get
| started by writing a test target. As soon as you need more than
| "edit tests, recompile, run, examine debug prints", you can start
| on both the GUI and the CLI together.
|
| Focusing on keeping a solid API makes things much simpler. And if
| you ever regret choosing Electron over Qt or vice-versa, having
| all the juicy parts behind an API makes it much easier to switch.
|
| For examples, look at Git, the TypeScript compiler, and
| Everything [0] (closed source unfortunately).
|
| There was a quick-search app for macOS that used V8-to-Rust
| asynchronous procedure calls as the API. It would make a great
| example, but I can't remember it's name.
|
| (Love the app idea btw! I look forward to trying it on my mess of
| files for my small business.)
|
| [0] https://www.voidtools.com/support/everything/sdk/
| goostavos wrote:
| >But should it be a CLI first application that's then wrapped
| with GUI?
|
| If you build it as a CLI, you can get the GUI for free via
| Gooey[0] (shameless plug)!
|
| [0] https://github.com/chriskiehl/Gooey
| Nicksil wrote:
| >If you build it as a CLI, you can get the GUI for free via
| Gooey
|
| But then you've just added a dependency and, unless you
| vendor that thing, or don't update it in the future, you've
| no way to ensure it doesn't screw up your application at some
| point down the road.
|
| Design the API, write the code, then have your front end(s)
| (cli, GUI, etc) call into it. Best of all worlds, no
| additional dependency.
| allanrbo wrote:
| Did you consider wxWidgets? I chose it over Qt and Electron for a
| recent project, because it gave me the most native looking UI
| across Mac/Win/Linux, and resulted in a small binary size and
| memory footprint. The project was an SSH file browser. Sounds
| like your project is also file browser related, so you may be
| able to get some inspiration or even reuse parts:
| https://github.com/allanrbo/filesremote
| x0054 wrote:
| I am researching wxWidgets at the moment. I really like the
| small file size on the FilesRemote and how quickly it starts
| up. Those are a big plus for me. I am not too concerned about
| the native look and feel because of the type of app I am
| making, but the speed is a huge plus.
| schaefer wrote:
| Is there a reason that flutter2 is not considered? With version 2
| comes a push for first class desktop support.
|
| Admittedly, I don't currently know of any books that have been
| revised to cover version 2, but there is momentum on the desktop.
| For example, it will be the default framework on Ubuntu moving
| forward [1].
|
| [1]: https://ubuntu.com/blog/flutter-and-ubuntu-so-far
| x0054 wrote:
| Wow, I haven't heard about the Ubuntu taking up Flutter. I
| wrote several commercial Flutter Mobile apps before, so this
| should be an easy transition for me. However, how mature is the
| desktop support in Flutter. I read that it's still in very
| early beta on Windows. Linux support and MacOS appears to be
| solid. I think this is worth a look for sure. One of my goals
| was to learn something new, but learning something new about
| something I already know is great too! :) Thanks for the
| pointer!
| justinclift wrote:
| Flutter is still single threaded isn't it?
| the__alchemist wrote:
| Qt, absolutely. Great API and docs, and much more performant.
| webmobdev wrote:
| - GUI vs. CLI
|
| Build command line tools first. Stick to the Unix philosophy of
| _" Small is beautiful - do one thing and do it well"_ with each
| command program. Then build a GUI app for whatever platform you
| want to support.
|
| Why CLI first? Command line tools can be used independently in
| scripts to automate various tasks (often repetitive tasks). This
| also further decouples programming logic so that you can work
| separately on the CLI code and the GUI code. (Here's some good
| tips on how to create a GUI for a command line tool -
| https://softwareengineering.stackexchange.com/a/204316 ).
|
| (Also keep in mind another Unix philosophy - _" Reuse. Don't
| reinvent / rebuild"_. The GNU Coreutils command line programs
| that is available for multiple platforms can be a real asset for
| your project - https://opensource.com/article/18/4/gnu-core-
| utilities . SQLite is another software that can really make your
| project simpler). - Language / UI Library
| Selection
|
| For creating the command line tools, I'd recommend whatever
| language you are comfortable with, but I'd opt for something that
| can create a standalone executable.
|
| For creating the GUI, consider the free and lesser known gem
| _Lazarus_ https://www.lazarus-ide.org/ - it can help you create
| _native GUI_ for many platforms from one code-base (with some
| tweaks for each platform). A native GUI makes your application
| small, fast, and familiar to your users. The catch - you will
| have to learn Pascal to use it - if you are familiar with it,
| here 's a good tutorial
| http://www.delphibasics.co.uk/Article.asp?Name=FirstPgm to help
| you get started. (Note: Lazarus is an open source fork of Delphi
| - https://www.embarcadero.com/products/delphi ).
|
| Lazarus is better than QT because it uses the operating systems
| native GUI toolkit. You also don't have to worry about licensing
| issues with Lazarus and can even create commercial closed source
| applications with it for free.
|
| Lazarus is better than Electron because Electron bundles another
| layer over the OS (the chromium browser framework) to render the
| UI. That's a lot of additional software just for a GUI, and will
| make your software big (50+ MB) and slower (chromium is a
| resource hog).
|
| (But ... if time is a constraint or you don't have the
| inclination to learn yet another programming language, then go
| with what you are most familiar. If it is C++ choose QT. If it is
| HTML + CSS + JS, choose Electron.) - Use Cases
|
| I'd like it to be platform and filesystem agnostic - easily
| portable to another OS. Have fast indexing and search. Extensive
| tagging. (Using a database, like SQLite, can really help with all
| this).
| shaicoleman wrote:
| If Electron is too heavy, there are lightweight alternatives such
| as Tauri [1] and Neutralinojs [2]
|
| 1. https://tauri.studio/en/
|
| 2. https://neutralino.js.org/
| x0054 wrote:
| Thanks! Will research them now.
| paulryanrogers wrote:
| My choice was Qt. In hindsight Electron probably would have been
| good enough. It also could have helped me launch sooner, iterate
| more easily, all at the cost of user memory.
|
| Then again mine is only a source included product, not a
| community effort.
___________________________________________________________________
(page generated 2021-06-12 23:02 UTC)