Hacker News new | past | comments | ask | show | jobs | submit login
LXQt 1.0.0 (github.com/lxqt)
193 points by jlpcsl 82 days ago | hide | past | favorite | 95 comments



LXQt is kind of in no man's land for me. If I want a very basic floating/stacking WM, I'll use Openbox (which is the WM they use anyway, just with extra stuff). If I want a Qt DE that is light on resources, Plasma is surprisingly good now (~400-450MB RAM on idle for me). Otherwise, something like a tiling WM will likely always be lighter.

I do appreciate some of their bundled tools though. PCManFM is a great little file manager, and Featherpad is a much nicer notepad type basic text editor than say KWrite.


The niche LXQt fills for me is a light desktop environment that looks and feels "normal". For example, I just (like ten minutes ago) put Debian LXQt on an older Thinkpad for my kids to use, because it exposes things nicely and still is light enough to not be frustrating. It will also keep my wife from yelling at me if she has to help them with something when I'm not around. It's a good balance of light and usable.


Does KDE not do the same for you? It was pretty strange back in the Plasma 4 days, but since Plasma 5 it's felt extremely "normal" and unsurprising, like Windows 7. I'm not a regular user so it's just my surface impression.


It's improved its heavyweight nature, but it's still a lot heavier than LXQt is. I use it on my main machine and love it.


I think a ton of people got disillusioned with KDE when they first introduced Plasma and got obsessed with tablets. Remember the awful kidney bean?

That was certainly the last time I used it. I just took another look and it seems like they have improved it a lot. But... I dunno, maybe they had their Digg moment.

This looks exactly like I would like a simple "modern Windows 95" UI to work, which I think is really what most people want.


I can accept that, thanks for sharing! I agree, things like XFCE and MATE need quite a bit of mucking around to actually look "normal".

I also quite like IceWM on Antix for this kind of experience.


I think XFCE is one of the most "normal" desktop you can get, but I suppose that depends on that is considered normal nowadays. It has a bar with a menu, a list of open windows, and notification/status section. It has a desktop where you can place folders, files and shortcuts. It's context menus make sense.

It's not perfect but with a few simple tweaks (most of which are scriptable via xfconf-query) they can be fixed. Instead of trying to maintain a desktop across my machines, or over rebuilds, I just run my script and I'm done.

The biggest gripe I have with it is the file choose/save dialog. It's default focus isn't the filename field (like WTF). Let's say you're going to save a file. When the dialog opens and you start to type, it starts to filter files in the current directory. It's totally f*ucking stupid, extremely annoying after the second time you encounter it, and not easy to change in the settings. You need to get under the hood.


> XFCE and MATE need quite a bit of mucking around to actually look "normal"

That's an odd statement. Sure XFCE may not be as polished or consistent, but most distros will ship a pretty consistent desktop.

Mate on the other hand received plenty of UX work from Red Hat and Canonical back when it was still Gnome 2 and you still have all the themes and styles from that era, to me it doesn't get more 'normal' than that. (OK, they changed the accent color to green and there is apparently no easy way to change that, but I'd say that's the only step back in that regard.)


I am 100% convinced that GNOME 2 was one of the greatest UIs of all time. Its UX was incredibly simple yet beautiful, and GNOME 3 and 4 instead feel gimmicky and disconnected from reality when compared to it. Mate really deserves more love nowadays.


My theory is that GNOME (basically RedHat) were concerned about software patents. I cannot think of any other reason why they would make it so different to the mainstream and thus less intuitive for most. IMHO it is not an improvement. Luckily Ubuntu have made it slightly more normal.


Around the time of GNOME 3, everybody was doing big changes to their desktop experience. There must have been something in the air that said let's screw up desktops. This was when Windows 8 was putting tiles everywhere (but you know, not actually everywhere) and OS X was ruining things in a more subtle way I can't remember.


Everyone involved has talked extensively over the years about what they think about the desktop UI experience there is no need to add complexity.


I guess by normal I just mean what my family members might be used to coming from Windows. XFCE is much better in that regard but the GNOME2 workflow that MATE seems to stick to is not quite easy to pick up from them, so it involves either configuring panels myself or getting a hold of the MATE Tweak tool to change the layout to Redmond or whatever.


I agree on IceWM; it was not hard to make it give that feeling of, "Oh, so it's just a normal computer, then." JWM was another of the super-light window managers that could do that pretty well with the right setup.


Have you looked at Ubuntu-Mate? Its 21.10 release has the makings of the best one in years. I'll concede that it has taken a bit of time for development to start coming together but now there seems to be a momentum and I've yet to see a version of the desktop that looks better. I wish more people would look at this version of Mate, with its best foot forward rather than some of these basic ones with absolutely no polish applied.


I've been using Ubuntu Mate since the day it came out and I am on 21.10. But I can't put my finger on anything that points to increased development momentum. Could you point me to what I'm missing?


Yes, I want something that looks and feels like Qt (I simply like the design language) with the Qt app ecosystem, but which sheds a metric ton of stuff compared to KDE that only serves to make me endlessly tinker with it.


Last time I tried Openbox I found configuration horrible (XML, really?) compared to 'traditional' WMs like fvwm, mwm, cwm e.t.c. If LXQt automates things like application lists then I guess that would permit a more usable experience. Plasma is not a thing on some non-Linux OSes atm so LXQt would be a decent alternative for those.


https://github.com/lxqt/lxqt/pull/2095

I got struck hard by this. I was very, very confused when I followed this link, looked at the repo, and saw commits from five years ago.


This kind of thing has unfortunately been rather common in the bigger corp environments where I've worked...

Inevitably someone finds out about submodules, falls in love, and suggests a megarepo like this. Then, forgetting about them - and never updating.


LXQt seems like a marriage of great concepts, but I had difficulty finding end-user help last time I tried it. What sites would you go to? Where's the community at?

Unrelated, but I wonder if anyone else feels this. All DEs seem broken/unfinished when the available settings aren't as comprehensive as in Windows or KDE. On Gnome you need gnome-tweak-tool. Without that it just isn't possible to do what feels like very common tasks, which puzzles me. What kind of "playtesting" does the LXQt developers do, how do they get their feedback from users?


> All DEs seem broken/unfinished when the available settings aren't as comprehensive as in Windows or KDE.

"...as comprehensive as in Windows up to Windows 7 (in Classic mode) or KDE."

There, FTFY.


From the README.md for the repo:

LXQt is the next generation of LXDE, the Lightweight Desktop Environment. It is the product of the merge between Razor-qt and LXDE-Qt.

I was wondering what the relationship between LXQt and LXDE was. Is it just the LXQt project who is claiming this is the next generation, or is that the prevailing consensus among both projects?


Basically LXDE got rebranded into LXQt, though since DEs and WMs don't get obsolete fast, LXDE will continue to work for a long time. You can still pick LXDE in Debian if you prefer Gtk 2 for some reason.


It’s a bit more than a rebranding, being completely rebased on a different framework, and LXDE still gets some work, for example, LXTerminal has commits from September. [0]

[0] https://github.com/lxde/lxterminal


Debian LXDE and Fedora LXDE Spin are performant, light distros that are easy to configure.


The thing is that Qt and Gtk3 and onward all consume more resources than Gtk2


I really cannot bring myself to use LXQt, even as someone who really likes the QT framework. KDE runs surprisingly fine, even on 13 year-old hardware, so it's hard to justify using such a stripped-back DE when there are better alternatives just around the corner. MATE and XFCE will do 99% of the things you want them to do but faster and more stable. I still have hopes that LXQt hits a degree of usability, though. I've been surprised before with desktops like Budgie.


I have similar feelings to everything you just said.

I assume the appeal to LXQt isn't so much that it's "lightweight" as that it's "simple". Because, like you said, Plasma is actually very lightweight and snappy, and I'd be willing to bet there are very few places where LXQt will run well and Plasma won't.


>Plasma is actually very lightweight and snappy

Not in my experience, though I have pretty high/less realistic standards coming from i3.

It's plenty usable on modern hardware (anything midrange+ from the past 10 years or so), but it is worth noting that I've still run across folks running core 2 duos in recent times. (Although fwiw they were running plasma, just complaining about it not being very responsive)


KDE can be configured to run with pretty minimal overhead, but it takes quite a bit of knowledge about how the DE works. After disabling the fancy compositor effects though, I think I'm comfortable saying that it's more responsive than my i3wm setup on a 13-year-old x201. Not a knock against i3, as it's a much better tiling WM than KDE ever will be, but I really think the resource requirements aren't the far off from one another.


That and i3 is probably doing more work via the CPU and is more than likely doing it in a blocking-single-threaded way.


I'm running Plasma on a low-range laptop from 2010 and it runs exactly as smoothly as it does on modern hardware. It was $600 in 2010, has 4 GB RAM and one of the earliest generations of the Core i3, with integrated graphics.

If your acquaintances have machines that struggle to run Plasma, I'm honestly surprised they can run graphical apps written in recent GTK or Qt versions at all.

In many cases, Plasma's going to run better/smoother than these "lightweight" window managers and desktops. Because, all the Stockholm Syndrome-ing about "simplicity" often translates to "probably is single threaded and does more CPU work than it should because it's easier." In my experience, they'll tend to have worse vsync issues and tearing.

I doubt i3 is actually drawing shit on the screen faster than Plasma with animations off.


>[..]In my experience, they'll tend to have worse vsync issues and tearing.

Thankfully I've been able to avoid that for the most part, but I will say it's certainly easier to avoid with plasma's compositor.

>I doubt i3 is actually drawing shit on the screen faster than Plasma with animations off.

I'd definitely be interested in a raw speed comparison if there was a good method/benchmark, but I don't think that has ever been my limitation (although if I were running on lower spec hardware everything counts)

Plasma certainly has more features, but it's still definitely heavier than i3 (or most (all?) tilingWMs), LXQt, icewm, and the like.

On decent hardware there's not a huge point other than preference, but when you've got 2GB of RAM and a 12 year old CPU every bit helps https://i.imgur.com/vZszQFE.png


In the case of a simple window manager like i3 I cannot imagine what it would need to do in a second thread and without a compositor it would definitely be drawing faster if not perceptively faster. I don't think one would be apt to notice any difference in performance save for plasmas still slow startup.

I could I suppose point a camera or a phone at the screen and measure I suppose.


What I'm most interested in is the latency (I guess that's more or less the same as "snappy"). Back when I had a netbook LXDE was one of the few that felt good.


There's certainly some added latency in GPU composited desktops so a lot of the time that has an effect with modern desktop environments and/or wayland vs LXDE which as far as I know doesn't run a compositor.

I'd love to find some good testing on it somewhere, but I do recall off the top of my head that Windows XP or Windows Vista/7 (with Areo disabled) had significantly lower latency than the GPU accelerated counterparts in Vista+. I believe it has to do a lot with Vsync, but imagine there's some additional overhead involved as well.

Of course many would say removing screen tearing is a valid tradeoff there, I mostly agree but not everything is significantly effected by tearing either.


What's LXQt's Wayland story?


Tangent...

There seem to be a fair few smaller (in community) DE projects (LXQt, XFCE, Cinnamon, Budgie, more I don't immediately recall) who are keen for Wayland support in principal but don't want to be landed with writing/maintaining their own display server.

I know there are libs like wlroots, libweston, mir, but in practice it still seems to be too much to bite off to write a display server with one of these.

Is there appetite in the Linux desktop dev community for a grab-and-go toolkit-agnostic Wayland display server that allowed DEs to plug in their own independent WM, decorations, animations, shell? In theory shell is doable already by xdg-shell, but splitting WM and decorations out would be a new approach for Wayland. Is this technically feasible? I have the urge to start writing one myself but I'm not experienced in this area and it would be interesting for myself but almost certainly subpar for purpose.

Am I just describing Wayfire?

Without commenting on tech differences (I'm loving my mixed dpi wayland setup..), the social/community impact of X11 allowing UI/UX people to have their projects separate to the display server seems to have been significant.


There is intersting things going on to provide that. Wlroots landed wlr_scene api to make it much easier to create a compositor on top of wlroots. There is also riverwm which is quite interesting, built as a tiling wm but delegating wm management to an app, so allowing to create any quite of window management on it.


> Is there appetite in the Linux desktop dev community for a grab-and-go toolkit-agnostic Wayland display server that allowed DEs to plug in their own independent WM, decorations, animations, shell?

Well, yes. It's called X11.


Some sort of bring-your-own-compositor adventure at the moment, if I'm reading this issue correctly [0].

The thread did mention PaperDE [1] however , which you might want to look at if you're interested in a lightweight Wayland + QT environment.

[0] https://github.com/lxqt/lxqt/issues/10 [1] https://gitlab.com/cubocore/paper/paperde



I'd guess Kwin.


Is Kwin usable without plasmashell / the rest of KDE? I always thought they were pretty tightly integrated.

I feel we're currently missing a minimalist stacking Wayland compositor in the vein of something like openbox.


KWin is indeed usable without the rest of KDE. It can be used as the window manager for XFCE or MATE, for example.

Also, I'm not very educated in this matter, but isn't wlroots a fairly good Wayland compositor? Considering sway is built on it and supports both tiling and stacking, I think that might be worth a look.


As I understand it, wlroots is more of a library that you can build a Wayland compositor on top of (sway being one example). It's not a compositor in and of itself.

It still might be a good choice for LXQt if they do plan on supporting Wayland, though.


One wlroots possibility would be Wayfire https://wayfire.org/


> It can be used as the window manager for XFCE or MATE, for example.

But that's on X11 then, right?


Yes, although KWin now supports Wayland quite a bit. There's an explanation here: https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayl...


It's usable and some people in the automobile industry are interested in using it in an embedded context.


Version 1.0, must be a major milestone. Congrats!

I wonder if there's a stand-out feature that signifies this release transition?

I was recently looking into lightweight pocket linux setup, and considered desktop alternatives, zeroing in on Xfce or LXDE. Will give LXQt another chance.


I had an old netbook with an Atom CPU and 2 Go of Ram. So naturally I installed Lubuntu on it with LXDE. It was ok. Then came LXQt. I tried to install on my machine but the new installer kept playing tricks on me.

Fed up, I decided to give Ubuntu a try and what a surprise. Not only was it a bit snappier than Lubuntu.

What made the difference, was that Ubuntu had a much, much better quality of life features that made using it much more productive.

I wish I were competent enough to create a distro that's both lightweight and has essential features for sane, easy to use functionality. Alas, I'm not.


My needs have become more and more simple over the last couple of years. In particular because my work machine is now a company-provided Apple laptop (ew). So, only all of my personal machines are Linux, and my personal life computing needs are relatively simple, in nerd terms (web browser, ssh in my LAN, and SAMBA-style file sharing on my LAN).

So my opinions might be a tad outdated as I haven't really fiddled with my UI that much in the last couple of years (except to switch back and forth between Wayland and X11, and nouveau and proprietary NVIDIA drivers for my main personal laptop).

But I haven't participated in a good, old, Linux desktop holy war and rant in a long time, so here we go. :)

GNOME definitely seems to be ahead of the competition (including KDE/Plasma) when it comes to basic, "just works", kinds of things. This includes better (hot-plugging) screen management in the common cases and the on-screen keyboard seems to work better/consistently than KDE's. I can't think of more off the top of my head, but I remember thinking there were more things that worked better- maybe audio/volume settings and network settings?

I'm even one of those weirdos who enjoys the GNOME Shell workflow/UX, though when I say "GNOME", I'm mostly referring to the whole suite of desktop libraries/utilities/etc. So Budgie and GNOME Classic/Fallback also "count" as GNOME desktops to me.

In any case, I do still have several gripes with the GNOME desktop(s):

1. Network Manager still seems to be unaware of wireguard. I hate that I have to manage this from the command line.

2. GDM's login screen doesn't share settings such as touchpad-tap-to-click with the regular desktop. Now, I understand that Linux is a multi-user system and that tap-to-click is configured on a per-user basis, but I feel like there should be (easily discoverable) global default settings.

3. GNOME Shell still feels a little slow and janky at times on my "old" personal laptop (2012, but has a Core i7 and 16GB of RAM). That seems to be the case for all combinations of Wayland/X11 + nouveau/NVIDIA, but I'll admit that nouveau is noticeably worse. It could be that it's an NVIDIA thing.

4. GNOME Shell's app drawer UX still sucks. I don't know what the answer is, and I agree with them that a nested menu that groups things by optional/convention-based metadata on .desktop files isn't a good option, but they still haven't found an answer that works for me. I guess I'm glad that we can at least manage and group things in recent versions, but that's too tedious for me, too. And the icons are still way too big.

5. [GNOME Shell] I thought the distinction between window-menu and app-menu was actually a good idea, but you just can't pull it off when you don't own the whole stack, which is a shame. So, I understand why they abandoned it. But, now that they did, the top bar is even more useless than it was in the earlier days.


To improve Gnome's top bar, install the "dash to panel" extension. So many UI tweaks, it's great.



I'm still on Lubuntu 18.04 (under old LXDE), not sure of what to do yet


I went to Xubuntu 20.04 and am quite happy. In fact, I switched my desktop to Xubuntu from Lubuntu in 18.04 so that I could upgrade to 20.04 [0].

[0] https://askubuntu.com/a/1363525


Not sure if it's any consolation, but I really liked LXDE, and really disliked LXQT. Something about the feel is just very different.

If you end in the same boat, probably Xfce is the closest. I ended up back on Gnome(with many customizations).


I'd have to agree with that. I can't put my finger on why, but LXDE felt ok in a way that LXQt just doesn't.


I never used LXDE much, but LXQt felt too oddly coupled. I don’t recall the exact details, but I found that I could no longer use the file manager after a minor desktop misconfiguration


LXQt is my favorite DE to put on a Raspberry Pi. It's fast and light on resources.

The only problem is that the version included in RPi OS is terribly old, and I haven't found a convenient way of getting the bleeding edge version onto it.


You should be able to add their repo, or newer Debian version PPA, to your sources.list, and apt update / upgrade.


I can’t figure out from the changelog or the main LXQt site if they finally have a “true” dark mode. Any hints on that?


How does it reach 1.0.0 without working font scaling? When you set DPI it has no effect.


no screenshots, wouldnt this be needed?


How lightweight can a desktop environment based on QT be? I thought QT is a rather hefty dependency.


how many GUI toolkits do you know that work on an STM32 uc ? because Qt does.

https://resources.qt.io/videos/programming-for-smart-devices...

I think that's there's a huge problem with Qt's installer where I've seen a lot of people blindly checking all the boxes and installing things they'll never need like 6 different windows ABIs, the android version and whatnot which will install literally gigabytes of stuff and lead to a bloated perception (I teach students to make UIs with Qt every year and every year even if I warn them beforehand, they used to still fall into that trap... nowadays I just tell them to use aqt which will just install exactly what is needed).

A build of Qt on desktop machines for the needs of LXQT (basically, QtCore, QtGui, QtWidgets) can be in the ~15-20 megabytes ballpark.


Qt is not big and is well architected, so you should not have issues with a Qt based DE but you could stop useless services to get more performance. Qt will not eat your CPU or RAM but if you have a very old device you probably want to use some OS designed for that type of hardware or use KDE3


> Qt is not big and is well architected

I've used Qt in the past and current. Qt is big and, while it might be sufficiently architected, I wouldn't describe it as well architected. There's a lot of Qt-isms that don't follow modern C++ paradigms. The concept of shallow- and deep- copy is particularly frustrating, everything that's based in QObject can't be moved, and a lot of the objects simply _aren't_ extensible enough. Qt's QNetworkAccessManager is probably one of the least-acceptable (or extensible) network access libraries; good luck adding support for custom types of proxies or schemes.


What do you mean is big? How much % of your RAM will a Qt application take?

What I mean by well architected is that:

1 it respects the user choice so it tries to use the user themes, icons , fonts (it would do a even better job if Miscrosoft and Apple would contribute a bit when they change their designs)

2 it is efficient, it does not use some hacky stuff like you see in angular or react, where one click causes some data to change then a lot of code runs and check what changed where, then try see what other data needs to change then finally updates the DOM, which DOM is a super complex piece of software that is super easy to eat a lot of CPU with just a line of CSS or cause a lot of recalculations when you update one item.

3 Qt gives you a lot of widgets to build on top of, I remember it had a lot of APIs not only for GUI but also networking, desktop integration(like to use the native notifications)

4 I loved the fact Qt had it's own standard library, I know some c++ purists won't like that and the qmake , but we need to understand how many platforms Qt targeted and that the col new C++ features were not there on all this platforms when Qt4 was created (and even with Qt4 I think there was a way to upgrade from Qt3 so there was not a complete start from scratch).

I assume there are some smaller toolkits, there are some posted here but I think the smaller ones have only 20% of the features.

IMO the reason Qt is not used as much is because it uses C++ , for modern application I think developers prefer garbage collected languages and Qt (last time I checked) did not had mature bindings for this popular languages.

Sorry for the long comment, what would you use today if you need to make an application for someone, something simple like some buttons, menus and it does a bit of work maybe with some files or the internet), the goal is to be fast and have very few bugs that you will have to support by fixing them.


> I loved the fact Qt had it's own standard library, I know some c++ purists won't like that and the qmake , but we need to understand how many platforms Qt targeted and that the col new C++ features were not there on all this platforms when Qt4 was created

Indeed so! Qt is living today with the fact that it was built and designed long before C++11 was really a thing (where C++11 is the baseline of modern C++ and I would argue that even C++17 should be considered the baseline). The design decisions of Qt are directly against modern C++ design. I think that's ultimately the core of the problem: that modern Qt is orthogonal, not complementary, to modern C++.

Range-for loop? Oops, accidentally detached and deep-copied into a temporary.

Move objects? Just, no.

unique_ptr? Nah, QScopedPointer. Also still not moveable. make_unique? Nah, reset(new...) and ignore the modern advice that you shouldn't use `new`

Qt still takes naked pointers and decides willy-nilly whether to take ownership. It still has examples everywhere for using naked new without even mentioning the context of a smart pointer. It has the concept of "you used new, but the parent actually owns it, unless the parent is null" which is just a time bomb for anyone new to the framework let alone the language.

No, there's no way I would recommend Qt to someone who isn't experienced. Since I wouldn't recommend it then it's no wonder to me why Qt isn't used so much. It has little to do with C++ and a lot more to do with the design decisions of Qt itself.

> IMO the reason Qt is not used as much is because it uses C++

Arguably. Also arguably is because Qt brings along a lot of unnecessary baggage. You mentioned using Qt requires using qmake (which definitely counts as arcane, if not archaic); cmake does a pretty good job of wrapping qmake but doesn't eliminate it. And all of that is because of Qt's non-standard magical signals & slots system which is really just a more error-prone semi-async system when compared to any other eventing system.

Using Qt efficiently strongly needs Qt Creator which isn't nearly as good as Visual Studio or VS Code and not as feature-rich as CLion or other intellij-based IDEs I've used -- but at least it performans way better than CLion or intellij trash.

Qt's license changing in 5.15 has also become a significant penalty to non-commercial use. This fact alone means there's no way I'd use Qt in a new project, even a commercial one.

Modern Qt developers also have to become javascript developers since Qt's UI is heavily driving towards QML. That's an unfortunate direction and also inhibits adoption of Qt IMO. Why write an application in C++ if you need to learn javascript anyway? There are better feature-rich javascript frameworks with better community adoption and better price points.

> what would you use today if you need to make an application for someone, something simple like some buttons, menus and it does a bit of work maybe with some files or the internet), the goal is to be fast and have very few bugs that you will have to support by fixing them

For GUI, Dear Imgui [0].

For network, Asio [1].

For files, plain standard streams. They're not fast but if your files are your bottleneck then I'd consider memory-mapped files.

[0]: https://github.com/ocornut/imgui

[1]: https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio/re...


Your suggestions are not compatible with what I was thinking , my scenario was that "I need to write a small application very quickly" not "I am staring a bussiness and I want to spend a few years developing an application", What I mean is that with Qt you have more then a GUI, you don't have to Google what library I need to do some networking , or what is the win32 API to count how many screens this PC has (and same for the other platforms). I did not work on Desktop application in many years so I am not sure what exactly is happening in Qt world now and for a quick project I don't want to learn some niche libraries .


> Your suggestions are not compatible with what I was thinking , my scenario was that "I need to write a small application very quickly" not "I am staring a bussiness and I want to spend a few years developing an application"

I disagree; it's very possible to write a small application very quickly in modern C++ without Qt.

> with Qt you have more then a GUI, you don't have to Google what library I need to do some networking

If you are new to Qt then you do need to google how to use Qt.

On the flip side, if you're not new to whatever other library you want to use for networking then you don't need to google to use that. Indeed, I don't need to use Google to figure out how to use asio and beast to connect to a server and download data using http.

> or what is the win32 API to count how many screens this PC has

What small application needs to know how many screens this PC has? I definitely don't consider that a small application and I would need to go "Google" how to get that information out of Qt.

I would just as quickly find that information from Xlib because fuck Windows.

> for a quick project I don't want to learn some niche libraries

For a quick project I don't want to use Qt. Your argument is merely an opinion.


It can be frustrating indeed that Qt is not quite C++, make no use of modern C++ library, and requires a preprocessor.

Still, I find it debatable whether modern C++ is so much better than Qt. Qt design principles might lead to less performance but I, for one, find the design consistent and solid.

The main advantage of Qt over modern C++ though is its stability. If you had written a Qt app 20 years ago it would still compile and work as intended, whereas C++ become a different language every 5 years.

I share your sentiment about QML though, and hope they will quickly reinvest into Qwidgets.


> The main advantage of Qt over modern C++ though is its stability.

Yes

> main advantage of Qt over modern C++ though is its stability. If you had written a Qt app 20 years ago it would still compile and work as intended, whereas C++ become a different language every 5 years.

Your arguments contradict eachother.

C++ only becomes another language every 5 years if you want to use the new features. The new features make things simpler and safer.

I say I do want to use the new features; I want the safety improvements and the simplicity offered. Qt makes it practically impossible to do.


Note that you don't strictly need moc when coding Qt app. I use verdigris which is an equivalent of moc but entirely implemented as macros. The drawback is that since C++ does not yet have proper reflection, the macros are a bit uglier...


Most of your points revolve around QObject's having its own ownership and lifetime model, of course it will be extremely painful to work against that. No surprise there. QObject ownership is sound and quite practical though, as long as you're not actively trying to work against it. It's certainly not complicated.

> Also arguably is because Qt brings along a lot of unnecessary baggage. You mentioned using Qt requires using qmake (which definitely counts as arcane, if not archaic); cmake does a pretty good job of wrapping qmake but doesn't eliminate it.

CMake does not invoke qmake for Qt projects. It does invoke moc though. Perhaps you meant that you need to use moc? That's mostly true, though verdigris does work and only requires a modern C++ compiler.

> And all of that is because of Qt's non-standard magical signals & slots system which is really just a more error-prone semi-async system when compared to any other eventing system.

Signal-slot is simply a convenient way to declare events (signals) and connect callbacks (slots) to them, using implicit per-thread event queues. Pretty standard stuff.

> Modern Qt developers also have to become javascript developers since Qt's UI is heavily driving towards QML.

This is simply false. Qt contains two separate UI systems for two very different use cases. Qt Widgets does not use QML (or JS) and is your classic CPU-rendered desktop toolkit. Qt Quick is a declarative UI framework designed for layer-based GPU compositing, mainly aimed at mobile, embedded and "graphically rich" interfaces.

You can write Qt applications for years and years and not even know how JS is spelled.

> For GUI, Dear Imgui [0].

Imgui is a nice library, but it lacks a very large number of features you'd want in a desktop application, all of which you'd have to write yourself. Some of which you'll have a hard time developing (e.g. accessibility). This is of course because Imgui isn't meant to be a general-purpose GUI library for desktop applications.

> For files, plain standard streams.

It's kinda funny that you complain so much and then recommend iostreams of all things.


> CMake does not invoke qmake for Qt projects. It does invoke moc though. Perhaps you meant that you need to use moc?

Indeed

> Signal-slot is simply a convenient way to declare events (signals) and connect callbacks (slots) to them, using implicit per-thread event queues. Pretty standard stuff.

They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots.

> Imgui is a nice library, but it lacks a very large number of features you'd want in a desktop application, all of which you'd have to write yourself.

Maybe in a full desktop application but remember the idea is for a small one.

> Some of which you'll have a hard time developing (e.g. accessibility).

A small free application doesn't need accessibility to be useful to the author.

> This is of course because Imgui isn't meant to be a general-purpose GUI library for desktop applications.*

If you say so.

> It's kinda funny that you complain so much and then recommend iostreams of all things.

iostreams are just as easy as qt and without the bloat needed for it.


> They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots.

Like I said, you don't have to use moc, there are alternatives. Also, Qt has supported "regular functions" for many years, since you can use connect() with function pointers, PTMFs, lambdas etc.

The only difference between a "regular function" and a slot: method is that the latter has some extra RTTI data which allows it to be safely called from dynamic bindings. Another use-case is old-style (Qt 4) connect where you pass the slot name as a string and connect() has to look-up the method pointer at runtime (and also checks parameter types etc.). That's a rare sight, though.

> iostreams are just as easy as qt and without the bloat needed for it.

iostreams is an atrocious API and bloaty on top. Easily the worst library in the C++ standard (in no small part due to its sheer age, being one of the oldest parts of the language).


Regarding QObject, you know the difference between identity objects and value objects? QObjects are identity objects. I sometimes see people using them as value objects (bags of data), and that is not what they are for. It's terribly inefficient, for starters.


What do you mean ? You mean I should have avoided using QString ? I created a program once and I wanted to be pure c++ in the algorithm part so I used the std::string there but I suppose some C dev will tell me that char[] is faster.

Usualy QObject based classes are needed to get the GUI working.


QString is not a QObject subclass. It's a value class. It is also movable - and yes, it's probably fairly recent that it's movable.


Qt is quite lightweight. Similar to GTK. Less lightweight than something like FLTK of course, but way better than Java or Web based GUIs. It won't be an issue unless you are running on an absolute potato.


Lightweight is relative.

I ship ~20MB of Qt DLLs with my desktop application.


Well, you can statically link and just include the functions actually in use; here is an example of a Win32 Qt GUI application with only 6.8 MB: http://software.rochus-keller.ch/CrossLine_win32.zip (just download, unzip and run; works also well with Wine)


Interesting. Usually, statically linking Qt doesn't do much for disk usage because signals and slots cause symbols to be "theoretically reachable" because the linker can't know which strings you are going to pass to QObject::connect() at runtime. More technically, otherwise unused symbols are reachable through the meta-object data tables.


Was there ever an effort to try removing those "theoretically reachable" objects? It sounds doable, but of course not trivial.


I've been wondering, but I never heard of an effort to do that.


I don't think it relies on the full QT stack.

QT used to support more minimal builds i thought i.e. without some WebKit extensions and such but yes full fat QT is a bit on the bloaty side :)


> How lightweight can a desktop environment based on QT be? I thought QT is a rather hefty dependency.

Hefty when compared to what? In a world of webview-based apps, Qt is extraordinarily lean.


I believe the FLTK and FOX toolkits are generally quite a bit lighter.

No doubt Qt has them both beat on convenience and features, but still, there are lighter toolkits out there.


Native Xlib.


xlib is not a toolkit.


Yey, will have to find some time to install later




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: