LXQt 0.11 Released(lxqt.org) |
LXQt 0.11 Released(lxqt.org) |
Context: I'm one of the original leads on LXQt, and I initiated the merge of Razor-qt and LXDE-Qt into LXQt.
I've been using LXQt as my main desktop for several years now. I've kept up with what other desktops have been doing. I've been especially impressed by the efforts of the GNOME team, and especially disappointed with the clusterfuck KDE has become... but those are just details.
I feel like the Linux desktop is dead, and one of the worst examples of open source software right now.
Almost nobody actually collaborates on anything. Everybody wants to do their own thing and it leads to developer fragmentation. Every project is undermanned. LXQt is especially undermanned right now. The Cinnamon guys, last I heard, want to switch to Qt but don't have the developers to do it and would end up being a LXQt clone.
Nobody needs that many desktops, especially when nearly all of them are clones of each other in either GTK or Qt and 95% of the apps duplicate each others' functionality. The worst part is that, with more effort spent on cross-desktop specs and evangelism, software written "for" one desktop would work far better on others. But the XDG (cross desktop group) is in a pathetic state right now, with nobody reading the mailing list and no specs ever being worked on. Nobody cares, because very few people have enough context to see the need for it all.
Not to mention the sad state of UI toolkits right now. This isn't about GTK vs. Qt or anything... but you can't pick up your favourite language (Python, JS, whatever) and easily write cross-platform apps that work well on Linux. So what does everybody do? They ship a god damn copy of Chromium in their app. Bloody electron apps that, of course, respect zero accessibility settings, platform integration out of the window etc. Because that is the easiest thing to do.
It's pissing me off. Most people who care about their desktop have migrated or are migrating to OSX and the whole thing snowballs.
TLDR: No collaboration across desktops. Fragmentation with no cross desktop compatibility. 2016 was the year the Linux desktop died - won't anybody revive it?
Younger developers are chasing the golden goose on the web/mobile, or banging frameworks until sunrise. They feel like old c++ codebase etc. are like old ruins, in deep dark caverns. They wouldn't touch any of it. They're anti-mailing-list and pro-slack. There is a huge gap between the two.
It's as if new generations come in and they want to make their own mark. And there is what's sexy ("getting rich yo") and what's completely unsexy ("let's pick up grand pa's code and move it forward on my mac book pro").
Qt is a pretty amazing framework (yes, I'm biased). You can write apps in Python, but Python is a clusterfuck for shipping anything cross-platform or any kind of desktop apps.
My vision for LXQt was to very much have a modern desktop (targeting recent tech such as fingerprint readers, wayland etc), while retaining some design patterns from the classic desktop ("classic" taskbar or global menu, icon-based desktop grid, etc) without trying to reinvent "desktop shells".
Working on the desktop doesn't always mean using ancient tech, nor solving ancient problems - FWIW I'm probably younger than the average HN demographic. We tried having/creating solid developer tooling, good documentation, a decent-looking website but there's only so much you can do when you're lacking manpower in every area. Nearly all my time was spent doing developer outreach.
This frustrates me to no end.
- Qt is almost impossible to fully bind. The vague hacks we had all got tossed out the windows with the move from Qt4 to Qt5. I've given up putting my own effort in here.
- GTK had some good progress with gobject introspection, but it's like talking to a brick wall trying to get issues fixed. Not to mention that it doesn't work as well as other toolkits on other platforms, and I dislike their new "look".
- wxWidgets is very hard to bind well.
- Motif never "feels" right
- IUP is sort of a dark horse, but I've never managed to build a nicely working application in it, and the build process is a nightmare (though it has improved).
Not to mention that each toolkit ends up trying to push their own weird languages and ui designer IDEs.
At the moment I'm crossing my fingers that libui https://github.com/andlabs/libui/ won't mess up. But for now it's quite incomplete.
You know a system is hard to write bindings for when noone is able to create Lua bindings for it.
It is only(?) used by common lisp[0].
And there was claro[1].
I'm not among the most people. I don't care about my desktop, and I've migrated away from all the focus on appearance to tiling window managers, currently awesome.
I almost never see my desktop, I just want my windows. I'm not a "the mouse is evil, twm's are efficient," I just got fed up with all the focus on the desktop. I don't care, I just want to do my work.
But that's just me.
BTW: Excellent comment. You clearly care. :)
* hibernate when closing lid
* cpu/mem/network visualization in top/bottom bar
* clean theme without much fiddling
* mute/unmute via hardware button
And the rest I forgot. I can live with some issues, but it compounds on the less popular DEs.
All those issue apply to Awesome as well. DE is much more than managing windows. A long time ago, I used various tiling window managers, but always ran the various Gnome background services as well.
So I stick to Windowmaker. I don't even really use its DE part, I use it as a WM mostly. It gives me terminals and other windows, and that's all I need. I don't even tweak it as I use to do 15 (or perhaps a bit more) years ago. It's fine for me as it is.
As a Plasma dev, honestly, we couldn't feel more different right now. I've been hacking on KDE for 12 years now, and this year has been one of the best. Here's where we're at:
* We're about to ship Plasma 5.8, which will be the first LTS release of the Plasma 5 product. It's been an incredibly satisfying dev cycle, where we really hunkered down and spent a few months on performance optimizations, robustness (especially around multiscreen) and fit and finish (our design guys did an awesome job). There's not a doubt in my mind that this is the best version of the KDE desktop we've ever released.
* We've significantly professionalized our engineering/process story in the last two-three years. All of our new code has really high test coverage, we're increasingly expanding test coverage of our older code, we've got better habits on code review, we've got real meeting cycles, etc. I'm pretty confident about calling some of our new code best-of-class - e.g. our kwayland lib is the best-tested Wayland implementation around, period.
* We've been able to do the above things despite having ongoing porting churn (the Wayland transition), which is a process challenge we failed pretty badly in the past (the KDE 3->4 transition). We've learned a lot about how to manage ourselves, and most of the work we've done for Wayland has directly improved the quality of the X11 experience as well. Every time we've had to rewrite something we've asked ourselves what other goals we can hit at the same time that deliver concrete value to users.
tl;dr We think what we do now is the best we've ever done, and that we get better year-over-year while living up to our original goals. And we're not about to stop.
But you're really talking about KDE here. Not linux. You have the context of a KDE developer. You're basically saying "The KDE project is doing great!", but that doesn't invalidate anything I said in my comment.
I've been dealing with the evangelism portion a ton more; what I've seen is that people no longer care.
Linux support for some of the newer tech is abysmal. Take for example hi-dpi and touch screen support; we're only now starting to get somewhere with both of those, and those don't even qualify as "newer tech". Things like UEFI have truly made Linux harder to install and deal with. We're going to catch up eventually but in the mean time, for users it's a terrible experience.
Desktop devs are so focused on their "experience" within the DE. Tell me, who's working on making GNOME/KDE apps look good on KDE/GNOME? Who's working on making them behave well? The rare times there's activity in XDG, it's "FYI" activity. "Hey, so, we're doing this in (gnome/kde) now. Comments welcome, whatever." - nobody ever replies. I worked for over a year on porting Android intents to XDG. Nobody helped. The GNOME project showed some interest in it; some good stuff came out of that, but intents are still not on Linux and, in 2016, it's still not possible to do something as simple as an "Edit this picture" action.
It's been a frustrating past few years. I saw a massive amount of new people interested in Linux, because "Windows 8 sucks". I also saw most of them go to macOS instead; the few that stayed went back to Windows when 10 was released. Linux really missed the boat there.
We are lacking a project that is actively working on the health of "Linux on the desktop". We need people to work on improving the experience of developing apps on Linux, improving the portability across desktops, creating clear specs, guidelines and documentation and we need all that not to suck. But who's going to do that? Mozilla doesn't seem interested. Valve, RH etc only have to care about the distro/DE they're shipping. Google's no longer looking at Linux as anything else than a kernel. Yeah, we're pretty screwed.
I have been using Unix/Linux from early 90's and desktops have always been fine most of the time. twm was fine, UDE was fine, FVWM was fine, I would be using them even today except that I'm lazy and satisfied with what comes out of the box. There is different types of eye candy and taskbars etc. but why are they so important? Interaction is not faster or easier than it was before. Configuration is easier but you don't need new desktop for that.
As an example, instead of starting another desktop project (lxde, razor-qt, lxqt), some could have contributed to or collaborated with xfce.
> Nobody needs that many desktops, especially when nearly all of them are clones of each other in either GTK or Qt and 95% of the apps duplicate each others' functionality.
In a way like lxde, razor-qt, lxqt in relation to xfce.
Seems like you've contributed quite a bit to the fragmentation, coming back and preaching collaboration will at best only fix part of the problem.
Like majewsky said, Qt was and still is so far ahead of GTK it's completely unreal. But you're also not factoring in the fact that LXDE already existed for 10 years, and we moved that off GTK. LXQt is a continuation of it all.
I pushed really hard in favour of KDE frameworks. I specifically pushed for kwin to be a bit more independent, and we got that. LXQt was a driving force behind the need for KDE apps to become less tied to their own desktop. LXQt, today, is using several libraries from KDE which were duplicated in the ecosystem before that (eg. Solid, kidletime, kwindowsystem).
We worked so much on reducing fragmentation. Do you think I'd be bitching about it and then undermining my own efforts?
As a former Qt (and KDE) developer, I can very much understand wanting to develop with the language and framework you're intimately familiar with. At least at the time (~2010), C++ with Qt was light years ahead of C with GTK.
As far as Linux DEs, most people use Unity, Cinnamon or Gnome and are quite content. And with today's RAM prices there is little place for a lightweight environment like LXQT, especially with QT apps looking worse than Gnome apps out of the box. LXDE could still have been a successfull DE todat had they not wasted time on merger and toolkit switch.
>>Most people who care about their desktop have migrated or are migrating to OSX and the whole thing snowballs.
According to Netmarketshare, users are abandoning OSX to Windows 10 and on a smaller scale to Linux. This is not suprising considering the ridiculously overpriced hardware, Apple no longer caring about the OS, or gaming on its hardware.
As far as I can tell, when software is open source, the barrier to people contributing is lower. And that leads to a sort of brownian jitter in the system. Once great systems, (kde in general and amarok in particular) suffer from contributions of new features, which add features but decrease reliability. Or they exist for so long that no new exciting features exist to be added, so the inevitable re-architecture death march begins (I'm looking at your kde4. You killed kde as a corporate desktop, so that you could add semantic search?).
Whatever the cause, be it the accretion of "features", or the inevitable "rinse, re-architect, repeat" cycle some project are on, it can only drive people away. But a project that is widely used collects developers, and it is difficult to say no to contributors - a common problem in volunteer projects outside software.
You have some of the same policy at the kernel level with torvalds "we do not break userspace" policy. But the higher layers are just too damn happy with breaking themselves for it to have any meaning.
1. The linux desktop has been reworked so hard and so many times to try and attract and accomodate those good ol' "my mom uses linux!" as a means of obtaining critical mass for the other things (drivers, well-polished software, ...). The few that this model attract are equally fine with their smartphone and a laptop built around a browser.
2. From (1), it is not even an attractive target for dev- work. I used Linux as a my main "desktop" from the days of downloading slackware over BBS in the early 90ies up until I was introduced to OSX around 10.4. I tried going back after Apple making it increasingly more awful after 10.6. I hated every minute of it - all the things I hated with new OSX was replicated, poorly. an endless stream of internal frustration "no I don't want to automount this usb stick what is wrong with you?", "why is my volume settings jumping around", "yes I plugged in a device, I don't need to be notified that I did what I did please shut up", "oh so two audio feeds with different sample rates are a no go?", "my mouse is low on batteries? I'm not using it, it's not even connected?", "hotplug monitor? enjoy panic and reboot", "I know there's updates to be had, there's always updates to be had, fuck off - daddy's working". I waste more time turning things off than I previously ever had to do turning things on. Now my (non-NIH) regular linux desktop use is confined to VMs that I just reset from template, do my thing and then murder.
3. Not even 'cool' anymore. The 'fragmentation' of the desktop was an attractive feature to young me. Jumping between WindowMaker to Enlightenment to KDE opened a lot of ideas as to what this thing could be used for, I enjoyed tinkering (still do, but not on this chimera). Now they are all convering into mostly the same confused pig but with different shades of lipstick. The same useless animations and effects and none of the useful ones.
"We" lost the mobile race (and never really took to participating) and payed the price with what is effectively a kernel fork. There's a good chance that VR can actually turn into the next "Desktop" (displays are nearly there, eyetrackers, haptic gloves etc. incoming) to make the browser look more pathetic. How many projects are seriously working on it, or is that already lost?
There's an ugly catch-22 that's been playing itself out in the linux ecosystem for a while now. Linux drivers for modern hardware sucks, especially Wifi, video and audio cards. None of the manufacturers are willing to get serious about developing drivers for Linux until it gets more users and it can't get more users without better drivers. OS X was able to sidestep this problem by forming corporate partnerships with hardware manufacturers. They become far more willing to develop drivers for your system when it can buy them hardware sales. To date, nobody has decided to create a desktop based on Linux that has pockets deep enough to encourage the kind of development it needs.
Drivers on Linux have always been like this, that's not the issue.
The real issue is that modern line-of-business application development (which is where the money is) has left the desktop for good. Windows has the same problem. It's not the Linux desktop that is dying, it's "the desktop" as a concept. Desktop vendors are sandboxing everything to death, for security reasons; and sandboxed apps are basically equivalent to a browser. More and more, the desktop is just a bootloader for browsers.
The only way out of this rut would require inventing something amazingly useful that is safe to share across desktop apps but not with browsers. The desktop needs something that appeals the mainstream and cannot be browserized. I don't expect Apple to ever come up with this (they love "browserization", it opened the market to their profitable mobile hardware), but Microsoft should really give it a go.
I'm pretty happy with most of the newer USB audio interfaces, as they happen to be more and more class compliant, so you don't need a seperate driver for it. I'm using the Presonus AudioBox 1818. It works fine with Linux, but I can't use the internal mixing engine. Would be fine if that worked, but is not that important for me.
What I really like about Linux drivers is that if they work, they won't get obsolete so quickly. I've had more luck with old supported hardware on Linux than on newer Windows versions. I also don't miss all the crapware that comes with some Windows drivers. I am looking at you Nvidia - I just want my monitor to work, I don't need 10 tools for my third monitor.
I also took it on me to stop slacking off and give LXQt a shot, and damn I loved it.
I'm currently using Xfce+bspwm but I'm swapping out Xfce for LXQt in a day or two and will hopefully start contributing and put my time to good use.
Thank you (and the other LXQt contributors) for all the effort you've put into the project.
Can you elaborate? I'm on Plasma 5 and quite satisfied with it, though my use of KDE applications has constantly declined over the years. (Which has nothing to do with KDE specifically, just with my workflow becoming more and more CLI-centric over the years.)
The people in the Linux ecosystem fighting more against each other than against Windows - a common enemy (sorry for war rhetoric).
Linux is the ecosystem with the least resources, but with the most competition inside the ecosystem. You have more than 10 different desktop managers, two competing display servers, hundreds of distributions and whatnot. A lot of people will say, competition is healthy for the Linux ecosystem, but I personally would disagree. I think most forks are a waste of energy - yes, I am looking at you Canonical.
So, while the Linux desktop is probably in a very bad place, it's not so bad if you compare it to the other two alternatives.
Luckily, I can use Linux now at my workplace and that alone made me much happier. I have recently converted a colleague as well. Strangely, he prefers Gnome3 but yeah...whatever makes him happy.
Mac OS X is the only same alternative, at least for me.
The main problem is that GNU/Linux wars have replaced the UNIX wars of the 90's.
Rather than cook up a protocol spec between high level and low level, they write a -kit/-d (more and more often these days as part of the systemd shoggoth) and makes its APIs (that are subject to change from version to version) the "protocol spec".
And most of this gets prototyped over at Fedora, by RH employees...
things are moving fast in the app-centric world right now, and while this has its downsides, it also populizes ideas that really do make things better - declarative layout, the functional (reactive) approach to ui-programming, using a network capable (rest-) interface between front- and backend and sane sandboxing. a desktop environment that offers a runtime for these kind of apps has the potential to bring back some developers to the linux desktop - KDE imho not only shines in regard to the Frameworks and KWin, their efforts in using QML as the basis for the whole desktop could lead to a more hackable experience for a new generation of developers in general.
bottom line: while electron really is an ugly hack atm, this approach to write cross desktop apps offers a developer experience that is superior in many ways and something that QT should really keep on moving forward: high quality ui-components and functional QML based frontend code combined with language agnostic backend code (c++ for resource heavy stuff, python et al for everything else)
This might have been the main reason for Canonical to develop - Unity & Mir, for stable development cycles.
I think Linux Desktop environments need to decouple the user applications from core desktop functionalities - window manager, themes, settings; everybody is doing their own thing.
Currently, every DE comes with its own solution for these functionalities.
1. Toolkits - GTK+, QT, EFL
2. Desktop - Gnome, KDE, XFCE, Enlightenment
3. Desktop/Systems Settings Control - Network / Disk / Display etc.
4. Applications - File Manager, Web Browser, Email Manager etc.
Gnome 2 forks brought more chaos into this argument.
I just hope (crossing fingers) moving to GTK3 doesn't mean visual bugs.
I'll be keeping an eye on LXQt. In the meantime, KDE 4 still serves me pretty well. Dolphin is a fantastic file manager for when you need a GUI, and KWin is a great window manager. And KHotkeys makes configuring global shortcuts so easy. And Plasma 4 lets you make decent panels. So I'm glad KDE 4 is in Jessie, so I can keep using it for several more years.
At the same time, I'm really enjoying using TDE on some of my systems. I loved KDE 3.5, and TDE picks up right where KDE 3.5 left off. It's fast, stable, sleek, light on resources, and looks great. It does everything I could want a desktop to do.
In a way, it gives the lie to KDE 4 and 5. I'm sure Qt 4 and 5 have some advantages over Qt 3, yet look at how well Qt 3 is still working in TDE! And I don't have to wait years for KDE to get around to feature parity again, only to have them jump to KPlasmaFrameworksDE6 the year after that and start reinventing the wheel again.
The XDG thing is another good point you made. If it weren't for XDG, we probably wouldn't have the decently usable desktops we have now; or at least they would be much less compatible, causing a lot of pain. So to some extent I think we need XDG, or something like it. If every DE project has to coordinate and standardize separately, users will suffer. Maybe a new XDG-NG could be formed by LXQt, Cinnamon, MATE, and TDE, the DEs that seem to be the most sane, focused on stability and usefulness.
Anyway, I'm not exactly one of your users yet, but thanks for your work nonetheless, and thanks for caring about the future of desktop Linux. I'm with you in spirit if not currently in software.
One suggestion: you said in another comment that you spent most of your time on developer outreach. Well, what do I know--but consider the old cliche, "If you build it, they will come." Nothing attracts developers like good software. When software meets users needs, and those users are developers with the skills to itch-scratch, they will naturally want to help when they can.
So just keep working on the software, making the best, most useful software you can, for yourself first and others second. As it improves, more people will use it, and more people will join the project. Don't worry about numbers--it will happen on its own when you do good work.
The point of XDG isn't about a particular user experience, it's about cross-desktop compatibility. If you lose the two biggest desktops, then it's doomed to uselessness. Like a W3C that Mozilla and Google don't listen to.
The first step of standardization is to get the people with the most pull to care. The problem is nobody cares anymore.
Bleh.
I tried damn near every combination of desktop environment and window manager on my RPi, hoping that someone had fixed this issue since the last time I tried running a Linux system. In the end I settled on LXQt as the best of the bunch, but it still isn't a good experience.
I'd say that the object-oriented style of GTK/wx/Qt/you name it is inherently hard to use cleanly in a language like lua - not that it can't be done but you constantly feel like "there must be a better way to do this". And then the kid next door shows you a HTML5 interface that just makes you go "wow", and the same again when he tells you he built it in 5 minutes. (The wow effect wears off quickly enough once you try such "arcane" things as keyboard shortcuts, or even getting a consistent TAB order half the time.)
It seems to me like everyone has realised that we need something better than writing python while thinking in C++, and everyone's experimenting with their own solution - hence why we have meta-object compilers and g-introspection and whatnot. Perhaps that's necessary because I don't think anyone has made a really good 21st century dynamic-language desktop application API yet that's almost as quick to work in as electron, but gets things right. Possibly with a sprinkle of functional programming and some kind of async thrown in.
You can't blame gnome 3 for not trying, but the amount of custom undocumented CSS you need to hack on to do something like picking an accent colour for the currently selected control make me think this is a really good learning example of how not to do it.
https://en.wikipedia.org/wiki/Ion3
http://notion.sourceforge.net/
My sincere thanks to all authors and maintainers of ion3 and Notion. I've used your work for at least a decade, probably longer.
Lightweight anything is also a good idea security-wise (reduction of the Trusted Computing Base).
Some might see the need for C libraries as evil and unnecessary (I personally don't), but it's the situation we're in.
Only python bindings seem to have made it up to Qt5.
(Although it would be nicer if it were a desktop-agnostic "Linux Connect", but the sad state of XDG means that this might never happen.)
I don't think it would be useless. If GNOME and KDE don't care anymore, then move on without them. Lead the way with the people who do care. Eventually your work will surpass theirs, and they will either join you, follow you, or fall into obscurity.
> The first step of standardization is to get the people with the most pull to care. The problem is nobody cares anymore.
I think the first step of standardization is to standardize. ;) If the DE projects I mentioned got together and defined useful standards and started using them, if they started solving real problems that they and other DEs experience, then the big two would naturally be attracted to the new standards and solutions.
But even if GNOME and KDE never came around, you still have four or five DEs (with the potential for more) that have useful interoperability. I think that would be valuable.
Possible elephant in the room: Red Hat/Fedora. My impression is that XDG is dominated by GNOME which is dominated by Red Hat. They have shown in many ways how little they care about users, standards, and stability. Time to leave them in the dust. Blaze a new trail for desktop Linux without them! ;)
I hope the KDE guys never go bonkers like the Gnome/RedHat guys and keep up the nice modularity they have achieved by now so other DEs can reuse some of their functionality.
And now i wonder about the state of Afterstep...
It's possible the issue isn't with the audio drivers themselves but with PulseAudio and ALSA, which are both huge, steaming pile of shit. I just assumed PulseAudio and ALSA were both bad because of bad driver support and not because nobody in the linux ecosystem knows how to write an audio system.
I'm not using Bluetooth on my Linux PCs, so I can't comment on this.
The last audio problems I had with Linux was more than 6 years ago when I was using Ubuntu - it configured my soundcard on the PC wrong, was easily fixed. I am using Arch Linux in the last years and didn't have a problem with sound card drivers at all. Recording 16 tracks at the same time, mixing and using the HDMI or the analog Output on my media pc.
This is actually systemd territory today.
(One of the reasons why I like systemd in practice. They may run counter to the Unix philosophy in every possible way, but at least shit now works the same across nearly all distros and desktops.)
All of those are possible with XFCE. Technically I think the mute/unmute thing comes through ACPI or something -- it works in any DE I've used.
Works fine, but then i do not have any transitory (USB) audio devices.
I suspect the lid close can be bound similarly (but these days you have the whole crapola of powerkit/powerd depending on systemd-logind handling the gruntwork, so who really knows).
Random crashes of random "ksomething" components, announced with a cheerful dialog with a cute icon (I've had these crashes upon a first login of a newly created user, how low is that?), the little activity chooser widget expanding and collapsing itself in top-right corner over and over, audio devices appearing and disappearing semi-randomly whenever KDE tries to play one of its sound effects, Just a few days ago, after upgrade to latest plasma, all my systray icons are double in size, and thus no longer neatly in two rows. I'm not a half-blind grandpa, or a smartphone user, I don't need icons the size of my thumbs! The systray widget _is_ still able to display smaller icons, when I make the panel narrower, but the only way I can get two rows of icons anymore is to make it so wide that two rows of these large icons can fit.
Just yesterday, I tried creating a new user account with the intent of starting out with a fresh configuration and recreating my customizations, to get rid of old cruft (KDE doesn't seem to handle upgrades from previous versions very well, e.g. I lost the right-click menu on empty desktop somewhere around plasma 5.4). I got crash on first start, text in various systemsettings sections not redrawing properly when scrolling, "desktop settings" menu item always produces two (!) dialogs side by side, probably because I have two monitors active, KDE sometimes starting into a black screen with no controls visible... Not a very good first impression for a new user.
I'm now suffering KDE until I can get something else going and configured to my workflow. LXQt is something I'm looking at primarily, since I like the idea, and also like to write code for Qt. Hopefully I'll even be able to contribute eventually.
But yeah - KDE is circling the drain from a regular desktop user's point of view. Although it's still usable, it's the thousand little cuts that will get you.
Hi-dpi is something we were pretty much done with one-two years ago (modulo per-screen dpi, which we need Wayland for).
> Tell me, who's working on making GNOME/KDE apps look good on KDE/GNOME?
Well, we've developed GTK+ versions of both of our last default looks (Oxygen and Breeze) and tried pretty hard to get to an agreement with the GTK+ guys on the window decos issue - it's true we're a bit disappointed how the latter went. I share your concerns about lack of cooperation, actually!
> But who's going to do that?
The same people who've always done that: You and me. I prefer rolling up my sleeve vs. waiting for a savior ...
For me the metric is simple, really:
- Is the Linux desktop still needed? Today more than ever.
- Is the Linux desktop today still better than one year ago? Yes.
As long as I have positive answers to those, I'll just keep working.
The Linux desktop is now in a much better overall shape than it has ever been.
The desktops themselves have reached a fairly polished state. Much less annoyance than before (like multi-monitor settings and other basic stuff). I use Cinnamon on my Mint laptop and KDE Plasma on my Neon dev workstation and both are fairly polished and stable.
OSS applications like Kdenlive are also getting polished and adding more professional features. I also use a macOS laptop and I actually think that it is now as easy/quick to edit videos with Kdenlive on my Linux machines than with iMovie on the mac.
KDEConnect is another great example, it is just brilliant.
LibreOffice is also progressing rapidly with other productivity tools.
Using both macOS and Linux desktops for java/web development, I actually think that Linux is better, faster and more stable in most respect. E.g.: Finder is a joke, it is even worse than Explorer, none of them come close to proper Linux file managers like Krusader, Dolphin or Caja.
All in all, the Linux desktop space has seen great improvements and the hard work seems to be paying off now (see the latest upwards trend on Linux desktop market share)
Guys, keep up the good work on both KDE Plasma and LXQt!!! Your work is greatly appreciated by many-many of us, happy Linux users.
Lots of projects delivering WPF and Qt based applications, for those after them.
What are you basing that on? Drivers on Linux have always been like this and Desktop Linux has always been DOA. OS X is a Linux based operating system that fixed this issue and linux users went to it in droves. You don't see the correlation?
> The real issue is that modern line-of-business application development (which is where the money is) has left the desktop for good.
I agree, the shrinking amount of money that can be made in the Desktop space is an issue. Or at least it's an issue that that's how people see it these days; microsoft is doing just fine with enterprise software licensing and I know more than a few $1M+ revenue line of business software businesses that are not saas based.
In any case, there is a solution for that: go the apple route and make the Linux Distro specifically for a new laptop. The state of laptop hardware these days sucks. It's all commodity junk, even the Thinkpads. Trying to push commodity hardware when the commodity crowd has gone to mobile is a losing strategy, as evidenced by decreasing sales year after year.
There's space for a high quality PC laptop that caters to the power user crowd, including a linux based OS with working drivers and a pleasant UI.
OSX (which btw is based on BSD, not Linux) has been around for ages, but it wasn't that popular among developers until Apple moved to Intel, released the iPhone, and changed the laptop game with the MBA. That was the combo breaker, not the desktop.
> it's an issue that that's how people see it these days;
I agree, there is still good money in the desktop game; it's just that the margins on web are so eye-watering large, the market can't resist the temptation.
> go the apple route and make the Linux Distro specifically for a new laptop.
That would be nice, and it was sort-of tried by various entities at some point (Canonical + Dell, RedHat + IBM...), to be fair only with the commodity plasticky shit. Someone is trying it today with what are basically last year's MBPs (https://www.crowdsupply.com/purism/librem-15). The problem is that both Linux and hardware move so fast and so chaotically, long-term support is always an issue; today's graphic drivers might not be good enough for next year's chips, and tomorrow someone at RedHat might decide the audio stack should be rewritten for systemd, and so on and so forth.
And to be honest, the margins in the laptop game are clearly very thin. There is a reason Apple treats OSX as second fiddle to iOS and can't be bothered to refresh their MBPs as they used to.
I can see it already, make pulseadio depend on logind under the banner of making audio device access "more secure".
Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year (https://www.youtube.com/watch?v=J_hlbjj_9-Q). From what I recall it was more of a full application framework rather than a library usable from existing processes.
I did try to give them a go at some point, but could never get things working.
Aside from this, the reliance on luajit makes this a no-go for me. (though perhaps you can use luaffi (https://github.com/facebook/luaffifb) to alleviate this?)
But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?
Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop.
Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while
What I meant is: the code base is ancient to them. The unsexy monolithic code base that's not running on the cloud and doesn't emulate itself 3 times before running. No new developer fresh of the boat wants to pick up large projects codebase, they want to write funky new code from scratch with tons of bugs, because that's where the fun lies when you're not paid.
I share your love for UX and UI development. For what it's worth, the LXQt project could really use people like you dedicating a few hours now and then on drafting app designs, filing UX issues, etc. If you're ever interested, file an issue on the tracker[0] and cc me (@jleclanche) on it.
I'm not sure where they stand wrt XDG, but I bet if you asked them for help with UX and designing stuff, they would love to collaborate.
Let's not put all the fault on "younger developers".
I agree with you completely when you say that nowadays developers care more about new and shiny JS/ROR frameworks than anything else, because they are easy to use and allow them to ship thing overnight and possibly make even a bunch of money out of it.
But let's talk for a moment about the "grand pa's" efforts to welcome new developers. I speak out of personal experience here. In the past, when I was a very young and very new to development, with a limitless willingness to learn and help out doing my part in open source (and, more importantly, limitless time to do it), many of my attempts at trying to collaborate -- two of the most notable and worst experiences on my side being Tox and Fedora -- ended up with me getting mocked for even trying. And when I say mocked I mean it. I wasn't just normally (or, to use a blasphemous word, politely) turned down, which I would have understood. Someone of the Fedora project, when I had attempted to take part in an initiative intended to attract new developers, even went the extra mile basically telling me to go get screwed because I had never contributed before.
This happened when I was around 16 or something. Now I'm 27 and it takes a huge effort on my part to even just consider contributing to "old guard" open source projects. Nowadays, I still would never dare to participate in mailing lists/IRC channels because I'm still too afraid of being treated that way again.
I'm not trying to start a flame war. I just wish everybody would be more self-critic.
On LXQt, I made sure there was no NIH. All the apps that came out of LXQt were lightweight alternatives to bloated stuff from KDE and were "in scope" of the desktop environment. Whereas Elementary includes an Email client.
To put things in context: An email client is office software. It's such a burden to maintain that Mozilla dropped support for theirs (Thunderbird), despite its massive userbase.
People work on what they want to work I suppose, but we're talking about apps that are never going to be used outside of that one particular desktop. That one desktop out of god knows how many, since everybody is working on their own piece.
Are there really so many different ways to do a lightweight tabbed text editor with syntax highlighting in GTK, that Scratch, gedit and Leafpad all need to exist? Or can we admit there's a problem?
Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results.
I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?
there are very good reasons for this for the future, like being able to package up applications into archives (like .apk for android, .jar or java etc.) as we already have a whole archive library (eet) that handles random access read (and decompress), so this would allow for lua apps to be shipped as single file archives with all script AND data files (images, theme data, videos, icons and more) in a single file just dropped into a directory with no extra dependencies or tools needed. to do this we need something like elua. our whole intent is to actually become a portable cross-platform toolkit where you do not need external plugins, binaries, libraries and can build a portable application that "just works" on multiple OS's without needing to instruct people on how to install 3rd party dependencies.
also so far we've supported both luajit and puc lua (and intend to drop puc lua because of ffi and a few other niggles) so this is a big problem as to which executable then gets used? different names. lua va luajit. how do you run things "by default" and know it will work and which one will be installed? part of our build uses elua and lua scripts to generate documentation so how could we run our doc generator when we don't know what executor is there on the host? we'd have to add more detection and have file.lua.in files where #!/bin/whatever is replaced with the correct lua etc. ... not pretty where now #!/bin/env elua will do fine.
In lua it is customary to bring along your own main loop.
People often start with one based on select, but later move to libevent, libev, cqueues, luv (libuv), glib or others.
> for lua there IS not native mainloop
Neither is there for C.
> as there is no native lua runtime (beyond a sample lua cmdline)
The 'sample' lua application is quite often used as a runtime; if your library can't be used from it, it won't be useful for the majority of developers.
> we provide one (elua) that will load in the bindings stubs for you and thus work
In elua you still have to load in the bindings yourself (via require).
> there are very good reasons for this for the future, like being able to package up applications into archives (like .apk for android, .jar or java etc.)
I have no idea how this is related. lua already has tools to pack resources into one executable (e.g. srlua). but you can use any tool/method you want. This doesn't dictate the main loop used in any way.
> how do you run things "by default" and know it will work and which one will be installed?
you just use #!/usr/bin/env lua. Which will pick up whatever the user/distro has picked (e.g. a user might use debian update-alternatives). If you need a particular version of lua, use `#!/usr/bin/env lua5.1` which is the generally accepted shebang.
And that is what we provide - yes the toolkit is built around the mainloop we provide. It's a core design concept. It's a necessary thing to have a working UI to drive I/O. Trying to avoid a mainloop is just an order of magnitude more painful and leads to pretty bad design. UI updates are tied in great detail to the mainloop where they actually time themselves to vsync updates invisibly to the programmer for example.
> Neither is there for C.
Yes, and thus a toolkit brings one along. This is the case for sure for GTK+ - that mainloop is glib. That's how this works. Trying to avoid a mainloop or just choose whatever one you like is also like asking "well I want to use GTK+ for this widget and Qt for this one, and maybe EFL for this other one... in my window". If you jump through enough hoops and create enough ugliness it might be possible, BUT it comes at a cost. Trying to avoid this pushes everyone into the loweest common denominator design which basically means "assume X11, a window and draw commands and you call a 'draw me' function, then have more functions to push in events etc." ... this gets insanely complex once you start dealing with sizing, layout logic which differ, and not to mention you just screwed the pooch on deferred rendering, trying to to real acceleration e.g. via OpenGL because this is no longer even close to optimal etc. ... and mainloops are similar (though simpler). you can squeeze them together with some effort but trying to design without one and "well go bring your own" just leads to incredibly horrible API as well as overhead for the developer.
> The 'sample' lua application is quite often used as a runtime; if your library can't be used from it, it won't be useful for the majority of developers.
that's not of much if any concern to us as we provide a runtime already.
> In elua you still have to load in the bindings yourself (via require).
that will change as its simply boilerplate someone shouldn't need to go from zero to working app.
> I have no idea how this is related. lua already has tools to pack resources into one executable (e.g. srlua). but you can use any tool/method you want. This doesn't dictate the main loop used in any way.
If your source and resources are packed into a single file then the executor needs to be able to read from that file and unpack stuff from it FIRST before a single line of any lua code is run. it has nothing to do with mainloop etc. - it has to do with features existing before any lua code is run.
> you just use #!/usr/bin/env lua. Which will pick up whatever the user/distro has picked (e.g. a user might use debian update-alternatives). If you need a particular version of lua, use `#!/usr/bin/env lua5.1` which is the generally accepted shebang.
perhaps ONLY on debian... because on arch i can have both lua and luajit installed and /usr/bin/lua is PUC lua ALWAYS and /user/bin/luajit is from luajit - always. env will not work here as the command is actually totally different.
No you don't need to abstract the X11 calls. What you should expose is an fd+pollmask (or collection of them) for the program to poll (+ timeout if you need it), and a function to call to make progress.
The latter you already have in C in ecore: `ecore_main_loop_iterate`
The former is a bit trickier with EFL, I guess you could create something with `ecore_main_loop_select_func_set`, but the API inside out: you really want to be able do the replacement select from outside of `ecore_main_loop_iterate`. I haven't read into the implementation to see if this is already possible.
> that's not of much if any concern to us as we provide a runtime already.
I don't want your runtime, I just want your GUI functions. I need you to integrate with my existing runtime.
> If your source and resources are packed into a single file then the executor needs to be able to read from that file and unpack stuff from it FIRST before a single line of any lua code is run. it has nothing to do with mainloop etc. - it has to do with features existing before any lua code is run.
Why? the lua code itself can do the unpacking if it wants to. There are tools around to do this. But I don't think we need to continue this subthread.