LXDE Desktop Being Ported To Qt

[scionicspectre]

Remember, it's not fair to yourself to compare toolkits based solely on desktop environments that use them. I'm sure you could create a memory-hungry DE with EFL, if you do it wrong.

Qt has been used for a long time in the embedded space due to its performance and portability. Take Qt on QNX (Blackberry 10), and many of the new mobile iterations of Linux since Meego. This was originally Qt made to run specifically on underpowered devices in very limited environments, and it did pretty well given the constraints.

With the proliferation of cheap ARM devices that are more powerful than desktops from 10 years ago, there are increasingly less reasons to be concerned about targetting the traditional low-end of sub-128 MB RAM PCs without minimal hardware acceleration for graphics. I think Qt has done plenty to prove itself, while GTK 3 still has a ways to go on mobile. Of course, if you have very specific needs that only GTK 3 addresses, go for it.

[energyman]

UTF-8 is 50% longer than UTF-16 for some Asian text, but UTF-16 is 100% longer than UTF-8 for ASCII which is worse. String class should support both: UTF-8 and UTF-16. Glib/GTK is using UTF-8 for strings.

and if you use something other than american english ASCII is just not enough. So who cares?

[dvanzo]

I assume it's the user's native language and the rest is not in "that language" because translation is missing for those strings.
Notice, that one entry in the menu on the right is also in "that language" (Chinese?).

My sister's notebook looks the same... One day all was ok (spanish), and the next, a mix of chinese or something and spanish... Tried to restore the language to spanish, english, etc... without luck...

Regards,

Daniel

(sorry my english!!)

[stqn]

There is nothing in particular about C++ that makes programs in it be bloated.

Actually yes, almost everything that makes C++ different from C is designed to ease the creation of abstractions and black boxes, which in turn _tend_ to make programs slower and bigger.

[jrch2k8]

Actually yes, almost everything that makes C++ different from C is designed to ease the creation of abstractions and black boxes, which in turn _tend_ to make programs slower and bigger.

you have something to support this barbaric assumption?

[HeavensRevenge]

All discussion saying C++ IS slowed and IS bigger vs plain C is indeed retarded, it ALL depends on implementation, http://benchmarksgame.alioth.debian.org/u64/cpp.php look, In most cases C++ is what, 20ms behind in terms of a massive workload which buys tons of USEFUL abstractions, unlike C, and helps create many programs be even faster than C and in a smaller codebase vs C since of course the C abstraction level is too low to get any logical abstraction built in a reasonably small amount of code.

Just because KDE has a huge ass doesn't mean the toolkit that KDE is built on does. The KDE's devs are at fault for its huge ass, not the toolkit.

Qt is absolutely fine as a UI toolkit to use for small program footprint. For example, many phone/mobile applications use Qt, yet I've never seen any mobile programs use GTK3.

[curaga]

Qt is modularized, not huge.
You can build modules on whatever technology you like. And considering that Qt is the first toolkit of its kind, all other toolkits are NIH…

They are in no way mutually exclusive; it can be both huge and modularized at the same time.

[ShadowBane]

They are in no way mutually exclusive; it can be both huge and modularized at the same time.

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

[jrch2k8]

They are in no way mutually exclusive; it can be both huge and modularized at the same time.

ill just say see the raspberry Qt5 demos in youtube then come again say where you are wrong and yes Qt for arm is a compile stack switch you don't need special sources.

[GreatEmerald]

Remember, it's not fair to yourself to compare toolkits based solely on desktop environments that use them. I'm sure you could create a memory-hungry DE with EFL, if you do it wrong.

Qt has been used for a long time in the embedded space due to its performance and portability. Take Qt on QNX (Blackberry 10), and many of the new mobile iterations of Linux since Meego. This was originally Qt made to run specifically on underpowered devices in very limited environments, and it did pretty well given the constraints.

With the proliferation of cheap ARM devices that are more powerful than desktops from 10 years ago, there are increasingly less reasons to be concerned about targetting the traditional low-end of sub-128 MB RAM PCs without minimal hardware acceleration for graphics. I think Qt has done plenty to prove itself, while GTK 3 still has a ways to go on mobile. Of course, if you have very specific needs that only GTK 3 addresses, go for it.

This. KDE is by default pretty resource-demanding (but not nearly as much if you compile it without things you don't need). It has nothing to do with Qt, though. Also, Razor-qt is showing quite nicely that lightweight Qt desktops work just fine.