Cairo Proposed To Become Part Of ISO C++

[zester]

Surprisingly to me at least is that openvg has very little to no hardware adoption. The implementations that exist are apparently software.I read about this on the fxos mailing lists FYI.
IOW, it's dead Jim.

What are you talking about, there are almost a billion devices that have support for OpenVG.

[BlackStar]

And iostreams do belong there because? If it's a matter of being a purist about what is a language, IO is not part of a formal language, so it shouldn't be part of the language specification. And luckily it isn't, and UI isn't proposed to be part of the language specification, either. One is, and the other is being proposed to be, part of the standard library specification, which is not the language, but a set of tools to use with it. You can use the language without EVER calling any piece of the standard library.

You are arguing semantics.

Give me *one* good reason why a UI library should be part of the standard library specification for C++.

[mrugiero]

You are arguing semantics.

Give me *one* good reason why a UI library should be part of the standard library specification for C++.

It's not semantics, it's actually reasoning. If it would be in the language, that'd be a real problem, and I'd be strongly against it. But it's not.
One good reason? Most software nowadays needs a GUI. A standardize way to make a GUI can alleviate common portability problems. That's what standards are for, to be able to make things compatible. If the standard gets adopted, it eases deployment (I have seen users scared because some small program installed lots of things they didn't know about, like Python or Qt; those users, not familiar with these things, though it might have been a virus or the like), as you only pack what you coded, not a huge set of libraries.
Lastly, I see no reasons not too. You could say "bloat", but as long as it's kept modular (which I mentioned an effort should be put on that), it won't add bloat to your programs. Using vectors should not drag behing a Cairo derivative library.

I'm not really in favor, but I see no reasons to oppose either. I'd probably stick to Qt for UIs anyway for the coming years, as standards need time for development, leave alone adoption.

EDIT: Also, you are the one stating "it doesn't belong", maybe you should give some reasons for it "not belonging".

[BlackStar]

It's not semantics, it's actually reasoning. If it would be in the language, that'd be a real problem, and I'd be strongly against it. But it's not.
One good reason? Most software nowadays needs a GUI. A standardize way to make a GUI can alleviate common portability problems. That's what standards are for, to be able to make things compatible. If the standard gets adopted, it eases deployment (I have seen users scared because some small program installed lots of things they didn't know about, like Python or Qt; those users, not familiar with these things, though it might have been a virus or the like), as you only pack what you coded, not a huge set of libraries.
Lastly, I see no reasons not too. You could say "bloat", but as long as it's kept modular (which I mentioned an effort should be put on that), it won't add bloat to your programs. Using vectors should not drag behing a Cairo derivative library.

I'm not really in favor, but I see no reasons to oppose either. I'd probably stick to Qt for UIs anyway for the coming years, as standards need time for development, leave alone adoption.

EDIT: Also, you are the one stating "it doesn't belong", maybe you should give some reasons for it "not belonging".

It is arguing semantics, because implementing the C++ language without implementing the C++ standard library is not possible. Like it or not, the language specification and the standard language specification are inseparable.

It does not belong because the UI paradigms between, say, a touch-based Android app and a Linux desktop application are completely different, yet the UI standard would have to support both (otherwise it would be useless in the first place.) It is not as simple saying:

std::ui::window foo(640, 480);
std::ui::draw_line(foo, 0, 0, 5, 5, std::ui::color::blue);
std::ui::draw_text(foo, std::string("Hello, world!"), std::ui::make_color(100, 100, 0));

You'd have to standardize on application lifetime management, which is deeply platform-specific. You'd have to standardize on things such as DPI awareness; text rendering; event notifications; modal/non-modal windows; global vs local menus; IMEs; and all the other garbage that comes with UIs (think Qt).

If you say "we just specify the interface, the details are left to the stdlib implementor", you are going to get something as badly specified as the "export" keyword: a feature so out of touch with reality that no compiler will ever implement.

If you say "no UI stuff, just a simple 2d drawing API", you will get something that noone will use. What's the point of a drawing API if you still need Qt to create a window?

I'm saying none of this is worth the effort. I would prefer the committee to focus on issues for C++ that affect real-world code. Make it so Qt 6.0 won't need MOC anymore. Make it so ITK does not take 45 minutes to compile on a 4-core system with a SSD. Make it so we don't need to combine std::string, QString, vtkStdString all in the same project.

The UI angle is well-covered by a dozen third-party libraries, as it should be.

Edit: the last language I used that had a built-in drawing API was GW-BASIC. Think about that for a moment

[erendorn]

It is arguing semantics, because implementing the C++ language without implementing the C++ standard library is not possible. Like it or not, the language specification and the standard language specification are inseparable.

It does not belong because the UI paradigms between, say, a touch-based Android app and a Linux desktop application are completely different, yet the UI standard would have to support both (otherwise it would be useless in the first place.) It is not as simple saying:

std::ui::window foo(640, 480);
std::ui::draw_line(foo, 0, 0, 5, 5, std::ui::color::blue);
std::ui::draw_text(foo, std::string("Hello, world!"), std::ui::make_color(100, 100, 0));

You'd have to standardize on application lifetime management, which is deeply platform-specific. You'd have to standardize on things such as DPI awareness; text rendering; event notifications; modal/non-modal windows; global vs local menus; IMEs; and all the other garbage that comes with UIs (think Qt).

If you say "we just specify the interface, the details are left to the stdlib implementor", you are going to get something as badly specified as the "export" keyword: a feature so out of touch with reality that no compiler will ever implement.

If you say "no UI stuff, just a simple 2d drawing API", you will get something that noone will use. What's the point of a drawing API if you still need Qt to create a window?

I'm saying none of this is worth the effort. I would prefer the committee to focus on issues for C++ that affect real-world code. Make it so Qt 6.0 won't need MOC anymore. Make it so ITK does not take 45 minutes to compile on a 4-core system with a SSD. Make it so we don't need to combine std::string, QString, vtkStdString all in the same project.

The UI angle is well-covered by a dozen third-party libraries, as it should be.

Edit: the last language I used that had a built-in drawing API was GW-BASIC. Think about that for a moment

I agree that I do not see exactly how it is supposed to be implemented, although it seems there are "optional" parts of the standards.
But then I never wrote graphical interfaces (except some QML, or graphical based stuff), so I have no idea of the use cases.
It would be interesting to know who needs that and for what.

What I would like to see in C++, are modules!

[a user]

I agree that I do not see exactly how it is supposed to be implemented, although it seems there are "optional" parts of the standards.
But then I never wrote graphical interfaces (except some QML, or graphical based stuff), so I have no idea of the use cases.
It would be interesting to know who needs that and for what.

i can give you a usecase from my study times:
the reason #1 why most of the students used java was because of easy access to a simple and portable gui and canvas drawing. if c++ would have some basic ui and drawing abilities most of them wouldn't had used java at that time. adding addition external libs just for that use case is highly unpractical.

but there are also many other usecases.

i would very appriciacte some basic gui/drawing abilities. the standard libs already have basic methods for more or less all other human/mashine interfaces but nothing for the graphical and one of the most important ones.

[Vim_User]

I can show you some headless acceleration hardware.
http://en.wikipedia.org/wiki/Nvidia_Tesla

And now show me the mass of webservers actually using that hardware. It is as simple as this: There is a use for unaccelerated graphics functions and therefore it is plain wrong to assume that people that produce libraries for this use are fools.

[BlackStar]

What I would like to see in C++, are modules!

Indeed! Modules are by far the biggest gap between a modern programming language and C++. They should have been added 15 years ago, but better late than never.

i can give you a usecase from my study times:
the reason #1 why most of the students used java was because of easy access to a simple and portable gui and canvas drawing. if c++ would have some basic ui and drawing abilities most of them wouldn't had used java at that time. adding addition external libs just for that use case is highly unpractical.

So you would like to see std::ui because java.awt is nice for beginners. Right.

Not only is this a terrible reason, java.awt is also the perfect example why adding a UI library to the standard library sucks. It's slow, it's ugly and it produces terrible UIs that no user would ever want to touch with a ten foot pole.

There is a reason why everyone hates Java UIs, and java.awt is a big part of that reason.

i would very appriciacte some basic gui/drawing abilities. the standard libs already have basic methods for more or less all other human/mashine interfaces but nothing for the graphical and one of the most important ones.

Human-machine interfaces like mice, keyboards, touchscreens, microphones, cameras? C++ offers nothing of the sort, you must be looking at a different language entirely.

[oleid]

I agree that I do not see exactly how it is supposed to be implemented, although it seems there are "optional" parts of the standards.
But then I never wrote graphical interfaces (except some QML, or graphical based stuff), so I have no idea of the use cases.
It would be interesting to know who needs that and for what.

Cairo is perfect for generating vector graphic file output. I use it for plotting graphs of simulation data to PDF files. I can use the very same plotting function for bringing the stuff to the screen, e.g. using SDL (via image surfaces) or GTK+ (using native, accelerated calls, e.g. OpenGL). But, as I understand it, a GUI toolkit is beyond the scope of this proposal.

[erendorn]

stuff

stuff

thanks