Features Coming In The Xfce 4.12 Desktop

[mrugiero]

Yes, you are right about the licensing dispute, Qt was supposed to be incompatible with the GPL, but that ended when Qt was relicensed in year 2000. Since then, there has been no licensing reason why new projects should be desktop specific. And some projects were always GPL anyway (KDevelop has been GPL since 1999). So I think there was more to it than that: the philosophy of the desktops was to make something that resembled Windows, where the desktop project had control over all of the software that came bundled with it. The problem with that approach is that it implicitly rejects third party software, even if that software is better, and it rejects opportunities to collaborate on cross-desktop applications. If Gnome desktop has an official app for functionality X (email, web, whatever), then that app will always be shipped as part of Gnome desktop, over all other competitors. It's a statist approach to creating a desktop. Competition is good, but the concept of a desktop having an "official X app" eliminates that competition. And I have no idea why generic programming tools like KDevelop/Nemiver were ever considered desktop specific. It can't be just about the widgets - nobody says that Skype is KDE specific because it uses Qt, or that Firefox is Gnome specific because it uses GTK.

I mostly agree, but I wouldn't say it eliminates competition, I'd rather say it discourages it (it's different, it's eliminated if the user is unable to use other app instead of the shipped one).

[curaga]

There's a difference between generic widgets (gtk, qt) and desktop-specific ones (libgnome* libkde*). If your app pulls in half of KDE, it can't really be called a desktop-agnostic app with any conscience.

[mrugiero]

There's a difference between generic widgets (gtk, qt) and desktop-specific ones (libgnome* libkde*). If your app pulls in half of KDE, it can't really be called a desktop-agnostic app with any conscience.

Nobody said it's desktop-agnostic. The only thing I said is you can consider that it eliminates completely competition, because even when the dependencies are kind of stupid big, you can run them from within other desktop.

[curaga]

I was responding more to chrisb:

And I have no idea why generic programming tools like KDevelop/Nemiver were ever considered desktop specific. It can't be just about the widgets - nobody says that Skype is KDE specific because it uses Qt, or that Firefox is Gnome specific because it uses GTK.

KDevelop pulls in half of KDE, therefore it's undesirable to install unless you run KDE.

[dee.]

I was responding more to chrisb:



KDevelop pulls in half of KDE, therefore it's undesirable to install unless you run KDE.

Why? Because of disk space or what? Not that big an issue, to be honest. I use Cinnamon, but I have no problems letting KDE libs squat on my HD so that I can use programs like Krita.

[mrugiero]

Why? Because of disk space or what? Not that big an issue, to be honest. I use Cinnamon, but I have no problems letting KDE libs squat on my HD so that I can use programs like Krita.

Not only disk space, but memory use. If you don't use KDE, this libs won't be shared by anything else, so there's no amortization for using libraries at all.

[dee.]

Not only disk space, but memory use. If you don't use KDE, this libs won't be shared by anything else, so there's no amortization for using libraries at all.

Correct me if I'm wrong, but won't those libraries only be used when an application is running that needs them? So there'd be no memory penalty the rest of the time.

[mrugiero]

Correct me if I'm wrong, but won't those libraries only be used when an application is running that needs them? So there'd be no memory penalty the rest of the time.

Well, there are two options, when a program drags them behind it: either, packagers are total jerks, and make you install libraries the program won't use, just for the sake of taking space, or the program does use them, and that's why they are dependencies. I tend to incline for the latter possibility.

[dee.]

Well, there are two options, when a program drags them behind it: either, packagers are total jerks, and make you install libraries the program won't use, just for the sake of taking space, or the program does use them, and that's why they are dependencies. I tend to incline for the latter possibility.

I mean, won't the libs only be taking up memory when some program is using them, ie. when you're running a program that needs those libs? And the rest of the time, when you're not using that program, the libs won't be taking up memory... what I'm saying is, that the additional memory usage is only when the application is in use, it won't affect the memory usage of the rest of your system.

Besides, the KDE libs don't seem to use all that much memory. When I start up Krita, it only takes up about 160-180 MiB of memory (although granted, I don't know how many of the KDE libs it uses). And unless you're using some really old, pre-DDR1 hardware, you're likely to have at least 2GB RAM, seeing as RAM is pretty cheap these days, so I don't really see the memory usage much of a concern. (And if you have pre-DDR1 hardware, you'll probably want to use something more lightweight than most KDE-based apps, anyway...)

I guess it'd be nice if we'd have this one universal toolkit library that would be suitable for the purposes of every possible application, on every possible hardware, to the extent that we'd never need any other toolkits... and as long as we're making wishes, I'd like to win the lottery, too

But in the meanwhile, I'm not going to refrain from using an application because it happens to use different libraries than most of the stuff on my computer. We've got this great system in place where we can have different desktops, with their different software collections, yet we can still run any apps in any DE - it's kind of cool. And it's also why Mir is such a horrible idea, because it threatens to break this system of interoperability.

[mrugiero]

I mean, won't the libs only be taking up memory when some program is using them, ie. when you're running a program that needs those libs? And the rest of the time, when you're not using that program, the libs won't be taking up memory... what I'm saying is, that the additional memory usage is only when the application is in use, it won't affect the memory usage of the rest of your system.

Besides, the KDE libs don't seem to use all that much memory. When I start up Krita, it only takes up about 160-180 MiB of memory (although granted, I don't know how many of the KDE libs it uses). And unless you're using some really old, pre-DDR1 hardware, you're likely to have at least 2GB RAM, seeing as RAM is pretty cheap these days, so I don't really see the memory usage much of a concern. (And if you have pre-DDR1 hardware, you'll probably want to use something more lightweight than most KDE-based apps, anyway...)

I guess it'd be nice if we'd have this one universal toolkit library that would be suitable for the purposes of every possible application, on every possible hardware, to the extent that we'd never need any other toolkits... and as long as we're making wishes, I'd like to win the lottery, too

But in the meanwhile, I'm not going to refrain from using an application because it happens to use different libraries than most of the stuff on my computer. We've got this great system in place where we can have different desktops, with their different software collections, yet we can still run any apps in any DE - it's kind of cool. And it's also why Mir is such a horrible idea, because it threatens to break this system of interoperability.

Of course, but why would you install KDevelop if you are not going to use it? I thought it was implicit that it wasn't shared between KDevelop and something else when running it. About the weight, I don't know, since I don't use anything from the KDE side (I do use some Qt apps, but the ones I use do not depend on anything from the KDE camp), I just know that as long as they are used only by an app, those libs are kind of a waste of resources. How much, of course, depends on how big the libs are. Of course, using it or not is a choice. As I already said, that's why one can not say it eliminates competition. The user is still able to choose whatever fits him. I wouldn't refrain from using a KDE program if the ones most compatible with my desktop of choice don't satisfy me either, but I've got pretty simple requirements and almost any software can achieve them :P

The thing with Mir and interoperability, I *think* it's more LightDM's fault than anything else's. As I see it, LightDM, which does a pretty basic use of display in general, could start as a DRI only app and then open the correct display server for the desktop you choose to use. But maybe there are technical impediments for that idea that I'm not able to see.