Slashdot Mirror
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.
i sincerely hope cairo itself remains 1. pure c and 2. as a project, entirely unconstrained by complaince to whatever 'standard' these c++/microsofty goons want. if they want to take a snapshot of cairo's api as a model for some c++ api, fine, whatever, couldn't even stop 'em if we tried. though the effort would be better spent finding more active maintainers for cairomm.
but cairo underlies current versions of major linux gui toolkits. i can't help but view this as some sort of convoluted gambit on microsoft's part to infest it with bureaucracy and c++ architecture astronautism and eventually seize control of the direction or just kill it.
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
While AGG is one of the most cleanest and high quality 2D rendering APIs, it's improbable that AGG will be accepted by the c++ committee, Herb Sutter works for microsoft, and AGG's author is very critical of many graphical features of windows, like the sub par font rendering. An example of this is the the dialog window for enabling high dpi font scaling.
http://i1.wp.com/www.istartedsomething.com/wp-content/uploads/2006/12/dpi480_3_l.jpg
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.
Okay you don't like C++, that much is clear but...
Hey let's get a standardized vector and 2D drawing library going! Fuck the hardware or implementation details which indicate you'd be better off not limiting the dimensions to 2. Never mind the fact that we'll be filling triangles on a GPU for any sort of efficiency at all. Nope. Fuck starting at the actual primitives present and working up from there, let's do the top-down approach yet again -- When the performance conscious folks include messed up limitations, like the Diamond Inheritance pattern (Which has no reason to exist, variable placement should be virtual too, dimwits).
Cairo is not limited to outputing raster graphics. It also supports vector formats such as PostScript, PDF and SVG. You may be doing the work on the GPU, or the GPU may have nothing to do with it at all. Even for raster graphics, it is not guarnateed that a GPU is even present or the fastest option. Seperation of vector 2D graphics and 3D graphics output is a long established tradition and hardly a design descision of the C++ standards commitee.. They are after all only looking to standardise on an existing C library in widespread use.
Yeah, I'll stick with C. At least it doesn't pretend to do anything but present the Von Neumann architectural constructs to me and let me build my OOP, etc atop them. It's still not optimal because it has the moronic assumption that functions should be on the stack and not the heap -- thus hindering or outright preventing closures, co-routines, and arbitrarily limiting recursion despite the system's available RAM -- but it's miles beyond C++ in terms of idealic design splattering all over the hard brick wall of reality's implementations. I mean really, if you can't use method overloading properly with templates and polymorphism then the language is broken by design, and there are no complete implementations.
C++ sure has its warts and I am definitely keeping my eye on Rust and D but what exactly would you consider a good way of handling method overloading + templates + polymorphism, and as a C fan why do you want to introduce such complexity to your code? KISS works well in C++ as well. On a side note C++ does handle the combination of features (http://stackoverflow.com/questions/4525984/overloading-c-template-class-method), albeit it is hardly pretty
Hey! I got an idea. You know what would be nice in C++? How about a standardized ANSI terminal interface, like VT100 -- Get ncurses into the spec. Oh! And you know what else? How about RMI! Yeah! Oh oh oh!! I got one I got one! INTER-fucking-FACES for IPC! Yeah! So you could query a program's interface and pass data between processes transparently in a language independent way -- and the doc comments could be lexical tokens too, so that if the .dat file was present even a terminal mode program could query a program's usage without needing a manually constructed manpage, and other programs could implement the same interfaces allowing us to assemble programs from sets of features. You know, something smarter than STDIN and STDOUT and a char**? Something actually fucking useful for a damn change?
If you want IPC abstractions use Boost (http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess.html). Maybe one day these abstractions will be added to the standard library as well. You could also look at platform specific IPC solutions such as COM, which seems fairly close to what you describe. However, until there is a commonly accepted base set of features which can be supported on all major platforms, looking to the C++ standards committe to provide guidance seems very odd to me.
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...