I have been thinking about creating a desktop app for a while now. Problem is I can't decide which framework to use. Ideally I would like to use Common Lisp, but McCLIM looks like it's from the eighties, there's also qtools and CommonQT that make it possible to use Qt in Common Lisp, but somehow I'm afraid to develop myself into corner with these tools. Could also use clojure and "seesaw", but again -- it's like I'm handicapping myself here. I could use Racket and it's GUI library, but Racket is marketed as a language for creating languages, so I'll skip that. I guess I still need to use Java 8 with JavaFX. I wish there was a lisp dialect just for developing desktop applications.
Yeah, it's a real shame. From what I see the best Common Lisp compilers and libraries are proprietary and seem to be stuck a in 90's vendor (think Borland) mindset.
I'll mention an earlier comment of mine: https://news.ycombinator.com/item?id=18045890 (a Scheme interpreter running in C++ land, to communicate with via s-expressions (really Scheme code) from 'real' Scheme or Lisp systems. Extending its parser to support Clojure and CL is on my mind, extending the interpreter to run programs written in those languages (e.g. '(defun square (x) (* x x)) instead of '(define (square x) (* x x))) is of course also a possibility if deemed useful enough.)
My work was interrupted because my employer decided to scrap the project this was planned for. I've got permission to release it as open source, which I'll do ASAP (I'm in the middle of cleaning it up a bit). Incidentally my position was made redundant at the same time, so I'm currently looking for new work, most likely I won't have too much time to work on that in the near future, but I'll try to continue working it on the side and will be happy to help where I can. Send me mail to [email protected] if you'd like to be notified once it's up.
> I could use Racket and it's GUI library, but Racket is marketed as a language for creating languages, so I'll skip that.
Why? Racket is very far from only being a language research platform, it's also a very good general purpose programming languages, and its GUI framework is quite easy to use. I would give it a try if I were you :).
Another option would be GTK. It is quite portable and while I haven't checked out the GTK libraries for Common Lisp, but as GTK is a pure C-based API, binding to it from other languages is very easy, so good bindings should be available. Personally, I have been using GTK3 via Go on Linux/Mac.
And for Common Lisp, there is of course LTk, it is extremely portable, but you have to live with the Tk UI toolkit (which got a pretty native look in the meantime).
Why not use Java 9 instead of 8? This could give your desktop app a smaller footprint (using the new modular jdk feature), so your app could start up faster.
If you're using Java anyways, why not clojure? I've written both clojure an common lisp, and even though the immutable datastructures take some getting used to if you're from CL or Java, they're awesome, fast and make programming so much more fun.
Hm I'm in the exact situation and I'm total beginner on desktop apps. I've been looking into Flutter for desktop but it isn't stable yet. If you ever come to a conclusion would you mind to share it? Thanks.
I still remember the amount of pain I went with trying to use Qt5 on python, the compile errors, the compile times, the differences between what QtDesigner showed and the actual output, made me appreciate CSS and SASS a lot more.
Same here. I designed and built the first version of Aether with Qt5 via Python. It was a miserable experience where the only way to solve certain things were to insert non-meaningful text into certain magic Python fields which would go and compile in C++. Plus a few hundred iterations of getting the magic incantations to work in a consistent manner.
For the second version — I've moved to Electron for UI and Go binaries for actual heavy lifting. At least that one is a known pain you can Google for.
When I used Qt4 years ago, I ran into a lot of issues regarding segfaults and generally issues with the underlying C++ objects. Admittedly this was largely my fault, but I did find that I had to worry about the underlying implementation a lot and not think idomatically in Python as much.
For folks who are new to Qt5 and are wondering how an app looks in production, we have a screenshot at https://www.sostronk.com/app
We released SoStronk's desktop app using Qt5 in 2014 and its going great today as well. Having had ~5 years development experience with this, I'll be happy to answer any questions :)
That looks great, but very different to what I've seen from playing around a bit with Qt.
Are you using some open source theme or components there, or is it very custom built? I felt that Qt Quick Controls 2 felt far too mobile focused when I tried it out, and looked/felt very out of place in a desktop application, but I guess if you're customizing it heavily then that's less of an issue.
I notice you're only providing a Windows download despite Qt being cross platform. Are there any blockers or issues in building the same app for Mac/Linux, or is that just not something you've looked at. I guess the latter since it's for a game, but just interested since I've seen a lot of comments in the past about difficulties making Qt apps run consistently across different platforms.
Are you using QML and JavaScript for all of the application code, or just using that for the UI and handling the main logic from C++ or other language bindings?
Any thoughts on the Qt/QML approach compared to Electron?
QML is fantastic. I use it for a commercial application of mine. Main difficulty is finding someone to implement designs but I can do that myself if push comes to shove as I don't need to do a full redesign every 6 months.
I know nothing about Qt beyond the most basic description but I’m interested in exploring it as an alternative to Electron. I see lots of debate in the comments here but limited context to help me understand what is being debated. Is this book for me? What background should I, a total beginner, be aware of before I dive in?
Qt is a very comprehensive system for apps developed mostly in C++. QML which is like a declarative Javascript, can be used to do quite a lot, but you'll almost certainly need to do some C++ customization in addition to the initial basic 'main app' process which requires C++ as well.
Many of their customers use it for display/kiosk things (think 'in car display') so it has a lot of hyper-specific attributes which can make it seem a little difficult.
The build process is ultimately C++ based (ie make, with their own layer called 'qmake') and so you're going to have to be familiar with that.
In our experience it's quite slow moving compared to JS/CSS/HTML obviously, and performance gains are very situationally dependant.
Qt is nice but takes some effort to make it do what you want it to do, just like any other c++ project. Once you get the hang of it though it can do just about anything, on any platform. At my previous job we had deployed a single code base QML ui interface across mac/windows/linux/android/ios. The mere fact you can do that and have it not look like junk everywhere is pretty cool.
Despite the focus on QML, the Widgets are very easy to work with -- mature, well thought out, cross-platform. I highly recommend PyQt for desktop application development.
I don't know Qt, but I have a cursory understanding of the DOM, to the point that I can make fully featured "SPA" applications from scratch. Most of my background has been in systems programming. Would learning QT enable me to make applications faster? I have only been exposed to UI programming and through React via Clojurescript and ReasonML and Angular 6/AngularJS
I really like QML but the licensing is kinda tough for hobbyists if you wanna do stuff outside of their opensource license. They used to have a cheaper license
Indeed. I was bemused by the first sentence in the section explaining the architecture of Qt:
> Qt Quick is the umbrella term for the user interface technology used in Qt 5.
It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.
QWidgets are not under active development, and the future is QML. QWidgets will likely only receive maintenance fixes going forward. Time to join the future!
[+] [-] jyriand|7 years ago|reply
[+] [-] oblio|7 years ago|reply
They're probably serving their existing customers well, since they're still around, but I doubt they're getting many new customers (or mass adoption) with these prices: http://www.lispworks.com/buy/prices-2c.html, https://franz.com/products/packages/.
[+] [-] pflanze|7 years ago|reply
My work was interrupted because my employer decided to scrap the project this was planned for. I've got permission to release it as open source, which I'll do ASAP (I'm in the middle of cleaning it up a bit). Incidentally my position was made redundant at the same time, so I'm currently looking for new work, most likely I won't have too much time to work on that in the near future, but I'll try to continue working it on the side and will be happy to help where I can. Send me mail to [email protected] if you'd like to be notified once it's up.
[+] [-] p4bl0|7 years ago|reply
Why? Racket is very far from only being a language research platform, it's also a very good general purpose programming languages, and its GUI framework is quite easy to use. I would give it a try if I were you :).
[+] [-] _ph_|7 years ago|reply
And for Common Lisp, there is of course LTk, it is extremely portable, but you have to live with the Tk UI toolkit (which got a pretty native look in the meantime).
[+] [-] misja|7 years ago|reply
[+] [-] j-pb|7 years ago|reply
[+] [-] MarvelousWololo|7 years ago|reply
[+] [-] kbp|7 years ago|reply
[+] [-] rsp1984|7 years ago|reply
[+] [-] iamcreasy|7 years ago|reply
[+] [-] mattigames|7 years ago|reply
[+] [-] rolleiflex|7 years ago|reply
For the second version — I've moved to Electron for UI and Go binaries for actual heavy lifting. At least that one is a known pain you can Google for.
[+] [-] jancsika|7 years ago|reply
I'd like to read some examples of that.
[+] [-] dman|7 years ago|reply
[+] [-] amelius|7 years ago|reply
[+] [-] pknopf|7 years ago|reply
I also went to mention that you can now use .NET/C# with QML as well.
https://github.com/qmlnet/qmlnet
PS: I'm the author.
[+] [-] Waterluvian|7 years ago|reply
When I used Qt4 years ago, I ran into a lot of issues regarding segfaults and generally issues with the underlying C++ objects. Admittedly this was largely my fault, but I did find that I had to worry about the underlying implementation a lot and not think idomatically in Python as much.
Have things improved?
[+] [-] shaan7|7 years ago|reply
We released SoStronk's desktop app using Qt5 in 2014 and its going great today as well. Having had ~5 years development experience with this, I'll be happy to answer any questions :)
[+] [-] wjoe|7 years ago|reply
Are you using some open source theme or components there, or is it very custom built? I felt that Qt Quick Controls 2 felt far too mobile focused when I tried it out, and looked/felt very out of place in a desktop application, but I guess if you're customizing it heavily then that's less of an issue.
I notice you're only providing a Windows download despite Qt being cross platform. Are there any blockers or issues in building the same app for Mac/Linux, or is that just not something you've looked at. I guess the latter since it's for a game, but just interested since I've seen a lot of comments in the past about difficulties making Qt apps run consistently across different platforms.
Are you using QML and JavaScript for all of the application code, or just using that for the UI and handling the main logic from C++ or other language bindings?
Any thoughts on the Qt/QML approach compared to Electron?
[+] [-] justinclift|7 years ago|reply
https://showroom.qt.io
Seems to be based on user submissions.
[+] [-] shaan7|7 years ago|reply
[+] [-] lnsru|7 years ago|reply
[+] [-] omegote|7 years ago|reply
[+] [-] cheez|7 years ago|reply
[+] [-] sickcodebruh|7 years ago|reply
[+] [-] sonnyblarney|7 years ago|reply
Many of their customers use it for display/kiosk things (think 'in car display') so it has a lot of hyper-specific attributes which can make it seem a little difficult.
The build process is ultimately C++ based (ie make, with their own layer called 'qmake') and so you're going to have to be familiar with that.
In our experience it's quite slow moving compared to JS/CSS/HTML obviously, and performance gains are very situationally dependant.
[+] [-] psyclobe|7 years ago|reply
[+] [-] sevensor|7 years ago|reply
[+] [-] dang|7 years ago|reply
[+] [-] bgorman|7 years ago|reply
[+] [-] rms25|7 years ago|reply
[+] [-] TheCabin|7 years ago|reply
[+] [-] iBelieve|7 years ago|reply
[+] [-] ognarb|7 years ago|reply
[+] [-] ausjke|7 years ago|reply
[+] [-] sjvpv|7 years ago|reply
[+] [-] quietbritishjim|7 years ago|reply
> Qt Quick is the umbrella term for the user interface technology used in Qt 5.
It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.
[+] [-] toyg|7 years ago|reply
[+] [-] DiseasedBadger|7 years ago|reply
I'm sure it's a nice book, though.
[+] [-] hellofunk|7 years ago|reply
[+] [-] glenrivard|7 years ago|reply
[deleted]