Slashdot Mirror

That already exists, it is called "Qt", like probably 2 decades.
https://en.wikipedia.org/wiki/...
http://qt.io/
http://qt-project.org/

It's modular but it's still got bloat. I'm writing an application which has a fairly modest UI that has a main window, some tabs and dialogs. The weight of the runtime I have to ship with it - icu*, Qt5core, Qt5Guid.dll, Qt5Widgets runtimes is nearly 38MB. Most of the modular bits with the exception of webkit - (multimedia, networking, OpenGL, SVG etc.) are comparatively lightweight compared to the slab of unavoidable "core" stuff that you need whether you like it or not.

Besides Qt has plenty of classes to deal with SQL, so I don't quite get the "Qt [...] seem to lack controls that deal with datasets and stuff".

http://qt-project.org/doc/qt-4.8/sql-programming.html
http://qt-project.org/doc/qt-4.8/sql-connecting.html
http://qt-project.org/doc/qt-4.8/sql-sqlstatements.html

Besides Qt has plenty of classes to deal with SQL, so I don't quite get the "Qt [...] seem to lack controls that deal with datasets and stuff".

http://qt-project.org/doc/qt-4.8/sql-programming.html
http://qt-project.org/doc/qt-4.8/sql-connecting.html
http://qt-project.org/doc/qt-4.8/sql-sqlstatements.html

Just do a wrapper for this.

Well, I also find strange that people say they see no difference.

I see no difference on my work or home network. I admit (and have done so several times in this thread) that the experience is different if you have high latency. The Wayland proponent's argument seems to be that because it does not work well in all cases, it is ok to break it for the other use cases as well. Since I am using it just fine, I am not happy about that kind of argument.

From the top of my head, GTK3 applications are the only ones based on a modern toolkit that still run very well.

Yes, also Qt4 seems to work well, I don't know about Qt5. It would be a shame if they broke it.

The fact that Qt5 needs libXrender doesn't mean it has a Xrender based backend. AFAIK, Qt5 only has two backends: software rasterizer and OpenGL. I've never seen any evidence of other backends.

The term "software rasterizer" does not necessarily imply that it does not use Xrender. Also both could work over the network, but I haven't tried any Qt5 application so I do not know how well this works.

http://qt-project.org/wiki/Qt5...

Trying to forward Wayland clients over the X prototol is dumb.
Wayland clients (application) do nothing but to push pixmap buffers to the server. Try to forward that directly over the network in any shape or form and you get terrible performance.

Why? RDP also pushes pixels and it supposed to be faster than traditional X remoting (also whenever I tried to use it it never worked for some stupid compatibility reason) . Also Xrender essentially pushes pixels and works well - atleast for Gtk. The question is only how to push the pixels. The X protocol is really very flexible, so I think one could make this fast, e.g. only transmit changes.

The only solution is either to have a pixel scrapping mechanism or to have Wayland clients (applications) support some other protocol. Which most Wayland clients (applications) already do: they support X.

Yes, a pixel scrapping mechanism which then send the pixels using X is what I had in mind.

That's not what he meant I think.

Modern X applications (well, the toolkits) are resorting so much to simply pushing bitmaps to the X server that X is becoming unusable over the network.

I always find it strange that people make such claims. I use X over the network and I do not feel any difference to local clients. I might not work as well on your network, but claiming X is "unusable" or "network transparency is broken" just plain ignores that it works very well for some of us.

Eg, the Qt developers found sometime ago that their client side rendering backend was much faster for local usage than the Xrender backend. So they made it the default for Qt4.4 And for Qt5 they didn't even bother with a Xrender based backend.

That does not seem to be true: http://qt-project.org/doc/qt-5...

The client side rendering backend pushes so much data Kate is actually painful to use over a Gigabit Ethernet local network, don't even mention working from home. And this can be said for many other applications I use daily.

I use gnome software such as nautilus, evince, eog, gedit over the network just fine. I just installed kate to test and it also works
perfectly... I could not notice any difference to a local client. Your Gigabit ethernet must be much slower than my gigabit ethernet....

I run applications remotely on a daily basis. But now it's mostly under Xpra instead of plain X forwarding.
Good performance over the network is buried very deep in the priority list of most graphical application developers, if it's on the list at all.

And an Xpra like solution is something you can implement for Wayland.

Unfortunately, rewriting the GUI over and over again seems high on the priority list of graphical application developers. I actually hope somebody just implements a solution which uses the X protocol to forward Wayland clients remotely...

Um what?

I'm on a mobile team and iOS and Android are a lot less similar than you would think. There are few constructs shared between the two. This isn't Qt's problem.

Technically speaking, it's not a case of "holding the copyright". If you want to contribute to Qt, you must accept an agreement that makes you retain copyright, but gives Digia the license of relicensing your code under any license form of its choice.

TL;DR: Digia owns the Qt trademark, but not the copyright on the entire Qt codebase.

Most hardware sold last year can run QT, and does not run Microsoft.net. "already been fought, and won, by Microsoft". How exactly is having a minority (and falling) market share "won"?

Here's a copy of QT that will run on most of the hardware sold last year:
http://qt-project.org/doc/qt-5...

Where's the .Net that will run on more than a small portion of currently sold hardware?

Not so quick. CSS can be found outside the web now. GTK and QT for example.

I used to use vim, but then switched to Qt's Creator even for non-Qt projects. VIM is nice when you're just writing a simple program, but for anything complex, I need to be able to find function definitions, jump through several function calls in a few seconds in files I've never seen, and still be fast.

Advantages:
* Autocomplete for functions, variables, classes, etc. (ctrl+space)
* Jump to definition for variables, functions, classes (F2)
* Keyboard-centric searching (search by class, method, filename, etc) (ctrl+K)
* Visual debugging with GDB (attach to sessions, change complex variables, switch threads, etc)
* Has a FakeVIM module;)
* Very fast and rock-solid stable
* Free (both in beer/libre)
* Cross-platform (used it on Linux/Mac/Windows. I prefer it to Visual Studio which is far too slow and has really wonky keyboard shortcuts)

Disadvantages:
* Have to use a windowing system. I still use VIM on remote systems.

There's just so many advantages of having an editor which understands your code model. Forget whether the function you're calling is camelCase or uses_underscores is a thing of the past for me resulting in most of my code compiling the very first time -- and when it doesn't, inline errors!

You can get your OSS fix here.
(For a generic project, just click New->Import Project->Existing project.)

QtQuick2 requires OpenGL. I didn't say I'm using OpenGL directly. However there is Qt3D and QtQuick3D that you might have a look at http://doc-snapshot.qt-project... http://doc.qt.digia.com/qt-qui... .
As for the graphs, there are some commercial graphs supplied by digia http://blog.qt.digia.com/blog/... or KDAB http://www.kdab.com/kdab-produ... or freely available QWT http://qwt.sourceforge.net/ .

https://qt-project.org/wiki/Qt...

Grab yourself :
- Qt http://qt-project.org/
- Bass API http://www.un4seen.com/bass.ht...

Get coding. Make it a simple MP3 player, or, expand on it until your hearts content.

Qt is great for making quick apps and learning a bit of C++ in the process.
The rest of time, you'll be learning "Qt functions", not a bad thing, as it pretty much contains everything you'll need to make a cross platform GUI program. Qt is quick to learn, very simple compared to most things out there.

If you prefer Visual Studio, or prefer more of a challange (and care about resource use of your program), use that with C++ and MFC, or C if you like.

Think simple, start simple then expand on your project if your enjoying it. This way, you'll learn quicker and get satisfaction out of doing it.

Best of luck.

I thought that Qt is available under a BSD license as well

Nope.

The PC-BSD project is developing a new open source (BSD license) desktop environment from scratch. The name of the project is Lumina and it will be based around the Qt toolkit

OK, so they're developing a BSD-licensed desktop environment atop a GPL v3/LGPL v2.1-licensed toolkit, right?

Qt Creator

Free, cross platform, open source. Who cares about Microsoft?

there's hope (and some evidence) that writers of toolkits such as Qt will pick up the slack.

Err, I don't know why you put it in such thin terms. Qt has pretty thoroughly integrated support for Wayland via QtWayland, which lets you write your own Wayland compositor using the QtCompositor class.

Architectures like Wayland directly benefit toolkits like Qt because it directly services what Qt was doing already: rendering in a buffer and displaying it.

You're just making stuff up as you go along. Seriously.

There is no useful string algorithm where the Nth unit of the string is "interesting" without first looking at the N-1 preceding units in order to calculate N

So obviously, the scenario of having fixed-format strings and having to extract something from their middle is not a useful string algorithm to you?

I suspect also you think UTF-16 is fixed-size

You really missed where I said "use UCS-2 - a fixed-width encoding, as opposed to say UTF-16". Use of any non-fixed-width encoding inside of a string class implies that you must use iterators instead of integer indices, otherwise every indexed string access has O(N) cost. The workaround is to embed index marks within the string, but then you have internal representation that can't interoperate as-is with anything else out there.

however you cannot change it to a version that does not throw exceptions on UTF-8 encoding errors

Qt doesn't explicitly throw. It is mostly exception safe when faced with exceptions thrown in user code, but that's it. None of its own code throws. QTextCodec IIRC by default replaces undecodable input by the unicode replacement character. Where the heck did you get the idea about exceptions and Qt?

Since moving to Open Governance, we're very open to external input: we're just very demanding, that's all. You can't expect us to just blindly accept any drive-by patch submission, or any security report from a self-proclaimed security expert. There's a process to follow, standards to reach, and it takes time to convince Qt maintainers that your patch or security concern is correct, let alone meets the quality standard required. If you're not prepared to stick around and defend your patch/security issue/bug report from robust questioning then why should we trust you? I'm a Qt maintainer, one of the first to be appointed under Open Governance from outside Nokia/Digia, and it still takes me several revisions before my patches get approved! It's hard work, simply because quality matters in a toolkit like Qt, especially with security issues.

As for the original article, well the issues were discussed with Qt in March last year, and our security expert at the time said we don't support running a Qt binary as setuid, nor does any gui toolkit, so the issue is not really our problem, the problem is with the fool who runs with setuid. However, in response to the publicity, he has now posted a patch to make this very explicit https://codereview.qt-project.org/#change,74531

You want Qt. Seriously. It'll be way more fun than developing for bare WINAPI.

> And Qt is not really C++ as it relies on MOC.

Who cares.

I always hear "OH MY GOD A MOC" and "NOT REAL C++" but I never hear any reason why it's actually a problem. And effectively (from the code you have to write) it's much prettier than comparable solutions.

> Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.
Qt is doing that: http://qt-project.org/wiki/New_Signal_Slot_Syntax

The file dialog used by Qt for Windows is the native one.

Even if you add extra widgets to the dialog, as Wireshark does?

And Qt is not really C++ as it relies on MOC.

Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.

C++11 is not even supported on most of the target compilers yet. And you can use c++ for signals/slots these days without string intermediaries.

http://qt-project.org/doc/qt-5.1/qtcore/qobject.html#connect-4

MOC just generates some signals/slots boilerplate code, which is C++ code. You might as well bitch that UIC is not C++ either because it generates C++ boilerplates from XML.

PS. the moderators utterly fail - the parent is neither informative nor correct. oh well. I guess I and everyone at Trolltech/Nokia/Digia didn't know they wasn't using c++ for last 10+ years.

When last I heard, a few years ago, QT had been acquired by Nokia. More recently, it seems that Nokia is being acquired by the borg(Microsoft).

It would seem that QT is to be owned by Microsoft. Is this correct? If so, what does that hold for QT? I realize that QT is LGPL or some such, but that doesn't mean that Microsoft won't ruin it or snuff it out. See Oracle and MySQL for a road map. Hopefully I am wrong.

Fortunately, yes, you are wrong. Digia bought the business side of Qt from Nokia in 2012. The free-software side of Qt is the Qt Project.

> As I'm getting back into C++ after almost 20 years and trying to start with Qt, I'd love to see some practical examples.

Sure. new signal slot syntax covers how to create anonymous lambda handlers for signals. No longer is it required to create methods on our public interface for a slot. This is pretty much The Big News (tm) when it comes to closures in Qt. But in general, I have late taking towards creating methods and interfaces which expect and rely heavily on callbacks-- and the new C++11 lambda expressions are now a very terse way to accomplish callback mechanisms in C++. Conceptually, it has always been possible, and the C++ 11 lambda extensions are effectively code inliners to accomplish the same task as creating a class to wrap state with a callback method-- which needed to be done by hand previously or attached to an existing class (further muddling its interface).

Qt 5.1 comes with Qt Quick Controls. These are widgets. Why they didn't hold the 5.0 release to add QML widgets beats me, but it's true.

See here: Qt Quick Controls

> - XRender allows you to do a lot of things "efficiently" but we can do them more efficiently with direct or client side rendering and just push a shared memory buffer to the server.

More efficiently? Only locally, remotely it depends on a lot of things (bandwith, latency).

> Qt5 will not use XRender.

I'm not so sure: this webpage list XRender http://qt-project.org/doc/qt-5.0/qtdoc/requirements-x11.html

Qt3 to Qt4 required you to change your code to support Qt4.

There will also be porting needed for Qt4 to Qt5 (e.g. QtWidgets being a separate module, changing QtGui include to QtWidgets). See http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5 for the full list of changes.

I used QAudioFormat from QtMultimedia in a project I was developing, This got moved from the QtMultimedia package to the qtmobility-dev package and from the QtMultimedia folder to the QtMultimediaKit folder.

Are you going to use the Qt Q... variants or the KDE K... variants of the different classes? Oh, and you cannot use them interchangeably (e.g. the file open/save dialogs).

Also, there is more emphasis in Qt on the QtQuick platform which is another moving target. Even then, are you going to use pure QtQuick, or use the new Ubuntu Phone/Tablet APIs they are creating?

Wow, you really had to think about that one, didn't you. Now tell us what critical software we all can't live without is written in scheme.

As for the rest, it would seem qt is pretty well covered.

KDevelop? Gorunka is talking about "Qt Creator" and you can find the Windows binary on their download page.

Thank you for making up for Slashdot's lack.

What he said is true but it misses the main points. The main thing you need to know is that it's based on the Meego system that powered Nokia's last successful phone, the Nokia N9. Like most of the new systems coming in (FirefoxOS for example) there is no hope of it immediately catching up Android and iOS on apps. HTML5 is becoming the cross platform way to quickly get that range so that's what they always push.

Tizen is more than that; It's NTT DoCoMo's new main smartphone platform and since NTT DoCoMo is where much of mobile innovation starts that makes it important. As ever, the best analysis is he one from Tommi Ahonen. NTT DoCoMo was strongly into Symbian and pushing Tizen will be their revenge for it being killed.

Tizen can support QT apps so the same ones that will work on Sailfish and Blackberry can easily work here. Also Tizen seems to be source code compatible with Bada which has been very successful in the newer mobile phone markets.

Yes. Qt will let you style the GUI with what is effectively CSS.

Native App
Qt App
There are huge differences. Qt doesn't do tool bars correctly. The text isn't aligned correctly in the ring menu. It uses a non-native widget to resize the tool bar. The icons look all out of place, doesn't used the native platform standard icon for the printing.

Actually most of the faults you mentioned in that example are are more to do with the program itself and not Qt. Qt does in fact do toolbars correctly on OS X (see the Qt documentation for specifics) but for some reason the TeXworks developers chose not to do it that way. Also, since icons are just loaded from image files there is no reason the OS X standard icons can't be used (I do agree that Tango icons look rather out of place there and I think some of them like the hand are even thr wrong resolution).

The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

Just compare (not, these are not exactly same thing, just pretty close):

• Qt5 QFile
• Java6+ java.nio.channels.FileChannel
• .NET FileStream
• Python 3 io module

Of these, Python's is least clear and useful in my eyes, by quite a margin. YMMV.

The project runs on Linux and on Nokia's N900 and N9 phones. I'm looking for help to port it to Symbian, Android, and iOS devices.

PySide is quite powerful as well, and can be used for both desktop and mobile development.

Sure, but what about your own types? Implementing COW is much harder than implementing a move constructor.

In case you are genuinely interested, it's not hard, because there's a helper class for that: QSharedDataPointer

I must admit, as someone who has coded in Qt, that is has some of the best documentation I've ever seen (from a developer's perspective). Just look at the docs on Containers . There's diagrams, examples, tables, and pictures.

Yes, they did. See the wiki page.

Somebody's porting Qt to it - looks like it's just the non-gui parts for now, though:

http://ssj-gz.blogspot.co.uk/2012/11/quickie-qtcorejs-proof-of-concept.html

Would be cool to be able to get Qt apps running in browsers without using the architecture-specific nacl.

There already is QT for NACL. It's a very interesting idea, you can deploy QT apps over Chrome instead of having to target a native desktop. If you build for x86 and ARM you've got a complete software stack for web-accessible native GUI apps that will run on any platform that Chrome runs on (which apparently will soon include Android).

Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.

And,

Qt itself will not throw exceptions. Instead, error codes are used.

http://qt-project.org/doc/qt-4.8/exceptionsafety.html

Which is not to mention the incoherent uses of exceptions and error codes in the C++ standard library.

I can't really answer that, though in my experience any declarative system has to be converted to old-fashioned native code and that always incurs some overhead. However, for a plain old GUI you're not going to see anything noticeable, and Qt quick has support for openGL and other 3d gfx that I would imagine just passes-through the relevant fast bits to the underlying system.

There are QML tutorials available.

It's actually not just a matter of the IDE alone. For me it's the combination of the IDE and Qt itself. People often forget Qt is not just a GUI toolkit - it provides a wealth of classes to implement really nice integrated applications.

Let me give one example to clarify this: suppose you want to write an application which needs to interact with web content, say, a map (Google Maps or OpenStreetMaps for instance). You want GUI controls on the C++ side which interact with markers on the map, you want to interact with the JavaScript in the map from your C++ code and pass data back and forth (like this: http://www.purplealienplanet.com/node/24). You want to integrate web content in your desktop application - It's all there.

Same if you want to use video, xml, link with a (embedded) database like SQlite, use GL content, use web services, gestures, (and many more: http://doc-snapshot.qt-project.org/4.8/classes.html), QtQuick for certain user interface (here: http://doc-snapshot.qt-project.org/4.8/qtquick.html), the signal/slot paradigm, the excellent documentation, etc. it's all there without having to go look for third pary libraries - plus it's all cross platform. You can take the same code, compile on Windows and move to Linux or Mac and it usually is just a matter of importing the project into Creator on the target platform and recompile it. All this is just fun to do with QtCreator because it is so well integrated and QtCreator is fine tuned for this.

When looking purely at the IDE, I guess both have their advantages and disadvantages - but the ease and speed with which Qt and Creator allow for the development of cross platform applications and the overall speed of Creator make it come out ahead of VS.

It's actually not just a matter of the IDE alone. For me it's the combination of the IDE and Qt itself. People often forget Qt is not just a GUI toolkit - it provides a wealth of classes to implement really nice integrated applications.

Let me give one example to clarify this: suppose you want to write an application which needs to interact with web content, say, a map (Google Maps or OpenStreetMaps for instance). You want GUI controls on the C++ side which interact with markers on the map, you want to interact with the JavaScript in the map from your C++ code and pass data back and forth (like this: http://www.purplealienplanet.com/node/24). You want to integrate web content in your desktop application - It's all there.

Same if you want to use video, xml, link with a (embedded) database like SQlite, use GL content, use web services, gestures, (and many more: http://doc-snapshot.qt-project.org/4.8/classes.html), QtQuick for certain user interface (here: http://doc-snapshot.qt-project.org/4.8/qtquick.html), the signal/slot paradigm, the excellent documentation, etc. it's all there without having to go look for third pary libraries - plus it's all cross platform. You can take the same code, compile on Windows and move to Linux or Mac and it usually is just a matter of importing the project into Creator on the target platform and recompile it. All this is just fun to do with QtCreator because it is so well integrated and QtCreator is fine tuned for this.

When looking purely at the IDE, I guess both have their advantages and disadvantages - but the ease and speed with which Qt and Creator allow for the development of cross platform applications and the overall speed of Creator make it come out ahead of VS.

I have recently migrated off of Visual Studio, onto Qt Creator because Creator has matured to be clearly better than Studio.

Can you (or anyone) give some clear examples on what you think is better about QT than VS? And don't say things like "the editor is clearly better" That doesn't really help me. What is features do you like that one has and the other doesn't?
I happen to like VS, the only other IDE I've used lately is xcode and it has some better autocompletion but otherwise I don't like it.

what about coming up with those open source IDE's?? I understand that they have never matched Visual Studio...

You know what this story actually tells? That even FOSS users don't like their IDE's. They want to use Visual Studio from Microsoft because frankly, it is much better than the open source alternatives.

...

If Microsoft is so bad then why the hell there isn't better open source versions of these things??

I have recently migrated off of Visual Studio, onto Qt Creator because Creator has matured to be clearly better than Studio.

Everyone has their own needs and preferences, I have copies of Studio, Eclipse and Creator on all of my machines at work and home - Eclipse is a necessary evil for some targets, but for the desktop, I was using Studio because it was the better environment - until the last six months or so.

Free, cross platform, and awesome:

http://qt-project.org/