You are not logged in.
I was thinking about forking XFCE and rewriting it's graphics in Qt. The reason for this is that after GTK4 was announced, the list of removed features included menus. They explained their reasons here.
These widgets were heavily relying on X11-centric concepts such as override-redirect windows and grabs, and were hard to adjust to other windowing systems.
Menus can already be replaced using GtkPopoverMenu in GTK 3. Additionally, GTK 4 introduces GtkPopoverMenuBar to replace menubars. These new widgets can only be constructed from menu models, so the porting effort involves switching to menu models and actions.
Tabular menus were rarely used and complicated the menu code, so they have not been brought over to GtkPopoverMenu. If you need complex layout in menu-like popups, consider directly using a GtkPopover instead.
Since menus are gone, GtkMenuButton also lost its ability to show menus, and needs to be used with popovers in GTK 4.
They basically said that both context menus and dropdown menus are outdated X11 "concepts", despite the fact that even android supports them. It's clear that GNOME is going to make it difficult for anyone who plans on using GTK to make an app that doesn't match Adwita's design rules, so I think XFCE would be benifit from dropping it as soon as possible. The main reason I came to this forum was to ask:
Would anyone be interested in helping?
What are your opinions on this idea?
Is there any chance that this could get merged with XFCE?
I haven't actually started this yet because there's still a small chance that everyone will tell me this idea sucks, so I'll wait untill I get some opinions on it first .
Offline
Hi and welcome to our lovely forum!
Would anyone be interested in helping?
What are your opinions on this idea?
Is there any chance that this could get merged with XFCE?
I haven't actually started this yet because there's still a small chance that everyone will tell me this idea sucks, so I'll wait untill I get some opinions on it first .
This forum is mainly for support questions and casual discussion within the community. All of the development work takes place in Xfce's Gitlab instance.
If you like your own idea and it scratches your itch; sure, why not? However, I doubt it'll get merged. Again, you need to open an issue and propose your own implementation for it to have a chance of succeeding. You might also wish to send a message to the xfce4-dev mailing list, or join #xfce-dev on Libera.
Thanks for joining us.
Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!
Offline
Hi!
This forum is mainly for support questions and casual discussion within the community. All of the development work takes place in Xfce's Gitlab instance.
Ok, thanks!
Offline
A couple of things you might want to investigate:
1. I think the developer of Xfce Terminal has created a library that can be used by any Xfce application. It contains UI elements (CSS classes) that have been removed from gtk4. I believe the current stable version of Xfce Terminal already uses menu bar, right-click menu etc. from this library. You probably wouldn't notice it since current gtk3 themes support these CSS classes.
The Xfce Terminal dev did a video that I watched, but I haven't looked at the actual code on Xfce GitLab.
xfce4-terminal: Development version 0.9.0 showcase
https://www.youtube.com/watch?v=tVoAYXW-tbs
2. There is a guy on the Ubuntu MATE forum who wrote he is creating C bindings for Qt. This should make it a lot easier to port something written in C to Qt.
https://ubuntu-mate.community/t/horribl … 4/22028/90
Offline
Thanks. Actually, I was the guy who made the Qt bindings for C on that other forum. i haven't worked on them for a long time though.
The menus and menubars are just one part of the bigger problem. GTK will continue to remove features until everything looks like GNOME, complete with client-side decorations (CSD) and hamburger menus. The worst part is that it looks like it's working, since XFCE has now started using CSD.
Offline
The menus and menubars are just one part of the bigger problem. GTK will continue to remove features until everything looks like GNOME, complete with client-side decorations (CSD) and hamburger menus. The worst part is that it looks like it's working, since XFCE has now started using CSD.
You are not wrong, but...
Is the glass half full?
Is the glass half empty?
Or is the glass simply too big
We might all die someday, but we don't have to die today. Xfce might die someday, but not today. I feel pretty good about Xfce right now. Xfce 4.18 looks like it will be a good release. I think libxfce4ui-nocsd will be baked-in with a GUI switch. Choice is good.
Yes, there are many problems in Xfce. I still feel there is more "accessible" functionality in Xfce than in any other desktop environment. The main limitation is the toolkit despite CSS giving a lot of possibilities. I'm not sure Qt is the answer. Qt tends to be a little laggy and buggy in my opinion.
That being said if I one day feel that Xfce has become a wreck, I would probably switch to LXQt. They have a clear focus although the switch from Qt5 to Qt6 might stall it for a while. Qt does have fractional scaling built right into the toolkit and this is now exposed in LXQt. Sadly gtk doesn't have this capability at the toolkit level.
This is pretty interesting. (Maybe when no more X.org drivers are created you can use a Wayland layer as hardware abstraction?). Using Trinity desktop or Compiz window manager in the 2030s should be doable this way.
While XWayland is normally used just for running root-less single applications like games within an otherwise native Wayland desktop, new patches from Red Hat that have been merged into the X.Org Server enhance XWayland's existing "root-full" mode of operation for allowing entire desktop environments and window managers to nicely function within the context of XWayland.
Red Hat engineers Olivier Fourdan and Adam Jackson have been discussing XWayland "rootfull" enhancements in recent weeks and the fruit of that work has now been merged. Via the X.Org Server issue tracker has been the discussion for the past two months over improvements to the XWayland rootfull mode for legacy X11 environments.
Some of the patches merged today clearly spell out: "This is useful when running a complete desktop environment within Xwayland rootful."
Offline
Xfce might die someday, but not today. I feel pretty good about Xfce right now.
That's true, but if XFCE continues to allow GNOME to puppet-string it with GTK, then it will be too late to stop XFCE from dying sooner than it has to. XFCE and MATE are both slowly adapting to GTK4's forced GNOME designs. If we just let it happen, there will almost certainly be a dark-ages where the only good desktop environment left is LXQt for years untill new ones appear or XFCE/MATE swich to another toolkit (which could be a fork of GTK, or Qt, or a toolkit from the future, or anything but gnome's GTK).
What I'm trying to say is that XFCE doesn't have to die when GTK kills every desktop environment using it. We could *save* XFCE by switching to something else.
Of course, positivity's never a bad thing .
I'm not sure Qt is the answer. Qt tends to be a little laggy and buggy in my opinion.
I'm guessing that you tried KDE and didn't like the animations and delayed desktop-icon selection, but this isn't how Qt normally looks. Maybe give LXQt a try to see what I mean. From what I've seen, Qt is actually faster than GTK.
Offline
I have used LXQt and it's good. It's probably 5 - 10 years behind Xfce in terms of features (depending on how many work on it). There are occasions when panel configurations and theming won't update in LXQt without a new login. From every Qt application I have tried on any platform my takeaway is that "settings" don't update as quickly as in gtk. I'm not talking about gtk on Windows here, because that's not relevant.
The most requested feature for LXQt is probably "Whisker menu". I believe Whisker menu is a C++ application. If you have what it takes port it to LXQt (I believe someone tried porting it to MATE, but apparently not that easy). Xfwm works very well with LXQt so no need for porting there. If I had Whisker menu and Xfce Places panel plugin in LXQt then I wouldn't miss that much from Xfce. But it would be a step down nevertheless and that's probably why you started this thread.
You haven't stated your reasons for not joining LXQt development, but a Qt fork of Xfce seems like a moon shot when LXQt is already up and running. LXQt has a working panel so "XfQt" could be created by porting Xfce panel plugins to LXQt panel.
The problem for LXQt is that there is probably not that much feature development right now. Qt port to Qt6 and Wayland compatibility probably account for most dev hours.
LXQt is nice, but it needs features to be comparable to Xfce. I'm not a programmer, but to me it seems LXQt is the obvious choice for someone wanting a Qt environment comparable to Xfce. I'm conservative and I don't believe porting desktop environments is a good idea. Trinity forked Qt3 and it probably bites them in some ways, but porting Trinity to newer versions of Qt would probably be a mess.
I will ride gtk3 into the sunset and then I come to Qt if the sun rises another day.
TL:DR Porting features to LXQt should be easier than porting Xfce to Qt. This I say as a non-programmer, happily aware that I don't need to wrestle with this. Much of what we have in FOSS is the result of "developer's itch". Taking on large projects isn't the ideal way of developing FOSS. Corporations sometimes do it, but not even with paid devs can the outcome of a big project be assured.
Offline
The reason I'm not working on LXQt is because I believe it's already doing great. It might not be as advanced as XFCE in some areas (although I'm not sure which exactly), but this isn't too much of a problem thanks to package managers. I just think that GNOME has been holding back the entire Linux desktop ecosystem for way too long. I'm hoping that both XFCE and MATE can eventually move away from GTK, and I came here because I think XFCE has a better chance of doing that since MATE was created to be as similar to GNOME 2 as possible.
I don't think this is a large project because of how easy Qt is to develop with. For reference, this is Qt program that displays a button in a window, and this is a GTK program that does the same thing. In fact, I've started working on a Qt version of mousepad about 4 hours ago and judging my what I've done so far, I think the rest won't even take a week to finish.
(PS: MATE has actually had a whisker menu for quite some time now, and I think LXQt may have also improved a bit since last time you may have seen it.)
Offline
Hey, I see that this turned into a full-on discussion on the mailing list. Good.
I'd like to share my point of view, if it matters. I disdain Qt. If I wanted it, I'd probably just switch to KDE or LXQt, but I don't and I'm not even going to bother looking at Xfce if it ever goes Qt. I could be wrong on many things about it, just like you are about GTK, which is fine. It's worth mentioning that I also dislike many features of GTK, or rather the fact that they always seem to get rid of a few useful ones in favor of "new, shiny" widgets. I hate CSD as much as your average Joe, but I also hate menu bars. Whatever GTK came up with isn't ideal but works.
You and I may have our own exaggerated, dramatized opinions and views, however, what users think is a tad bit more important, I think. I'd suggest to always keep that in mind. It's ultimately the users that decide if a feature is worth implementing, or at least, that's how an ideal scenario plays out.
With all that said, I'm not against your idea. I encourage you to fork, bring a couple of more people to your cause, work on it together and then hand it on a silver platter. At worst, you will have tried at least. At best, you succeed and will be left satisfied. Just remember that "GTK bad" only doesn't warrant a massive overhaul.
Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!
Offline
Hello KBar, and thanks for sharing.
A lot of people have been saying that they don't like Qt, but no one ever gives any reason why. Can someone please just tell me why everyone on this forum hates Qt so much?
(EDIT: This wasn't supposed to be as rude as I'm just realising it is. Sorry)
Last edited by sfammonius (2022-07-10 00:21:01)
Offline
Let me quote myself from another post on another site:
"I really like Qt5 apps, but for a DE there is something about the "to the metal" feel that gtk offers that I don't get from Qt. Gtk is instant and changes take effect immediately."
I already wrote basically the same thing in this thread, but you didn't believe me. For what it is worth; Featherpad is my preferred text editor.
The thing that bothers me is that I can't take you seriously. You say you want to port Xfce to Qt. If you mean the whole DE then this is a 5 year job for two professional full-time devs with a few hobby devs as backup. Yes, you do have to worry about quality. That's the whole point of porting something.
Ask the Xfce devs about the workload porting Xfce from gtk2 to gtk3. You should also research the trouble PCMan had porting his file manager from gtk2 to Qt5.
Maybe you have an ace up your sleeve with your Qt bindings for C. They are unfinished and experimental, but if you can pull that off then you have done more than can be expected from a single dev. That can easily turn into a full time project if you want to keep them updated and working.
The LXQt devs are talented and do good work. They have already ported "50 % of Xfce" to Qt. You want to start from scratch. That could be seen as a sign of insanity. I don't think you are insane, just unrealistic.
There are lots of things that never need to be ported: Xfwm, Thunar, Mousepad and every other Xfce application. Why? They already work perfectly fine in other desktop environments. I hardly use any Xfce applications and I still consider myself an Xfce "fanatic" because of the Xfce panel/plugins and some nice "extras" like Settings Manager and Xfwm.
The thing about Xfce is that it is the best designed DE. I don't understand what is going on under the hood, but the fact that Xfce can do updates of specific components without breaking tells me modularity and UNIX design principles are at work. LXQt is also nicely designed with a few shortcomings, for example the file manager PCManFM-Qt handling the desktop. I'm not a big fan of PCManFM-Qt, but does it really matter what file manager is default when any file manager can be used?
*The only things you really have to port are panel plugins.* When I suggested Whisker menu you compared it with some other menu. If Whisker menu isn't important to you, why is Xfce important to you? You can use Thunar in LXQt, but you can't use Xfce panel in LXQt. That's why you have to port all the Xfce panel/plugin functionality to LXQt. After that you are basically done, but this is no small task. I say at least five years for one unpaid dev. Remember, it's all about quality.
*It would be a very bad idea to try to port full Xfce to Qt.* If you don't believe me, ask the LXQt devs. On the other hand if you tell the LXQt devs that you want to port some panel plugins to LXQt panel then it's just a bonus for them. As long as you use Qt Widget of course. No Qt Quick or Kirigami in LXQt. LXQt is fully based on Qt Widget and can be fully themed by this toolkit.
Last edited by File Manager (2022-07-11 23:27:45)
Offline
I realize that there's a few things I should have clarified first.
I never said I wanted to make it "from scratch". I will be very careful not to rewrite code that LXQt or KDE has already written. For example, text highlighting in Mousepad would be something that I would use FeatherPad's code for.
I hadn't taken panel plugins into consideration. I will try to port the most important ones and the whisker menu, but I doubt I'll finish all of them.
I only want to port the visual appearance, not the core libraries. You're saying that XFCE apps are the thing that I won't need to port, but I'm pretty sure they're the only things I'll need to port.
About the QTC bindings, the reason I haven't made much progress in them recently is because I'm stuck on the event system. It's so complicated that I can still barely wrap my head around it, so I don't think I'll be able to explain it too well. I also realise that there's much more to Qt than it's widgeting system, and even though that was all I had been planning on binding, all of it's other systems are integrated with each other and I keep finding more and more parts that would have to be binded. I want to get back to that project eventually, but It would take years to finish and I don't see why I can't just use C++ for this considering that XFCE's apps aren't really that integrated with each other.
Also, I don't think the time it takes to update themes is Qt's fault. KDE's system settings, LXQt's appearance settings, and Qt5ct all take different amounts of times to apply the themes. I think this is because those apps are applying all the settings (font, colors, style, platform theme, and maybe others). When I get to XFCE's settings manager, I'll try to make the theme switcher as fast as possible.
Last edited by sfammonius (2022-07-10 00:24:37)
Offline
You're saying that XFCE apps are the thing that I won't need to port, but I'm pretty sure they're the only things I'll need to port.
You know if you had written that you want to port some Xfce applications to Qt then my entire approach to this thread would have been different because it would have been a totally different topic. We have basically been discussing two different things this entire thread...
"Would an XFCE Qt fork be a good idea?" - I wish the word "application" had been part of this thread title.
If you want to port Xfce applications to Qt then I think you will be able to do just that.
Offline
If you want to rewrite some apps to Qt and C++ I can help you.
Offline
I am using Xfce for two simply reasons. Lightweight DE & GTK+.
My all timeline on Linux have been on GTK. Ofcourse, for testing i tried distros with KDE, but i don't find myself aesthetically in QT.
Devuan/XFCE
Offline
If you want to rewrite some apps to Qt and C++ I can help you.
That would be great! You might want to start with a small app to get warmed up, and those are listed here (I've already started on mousepad). Aside from the apps, we also eventually want to port the greybird theme as a QStylePlugin, so you could try doing that if it sounds interesting.
I'm really stuck on the build system though. I have absolutely no idea how to use GNU Autotools, and I'm not even sure if I should use it as opposed to qmake. What should I do?
Offline
I am using Xfce for two simply reasons. Lightweight DE & GTK+.
My all timeline on Linux have been on GTK. Ofcourse, for testing i tried distros with KDE, but i don't find myself aesthetically in QT.
Part of the plan is to make a Qt style to match greybird, so that no one feels akward using the Qt port. You might also want to try using the Oxygen style, cuz I think it's awesome .
Offline
I'm really stuck on the build system though. I have absolutely no idea how to use GNU Autotools, and I'm not even sure if I should use it as opposed to qmake. What should I do?
I'd suggest joining #xfce-dev on Libera and ask from fellow developers. Set up a bouncer if you can, as it will allow you to throw your question out and remain offline. When you come back and connect to your bouncer, it will present you with the log of all messages since you were absent.
Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!
Offline
sfammonius wrote:I'm really stuck on the build system though. I have absolutely no idea how to use GNU Autotools, and I'm not even sure if I should use it as opposed to qmake. What should I do?
I'd suggest joining #xfce-dev on Libera and ask from fellow developers. Set up a bouncer if you can, as it will allow you to throw your question out and remain offline. When you come back and connect to your bouncer, it will present you with the log of all messages since you were absent.
Thanks. I have no idea how to use IRC though, so I'll just use the mailing list.
Offline
ppitu wrote:If you want to rewrite some apps to Qt and C++ I can help you.
That would be great! You might want to start with a small app to get warmed up, and those are listed here (I've already started on mousepad). Aside from the apps, we also eventually want to port the greybird theme as a QStylePlugin, so you could try doing that if it sounds interesting.
I'm really stuck on the build system though. I have absolutely no idea how to use GNU Autotools, and I'm not even sure if I should use it as opposed to qmake. What should I do?
I work with orage app and rewrite it`s view. So maybe we can start from this?
Offline
I work with orage app and rewrite it`s view. So maybe we can start from this?
Ok. I've made a new organisation on GitHub called xfce-qt, and I made a new repository for Orage and mousepad so far. The link for the Orage repository is here, so you can just send a pull request once it's finished. The pull request should include the 2 files that are already in the repository, and an AUTHORS file where you can add your name (or username).
After the code is done, I'll add the gettext translations and CMake build system, and then we'll be done!
Quick reminder though: add the following lines right after initiating the QApplication:
QCoreApplication::setOrganizationName("xfce4-qt");
QCoreApplication::setOrganizationDomain("xfce4.org");
QCoreApplication::setApplicationName("orage"); // or whatever the app name is
This will help with QSettings and possibly QtDBus in the future. The reason organization name is set to xfce-qt is because settings it to just xfce could interfere with GTK xfce apps and possibly break them both. Later, we'll revisit the code and make the organization name depend on a macro that can be configured during the build process.
Last edited by sfammonius (2022-07-12 11:47:13)
Offline
To everyone: Sorry if this is a strange question, but I'm terrified about the idea of finishing this and then having it ignored forever. Is there any way I can actually contact the XFCE maintainers to ask them weather they would be willing to merge the Qt versions?
Last edited by sfammonius (2022-07-14 16:48:31)
Offline
It would be harder for them to agree to something unseen. Show them something attractive, that works, and enjoy the ride either way.
Just my unwashed opinion.
Last edited by eight.bit.al (2022-07-14 19:46:17)
Fight against surveillance capitalism.
Offline
It would be harder for them to agree to something unseen. Show them something attractive, that works, and enjoy the ride either way.
I'm thinking the same thing, but the developers might not be. They might say "make it first, and we'll consider it if it's good" or they might say "we'll stick with GTK no matter what". I just want to make sure since I know this will take a long time to make.
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 697.62 KiB (Peak: 746.46 KiB) ]