LXQt 0.11 Released(lxqt.org)

84 pointsby Tsiolkovsky10 anni fa91 comments

http://lxqt.org/release/2016/09/24/lxqt-011-et-al/

96 comments

So while this is on HN, I wanted to talk a bit about LXQt and desktop OSes in general.

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?

keyle10 anni fa

I feel it's somewhat a deeper change. Older developers are getting kids and have very limited / no time to allocate for open source development (unsupported financially).

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").

[deleted]10 anni fa

scrollaway10 anni fa

It's not like you can't make desktop development "sexy", though. You could, but we're not there yet.

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.

keyle10 anni fa

Yes I really like your vision of desktop. And I'm not saying desktop dev is unsexy. I'm a designer/ux/ui developer. There is tons of sexy stuff to do. Just look at the VFX of scifi movies and take cues (http://www.aspenexcel.com/), desktop is stuck in the past and could move forward.

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.

scrollaway10 anni fa

Yah I got what you were saying. It just annoys me that this is the state we're in.

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.

https://github.com/lxde/lxqt/issues

acchan10 anni fa

How do you feel about elementary OS? [0] They spend a lot of effort on UX and it's the project I personally believe has the most chance to push Free Software to a wider audience, but on the other hand it's yet another project contributing to fragmentation.

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.

[0] https://elementary.io

scrollaway10 anni fa

I like that they're doing some good UX work (although it's really just copying apple's HIG... and style), but again it's not very interesting to have a group of people working on apps, when the apps themselves look like crap on any other desktop.

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?

cutthehypocris10 anni fa

> Younger developers

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.

[deleted]10 anni fa

reddotX10 anni fa

i'm old and i never liked mailing lists

daurnimator10 anni fa

> 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.

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.

rasterman10 anni fa

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full bindings with zero maintenance overhead EXCEPT for fixing bugs in the generators or the initial work for adding a new language binding tool". At least the plan is to have language bindings "first class citizens" all coming out of core development (with yes, the core still in C - that's how we roll). Our cross-platform support hasn't been great and originally it was never intended/planned, but now we do port to Windows, Mac and Linux (X11 + Wayland), other Unixen... sure the ports need more work/maintenance and to be made easier and less prone to breaking, and we don't have iOS, android or Windows Phone ports (and no obscure OS's like Symbian, QNX etc.), so that's something to fix, but we're shifting design to push portability first and foremost and that allows for OS ports, so maybe this will pan out. There are Python bindings waiting int he wings that will come in once we're done with our interfaces work and the core OO layer is stable (not changing/breaking), so that language will get added. given the range of languages above and Python I think that means that adding more languages shouldn't be hard as most core concepts have been covered. Just FYI on "pick up favorite language and write cross-platform app".

daurnimator10 anni fa

> LuaJIT bindings

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?)

rasterman10 anni fa

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

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?

daurnimator10 anni fa

> well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

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

rasterman10 anni fa

node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.

daurnimator10 anni fa

You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway?

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?

rasterman10 anni fa

well we already did the integration. it doesn't need exposing. it's meant to be handled by the bindings for that runtime environment specifically or is just always available. so it merges currently with glib mainloop and with libuv so if you run the ecore mainloop you ALSO have (optionally as long as efl is compiled with these) a glib and a libuv loop too merged together as one, so they all are then compatible and work at the same time. yes - it requires the app spin up the ecore mainloop (it actually is the efl.loop now) instead of another, but existing code that uses the 'native mainloop' for that runtime will continue to happily work just as it was working before in that runtime env, but as lua never provided a mainloop, then we're it along with glib if you want and/or libuv. the integration is done down in the c code for the efl loop. for lua there IS not native mainloop as there is no native lua runtime (beyond a sample lua cmdline), and by this i contrast it to something like node.js. we provide one (elua) that will load in the bindings stubs for you and thus work. we do this because lua itself unlike something like node.js or python doesn't push the idea of "a single lua executable to run all lua runtimes". it has demo/sample/test executors, but it is built as a library primarily to then be embedded into another runtime. we happen to provide a guaranteed runtime binary too.

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.

daurnimator10 anni fa

> but as lua never provided a mainloop, then we're it along with glib if you want and/or libuv.

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.

rasterman10 anni fa

> 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.

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.

daurnimator10 anni fa

> 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.".....

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.

mushiake10 anni fa

smoke/kde was supposed to be contender for gobject-introspection, however it is barely maintained.

It is only(?) used by common lisp[0].

And there was claro[1].

[0]https://github.com/Shinmera/qtools

[1]https://github.com/Araq/Claro

daurnimator10 anni fa

It too seems to be stuck on Qt4.

Only python bindings seem to have made it up to Qt5.

ufo10 anni fa

> Qt is almost impossible to fully bind.

You know a system is hard to write bindings for when noone is able to create Lua bindings for it.

a3n10 anni fa

> Most people who care about their desktop have migrated or are migrating to OSX

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. :)

idle_zealot10 anni fa

While I also prefer a tiling WM, the fragmentation of desktop environments still managers to affect me. Despite an abundance of options for basic applications like file managers, everything I've tried leaves something to be desired, often something that another option gets right. If developers would focus on just a few choices with incompatible philosophies, even people who didn't use their DE would benefit.

qznc10 anni fa

I live in terminal and browser almost exclusively, but I still want a full desktop environment. I switched to Mate on my old laptop, because Unity and Gnome3 need to much resources. I tried others (XFCE, LXDE, ...) but they lacked little features like:

* 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.

majewsky10 anni fa

> * hibernate when closing lid

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.)

ac2910 anni fa

>(XFCE, LXDE, ...) but they lacked little features like: * hibernate when closing lid * cpu/mem/network visualization in top/bottom bar * clean theme without much fiddling * mute/unmute via hardware button

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.

digi_owl10 anni fa

On my desktop i have a mute key on the keyboard, and it shows up in X11 as a special key. From there i have set the XFCE keyboard manager to run some ALSA commands on pressing it to toggle the mute state of the master volume control.

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).

wott10 anni fa

My personal conclusion is always the same: I always come back to Windowmaker. Every single time I use another DE, no matter how shiny it is (and they are truly beautiful when you open them for the first time), I face half-baked applications, many bugs, and basically half of the stuff is fucked up with each update.

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.

digi_owl10 anni fa

Been poking at Icewm for a similar reason.

And now i wonder about the state of Afterstep...

sho_hn10 anni fa

> 2016 was the year the Linux desktop died

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.

scrollaway10 anni fa

Please, please don't take this the wrong way because, even if I personally don't like the direction KDE has taken, I have a lot of respect for the project...

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.

sho_hn10 anni fa

> 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".

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.

asoltesz10 anni fa

A agree with your metrics and your conclusions as well.

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.

zaggynl10 anni fa

Thanks for all the work, love Plasma on openSUSE Tumbleweed so far, keep going!

nabla910 anni fa

This may be silly question but what is behind the interest of developing new Linux desktops?

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.

fredmorcos10 anni fa

> 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.

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.

scrollaway10 anni fa

So, you quite clearly know absolutely nothing about the situation LXQt was in, yet here you are telling me what I should have done?

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?

asoltesz10 anni fa

Collaboration like this is really great.

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.

majewsky10 anni fa

> As an example, instead of starting another desktop project (lxde, razor-qt, lxqt), some could have contributed to or collaborated with xfce.

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.

fredmorcos10 anni fa

Absolutely, but you'd be a nice guy if you factor out the essential and common parts into C libraries, so that others can make use of it as well (from any language and framework) which increases collaboration and decreases fragmentation.

Some might see the need for C libraries as evil and unnecessary (I personally don't), but it's the situation we're in.

vamur10 anni fa

According to Netmarketshare Linux is now above 2%. And if ad-blocking users are accounted for numbers should be close to 3%. Additionally, the number of games for Linux on Steam is about 2700 and should be 2800 by the end of the year. So Linux desktop is anything but dead. It will obviously remain a niche for a long time but that is not an issue as long as it is a viable alternative to Windows and OSX.

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.

anothermouse10 anni fa

I've been watching this happen like a scheduled car crash for years. Every 2 years, another open source project succumbs to the problem.

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.

digi_owl10 anni fa

Yeah, for all the derision Microsoft gets for their buggy code we can still use a Win32 binary from the 3.1 days today.

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.

crazyloglad10 anni fa

Guessing wildly:

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?

digi_owl10 anni fa

Nokia actually tried using "desktop" Linux on the mobile (Maemo), but i fear the result was that they set of a CADT that has lead us to Wayland and all that churn.

lj310 anni fa

Desktop Linux has bigger issues than UI toolkits. That's probably one of the reasons why you're having difficulty getting developers interested. I, personally, wouldn't contribute any time to a UI toolkit or desktop environment until some of the more egregious problems facing the linux desktop get resolved, if they ever can be.

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.

toyg10 anni fa

> it can't get more users without better drivers

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.

lj310 anni fa

> Drivers on Linux have always been like this, that's not the issue.

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.

toyg10 anni fa

> OS X is a Linux based operating system that fixed this issue

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.

digi_owl10 anni fa

> and tomorrow someone at RedHat might decide the audio stack should be rewritten for systemd

I can see it already, make pulseadio depend on logind under the banner of making audio device access "more secure".

pjmlp10 anni fa

Windows desktop is doing just fine on the enterprise.

Lots of projects delivering WPF and Qt based applications, for those after them.

brusch6410 anni fa

Which audio cards do you mean exactly ?

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.

lj310 anni fa

You name it, I've had issues with it. From the Intel audio card in my Thinkpad w530 to the Creative Soundblaster in my radio station's automation tower. I've never used a USB audio interface with Linux, but bluetooth audio on linux has a massive delay. In fairness, that delay is also present on OS X. For whatever reason, Windows is the only OS that will stream audio across bluetooth in real time.

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.

brusch6410 anni fa

okay ?

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.

digi_owl10 anni fa

In large part because WinTel has driven the consumer computing margins so low, that OEMs have to rely on bundling to actually make a profit.

aban10 anni fa

I read this thread and the issues you and others talked about hit too close to home.

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.

majewsky10 anni fa

> especially disappointed with the clusterfuck KDE has become...

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.)

pzone10 anni fa

I was a bit surprised by that line as well. I mean of course KDE is going to be behind GNOME in general since it is a bit more volunteer centric with less corporate funding, but I don't think it's in bad shape at all, and it is my preferred desktop environment. Many individual KDE projects are open-source gems. (Krita, Kdenlive, Dolphin, KDE Connect)

majewsky10 anni fa

KDE Connect is easily the one desktop application that adds the most value for me in day-to-day use, on the scale of "How could I ever live without this?"

(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.)

macco10 anni fa

Your so right. The fragmentation of the Linux desktop is the reason I think Linux will never play a bige role on the desktop.

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.

Jean-Philipe10 anni fa

I agree - but on the other hand, I feel desktop is in a bad place in general. I'm a regular macOS user and I miss the Linux days, will probably install Linux on my Mac again. macOS incredibly glitchy and unstable (at least for me), and I'm not happy with the usability either. Windows doesn't look like a valid option at all to me. Had to use Windows 10 to fix some bugs the other day. No.

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.

asoltesz10 anni fa

I have the same experience with macOS as you (Java/web developer here). I find it quite unintuitive and generally lacking in the usability department. E.g.: it is a joke that I cannot deactivate the global menu and I also cannot place the global menu on both of my monitors without making the monitors separate desktops. I find this "our way or the highway" mentality of Apple quite repelling.

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.

pjmlp10 anni fa

This is why I went back to Windows and sadly look back with hindsight to my GNU/Linux desktop days as time lost where I could have instead have taken advantage of my game development skills, instead of switching between desktops and graphic libraries all the time. When I started using GNU/Linux SVGALib (using root) was the only API available.

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.

mlinksva10 anni fa

Thank you for initiating the merger. I admired that because I agree fragmentation is a big problem -- http://gondwanaland.com/mlog/2013/10/22/open-source-prolifer... -- and the Linux desktop is a prime example. Clearly more mergers are needed.

digi_owl10 anni fa

Best i can tell, this has come to be because XDG/Freedesktop stopped being about specs and became all about code.

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...

bemused10 anni fa

maybe focusing the generation perspective on the tech involved can help with moving this forward - as much as I'd like to contribute to a sane linux desktop in general (and LXQt is definetely the most promising one atm), theres no way I go back to write c++ based 'old school' UI-code anymore. I think for writing UIs you really want the flexibility of a declarative approach - haven't kept up with QML lately but v1 wasn't that great, same with gtk.Builder. people are not shipping a bloated copy of chromium in their apps without reason: we got so used to the power these monsters of layout engines offer, that people think its worth it! even though there still is no decent set of UI-widgets/components for the browser .. (something that can compete with QT or GTK with accessibility etc build in)

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)

pjmlp10 anni fa

The major difference between QML and the UI approaches from Oracle, Apple, Google and Microsoft for their layout engines, is using a JavaScript variant instead of XML, but the spirit is the same.

crudbug10 anni fa

I totally agree.

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.

n3storm10 anni fa

Same old song, pal. I have been using XFCE since long time ago, no big changes, very few bugs, no bloat, no propaganda or vaporware. It's solid, it works, it's light on resources, it's configurable (I have made mine look like Mac OS 9 and BeOS).

I just hope (crossing fingers) moving to GTK3 doesn't mean visual bugs.

n3storm10 anni fa

Also, I added compton for candy effects. It would be great if XFCE integrated compton or more compositing features, but not absolutelly necessary.

alphapapa10 anni fa

Well, I'm glad to hear someone like you (a DE developer) say these things. GNOME went off the rails years ago, and KDE seems to be headed that way with KDE 5 (or is it Plasma 5? or Frameworks 5? or...? Just KDE 5!).

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.

scrollaway10 anni fa

> 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.

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.

alphapapa10 anni fa

> 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.

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! ;)

[deleted]10 anni fa

aq3cn10 anni fa

It seems like you don't watch Unix porn (http://imgur.com/r/unixporn).

bratao10 anni fa

Could you please explain what the state of KDE ? I always cheered for them, because I was a big fan of Qt

scrollaway10 anni fa

I'm being a bit unfair on KDE. Their efforts on Frameworks are excellent. Kwin especially is an amazing thing. But as a desktop, it's a disaster. Bloated, awful UX. Nearly every "core" app basically depends on the entire desktop, which makes them unusable outside of it.

Bleh.

pferde10 anni fa

Correction: their efforts _used to be_ excellent, and I've been a big fan since KDE2. But lately, the whole plasma desktop feels like it will topple over and fall if I so much as look at it funny.

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.

scrollaway10 anni fa

Please don't hesitate to email me (jerome at leclan dot ch) if you are interested in contributing to LXQt. Any help is appreciated, even if you can dedicate a few hours a month.

kitsunesoba10 anni fa

Those have always been a big turnoff for me, too. On top of that, I've never liked KDE's UI design; parts of it come off as overcrowded while others have oddly distributed whitespace and the lack of flowing lines and symmetry in its control layout give a chaotic feel. From this perspective, I feel the gnome guys are doing a much better job even if they comically oversize many UI elements.

[deleted]10 anni fa

starky10 anni fa

The structure of Linux is really its worst enemy, having everything be a separate package results in a terrible end user experience, exacerbated by the developer fragmentation you mention. The only way to get a good looking and usable system is full top to bottom integration of the entire desktop environment. There are a few that try, but in the end you are running GTK and/or Qt, both of which are hideous and stick out like a sore thumb against anything well designed.

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.

dvdkon10 anni fa

What's wrong with Qt? Apart from how big it is, I think it's the best GUI toolkit around.

red_admiral10 anni fa

How much of this is due to fragementatation/walled-garden mentalities, and how much due to issues with the C++/OOP-style API that most GUI/widget toolkits seem to share? With fragmentation as a consequence of everyone exploring their own solution to a genuine problem.

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.

aq3cn10 anni fa

Since when I have switched to i3 window manger, I am totally enjoying it. It's minimal, fast, keyboard centric and perfect for computer with small screen size.

https://i3wm.org/

lsh10 anni fa

If we're shouting out to our favourite window managers, then a long, long time ago I switched to ion3 and then for a long long time it was left unmaintained until Notion (not-ion) came along:

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.

sudhirkhanger10 anni fa

Any of you use a lightweight desktop environment like on high end expensive system. Why? Does it matter if you end up using lightweight desktop environment on a low end system and end up using resource intensive apps on top of it?

int_19h10 anni fa

Those things aren't lightweight only in the matter of resources used - they're also lightweight in how much attention they demand when interacting with them. Some people just want a simpler flow with less overhead.

pferde10 anni fa

Less space for the DE's configuration to get screwed up and start getting in your way.

majewsky10 anni fa

I tend towards lightweight anything just because I'm so fed up with the ridiculous complexity all around us. I take pride in understanding what every process on my systems actually does, and why it is necessary.

Lightweight anything is also a good idea security-wise (reduction of the Trusted Computing Base).

qznc10 anni fa

I recently switch to Mate (the Gnome2 fork), because it requires less memory than Ubuntu Unity and Gnome3. My old laptop has 4GB RAM it I often its the limit when compiling stuff and maybe running a VM.