LXDE Desktop Being Ported To Qt

[mrugiero]

Windows has MFC, WTL, Windows Forms, and the Windows Presentation Foundation, (all provided by Microsoft) Additionaly a lot of open source toolkits can be used on windows. I believe there are less official toolkits for OS X, but that is largely a product of their not caring as much about backwards compatability.

I already named MFC. It's a wrapper, it's different from a full-fledged library, since it introduces as much fragmentation as XCB introduces fragmentation compared to Xlib. It's pretty much a binding to another language, and nothing else, and if done good this implies this will really be far lighter than a *real* different toolkit.

http://en.wikipedia.org/wiki/Windows_Forms
Wrapper around Win32, and targeted to managed code, so more of a kind of binding than a real toolkit.

http://en.wikipedia.org/wiki/Windows_Template_Library
Also a wrapper, but targeted to C++ code.

http://en.wikipedia.org/wiki/Windows...ion_Foundation
Targeted to managed code. Not really the same niche. This is the only one on that list that I seem to have been wrong about, since this *actually* seems to have a different underlying framework (DirectX based, so again, it's a different beast). Not really kept for the sake of having options, but because this introduces real differences on how you think programs (or at least that was aimed), since this tries to separate the logic from the UI, which is not really doable with Win32 (for a start, you need an event handler to control most of the program logic, and this ties tightly the UI bits with the program's logic bits).

And about the free ones, they have no use when using Windows only applications, and exists on Windows mostly because of portability (you can port free software, but you have no way of porting Win32 aside from completely reimplementing it).

And the point of having different toolkits for the same thing is not clear yet. When GTK came out it made sense, because it was feared that Qt could have become closed overnight. This concern is no longer valid (there is a legal agreement that makes that impossible), so both camps should work out whatever difference they have already and merge, and make wrappers for different languages instead of complete toolkits.

[dee.]

What does it matter how things are done on windows anyway? It's a dying OS...

[oleid]

read what you quote! what mrugiero wrote is right. there is only ONE real toolkiit for widget drawing etc: win32 api.

all other "toolkits" are just wrappers.

This is true for MFC and Windows Forms, however, not for WPF. I don't know about WTL.

[a user]

Windows has MFC, WTL, Windows Forms, and the Windows Presentation Foundation, (all provided by Microsoft) Additionaly a lot of open source toolkits can be used on windows. I believe there are less official toolkits for OS X, but that is largely a product of their not caring as much about backwards compatability.

read what you quote! what mrugiero wrote is right. there is only ONE real toolkiit for widget drawing etc: win32 api.

all other "toolkits" are just wrappers. while on linux the existing toolkits are doing everything on theit own. the win32 api is used for drawing a window, a button, a frame and every other thing.

BUT, of course it is possible to not use that and draw things on your own on windows. there are plently of programs just doing so, having their own widget styles etc.

[curaga]

But claiming it is inefficent because it is huge (has lots of modules) is just plain wrong.

It is inefficient because the modules themselves are huge

So while you can ignore the 3d or SVG support, QtCore itself is huge.

[erendorn]

It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.

As Delgarde said, no.
Qt is available on windows and mac. LXDE isn't.

[dee.]

Except, you know, all the people at canonical, and all the people using their software - which easily represents the biggest chunk of the desktop linux market (in anticipation: no, distrowatch numbers do not represent market share). And being the most popular means attracting the most software and driver support (c.f. Steam support, and GPU driver updates tailored to go with it). If you make a DE and you're not paying close attention to this trend, you're not doing your job very well.

No, Ubuntu does not represent the majority of desktop Linux, that's just stupid. Even in the Steam survey Ubuntu couldn't get a majority share. What statistics do you have to show otherwise?

And no, Mir is not going to "attract the most driver and software support" because of steam. GPU makers don't care about Steam, which is small peanuts compared to the render farms running RHEL which will be running Wayland.

Besides that, Mir is being made for the needs of Unity only, and Canonical makes no guarantees of not breaking server-side APIs, thus, no one is going to port their DE to Mir. All the other DEs have already stated that they support Wayland, all the toolkits have stated they will support Wayland, even Ubuntu-derivatives (Kubuntu, Lubuntu) have stated they want nothing to do with Mir. Face it, Mir is going to be a Canonical-only solution that no other distro anywhere will use.

Although strictly speaking, the aim is that the vast majority of users won't need to have anything to do with Mir, they'll just get a desktop that works. When was the last time you bought a computing product based on its display stack technology?

People choose computing products because of compatibility all the time.

All i was saying in any case was that if you build a desktop on QT5 it should run on mir whether you plan to or not, that's the point of QT be cross platform to begin with.

Incorrect, as already explained by another person.

[ShadowBane]

Windows == Win32 API
Others are just wrappers around it (MFC, I'm looking right at you).
I don't know nor care about Mac, but my guess is it does have a single "toolkit", too.

And there are more than the look and feel problem. For a start, trying to find the best app for a given set of problems might imply using several different toolkits, which is a waste of resources (specially memory). Libraries are supposed to allow you to save memory through sharing. If apps don't share, there is no gain.

Windows has MFC, WTL, Windows Forms, and the Windows Presentation Foundation, (all provided by Microsoft) Additionaly a lot of open source toolkits can be used on windows. I believe there are less official toolkits for OS X, but that is largely a product of their not caring as much about backwards compatability.

[mrugiero]

Agreed.

No platform has a single toolkit, not Windows, not OSX, and certainly not Linux.

What is needed is consistent look&feel and theming. Qt has done this for a long time, automatically adapting to GTK, Mac and Windows themes. GTK refuses to add this functionality, although it exists.

That's the problem. Make them look the same and let the developers choose whatever they feel more comfortable with.

Windows == Win32 API
Others are just wrappers around it (MFC, I'm looking right at you).
I don't know nor care about Mac, but my guess is it does have a single "toolkit", too.

And there are more than the look and feel problem. For a start, trying to find the best app for a given set of problems might imply using several different toolkits, which is a waste of resources (specially memory). Libraries are supposed to allow you to save memory through sharing. If apps don't share, there is no gain.

[HeavensRevenge]

Well the UI framework's base language used does not imply a bloated nature of the resultant product. C & C++ are equivalent in terms of speed, and the only reason why KDE is slow and bloated is because the KDE dev's coded it that way without performance in mind and only functionality.

http://benchmarksgame.alioth.debian.org/u64/cpp.php is a popular comparison of languages and that shows that C++ is not slower nor nescessarily more bloated. Usually it's abstractions help code size and speed.

So just because KDE is slow and big doesn't mean one bit that the programs coded in Qt must share the same trait as slow or bloated, its 100% dependant on the implementation, not the UI framework.