Xfce 4.12 Planned For Release In A Few Weeks

[enihcam]

Well I think this is the biggest problem with a lot of free & open source programs/apps - lack of manpower, or to be more precise to many different apps doing the same with little to no differences :/

Am I the only one who is waiting for Xfce merging with LXQt?

[Steve DL]

Am I the only one who is waiting for Xfce merging with LXQt?

Yes... I don't see why we would merge a perfectly good DE, with so many users who appreciate it for being exactly what it is, with LXQt. Elementary, Cinnamon or MATE would probably be more logical choices, besides.

[eidolon]

Am I the only one who is waiting for Xfce merging with LXQt?

I have no interest. Let Xfce be Xfce, and let LXQt be LXQt. The LXDE and Razor-qt merger was apropos once Hong Jen Yee made the determination that LXDE was moving to Qt. Even if Xfce moved to Qt (and I wish Xfce developers would take a long, hard look at which current toolkit is going to best meet Xfce's cholesterol-free needs), I don't think that "Qtce" and LXQt would make for a good project match. From a logo perspective, the Q could make for a nice hamster wheel for the mouse to run in though. But all present indicators are that GTK+ 3 is the direction moving forwards.

[Steve DL]

I have no interest. Let Xfce be Xfce, and let LXQt be LXQt. The LXDE and Razor-qt merger was apropos once Hong Jen Yee made the determination that LXDE was moving to Qt. Even if Xfce moved to Qt (and I wish Xfce developers would take a long, hard look at which current toolkit is going to best meet Xfce's cholesterol-free needs), I don't think that "Qtce" and LXQt would make for a good project match. From a logo perspective, the Q could make for a nice hamster wheel for the mouse to run in though. But all present indicators are that GTK+ 3 is the direction moving forwards.

I can feel the potential PR drama in making any announcements about which toolkit we'll port to... Truth is I don't think we haven't had a serious chat and made a binding decision yet (but I occasionally miss discussions so don't quote me on this ). Most developers seem ok with using GTK+3, even though that means solving a few challenges and accepting a few things we might dislike. It certainly seems a lower cost and disruption than moving to Qt though.

My personal opinion, which only engages me and I should point out that I am not in charge of big decisions, etc, don't start a flame war, etc, is that we should move to something else. I personally think LXQt looks horrendous (both in terms of theme and layout), and even though I love writing Qt code we'd have to make our own UI components to make Xfce look the way we like it. We'd probably waste a lot of time. At the same time I don't like at all the fact that GTK+3 makes design decisions which can badly interfer with our DE based only on GNOME or Red Hat's immediate needs. I understand why things are that way but I don't like that. So right now there isn't a toolkit that I feel happy writing code with for Xfce.

And on top of that, we don't even get to choose what we want to use. We need to go where the apps go and to ensure apps are compatible with our DE, not the other way around. Most big cross-DE apps these days are written in Qt and purposefully made to look worse than vanilla Qt (hello Skype, hi LibreOffice, VLC when will you hire a UI designer??). They're not really standard Qt so us writing a Qt DE wouldn't make those monsters any more "integrated". Most apps used by Xfce users are written in GTK+2 and GTK+3, hence that makes more sense right now. We need to support GTK+3 vanilla apps, and because of the CSD decisions and full CSS-theming we already know we'll have a crapload of horrendous Linux apps in our users' desktops in the future and we can't do a thing about that, so we might as well keep things simple. There's no interest/point in us starting our own toolkit -- and ignoring GTK+3 is not a viable option either.

This being said, I look with great attention towards Papyros. I love the idea of using QML to provide nice, modern, HCI-theory-backed abstractions for user interaction. If it turns out that Material apps make their way to Linux, it might make sense to use a Material toolkit for our DE rather than GTK+3/native Qt. Only time will tell. In the meantime, it's up to the core Xfce devs to make viable decisions for the short-term future.

[eidolon]

I can feel the potential PR drama in making any announcements about which toolkit we'll port to...

A shocking return to XForms.

Truth is I don't think we haven't had a serious chat and made a binding decision yet

I took https://mail.xfce.org/pipermail/xfce...ay/029784.html & https://wiki.xfce.org/releng/4.12/roadmap/gtk3 as a solid indicators that resistance if futile.

We'd probably waste a lot of time.

I understand, and I'm not necessarily pushing Qt. I just hope the viable alternatives are investigated. I think there will be regrettable time (and other) costs regardless. Some paths lead me to believe that cost will be mostly upfront, while others seem more ongoing costly affairs.

So right now there isn't a toolkit that I feel happy writing code with for Xfce ... We need to go where the apps go and to ensure apps are compatible with our DE...

+1

So at some point third-parties will have to choose between supporting Xfce 4 and GNOME 3 (and the other [peers] :-) ).

My concern is that is a losing proposition.

[duby229]

Why would you assume the worst out of them? Most people I talk to in the GNOME ecosystem are mindful and helpful. I like the new GTK+3 widgets. I understand the drive for identity/change of GNOME and why they want to import good ideas from mobile UX into the desktop. I'm not a GNOME or Red Hat insider so I can't judge why they let their code break so often. I assume they are under big economic pressure to deliver mobile/convergent products for their clients, and if we're lucky enough to be writing Xfce for our own enjoyment, we also have no money and no wo/manpower :-) So I don't know what strategy is best for an individual project. I can tell though that I personally prefer releasing rarely, but releasing things that are finished. I guess that's why I didn't release new software in the past few years

No offense meant to you. I really like xfce as it is now.

It is a fact that GTK3 has broken multiple things many times. Seems like over and over again and again. It's not really GTK3 I don't like, It's the arrogant way that they develop it without any concern at all for breakage that I don't like.

[wizard69]

LXQT is still very much alpha software and KDE is bloated.
Cinnamon is the only modern DE that actually feels polished - shame it hogs memory though.

Better to hog memory and work then to run light and take for ever to do anything.

[duby229]

Better to hog memory and work then to run light and take for ever to do anything.

I'm pretty sure you got that backwards. It's almost always better to run run light, than it is to hog a resource and turn that resource into a bottleneck. If you thrash a HD, then the HD becomes a bottleneck, if you thrash RAM, then the RAM becomes a bottleneck. Bigger always takes longer.

[zanny]

even though I love writing Qt code we'd have to make our own UI components to make Xfce look the way we like it.

If you use QtQuick you can retheme all the controls almost entirely. With the one engine and several themers they make it look native on Android, iOS, Windows, OSX, and they make it use the KDE theme on Linux. Widgets would be harder, since the theming back end for that is actually an entire module for each OS target, so you would have to write a lot of code against QtWidgets to restyle them.

I'm pretty sure you got that backwards. It's almost always better to run run light, than it is to hog a resource and turn that resource into a bottleneck. If you thrash a HD, then the HD becomes a bottleneck, if you thrash RAM, then the RAM becomes a bottleneck. Bigger always takes longer.

What takes a lot of memory in KDE?

• Plasma - It runs a QtQuick JIT and maintains a sandbox for the apps it runs. Its at web-browser complexity in that regard, but usually only uses 200-300MB.
• Baloo - Its indexing every file on your computer, and you can turn it off. Consumes 50 - 500MB depending on how much stuff you got and how often you are using it.
• Akonadi - You can turn it off as well, and all its doing is running polling daemons against web accounts and maintaining databases for stuff like calendar events. If you don't use any of KDE-PIM you have no reason to even have it installed anymore.
• KWin - Can use a lot of memory when you have compositing and a lot of bells and whistles turned on. Just like any other compositor. With just Breeze and none of the transparency features enabled it only uses 75MB with over 2 dozen windows open on my 5.2 install.

And then I'd ask what takes a lot of CPU time? Besides the plasma shell starting everything else is synonymous across distros with any compositing window manager, and sddm is lighter weight than GDM or LightDM, but it will probably get bigger as more features are pulled over from KDM. Not like that is a bad thing.

Bloat implies waste. KDE4 did have some of that, features nobody used and configurations on configurations to the stars. KDE5 did curtail some of it (and sometimes in ways I don't like - you can't manually set date formats anymore, for example, so I can't put my clocks in ISO dates, and you can't resize Kickoff anymore, but at that the memory overhead of the applet seems to have gone from ~25MB to 5MB of ram usage when I enable / disable it on my two machines). Qt itself is inherently somewhat bloaty, because signals and slots add a lot of binary size on top of how C++ already generates pretty large binaries when you are using templates. But does binary size really matter if its all optimized code? The alternative is to not have compile time work being done through templates that you then end up doing at run time, slowing everyone else down to save some disk space.

[duby229]

If you use QtQuick you can retheme all the controls almost entirely. With the one engine and several themers they make it look native on Android, iOS, Windows, OSX, and they make it use the KDE theme on Linux. Widgets would be harder, since the theming back end for that is actually an entire module for each OS target, so you would have to write a lot of code against QtWidgets to restyle them.



What takes a lot of memory in KDE?

• Plasma - It runs a QtQuick JIT and maintains a sandbox for the apps it runs. Its at web-browser complexity in that regard, but usually only uses 200-300MB.
• Baloo - Its indexing every file on your computer, and you can turn it off. Consumes 50 - 500MB depending on how much stuff you got and how often you are using it.
• Akonadi - You can turn it off as well, and all its doing is running polling daemons against web accounts and maintaining databases for stuff like calendar events. If you don't use any of KDE-PIM you have no reason to even have it installed anymore.
• KWin - Can use a lot of memory when you have compositing and a lot of bells and whistles turned on. Just like any other compositor. With just Breeze and none of the transparency features enabled it only uses 75MB with over 2 dozen windows open on my 5.2 install.

And then I'd ask what takes a lot of CPU time? Besides the plasma shell starting everything else is synonymous across distros with any compositing window manager, and sddm is lighter weight than GDM or LightDM, but it will probably get bigger as more features are pulled over from KDM. Not like that is a bad thing.

Bloat implies waste. KDE4 did have some of that, features nobody used and configurations on configurations to the stars. KDE5 did curtail some of it (and sometimes in ways I don't like - you can't manually set date formats anymore, for example, so I can't put my clocks in ISO dates, and you can't resize Kickoff anymore, but at that the memory overhead of the applet seems to have gone from ~25MB to 5MB of ram usage when I enable / disable it on my two machines). Qt itself is inherently somewhat bloaty, because signals and slots add a lot of binary size on top of how C++ already generates pretty large binaries when you are using templates. But does binary size really matter if its all optimized code? The alternative is to not have compile time work being done through templates that you then end up doing at run time, slowing everyone else down to save some disk space.

It's too bad this forum can't nest quotes. If you look up, peppercats said cinnimon hogs resources, wizard69 said it was better to hog resources. Which is why I said it's not better to hog resources.

It is OK to use resources you need, but it's never OK to thrash them. A good design is always the lightest design. The trick to avoiding bottlenecks is to avoid touching things needlessly. The point is, if you don't have to do something for your design to work, then don't do it.