Username or EmailPassword
This means more animated, pretty, and stable KDE releases!
Man how I wanted an elegant desktop environment written in Qt. It's kind of sad liking Gnome but hating Gtk, and loving Qt and hating KDE mentality of "complex is good" or "if doesn't have 451 buttons it isn't good".
"if doesn't have 451 buttons it isn't good".
You seem to be talking about a different KDE than the one I'm using...
I actually like GTK. In my limited experience, in GTK, more typing is involved, but things make more sense and it's easier to get things right. In particular, I like how containers (that provide layouts) are widgets themselves, meaning that you can put a complex layout with multiple widgets in it anywhere that you could put a single widget. That's not true in Qt (at least, not without a little extra work): there, layouts are a separate entity from widgets. This bit me recently trying to create a push-button in Qt that could accommodate arbitrary child widgets and layouts: that's just there in GTK, but I had to sub-class QFrame in Qt and override the mouseReleaseEvent (which got the job done, save for the minor quibble that the result doesn't look like a normal QPushButton).
Having said that, Qt is probably a much easier toolkit to use, and C++ facilities are pretty handy for adding new functionality to widgets. It kinda makes me want to try gtkmm.
While that is true, something about that approach just doesn't sit with me: I find treating containers as widgets to be more... elegant and orthogonal, I suppose. I think that model is just more elegant and flexible, and is easier for me to keep track of and reason about.
No disagreement! I don't think that Qt is doing anything wrong by having Layouts and Widgets be separate things, I just like the gtk way better, and find it more intuitive. It's entirely a question of personal preference.
Heh, well, partly because we didn't want them to look like QPushButtons: we just wanted images you could click on, without the border or background-gradient. (So, when I complained that they "didn't look like QPushButtons," what I guess I should have said was, "most of QFrame's borders where too ugly to use.") Also, for whatever reason, when I used QPushButtons, they didn't size themselves properly (I think: they didn't show up, and my theory at the time was that they where requesting a zero size allocation, for some reason).
At least you can customise it, unlike another DE I could mention, which removes customisation on just about every release.
I'd rather customise and disable what you want than virtually no custimsation at all(an OS and DE come to mind).
Just read this: http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in...
Man how I wanted an elegant desktop environment written in Qt. It's kind of sad liking Gnome but hating Gtk, and loving Qt and hating KDE mentality of "complex is good" or "if doesn't have 451 buttons it isn't good"
Darn. Couldn't have said it much better myself; I love how smooth the animations are in KDE and how much more advanced Qt feels compared to GTK+, but I just really hate how every KDE app includes a gazillion menu entries, buttons, layouts, heck, they seem to be stuffing the whole kitchen sink in there, too.
Oh well, this isn't a KDE thread though. Good thing to see Qt getting improvements, might be worth learning to use it myself too someday.
"i dont use this feature so nobody else should!"
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away...
this is what you are saying, you do realize this?
Nope, it's not. To copycat you, I could just as well state: "on a related note, i just really hate how no one ever has enough stuff with them all time time, i really need first aid kit, full toolbox, kitchen sink, vacuum cleaner, 12 different screwdrivers, canister of gasoline and a toolshed with me every time i do something as simple as drink coffee"
Exaggerating things is fun, isn't it? Oh, and it _clearly_ makes my post look mature and well-presented, doesn't it?
The problem isn't just having a tool-shed or not, it's how well-organized the tool-shed is, and how easy it is to find the tool you want at any given time. It's fine to have lots of advanced and powerful features, but they need to be presented in such a way that the application remains easy to use in the likely-more-common simple use cases. Advanced features shouldn't be in the way.
That, I suppose, is my biggest problem with KDE. All that complexity might not be a bad thing in and of itself but. typically, I find that the abundance of options and features are not managed well, which can make it difficult to get into KDE (and KDE apps) and start using them for simple tasks. I really dread having to wade through four or five long, similarly-named option panels trying to find the one setting that I actually want; that happens to me a lot, when I try to use KDE. Edited 2009-12-02 16:00 UTC
I think people on open source community should starting studying design.
Too bad QML wasn't ready yet for this release. When they finish it we will have a killer tool for developing more interactive user interfaces. Hell, even designers can program in QML
Well actually I was said that a designer tool for QML is on the works. Indeed, if you think about it, it matches perfectly with vector graphics tools IMO.
From the looks of it, QML is to QT what XAML is to .NET and WPF. Disregarding the ".NET sUxX0Rz" mentality, as I believe most languages and platforms have their own merits, would this a fair comparison?
So for PySide support we'd have to wait for a stable release of PySide, but why not get PyQt support in Creator?
Sorry to nitpick, but this article has more (very obvious) typos than any OSNews articles I have ever seen:
operatig -> operating
Meamo -> Maemo
Did they fix rendering speed for running X remotely or for running remote terminal sessions on windows? This all started with qt4. Maybe one of these decades that will be dealt with.
AFAIK that's because of the default theme being more complex. Change to a minimal theme without gradients, pixmaps and effects and it should be as fast as Qt 3.
A much better option is to use NX instead of plain old remote X or VNC though. It's so much faster it's not even in the same league.
Well, bringing up an image chip from a 4MP camera, selecting some lines and point measurements results in saturating a gigabit connection for .5s or longer bursts (~40mb/s). Doing the same thing in a fltk program I get acceptable performamce over a 1/4 T1 line internet connection (only image navigation is slow,measuring is faster). QT's problem: excessive chatting chatting between the server and client because of all the QGraphicsView stuff. Note this is a also problem with windows remote terminal.
Running vnc (or rdesktop) does help with this because all the composting is done on the server only and screen updates are transferred.
The easy answer has been to not use Qt but any number of non over engineered toolkits. Comments from customers is that the non qt stuff feels amazingly faster. And build management is much easier.
. In addition, community support is available for the real-time operating systems QNX and VxWorks.
I am confused, what is that supposed to mean? Isn't VxWorks for embedded systems only? I am not aware of a VxWorks with a GUI. Excuse my ignorance but can someone please clarify this?. Edited 2009-12-02 10:45 UTC
There are several X11 versions for VxWorks, and you can always use Qt Embedded, which comes with its own windowing system + compositing window manager, independent of X11.
This leaves me with 2 questions open to discussion:
Does this mean we are going to have to rebuild Qt4-QtRuby again from scratch?
How is this going to affect KDE 4.4?