Slashdot Mirror

what would be your baseline choice
In your case: C++ and Qt, https://www.qt.io/

That was probably the status 20 years ago.
Check this out: From Qt 5.9 onwards, the Green Hills Software INTEGRITY Real-Time Operating System (RTOS) is a supported platform.
The Green Hills INTEGRITY Real-Time Operating System (RTOS) is widely used in safety- and security-critical systems.

This means you got a lib with Unicode, left to right, upside down writing, i18n as simple as breaking the egg and layout management. All the elements fall in place automatically, regardless of screen size and you can have the font adapting to the given DPI. It's all there - even Qt!
You don't really want a multi-user, multi-processing system for something like that. It can all cause unnecessary problems. It's straight down the line programming here: Input -> Action -> Output.

And we can even go one more level deep with the QPushButton example. QommandLinkButton inherits from QPushButton, which inherits from QAbstractButton, which inherits from QWidget which inherits from QObject. The fact that you said inheritance is rarely used by Qt for GUI programming is just absolutely hilarious.

Go read Qt's commercial terms,

Maybe YOU should read them. You need a commercial license if you want to produce closed-source proprietary products. You can still sell your product / offer support, etc., without a commercial license, you just have to provide source.

And Qt is not the only game in town.

Which is not true. I worked for a small company selling close source Qt applications. We started out using the LGPL version of Qt 4.3 and once we made enough revenue we switched to the commercial license so that we could use some of their close source libraries. We used v4.3 through v5.5 and the quality and support was excellent. Going from 4.x to 5.x was painless so claims that the product is poorly supported are bunk.

Go read Qt's commercial terms,

Maybe YOU should read them. You need a commercial license if you want to produce closed-source proprietary products. You can still sell your product / offer support, etc., without a commercial license, you just have to provide source.

And Qt is not the only game in town.

Loved the part about how small developers can't afford QT, nice touch.

Go read Qt's commercial terms, you ignorant fuckwit.

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

Qt can do this easy-peezy. It won't even take day. I've done a similar thing, though not with shaders, but they added the shader logic recently. My usage was prior to that.

Qt can do this easy-peezy. It won't even take day. I've done a similar thing, though not with shaders, but they added the shader logic recently. My usage was prior to that.

If you're willing to pay money for an IDE, CLion is fantastic.

If you're not willing to pay money, Qt Creator is also pretty good, and despite having "Qt" in the name it is perfectly good at working on non-Qt projects.

Anybody who tells you to use Eclipse can't be trusted.

When did LGPL become an issue? https://blog.qt.io/blog/2016/0...

Much more likely to involve Qt for Android.

That's the right direction. Apple already has a pretty good version of it. (See below.)

Bounds checking C like this now is weak and very, very late:
https://gcc.gnu.org/ml/gcc/199...
https://www.lrde.epita.fr/~aki...
http://blog.qt.io/blog/2013/04...
http://valgrind.org/docs/manua...
https://en.wikipedia.org/wiki/...

But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.

http://www.cocoawithlove.com/2...

Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.

I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.

Take a look at the Qt framework. It's wonderful for cross-platform application development. Qt coupled with improvements in C++11 (smart pointers, auto, etc) have completely changed my opinion of C++ for the better. You should not need to use "new" unless creating a QObject or smart pointer and both will handle memory cleanup themselves. You shouldn't really have to use delete. Others have written about this more coherently and succinctly than I'm able to right now, but I encourage you to check it out.

The Qt IDE is quite nice and the official documentation is very good. There are some good tutorials out there and there's enough of a community that it's easy to find Qt-specific answers with a web search. If you're at all a monkey-see-monkey-do kind of learner then something like VoidRealm's series on learning Qt/C++ could be helpful. He's got a great voice that I haven't found annoying after listening for many hours. Some of that series is basic stuff you can skip over but even if you're familiar with a topic but want to learn "the Qt way" then I'd recommend playing it back at an increased speed until something catches your interest.

So you specifically said not C++ and I suggested it anyway since you really do not have to worry about allocating and deallocating memory like you once had to (use QObjects and assign them a parent if they're not automatically assigned one and use smart pointers for anything else you want on the heap). In that same vein of not listening to your requirements, Qt probably qualifies as a corporate language/framework. It is open source (LGPL/GPL but also has a commercial license for $$) and welcomes contributions from the public. I don't see this as a bad thing myself since the money brought in from commercial subscriptions helps pay for development and growth of the framework. Also I use Qt for both personal and open source projects so have no issues with their licensing, but if your use-case means you'd have to pay I think it's a very worthwhile business expense. Also pertinent is that Qt is becoming more and more used in e.g. Fortune 500 companies and has a symbiotic relationship with KDE. I think Qt's future looks very promising, which is important to me when investing a lot of time into learning a new technology.

It's definitely compiled. It creates fast cross-platform applications and making UIs is simple. It's easy to make it talk to databases including but not limited to embedded SQLite, PostgresQL, MySQL, Oracle, and SQL Server.

Check it out. C++ is a changed beast. Its creator and other experts flat out say to use a subset of all its features, which include some major improvements in C++11/14. Forget your preconceived notions or past experience and give it a shot. Memory management is much simpler now. Qt makes it even easier and adds a whole lot of extras, including a great IDE.

https://wiki.qt.io/Licensing-t...

So basically, if I take the gamble and turn out wrong, I can end up with some OSS SJW making my life miserable. You can see why anyone would be nervous to produce closed source code with QT if they arn't a megacorp.

Cathegorically, *no*. X11 forbids the application from having any say over where its windows appear. At best it can give a hint. The Window manager is totally free to ignore this hint

From the QT documentation:

Furthermore, a toolkit cannot simply place windows on the screen. All Qt can do is to send certain hints to the window manager. The window manager, a separate process, may either obey, ignore or misunderstand them. Due to the partially unclear Inter-Client Communication Conventions Manual (ICCCM), window placement is handled quite differently in existing window managers.

X11 provides no standard or easy way to get the frame geometry once the window is decorated. Qt solves this problem with nifty heuristics and clever code that works on a wide range of window managers that exist today. Don't be surprised if you find one where QWidget::frameGeometry() returns wrong results though.

Well, because you can't write native ios apps in anything except Apple's approved garbage language.

False. You could use Object Pascal or C++ or C# or JavaScript or any language which provides you with a toolchain to target iOS.

Object Pascal and C++ and C# and JavaScript to name a few. You can program for iOS using any language which provides you with a toolchain to target iOS.

There are NOT a lot of choices of languages when it comes to that.

Not true. In addition to Objective C and Swift you can program for iOS in, for example, Object Pascal or C++ or C# or JavaScript.

Not true indeed. You and I have a huge difference in what "a lot" means. A lot of difference.

There are NOT a lot of choices of languages when it comes to that.

Not true. In addition to Objective C and Swift you can program for iOS in, for example, Object Pascal or C++ or C# or JavaScript.

new standard bytecode

That will be WebAssembly. With WebAssembly and a compiler that supports it you can conceivably take a desktop application, compile it to wasm and run it in your web browser.

We really need something like XUL or XAML made in to a web standard.

I don't think we do. For a WebAssembly application we can use 2D canvas or WebGL for the GUI. Any development environment built for making cross platform GUI applications (like Qt or Delphi) is in a good position to take advantage of WebAssembly in this way once wasm makes its way into browsers.

apparently you haven't heard of Qt because it works like shit all of those platforms.

Fixed that for you.

it's not easy to write native apps to run on both Android and iOS, never mind considering Windows Phone and BlackBerry

apparently you haven't heard of Qt because it supports all of those platforms.

Native apps from "garage" developers: zero users on Wii U. Web apps from "garage" developers: greater than zero users on Wii U.

You're not genuinely trying to argue that the Wii U is a significant application platform, are you? It's a games platform for children, and the least successful console of the current generation by a mile. You'd be crazy to target it for applications, native or otherwise.

Even HTML5 game support is weak on the Wii. No support for sound? Does it even have WebGL support? Nope, guess not. And look at this weird non-standard stuff. Effortless support it ain't.

You haven't provided evidence for your claim that web development with all its current limitations, with all the vagaries of differences between browsers is more efficient or productive than native cross platform application development. Some me some real, measurable outcomes instead of making vague assertions.

First, there's the overhead of obtaining hardware on which to test the build for each platform. You essentially have to buy a Mac, buy a copy of Parallels, and buy a retail copy of Windows.

Welcome to professional development. And as you said yourself it's the same deal for web development. What, you got your Wii U for free in a box of cereal or something?

That's fine once your company is big enough to afford "the right development environment".

Many cross platform languages, libraries, and development environments are free. You can use GCC or Rust or Python or Free Pascal and their associated libraries, or use none of them and use something else. You want to do GUI applications? Look, here's an option. Here's another. Use what you want, I don't care.

There are more options available now than ever. Small companies can easily find the right development environment for them for native application development for as much or as little money as they want to spend.

I can't comment on Atom (or Xcode, for that matter).

I can comment on UNIX-based editors and IDEs, though.

There's Eclipse's C/C++ module. It runs fine on Linux.

Emacs might suit your needs as well, but getting it set up with all the bells and whistles of an IDE is a bit of a pain. There are projects that help with that, however, like spacemacs (defaults to vi keybindings, but supports emacs keybindings as well). I use emacs with a custom config, but I haven't done much C++ since I switched from vim. What I have done has worked OK, but I'm sure my config has room for improvement.

QT Creator is cross platform and supports C++. It can do non-QT projects just fine.

There's Anjuta and KDevelop as well, but I haven't used either of those in quite some time and have no idea what the status is. KDevelop used to be used quite a bit for KDE development, which is C++.

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

I live in Montreal -- two official languages French/English. I also do development for Latin America. QT bloatware is great. User selects his language and there we are, one software for E/F/S.

Compile the libs statically and link only what you need?

Yeah, that would work, except that Qt is licensed under the viral LGPL if you aren't paying big bucks for a commercial license.

Look what the Qt licensing FAQ says (emphasis added):

The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.

and

The user of your application has to be able to re-link your application against a different or modified version of the Qt library.

So dynamic linking is pretty much the only option for many Qt users.

Now that you know this, you can quit being such a smug fuckface and realize that the bullshit you're suggesting is just that: bullshit. You can also apologize to us for subjecting us to your idiocy.

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

I was bored at work and checked libqt5core and libqt5gui vs gdk/gtk. Those two qt5 components amount to ~10 MB vs ~5MB for gdk/gtk. QtQuick probably gets that well over 20MB.

But you're not going to use either on some Cortex-M MCU anyway, so who cares.

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

http://doc.qt.io/qt-5/androidg...

Qt 5.x offers IOS / Android and Windows Phone App development

Qt5.4 supported platforms

You could of course a popular SDK that works on desktops as well. But who would do that?

Xfce 4 has been a great desktop environment, but it's now clear that GTK+ is a dead end.

GTK+ is rife with serious problems. The first is that it's affiliated with the GNOME crew. Their grasp of sensible, proper UI design is very suspect, especially after the GNOME 3 disaster. For example, these are the kind of people who took gedit, GNOME's text editor, and changed it from this sensible, usable UI to this hideous, unusable UI. You can even see a screenshot of this shitty UI in the Xfce 4.12 tour! It has, sadly, been infected by this bad UI design.

The portability of GTK+ is, to put it politely, utter rubbish. X11 is the only platform where it isn't a disgrace. It "works" under Windows and OS X, but if by "working" you mean it runs but is generally unusable. I haven't been able to ever get it working properly under OS X. It didn't even get to the point where it showed a UI, the last time I tried it. Inkscape is horrible. GIMP is horrible. Every other GTK+ app I've tried on Windows or OS X has been absolutely horrible.

It will be a lot of work, but they need to port Xfce from GTK+ to Qt. Qt is a much better toolkit. It looks great. It works (and actually works, in that the resulting software is perfectly usable!) pretty much everywhere.

GTK+ had its place in the late 1990s. But we're well past that time now. Qt is the best toolkit to use these days. I truly wish that the Xfce devs would port from GTK+ to Qt, so that we users can use it on Windows and OS X, as well as getting a much better experience under Linux.

Xfce 5 has to be based on Qt.

I like Inkscape. It's generally a great program. But its most serious problem is that it uses GTK+ as its toolkit.

GTK+ is rife with serious problems. The first is that it's affiliated with the GNOME crew. Their grasp of sensible, proper UI design is very suspect, especially after the GNOME 3 disaster. For example, these are the kind of people who took gedit, GNOME's text editor, and changed it from this sensible, usable UI to this hideous, unusable UI.

The portability of GTK+ is, to put it politely, utter rubbish. X11 is the only platform where it isn't a disgrace. It "works" under Windows and OS X, but if by "working" you mean it runs but is generally unusable. I haven't been able to ever get it working properly under OS X. It didn't even get to the point where it showed a UI, the last time I tried it.

It will be a lot of work, but they need to port Inkscape from GTK+ to Qt. Qt is a much better toolkit. It looks great. It works (and actually works, in that the resulting software is perfectly usable!) pretty much everywhere.

GTK+ had its place in the late 1990s. But we're well past that time now. Qt is the best toolkit to use these days. I truly wish that the Inkscape devs would port from GTK+ to Qt, so that we users can use it on Windows and OS X, as well as getting a much better experience under Linux.

I'm just a designer, and I've never done any C++ programming, but I'm thinking that maybe I'll have to learn it so I could potentially contribute to any effort that arises to fix the UI of Inkscape.

http://www.qt.io/qt-in-use/