Originally posted by sgtGarcia
View Post
Announcement
Collapse
No announcement yet.
Xfce 4.12 Planned For Release In A Few Weeks
Collapse
X
-
Originally posted by enihcam View PostAm I the only one who is waiting for Xfce merging with LXQt?
Comment
-
Originally posted by enihcam View PostAm I the only one who is waiting for Xfce merging with LXQt?Last edited by eidolon; 09 February 2015, 07:50 AM.
Comment
-
Originally posted by eidolon View PostI 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.
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.
Comment
-
Originally posted by Steve DL View PostI can feel the potential PR drama in making any announcements about which toolkit we'll port to...
Originally posted by Steve DL View PostTruth is I don't think we haven't had a serious chat and made a binding decision yet
Originally posted by Steve DL View PostWe'd probably waste a lot of time.
Originally posted by Steve DL View PostSo 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...
Originally posted by Steve DL View PostSo at some point third-parties will have to choose between supporting Xfce 4 and GNOME 3 (and the other [peers] :-) ).
Comment
-
Originally posted by Steve DL View PostWhy 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
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.
Comment
-
-
Originally posted by wizard69 View PostBetter to hog memory and work then to run light and take for ever to do anything.Last edited by duby229; 09 February 2015, 12:47 PM.
Comment
-
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.
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.
- 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.
Comment
-
Originally posted by zanny View PostIf 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 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.
Comment
Comment