Cairo 2D Graphics May Become Part of ISO C++
An anonymous reader sends this news from Phoronix:
"The C++ standards committee is looking at adopting a Cairo C++ interface as part of a future revision to the ISO C++ standard to provide 2D drawing. Herb Sutter, the chair of the ISO C++ standards committee, sent out a message to the Cairo developers this week about their pursuit to potentially standardize a basic 2D drawing library for ISO C++. The committee right now is looking at using a C++-ified version of Cairo. Sutter wrote, 'we are currently investigating the direction of proposing a mechanically C++-ified version of Cairo. Specifically, "mechanically C++-ified" means taking Cairo as-is and transforming it with a one-page list of mechanical changes such as turning _create functions into constructors, (mystruct*, int length) function parameters to vector<struct>& parameters, that sort of thing — the design and abstractions and functions are unchanged.'"
C++ stopped being a fully-humanly comprehensible language a long time ago. Might as well just add more crap to it like it's going out of style.
This is redundant. High level concepts like drawing graphics are always going to be system dependent, and today's operating systems come with them already. I don't see why having this as part of the C++ base library benefits..
Blitting to the screen may be OS-dependent, but rendering to a canvas need not be.
Cairo is a great library, I've used it and found it very easy, but it's not remotely approaching a standards-quality design.
Yeah, to make it C++ standards-quality they'll need to make it much less intuitive, add tons of templates to make it unreadable, and change the method names to something that makes much less sense...
Is there anything it cannot do?
Garbage collection.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.
Firstly, I take issue with your premise that Cairo is no more than a toy and useless in actual work.
Secondly, One very important usecase for a simple drawing library in the standard is to provide an easy route for novices to write cool, interactive and meaningful programs, without needing to write several hundred lines of scaffolding code and be well-versed in 6 different layers of abstraction from OSes to frameworks and graphics API.
I don't know how other people learned programming, but in my case, the most engaging things I wrote all those years back in BASIC and Pascal (under DOS) were graphical programs in nature (extremely simple games, GUI-like apps that didn't really need the GUI, function plotting and other graphical toys, etc.) I'm guessing that I'm not unique in the fact that having access to simple, straightforward, inefficient, well-documented, built-in 2D graphics API led me to all sorts of cool experiences in programming and (majorly) determined my pursuit for the rest of the two decades since.
Now, it is obvious that there will always be more novice programmers than experienced ones, so, I don't see the problem with the ISO C++ committee to explore standardizing such a library. Do you, really? Who is this going to hurt?! For most of us, this is pretty much out of our way, since we either write more serious graphical applications and need platform-specific, performance-oriented APIs that offer much more control and features, or we haven't written anything that needed a 2D immediate-mode graphics API in years. So, I ask the Slashdot readership again, what's wrong with standardizing a simple, straightforward 2D drawing API to help the novices and the occasional non-performance-sensitive drawing needs of the community?
Qt doesn't get out much beyond Win/Lin/Mac.
Qt isn't available for enough platforms because it only runs on Windows, Mac, Linux, Android, iOS, Blackberry, Kindle, vXWorks, BSD, Solaris, Haiku, WebOS, OS/2, Tizen and AmigaOS? Anything that passes the "does it run on Amiga?" test is good enough for me.
This space intentionally left blank
So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.
There was a keynote done by Herb Sutter this past September and at roughly the 57 minute mark of his presentation Keynote: Herb Sutter - One C++ he shows a 15 LOC example of numbers being input and then output sorted. He then said, "We need to get past the VT100 era." He continued saying that the standard C++ program cannot even exercise the abilities of the VT100 which has underscore and bold, etc. Pure, portable C++ code cannot even drive a 1970s era VT100.
If you continue watching you'll see the point Herb is trying to make and that point may help explain why they are looking to do this.
Unless things have changed I never paid Qt any attention because it is dually licensed and therefore not truly free software and its ownership keeps changing between commercial companies.
Last I checked Qt is "free" for open source projects but requires an expensive commercial license for anything else.
You last checked about a decade ago, then.
Here's how it works now (and has worked for a while now): Qt is Free. Not "free", but Free. It's under the LGPL. And the GPL.
"But it's owned by a commercial company, and they can just close off the source."
Nope. Still stays open. Back a few years ago, the KDE group got a special concession from Nokia. They set up the KDE Free Qt Foundation; if the commercial owners of Qt (Digia) stop releasing Qt under the LGPL and GPL3, KDE has the right to make the whole thing BSD. Irrevocably. And the agreement stays, even if Digia is sold, bought, etc. Read the link if you'd like to know more.
Basically, Qt is Free. If the owners ever stop releasing it for Free, KDE gets to release it under an even more Free license.
Qt has been Free for a while. Qt is still Free. It will remain Free
The real litigious bastards...