When we reported on the release of Xfce 4.8, we ignored a statement inside the release announcement about the lack of new features coming to the BSD world. The statement was a bit disconnected from the rest of the press release, but Xfce developer Jannis Pohlmann has published a blog post giving a few more details about the issue.
I did understand what the issue referred to in the Xfce 4.8 release announcement. Several new and modern lower-level frameworks are designed for Linux, with no equivalent available on the BSDs – let alone compatible ones. This development is of particular concern for developers that get the most use out of these frameworks, such as those working on desktop environments.
“As some of you may recall is that HAL, the hardware abstraction layer that has for the past few years been used for volume and power management as well as a few other things, has been deprecated and replaced by a variety of frameworks,” Pohlmann details, “Today there is udev for device information, udisks for volume management, upower for power management as well as ConsoleKit and PolicyKit for session and permission control.”
None of these fancy new frameworks work on BSD, since they are all designed to work specifically on Linux. The end result of this is that an environment like Xfce, which implements support for these, will have considerably reduced functionality when run on anything else. According to Pohlmann, this is seriously hurting the portability of Xfce.
“For 2-3 years now all this has been a big mess,” Pohlmann believes, “New frameworks were invented, dropped again, renamed from *Kit to u* and somewhere on the way it became impossible to keep Xfce as portable as it was before. I know that this is nothing new and that BSD folks faced the same situation as they do now back when HAL was invented but I don’t think it has to be this way.”
He is not aware of a solution, though, making it problematic for Xfce to be fully functional on BSD. I’m not entirely sure where I personally stand on this – after all, it is not the responsibility of Linux developers to take the BSDs into account. In the end, it’s the BSD developers’ task to provide the equivalent frameworks on their own operating systems.
Still, it would be nice if some sort of solution can be devised, since it’s a shame that the BSDs can’t enjoy Xfce to its fullest potential. Since I’m not entirely versed in this subject – how do GNOME and KDE handle this?
this is, uhm, news?
FreeBSD has had devd since 5.0 was released many, many years ago. This is a kernel-level, event-driven notification framework for hardware. Everything devfs, new-devfs, udev, HAL, new-udev, and udisk wanted to be … was already there.
It’s very easy to add a script to an ACTION stanza in /etc/devd.conf to do whatever you want (mount a filesystem, import images, start a hot-spare replacement in ZFS, etc). And /etc/devfs.conf covers setting users/groups/permissions on devices nodes as they are created by devd.
powerd has been available in FreeBSD since the 5.0 days, and handles CPU power management with a bunch of options.
All of the *Kits have been available on FreeBSD fairly soon after they’re available on Linux.
This is not an issue of “FreeBSD doesn’t support the features we need” and more an issue of “FreeBSD does things properly, without changing every 5 minutes, and we don’t know how to handle that”.
The correct “solution” here is for “desktop” devs to stop using the kernel features directly and having to continuously rewrite things for udev, HAL, *Kit, u*, etc and instead to write to a standardised abstraction layer with pluggable backends. Something the KDE devs figured out with 4.0 and the creation of Solid and Phonon and similar.
Maybe the freedesktop.org community should get together and work on this abstraction layer, and then let the kernel devs from Linux/FreeBSD/whateverBSD/Solaris/etc work on the backends. A nice decoupling of the “desktop env” from the “kernel/u*/*Kit backends”.
Either that, or all the desktop env projects need to remove things like “portable”, “for Unix-like systems”, “POSIX-compliant” and other such nonsence, and mark themselves as “Linux-only”.
Edited 2011-01-19 23:19 UTC
Uh, so you want a standardised abstraction layer with pluggable backends – so, HAL and friends, then? Because that’s *exactly* what those packages you’re complaining about are!
No, HAL was a piece of crap that re-invented the wheel on every platform it appeared. What the original poster was talking about is something similar to KDE Solid which provides an abstraction for developers away from concerning what the underlying operating system is.
The problem with that: it has been how long and there is still no FreeBSD backend for KDE Solid. Abstractions are all very nice but if there aren’t the people to implement the backends then the whole exercise is a waste of time.
There are backends for solid on all kind of platforms including OSX and Windows. Just because there is probably none for FreeBSD doesn’t mean the abstraction is unneeded.
Has KDE or FreeBSD dropped HAL support? If not, then that’s the BSD backend right there. Why would any KDE developer go to the extra effort of interfacing natively with the kernel when HAL is already supported? A BSD dev could do that of course, if they felt it was important enough.
Kawai touched on this as well, above.
In theory, HAL should have been perfect, in that it would be a portable abstraction layer for hardware access/info/notifications. However, the architecture of it was crap (polling? really? name a single kernel without an event system), and it was very Linux-specific. Writing alternative backends for it was nowhere near simple. There was also no input from non-Linux devs.
Those who ported HAL to non-Linux OSes have nothing good to say about it.
Thank you for pointing out the truth. Linux isn’t so much an “operating system” as it is a kernel with a compilation tape GNU and (to a lesser extent) BSD code wrapped around it.
BSD has a solid code ancestry and is a consistent, stable family of true operating systems.
Flame away, penguinistas.
Edited 2011-01-20 15:16 UTC
The various Unix-like OSes have never had any kind of agreement on how to deal with modern hot-swappable hardware. That means that without a meaningful “translation” layer that provides a consistent API for desktop environments to use from kernel to kernel, any sort of cross-platform desktop environment is either going to need to have built-in support for multiple different OSes by themselves or they’ll need to restrict themselves to mid-90s level functionality, neither of which is a decent option.
Any BSD system (I use OpenBSD, but the same thing is true for other flavors) put nearly all of development resources to form a consistent configuration interface. So, porting some always evolving linux interfaces to BSDs simply makes no sense as far as so much development resources were invested into solid native interfaces.
As far as it comes for popular projects like GNOME, ports maintainers find ways around. XFCE isn’t that popular, so there simply isn’t enough development resources on the BSDs’ side to port it in a way that makes sense.
At the same time, XFCE team writes code for Linux interfaces. As they are not interested in BSDs enough to also write code for there interfaces, no BSDs support come out of the box.
In any case: if You want all XFCE’s features on Your BSD flavor of choice, DIY. It’s a free software at the end!
Actually, no – XFCE codes to the same interfaces as Gnome and KDE do, and those interfaces aren’t Linux-specific. However, they *are* only available on Linux for the moment, since Linux-based developers are the ones doing all the work. Now deprecated, HAL used to be the same, until the BSD people came to the party to add a BSD backend.
Agreed – those wanting to use modern desktops on BSD are going to have to do the work to support it. Nobody else is going to.
contradicts
But maybe that’s just me.
The architecture itself is not Linux-specific. The backends however, are.
Architecture of any API isn’t whatever specific until You define being specific as being developed for a particular platform with that platform in mind.
That said, udev is definitely linux-specific, as is udisk and as HAL used to be (regardless of the fact it was ported to FreeBSD as WinAPI was ported to linux with WINE project).
ConsoleKit isn’t that platform specific and therefor is ported to BSDs (eg. see http://openports.se/sysutils/consolekit).
Right, they just happen to be written by Linux developers who usually write code from a Linux perspective. And will, more than likely, be completely replaced (yet again), as is custom with Linux frameworks.
Hmmmm, don’t you know that the most widely distributed program in the *ix world is OpenSSH? Written by a subset of the OpenBSD devs in two forms.
One is the version shipped with OpenBSD. When that code is audited and tested OpenSSH Portable is built for the benefit of other *ix-like OSes.
See OpenSSH ( http://www.openssh.com/ ) for details.
At least the smallest of the BSD dev teams doesn’t tell you all to DIY or go without.
He said DESKTOP. OpenSSH itself has nothing to do with the desktop. The package for OpenSSH seems to be a bit over two megabytes. I don’t think that compares next to a multi-hundred-megabyte desktop environment (nor XFCE).
There is no such term as “*ix-like”. It’s unix-like (capitalization about personal taste).
Then there’s a bunch of people who like to use “*nix” and such for whatever reason.
Edited 2011-01-20 07:37 UTC
”
There is no such term as “*ix-like”. It’s unix-like (capitalization about personal taste).
Then there’s a bunch of people who like to use “*nix” and such for whatever reason.
”
“unix-like” = 9 characters
“*nix” = 4 characters
“a bunch of people” probably like typing five less characters.
Shouldn’t it be “unix-like” and “*nix-like”, in which case they are exactly the same length?
Let’s look at the *nix naming convention through the other end of the telescope. I hereby would like to put a motion on the table:
GIVEN that UNIX(tm) contains substantial amounts of BSD code and tools, and
GIVEN that through the early 1980’s the original “Berkley Unix” project became one of the main code providers for research Unix,
BE IT RESOLVED that all official UNIX(tm) distributions, as recognized by the Open Group, be henceforth referred to as “BSD-like” to avoid confusion with the Berkley Software Distribution and its legitimate descendents.
Nice.
If I hadn’t already posted, I would definitely +1 this post. 
“*” meaning “whatever” taken from standard computer use use.
Examples:
“dir *.exe” meaning display all files where filename ends “.exe”
“rm *20110120.*” meaning remove all files that contain “20110120.” in the filename
Thus; “*nix” meaning anything ending in “nix” to include Minix, Linux, BSD Unix, ATT Unix, IBM Unix and so on. You’ll also see “*bsd” referring specifically to the BSD branches; OpenBSD, FreeBSD, PC-BSD.
In the end, “*nix” and “Unix like” mean the same thing.
Personally, the amount of time I spend discussing *nix related topics; I’ll stick with the shorter “*nix”. Not that I’ll hold anyone else to that standard as often use “Linux based distributions” or specify a distribution instead of referring to the kernel type (“Linux”) and “distribution” instead of “OS”. Where the language does not have legal implication (deserved or not); each to there own choice of use.
Except that Linux ends in “nux”, not in “nix”.
Try splitting a curly one next time.
exactly, and I have never heard of an OS called “nix” either …
clearly, we should refer to them as:
[A-z]+n?x
or
.+n.x
We should just call it “bsd-like” instead. It’s shorter and more correct.
Seriously though, most BSD users go with a full service desktop like KDE/GNOME or superminimalist with WindowMaker/dwm. In the grand scheme of things it doesn’t matter that GNOME-lite (XFCE) doesn’t support them.
BSD users prefer looking at terminals/consoles anyways; they barely interact with the desktop.
So I am not a real BSD user cause I use Openbox …
Erm, excuse me… WindowMaker… superminimalist?
Ha! Haha! Ha! Haha! Haha! (insert Mandark laugh here)
I think you have an opinion about WindowMaker that needs some revision. If you would call any classic tiling window manager to be superminimalistic, well, I would fully agree. Fluxbox superminimalistic? Maybe not super, but yes. Or fvwm2, olvwm. Superminimalistic would be something like twm, but… WindowMaker? No, definitely not.
As a user of WindowMaker (many years now on my primary desktop) I am traditionally laughed at for using such an inconvenient, bloated, overloaded and unconfigurable piece of software. 🙂
Please see the currently correct captioning: While XFCE (all caps) usually refers to XFCE version 3 (using “classic” Gtk, being fully portable, being lightweight, efficient, usable and easily configurable), the version 4 is called Xfce now.
And I have to admit in conclusion: I’m not fully sure if the caps in “WindowMaker” are currently the correct choice. Sometimes, such simple things change.
Your classification of Xfce (4) as “Gnome-lite” is fully currect in my opinion. So the predicate “lightweight” is already lost. 🙂 But okay, on the other hand, we’re not talking about window managers, but about full desktop environments where the predicate “lightweight” may apply to Xfce.
Again, I don’t know where you take this opinion from. Let me emphasize that most BSD users *I* do know don’t look at consoles. Most of them prefer a versatile and fast window manager, not just for terminal windows, but for everything else. Among them, there are several “power users” who prefer doing their work & fun on KDE and Gnome desktops. Of course, those are *my* individual observations which do not claim to be applicable to everyone and everything.
Most BSD admins probably use Win7 and ssh.
That statement is as accurate as this one below.
Most Linux admins probably use Win7 and ssh.
Actually I retract my statement, most BSD admins are likely using XP and ssh.
Most BSD servers exist inside corps and are accessed remotely.
Most Windows Server admins probably use Ubuntu and rdesktop.
I use Debian or Ubuntu with rdesktop. Do I win a prize?
Yes, your prize is the Adobe suite for OSX.
I’d vote you up for “funny” but alas, the stupid restriction that you can’t vote once you have commented is still alive and well.
Edited 2011-01-20 19:42 UTC
That’s a wicked prize, thanks!
I am but one admin but personally, I used a VM with Debian on it before having a notebook issued. The notebook is win7/Debian booted into Debian 95% of the time. I’d suggest that any BSD or Linux admins who have the choice are using BSD or Linux on a local machine or VM when doing any heavy work with console managed servers.
Sure, one can use Putty and filezilla or WinSCP but it’s like running a race on crutches; you’re constantly aware of functionality lacking from a natural interface like native SSH and Rsync.
(Just to interject one real life example. Now we return you to your regularly scheduled nerd slap fight.)
I’m not actually trying to start a nerd fight, just pointing out that there is some truth in what the parent said.
In all fairness it is due to corporate policy, not choice.
I was actually amused by the jokes back and forth but thought it worth adding the example anyhow. “nerd fight” was just a humorous reference to the back and forth jabs.
I’m the other way around.
When I am developing, I prefer to use the same OS, even if I technically could get by using something else.
For server admin though, I prefer to use W7 with putty, winscp, vnc, remote X, etc.
I tend to use Windowmaker, but install many of the KDE tools, so at whatever point I need any of the HAL-connected features (or KDE’s awesome virtual filesystem), I just pull up Konqueror or Kate, but other than that, I like my desktop to stay out of the way.
– Using BSD since 1999; using BSD as a desktop since 2003.
OK guys, this news talks about BSD, Linux, GNOME, KDE and XFCE. So let’s start the usual religious war between BSD and Linux and while we are at it, GNOME vs KDE vs XFCE. We can also digress into a BSD vs GPL license war. The comment section should be 200 posts long by the end of the day.
Edited 2011-01-20 06:45 UTC
You really do not understand the problem, dont You?
I think there are several problems, not just one. One problem is that Xfce 4.8 does not work on BSD because it uses linux specific stack for hotswapable devices. That is the only problem that matters to you. The other problem is that this comment section will soon be filled with hate speech from people who want to show that the other religion suck. I was trying to address and prevent the second problem, not the first one. Maybe I was wrong and the second problem do not exist and everything is under control but I had the feeling that this would happen, because this article talks about both Linux and BSD, GNOME, KDE and Xfce. I think my concern is reasonable.
I think that the main problem is with the XORG developers, they are more and more Linux centric, as other UNIX systems would just vanished …
My dad is stronger than your dad.
So what..? My feet smell stronger than your feet.
Yeah, that’s what your mom tells me.
I would like to see the BSDs have a little more desktop love. It would be great if Xfce could be a little more portable in this regard. Perhaps this is something the Xfce devs need to tackle head on….
Exactly! This only happens, because Xfce developers have decided to use Linux specific APIs, instead of implementing an OS abstraction layer.
Unfortunately UNIX based OS are not as portable as many people think.
So now Xfce is Linux only.
If proper abstraction layers had been put into use, Xfce could be fully enjoyed not only in BSD, but in HP-UX, Solaris, Aix among others.
The lack of portability between *nixes has a long history. This is no different. The players have changed, but the game is the same.
Edited 2011-01-20 18:20 UTC
There are way too many abstraction layers around. The should be one layer in between the kernel and the desktop stuff. Call it udev/devfs/devd/HAL/policyKit, you name it. Write this layer portable, but do not stack them. Then it is up to the BSD devs to port this layer.
There have been way to much changes in the linux ecosystem in this area. It is logical that devs write their software for a large audiance, which is linux in the open source world. BSD* devs could port a well designed abstraction layer to BSD such that desktop apps could be ported. But this requires that the abstraction layer is more or less stable for ~5 years, not 2.
Edited 2011-01-20 21:37 UTC
The problem with that idea is that layers above the kernel are vast and ever changing, not to mention the changes to the array of hardware a kernel has to support. A *lot* can happen in two years that can make things go obsolete, no matter how well you plan ahead. Trying to have core technologies remain stable for 5 years just makes the transition away from them that much harder at the end of those 5 years.
I think that’s the main working field of PC-BSD and DesktopBSD: Providing a full-featured desktop on FreeBSD’s OS basis.
In my opinion, nobody wants a “half-featured desktop”. As it has already been mentioned, there are mostly the camps that use functional window managers (Windowmaker, Openbox, dwm have been mentioned, there are many other good ones), and there are those who prefer a full-featured desktop. Choices here are KDE and Gnome.
As Xfce is based upon the same Gtk version as Gnome is, you get nearly 3/4 of Gnome with a Xfce install in terms of dependencies. But you don’t get all the default applications.
If you’re intending to tailor your system according to your needs, you will choose whatever you prefer, from any kind of toolkit, be it the “original” Gtk, Gtk+, Qt, Xaw, OpenMotif – many of them exist. You won’t care about “the holy consistency” when you care about speed. And as you can easily conclude, speed matters on systems that are already some years old. Newer systems are really good at compensating bloat. 🙂
I disagree, a distro like Crunchbang can be useful for turning an old computer into a browsing kiosk and media player.
I don’t see any need to disagree with that. But I wouldn’t call that a “half-featured desktop”, but instead a specialized or tailored solution, as many professional users create theirs from scratch. In fact, I’m using such a specialized solution for a 300 MHz P2 which is a fully usable desktop including multimedia capabilities. This tailored solution has been created from scratch by using XFCE 3 – means: Lightweight stuff is important here, as well as a wise choice of software, and this choice is NOT limited by being tied to a specific desktop.
Of course, such a desktop could be called “half-featured”, as it doesn’t have icons on the desktop, for example, or doesn’t include many things that today’s average users require. On the other hand, it includes powerful and versatile software that this specific group of users doesn’t even know about.
But keep in mind that old computers (where old means “older than 2 years”) don’t seem to be in the scope of “modern” developers, as making software usable on such platforms requires efficient programming and avoiding bloat (traditionally introduced by cascaded abstraction layers).
Yea I have built them from scratch but this is an area where a specialized distro can be a time saver.
Does everything really have to be so portable?
Would a stack of closeley integrated Linux-components (or any other OS for that matter) be that bad?
I can see that it maybe has to for server stuff, but for desktop?
Actually, no. Except the fact that, in general, good software is inherently portable. Non-portable software often means poor, bad designed, buggy software. With this in mind, you can make your own assumptions.
Thanks for answering my question!
(Seems like most people took it like rethorical trolling…)
Indeed. Not.
When KDE decided to implement their system/hardware integration API using a frontend/backend architecture, they were ridiculed: somebody from the HAL team even created a T-Shirt (http://www.zazzle.de/kde_abstrahiert_meine_abstraktionsschicht_tshi…) for that.
If any of the XFCE developers bought such a T-Shirt, they probably wish it would read “XFCE abstracted my abstraction layer”
Edited 2011-01-20 10:20 UTC
Given that HAL is dead now, I wonder if it wouldn’t be possible to create a meta teeshirt making fun of this stupid claim?
I remember that the GStreamer author(or maybe it was only a gstreamer’fan) had a similar criticism against Phonon just after releasing a major version of GStreamer i.e just after making incompatible changes to the API!
I’m a bit confused about this really. I was under the impression that user-space desktop apps used dbus for this. Isn’t this just matter a of writing a dbus service for BSD that mimics the udev dbus service interfaces?
Edited 2011-01-20 11:08 UTC
Not really, thunar-volman uses the udev library for device management and notification etc.. So someone in BSD camp will need to implement the same backend for *BSD, probably using devfs. That is what happened with HAL as well.
A common abstraction layer, such as HAL helps a lot in terms of interoperability, because most applications end up using it in terms of device related operations. So it is a single coding effort to implement a BSD backend in HAL, which was done. Now with udev and libudev, coding will be needed for every other component that uses it directly.
The KDE folks are doing it in the best way imho, implementing their own hardware abstraction. Then every other KDE app uses that, and you only needed to implement a BSD or any other backend for the abstraction layer.
But the HAL api was only accessed by desktop apps thru dbus. All you needed to do to “port|” HAL to a new platform was to somehow implement the same dbus interfaces (by no means a simple task though. I know, I tried). Why wouldnt udev be done the same way?
Well, the real problem is that udev doesn’t actually do any of the things that HAL was primarly used for. For that you need a rather wide range of other new special-purpose services like upower, udisks, unameit, etc.
A KDE developer working on porting solid from HAL to udev complained about this, and how there was a still a few things done by HAL which didn’t even have new interfaces. In the new “udev” backend, they had to implement direct parsing of linux /proc files to support features that previously came through HAL. Stuff like that makes “udev” implementation much less portable.
If I may rant it bit, it seems GNOME developers in their eternal wisdom and continued strugle to make everything clean and pretty, forgot to implement anything useful from HAL into udev before they decided to deprecate HAL.
I am not really sure why Xfce 4.8 needs ConsoleKit and PolicyKit, but those are available on FreeBSD at least:
http://www.freshports.org/sysutils/consolekit/
http://www.freshports.org/sysutils/policykit/
Oh, and FWIW, I am a happy user of Xfce on FreeBSD since the Xfce 3.x days, currently using Xfce version 4.6.2. I haven’t missed Thunar-volman at all.
perfect combo!!!
> None of these fancy new frameworks work on BSD
For this very reason I am about to drop Linux in favor of FreeBSD.
Do you mean you are switching to BSD because the Linux devs and their frameworks fail to supporting BSD well enough?
I think they want stable interfaces.
I see a place for that, but I also see advantages to forward-thinking, evolutionary development.
That’s why we have different OSen, though.
I would rather say, because the BSD team does not normally prefer incompatible solutions to the old ones. Because it is not in BSD tradition to fix what is not broken. Because you have to convince them when you want to violate Occam’s razor.
Actually, it’s just words, I know, but, really, I’m tired of the innovative trends in Linux. D-bus may be interesting, but why introduce a new IPC technique? I understand that the D-Bus developers may have been unaware of the work on AMQP, but why not take an existing protocol, like POSIX mq_* or System V msg*, and extend it? Or, if they chose to make something completely new, why not follow the Unix way and make the protocol network-transparent and, maybe, text-based?
Now, take some other “improvement”, like Qt or GTK. What made the developers dump the notion of the X resource database? They also preferred “new” to “better”. They also forgot about network transparency. And only one step on the way to yet another innovation, Wayland, which also leads in the same direction, making Linux another Windows — a self-contained, network-unaware black box.
One of the funnier posts I’ve read on this otherwise quite serious website. Don’t get me wrong, I tend to find the profileration of humor annoying (lowers s/n ratio), but I can appreciate an occasional understated and dry jab at the bsd mentality.
My intention was to be terse rather than funny, sorry
I can see where you are coming from, the BSDs are lacking allot of features you find in desktop versions of Linux.
Just some thoughts:
Independently of what is what, an H.A.L. interface layer is needed. What composes it is irrelevant as long as the tasks are efficient and secure.
Be it udev+usession+uwhatever is only the good old each-monkey-to-is-own-branch trick.
The fact that present situation poses problems to BSD usage of XFCE… is only an effect warning us that something is missing.
Be it on Linux or in BSD, it is not very much relevant, as coexistence is needed and has a strategic value. Not to mention the spirit of both systems.
It is not a matter of “following” but of getting the wheels properly implemented.
Let us remind that XFCE, as a linking point between Linuxes and BSDs has the peculiarity of being a check point, also one that shows an opportunity… pointing the way to go.
AKA Factor-H, DuLac
Wow, no news since WEDNESDAY!
I am starting to see what this dude means: http://angrytechpundit.blogspot.com/2011/01/osnews-and-day-it-died….
yeah, slow on news lately. pig flu?
As long as you’re complaining, how about submitting news articles?
Also while you mention that article:
If the author had his way then you would see an even longer timespan between articles so just shut your trap or do something about it eh?
Edited 2011-01-23 17:58 UTC
Several news items have been posted since Wednesday. Apparently something’s wrong with the frontpage not showing any of them. For the moment, check the Archive page ( http://www.osnews.com/archive ) for latest news.
Duh, actually they’re shown, but only in the right column. Hopefully this’ll be fixed soon.
Well, being using Xfce 4.8 for a couple of days. As some distros already packaged it and some people are having problems with it, I suggest who really want to go for it to or use what is inside the git repository (http://git.xfce.org) or download the patches and apply to the released versions (and, of course, go to compile and install process). This solves most of the problems I had on my system (openSUSE).
Answering a guy on Xfce 4.8 release annunciation thread (it is locked now), yes, you can freely position your icons on the desktop now but I was not able to drag all together when using rubber-banding (and didn’t try to delete them), even though they are selectable this way.
xfwm4 has nice compositing support (for what I care, i.e., drop shadows and transparency). Also, Firefox, Thunderbird and OpenOffice loading are a lot faster under it than on KDE. The other programs I use at most are Qt based and I see no difference on loading time.
See no reason why I should not be able to correct my post after just a couple of minutes.
Anyway, please “been using”. Bah.