GUI

[nuclearr...@gmail.com]

Sir, 

I am a die-hard c++ fan. I have noticed that languages like Java and C# have a built-in GUI libraries. This is not the case with C++. There are hundreds of 3-rd party libraries. MFC is only supported by Visual Studio. What we can do is have all the libraries carefully examined and merged into a new one. Or, else standardize a library and include in c++ standards.

Thank you.

Yours faithful,

Hemil R.

[D. B.]

A full GUI library is way, way beyond the scope of the Standard.

but even if it wasn't, this is funny:

What we can do is have all the libraries carefully examined and merged into a new one

Who's going to do this? Have you made a start? Good luck.
 

[Ville Voutilainen]

On 12 October 2016 at 12:42, D. B. <db0...@gmail.com> wrote:
> A full GUI library is way, way beyond the scope of the Standard.

No it's not, there's no such rule.

[Victor Dyachenko]

On Wednesday, October 12, 2016 at 12:25:34 PM UTC+3, nuclearr...@gmail.com wrote:

Sir, 

I am a die-hard c++ fan. I have noticed that languages like Java and C# have a built-in GUI libraries.

There is no single "Java GUI library". See here http://stackoverflow.com/questions/7358775/java-gui-frameworks-what-to-choose-swing-swt-awt-swingx-jgoodies-javafx

For C++ we have at least Qt and wxWigets. Why do we need to put them into Standard? To have big deprecated parts in the Standard in the future?

Why don't we have universal GUI library in C++? Because there is no the only way to implement GUI.

[Ville Voutilainen]

On 12 October 2016 at 13:50, Victor Dyachenko

<victor.d...@gmail.com> wrote:
> For C++ we have at least Qt and wxWigets. Why do we need to put them into

I don't recall anyone suggesting putting Qt or wxWidgets into the standard.

> Standard? To have big deprecated parts in the Standard in the future?

Why would such deprecation be necessary?

> Why don't we have universal GUI library in C++? Because there is no the only
> way to implement GUI.

There's not only one way to implement most of the standard library,
which is one reason why
it doesn't mandate any particular implementation, so that's a non-issue.

[Victor Dyachenko]

On Wednesday, October 12, 2016 at 1:54:53 PM UTC+3, Ville Voutilainen wrote:

On 12 October 2016 at 13:50, Victor Dyachenko
<victor.d...@gmail.com> wrote:
> For C++ we have at least Qt and wxWigets. Why do we need to put them into

I don't recall anyone suggesting putting Qt or wxWidgets into the standard.

I just wanted to say that one can write portable GUI today using C++ without having "C++ standard library".
 

> Standard? To have big deprecated parts in the Standard in the future?

Why would such deprecation be necessary?

Why std::auto_ptr, std::strstream et al were deprecated? Because today we have better solutions. GUI and GUI libraries are evolving. Imagine MFC mid-90's vintage being the part of Standard. GUI system is a very sophisticated thing. Much more complex than vector class or sorting algorithm.

[Victor Dyachenko]

I just wanted to say that one can write portable GUI today using C++ without having "C++ standard library".

Must be "C++ standard GUI library"

[Victor Dyachenko]

On Wednesday, October 12, 2016 at 2:05:26 PM UTC+3, Victor Dyachenko wrote:

> Standard? To have big deprecated parts in the Standard in the future?

Why would such deprecation be necessary?

Why std::auto_ptr, std::strstream et al were deprecated? Because today we have better solutions. GUI and GUI libraries are evolving. Imagine MFC mid-90's vintage being the part of Standard. GUI system is a very sophisticated thing. Much more complex than vector class or sorting algorithm.

And again. There were attempt in the Java-world to create universal GUI - AWT. They are failed. And Swing as replacement failed too.

[mihailn...@gmail.com]

The reason why there is no standard GUI module has been answered by the committee directly - there is no ready library, which everyone will agree upon to be included.

Writing one from scratch is out of question - it is way too much work without a clear, well defined scope. 

So, the committee stepped back and decided to include Graphics 2D lib, the logic being, one should be able to draw on the screen, not just output to the console.

I personally am skeptical about this one as well, but that's another story.

[Ville Voutilainen]

On 12 October 2016 at 14:05, Victor Dyachenko

<victor.d...@gmail.com> wrote:
>> I don't recall anyone suggesting putting Qt or wxWidgets into the
>> standard.
>
> I just wanted to say that one can write portable GUI today using C++ without
> having "C++ standard library".

One can write a whole lot of things without using the standard library
for that. The issue
there is that such solutions are less portable than they would be as
standard features,
and the availability is another issue.

>> > Standard? To have big deprecated parts in the Standard in the future?
>> Why would such deprecation be necessary?
> Why std::auto_ptr, std::strstream et al were deprecated? Because today we
> have better solutions. GUI and GUI libraries are evolving. Imagine MFC

GUI libraries, and especially their APIs, don't seem to evolve nearly
as fast as some
people like to think. But if your view is that it's better to have
nothing than to have something
in the standard library, I doubt I'm going to agree with that view.

> mid-90's vintage being the part of Standard. GUI system is a very
> sophisticated thing. Much more complex than vector class or sorting
> algorithm.

Yeah, which is actually a fair reason to have a standardized GUI
library or to have standardized
facilities that help GUI programming.

[Victor Dyachenko]

On Wednesday, October 12, 2016 at 2:50:29 PM UTC+3, Ville Voutilainen wrote:

But if your view is that it's better to have
nothing than to have something
in the standard library, I doubt I'm going to agree with that view.

No, my view is that not everything in the world must be in the programming language standard. Even C++ language features today can be shipped separately - as TS. Don't get me wrong, I like ISO C++ standard but it's impossible and impractical try to put everything into it. It is good place for fundamental programming components but not for frameworks. It should provide tools for framework writers like reflection, strings support, filesystem etc, but not to declare one of frameworks "standard" or (even worse) make yet another "design by committee". So I personally don't believe in standard C++ killer-API for GUI. However one can blame me in the future if it will be implemented :-)

[Ville Voutilainen]

On 12 October 2016 at 15:23, Victor Dyachenko

<victor.d...@gmail.com> wrote:
>> But if your view is that it's better to have
>> nothing than to have something
>> in the standard library, I doubt I'm going to agree with that view.
>
> No, my view is that not everything in the world must be in the programming
> language standard. Even C++ language features today can be shipped
> separately - as TS. Don't get me wrong, I like ISO C++ standard but it's
> impossible and impractical try to put everything into it. It is good place

Nobody has suggested putting "everything" into the standard.

> for fundamental programming components but not for frameworks. It should
> provide tools for framework writers like reflection, strings support,
> filesystem etc, but not to declare one of frameworks "standard" or (even
> worse) make yet another "design by committee". So I personally don't believe
> in standard C++ killer-API for GUI. However one can blame me in the future
> if it will be implemented :-)

Well, there's a chance that we might indeed standardize facilities
that help writing GUIs,
as I already said, instead of standardizing a complete GUI.
Nevertheless, that doesn't mean
we couldn't standardize a complete GUI, in the principal sense.

[HarD Gamer]

For to have a gui is needled a real world naming convention, and a fully integration with Modern C++.

And a new C++ standardy library is needled, to be consistent, robust, simple to learn.....

[Matthew Woehlke]

On 2016-10-12 07:08, Victor Dyachenko wrote:
>> I just wanted to say that one can write portable GUI today using C++
>> without having "C++ standard library".
>>

> Must be "C++ standard *GUI* library"

Circa Qt4, you could certainly use Qt as a replacement for STL ;-). (Qt5
is slowly moving away from that...)

--
Matthew

[Matthew Woehlke]

On 2016-10-12 06:54, Ville Voutilainen wrote:

> On 12 October 2016 at 13:50, Victor Dyachenko wrote:
>> For C++ we have at least Qt and wxWigets. Why do we need to put them into

>> Standard? To have big deprecated parts in the Standard in the future?
>
> Why would such deprecation be necessary?

...because UI's are constantly evolving? Just look at what we have today
compared to 10 or 15 years ago. MFC is dead. Qt has changed
*significantly* in that time period. Why would we expect that trend to
be any different 10 years from now?

It's not just because we're creating better ways to "do GUI", either.
The entire notion of what constitutes a GUI, and even how people
interact with computers, has changed significantly.

For STL this isn't a huge issue because STL is mostly dealing with
underlying algorithmic issues, which tend not to change (mathematics
isn't a static field, but it's not nearly as volatile as HCI). But I
remain concerned by things like the standard graphics library proposal
(just look at how much OpenGL has changed in the last 10-15 years), that
they will be seen as hopelessly obsolete a few years after adoption, if
even that long.

>> Why don't we have universal GUI library in C++? Because there is no the only
>> way to implement GUI.
>
> There's not only one way to implement most of the standard library,
> which is one reason why it doesn't mandate any particular
> implementation, so that's a non-issue.

That's a non-sequitor. "Implementation" in this context isn't talking
about under the hood, it's talking about the design of the API itself.
Existing GUI frameworks have radically different API's and even use
paradigms (just look at e.g. how widgets are laid out). How do you pick
one to "bless"? Why would you expect any decision made today to still be
considered acceptable in 5-10 years?

--
Matthew

[Domen Vrankar]

2016-10-12 15:42 GMT+02:00 HarD Gamer <rodrigo...@gmail.com>:

 

For to have a gui is needled a real world naming convention, and a fully integration with Modern C++.

And a new C++ standardy library is needled, to be consistent, robust, simple to learn.....

GUI is not necessarily what you see on your phone/PC every day...

 

In your example there is a button class. Button as far as I'm concerned is area with on click event and some more or less fancy graphics (e.g. a simple button in OS, a rock in 3D scene with some press me icon or a styled button/url link on a web page). It's the same for checkboxes (multiselect dropdown, multiselect list, group of checkbox fields or group of toggle buttons) or radio buttons (single select dropdown, single select list, group of radio buttons, ...) with boolean variable and on click callback. Then there is layout, rendering and styling that are loosely related to the data...

I'm not certain if a simple gui library would be something that would cower all the issues and also be simple to use... The data representation is already C++ itself, ranges could probably be used for conversion of data in different representations (D3.js library style)... There is a 2D rendering library proposal and if I recall correctly some people are also working on event library proposal...

It would be hard to convince different operating system vendors or future devices to have the same graphics, same element dimensions or even similar screen resolutions - for that to be handled automatically you'd have to define automatic or manual conversions from one layout to another and element hiding as I doubt that everybody would agree on default fallbacks... It would also be hard to define which widgets are the basic building blocks (is one type of a graph a basic widget or already advanced stuff?).

It's been pre C++11 since I wrote a simple GUI lib and I'm just writing down my current thoughts so I could be mistaken but I'm guessing that besides the proposals mentioned above it would be nice to have some constructs for 2D and 3D space layout (scenegraph if I recall correctly) and maybe some helpers for widget creation (event moves line on one or another side of some other element and you've got yourself a carrot for text field - not necessarily straight lined one - so you only need a generic sticky layout object that sticks to a different object) but not the widgets themselves (oh and window is a drawing area with a layout defining where elements should be drawn). The rest of the stuff should remain in the domain of different libraries/os-es/websites/games.

Just my 2 cents.

Regards,

Domen

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 13:54:48 CEST, Ville Voutilainen
escreveu:

> Why would such deprecation be necessary?

Well, the SG working on a standard library proposal for a graphics library was
designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
accelerated lib).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Ville Voutilainen]

On 12 October 2016 at 18:05, Thiago Macieira <thi...@macieira.org> wrote:
> Em quarta-feira, 12 de outubro de 2016, às 13:54:48 CEST, Ville Voutilainen
> escreveu:
>> Why would such deprecation be necessary?
>
> Well, the SG working on a standard library proposal for a graphics library was
> designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
> accelerated lib).

They are still working on it. Which part of it is non-HW-accelerated?

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 18:07:04 CEST, Ville Voutilainen
escreveu:

> > Well, the SG working on a standard library proposal for a graphics library
> > was designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
> > accelerated lib).
>
> They are still working on it. Which part of it is non-HW-accelerated?

The 2D part.

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 18:07:04 CEST, Ville Voutilainen
escreveu:

> > Well, the SG working on a standard library proposal for a graphics library
> > was designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
> > accelerated lib).
>
> They are still working on it. Which part of it is non-HW-accelerated?

The 2D part with imperative-style programming.

[Ville Voutilainen]

On 12 October 2016 at 18:18, Thiago Macieira <thi...@macieira.org> wrote:
> Em quarta-feira, 12 de outubro de 2016, às 18:07:04 CEST, Ville Voutilainen
> escreveu:
>> > Well, the SG working on a standard library proposal for a graphics library
>> > was designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
>> > accelerated lib).
>>
>> They are still working on it. Which part of it is non-HW-accelerated?
>
> The 2D part with imperative-style programming.

Cairo HW-accelerates that part, so why wouldn't this library they are
proposing, since it's based
on Cairo?

[Nicol Bolas]

Hardware accelerated in what sense?

According to this post from 2012, `cairo-gl` is not fully hardware accelerated. It only accelerate "GPU compositing and some rasterisation". Is that the fault of the cairo API or the fault of the implementation of `cairo-gl`?

By contrast, NVIDIA's NV_path_rendering OpenGL extension is not only fully hardware accelerated, it permits the use of shaders.

I have not taken anything remotely like a thorough examination of Cairo, C++ 2D, or NV_path_rendering. But Cairo as an API doesn't seem like it is designed around the question of whether an operation is hardware-acceleratable or not.

It also doesn't look anything like modern APIs. If you look at the evolution of graphics APIs from a performance standpoint, there is a strong move from "call a bunch of functions to set state, then render" to "set up a small number of objects, then render". Cairo is far more like OpenGL than Vulkan.

To me, this sort of thing is the big reason why large-scale projects like 2D libraries and GUIs cannot work in the C++ standardization environment. Yes, you'll eventually get something. But is it something that people will use?

How many people would use C++2D to do actual work? While I appreciate Herb Sutter's desire to make pure C++ more effective at doing things, the particular impetus he pointed out is simply not something that actual people have a genuine need for. C++2D feels like a stunt rather than a tool that solves a genuine problem.

Could a C++ GUI library be used to make GUI applications? Sure. Would they be anything like professional GUI applications? How responsive to the change in GUI environments would they be? Mobile platforms introduced a substantial shift in how a GUI is put together; how would a C++ GUI library handle similar shifts in the future? How cross-platform could such a library even be? How responsive would it be? And so forth.

The standard library can work for things with have a solid foundation, which isn't going to change very rapidly. Networking, basic filesystem access, XML/JSON processing, etc. The standard library is not a good place for a quickly-changing environment like GUIs.

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 18:21:22 CEST, Ville Voutilainen
escreveu:

> > The 2D part with imperative-style programming.
>
> Cairo HW-accelerates that part, so why wouldn't this library they are
> proposing, since it's based on Cairo?

Because Cairo 2D acceleration is an already outdated design that does not
fully utilise the GPU acceleration. GPUs haven't operated in a way that Cairo
uses since the early 1990s. GPUs operate in retained mode, which means there's
a big impedance mismatch between imperative programming and how they operate,
and they're designed for 3D.

Trolltech, then Nokia, then Digia, investigated this for years. We
investigated acceleration back in 2008 with Qt 4.4; we discussed integration
with Cairo in 2010. Qt from 4.5 to 4.8 could replace its graphics system with
one based on OpenGL to try and better utilise the GPU, but the end result was
that this was slower and buggier than the CPU-based raster renderer.

In 2010, after investigating Cairo, we investigated what Clutter does (COGL),
and redesigned everything. The product was that is the core of the QtQuick
module: the scene graph. That was first released in Qt 5.0 -- it is, quite in
fact, one of the two reasons why we switched from 4.x to 5.x.

So if you want a good API to base on for graphics, look into that. You can
skip the QML bits, just the core scene graph is fine.

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 09:35:09 CEST, Nicol Bolas
escreveu:

> The standard library can work for things with have a solid foundation,
> which isn't going to change very rapidly. Networking, basic filesystem
> access, XML/JSON processing, etc. The standard library is not a good place
> for a quickly-changing environment like GUIs.

Just one example: despite high-resolution displays having been available for
some years (Mac "Retina" displays), we're *still* trying to figure out how to
provide an API for cross-platform and cross-device development to take HiDPI
into account. How do you deal with devices with resolutions falling in-between
2x and 3x: you round up, round down, or use non-integral? And what happens
when you connect a 1x display to a machine that already has one with 2x, and
you window is placed half-way between then?

[If you want to know more, Morten Sørvig gave a very good summary of this
problem during QtCon last month; I don't know if the slides are online]

[Ville Voutilainen]

On 12 October 2016 at 21:06, Thiago Macieira <thi...@macieira.org> wrote:
> Trolltech, then Nokia, then Digia, investigated this for years. We
> investigated acceleration back in 2008 with Qt 4.4; we discussed integration
> with Cairo in 2010. Qt from 4.5 to 4.8 could replace its graphics system with
> one based on OpenGL to try and better utilise the GPU, but the end result was
> that this was slower and buggier than the CPU-based raster renderer.

But what does that have to do with Cairo? The company I work for did
graphics optimization
work for mobile devices that ran Cairo over OpenGL-ES2 in 2012-2013,
and the end result
was not buggier than a cpu-based raster renderer and performance-wise
it ran rings round
a software renderer.

Sure, there is some impedance mismatch, but that didn't seem to hurt
Cairo being fast
at 2D rendering on GLES2 hardware.

> In 2010, after investigating Cairo, we investigated what Clutter does (COGL),
> and redesigned everything. The product was that is the core of the QtQuick
> module: the scene graph. That was first released in Qt 5.0 -- it is, quite in
> fact, one of the two reasons why we switched from 4.x to 5.x.
>
> So if you want a good API to base on for graphics, look into that. You can
> skip the QML bits, just the core scene graph is fine.

You're more than welcome to let SG13 know about these insights. :)

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 21:17:30 CEST, Ville Voutilainen
escreveu:

> But what does that have to do with Cairo? The company I work for did
> graphics optimization
> work for mobile devices that ran Cairo over OpenGL-ES2 in 2012-2013,
> and the end result
> was not buggier than a cpu-based raster renderer and performance-wise
> it ran rings round
> a software renderer.
>
> Sure, there is some impedance mismatch, but that didn't seem to hurt
> Cairo being fast at 2D rendering on GLES2 hardware.

I'm not doubting that. Yes, there's a lot that you can do with the hardware to
accelerate some operations.

But you can't get the most out of the hardware with that impedance mismatch.
The whole point is that we should design an API that *can* get the most out of
the hardware, not one we know won't be able to.

> > In 2010, after investigating Cairo, we investigated what Clutter does
> > (COGL), and redesigned everything. The product was that is the core of
> > the QtQuick module: the scene graph. That was first released in Qt 5.0 --
> > it is, quite in fact, one of the two reasons why we switched from 4.x to
> > 5.x.
> >
> > So if you want a good API to base on for graphics, look into that. You can
> > skip the QML bits, just the core scene graph is fine.
>
> You're more than welcome to let SG13 know about these insights. :)

We did, when it formed.

[mihailn...@gmail.com]

I am with Thiago on this one - today is the worst time to have standard drawing (or GUI for that matter) library.

That ship has sailed more then 10 years ago. Today is the time of the most rapid development in that area, both hardware and new APIs to access it.

Indeed, everything will be outdated the moment it is released.

Having said that, probably an "old school" lib has its place as well, just to be able to draw stuff on screen.

[Sean Middleditch]

On Wednesday, October 12, 2016 at 8:21:24 AM UTC-7, Ville Voutilainen wrote:

Cairo HW-accelerates that part, so why wouldn't this library they are
proposing, since it's based
on Cairo?

This was a point I was trying to make to that working group. Cairo is super sub-optimal. Every major vendor who started using Ciaro dropped it and replaced it with a better library, often having to home-grow their own.

Cairo is a stateful/contextful library built around GL-like models of programming. Which isn't how hardware works, nor how drivers work, nor even how good software works. Good canvas drawing libraries operate in as stateless a fashion a possible.

This is both about speed and interface design. Stateful interfaces like Cairo/GL require a huge amount of work in the library to bounce state changes and optimize around call patterns that the user is forced to write sub-optimally due to the composition problem.

The composition problem results in different pieces of code not being able to cooperate seamlessly. Hand off a Cairo canvas to a helper routine/library and you have no idea what state may be changed out from under you. So to avoid surprise bugs you have to do a full state save/restore. Which is expensive when you don't need it. So the library has to do a ton of work to de-bounce unnecessary state changes that the library itself is forcing users to make for correctness. And that's assuming that users remember to do all the extra steps to achieve said correctness and don't just get all the bugs.

Basing a modern canvas library that will be standardized in 2020+ off of Cairo would be a baffingly poor decision. It was an out-dated model of graphics programming 5 years ago and isn't going to be any less antiquated 4 years from now. It will be difficult to use and it will be inefficient, thus solving few real use cases; beginners or quick uses need easy and pros need efficient.

I don't even want to get into the GUI parts. You claimed earlier that GUIs don't change that often, which is just outright wrong. You can't go a week without Apple or Facebook or Google or Microsoft or Twitter or Uber or whoever releasing a new library in this domain. The C++ community talking about standardizing widgets and MVC while the folks who write most of the GUIs we actually use day-to-day are off in functional-reactive land shipping efficient component-based stateless reactive UIs. Let's not even get into how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML, or so on with barely any C++ even in the application UI code.

Putting Cairo into the stdlib makes barely more sense than putting 3dfx Glide into the stdlib, IMO. :)

We just need a package manager. The problem with third party libraries isn't fundamentally that they're not in the standard; the problem is that using non-standard libraries involves steps that vary wildly by compiler and environment. Rather than pulling individual libraries one-by-one into the standard and signing up to maintain them in perpetuity, fix the fundamental root problem. Then folks who decide they want C++ Cairo can just import cairomm and be done with it.

[Ville Voutilainen]

On 12 October 2016 at 23:30, Sean Middleditch
<sean.mid...@gmail.com> wrote:

Thanks for the explanation for the performance/api parts.

> I don't even want to get into the GUI parts. You claimed earlier that GUIs
> don't change that often, which is just outright wrong. You can't go a week
> without Apple or Facebook or Google or Microsoft or Twitter or Uber or
> whoever releasing a new library in this domain. The C++ community talking

I have no trouble finding any domain you want for which someone somewhere
releases a new library every week. What impact that has on actual users
is a completely different question.

> about standardizing widgets and MVC while the folks who write most of the
> GUIs we actually use day-to-day are off in functional-reactive land shipping
> efficient component-based stateless reactive UIs. Let's not even get into

I wonder what makes you think a standard GUI would necessarily be a matter
of standardizing widgets and MVC.

> how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML, or
> so on with barely any C++ even in the application UI code.

Ah, yes, thus creating UIs that are bad both in performance and in quality as
far as bugs go. What C++ needs is a modern GUI library, standard or not,
and such declarative UIs based on languages with next to no type checking
aren't the solution.

> Putting Cairo into the stdlib makes barely more sense than putting 3dfx
> Glide into the stdlib, IMO. :)

An eye-opening comparison, to be sure.

> We just need a package manager. The problem with third party libraries isn't
> fundamentally that they're not in the standard; the problem is that using
> non-standard libraries involves steps that vary wildly by compiler and
> environment. Rather than pulling individual libraries one-by-one into the
> standard and signing up to maintain them in perpetuity, fix the fundamental
> root problem. Then folks who decide they want C++ Cairo can just import
> cairomm and be done with it.

Getting something like that would certainly solve quite many problems.
How to get it
is another matter. I know how to get a library into the standard. I
don't know how to
get a package manager in.

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 11:36:19 CEST,
mihailn...@gmail.com escreveu:

> Having said that, probably an "old school" lib has its place as well, just
> to be able to draw stuff on screen.

That's what the C++ 2DGUI library was supposed to be. Painting some pixels on
screen, early 90s style.

I have no problem with it if it is qualified as such. But if you label it as a
modern GUI library, it's DOA (deprecated on arrival). In fact, I would
heartily oppose such labelling, as it would give people the wrong impression
that they can use it to make nice, HW-accelerated, modern UIs and that the
other toolkits are deprecate because of it.

[Thiago Macieira]

Em quarta-feira, 12 de outubro de 2016, às 23:45:03 CEST, Ville Voutilainen
escreveu:

> > how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML,
> > or
> > so on with barely any C++ even in the application UI code.
>
> Ah, yes, thus creating UIs that are bad both in performance and in quality
> as far as bugs go. What C++ needs is a modern GUI library, standard or not,
> and such declarative UIs based on languages with next to no type checking
> aren't the solution.

The core of QtQuick is written in C++. If you strip out the QML interpreter,
it's actually quite neat. It's using C++ to do retained (declarative)
programming. It even has a C++ API for manipulating the graph, adding nodes to
it, even the one node that operates 90s-style (QQuickPaintedItem).

What it lacks is the front-end for higher-level useful elements, like buttons,
lists, etc. Those are only available in QML.

[Ville Voutilainen]

On 13 October 2016 at 10:46, Thiago Macieira <thi...@macieira.org> wrote:
>> > how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML,
>> > or
>> > so on with barely any C++ even in the application UI code.
>>
>> Ah, yes, thus creating UIs that are bad both in performance and in quality
>> as far as bugs go. What C++ needs is a modern GUI library, standard or not,
>> and such declarative UIs based on languages with next to no type checking
>> aren't the solution.
>
> The core of QtQuick is written in C++. If you strip out the QML interpreter,
> it's actually quite neat. It's using C++ to do retained (declarative)

I know. :)

> What it lacks is the front-end for higher-level useful elements, like buttons,
> lists, etc. Those are only available in QML.

Yes. Fixing that is an item on my bucket list. :P

[D. B.]

On Wed, Oct 12, 2016 at 9:45 PM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

> how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML, or
> so on with barely any C++ even in the application UI code.

Ah, yes, thus creating UIs that are bad both in performance and in quality as
far as bugs go.

+1! Personally, give me programmatic/procedural control of the GUI any day. XML et al won't cut it most of the time, for various reasons.

 

What C++ needs is a modern GUI library, standard or not,
and such declarative UIs based on languages with next to no type checking
aren't the solution.

Yeah, I call it gtkmm. ;-) It has a solid foundation, is adopting modern C++ at a rapid pace, and - excuse the cliche - just works. Plus, markup semantics are available for those who want it. And it's only going to get more modern with GTK+ 4 having just branched to development.
 

(Shame how most of the internet tries to present GTK+ et al don't exist, then. gtkmm especially! I know it's not got a 'real' C++ base, but the key thing is it works, and very well.)

[Thiago Macieira]

Em quinta-feira, 13 de outubro de 2016, às 09:22:05 CEST, D. B. escreveu:
> Yeah, I call it gtkmm. ;-) It has a solid foundation, is adopting modern
> C++ at a rapid pace, and - excuse the cliche - just works. Plus, markup
> semantics are available for those who want it. And it's only going to get
> more modern with GTK+ 4 having just branched to development.
>
> (Shame how most of the internet tries to present GTK+ et al don't exist,
> then. gtkmm especially! I know it's not got a 'real' C++ base, but the key
> thing is it works, and very well.)

We're going off-topic here... we can continue off-list if you want.

The problem with GTK+ and gtkmm is the same as the problem with QtWidgets and
that which I talked about before: right now, all of them are imperative
programming.

I know GTK+ developers are willing to break with the past, sacrificing their
existing user-base, in order to improve their functionality and API. So it's
possible they'll transform their API so that it becomes declarative/retained-
mode. It remains to be seen.

Either way, GTK+/gtkmm is not a good foundation today, any more than Cairo is
(GTK+ 2 and 3 use Cairo).

[Dejan Milosavljevic]

Just to put more oil on fire.

GUI imply existing of next libraries:
    - image-vector manipulation,
    - image-raster manipulation,
    - retrieving user action from mouse/keyboard/trackball/joystick/touch-screen/...
    - Styles ( AKA skinning ) ( possibly/greatly imply XML library )

First two of them are already mentioned as 2D libraries.
I think that we can put more and more items on above list.

So real question is: What libraries we need to implement ( add to standard ) before creating standard GUI?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2050507.DOLSdCVWf1%40tjmaciei-mobl1.

[Rene Rivera]

On Thu, Oct 13, 2016 at 3:22 AM, D. B. <db0...@gmail.com> wrote:

On Wed, Oct 12, 2016 at 9:45 PM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

> how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML, or
> so on with barely any C++ even in the application UI code.

Ah, yes, thus creating UIs that are bad both in performance and in quality as
far as bugs go.

+1! Personally, give me programmatic/procedural control of the GUI any day. XML et al won't cut it most of the time, for various reasons.

Sorry to burst your bubble.. But the better GUI designs separate the visual design from the programatic task design. Where the presentation is as much data driven as possible. Hence using things like HTML, JSON, XML, etc as presentation descriptions (and some times the dynamics of the presentation).

And to truly burst your bubble.. Programmers are horrific GUI designers. And anything that makes it such that programmers aren't aligning buttons, and laying out tables, etc. is a "really good thing".

--

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

[FrankHB1989]

在 2016年10月12日星期三 UTC+8下午6:54:53，Ville Voutilainen写道：

On 12 October 2016 at 13:50, Victor Dyachenko

<victor.d...@gmail.com> wrote:
> For C++ we have at least Qt and wxWigets. Why do we need to put them into

I don't recall anyone suggesting putting Qt or wxWidgets into the standard.

At least Qt is not fit here, definitely. Technically you have to do tooooo much work to work around with [intro.refs], for example.

 

> Standard? To have big deprecated parts in the Standard in the future?

Why would such deprecation be necessary?

[FrankHB1989]

This is a bit off topic. Besides the concrete implementation, GUI has nothing necessary to do with any particular set of graphics API.

在 2016年10月12日星期三 UTC+8下午11:05:47，Thiago Macieira写道：

[FrankHB1989]

在 2016年10月13日星期四 UTC+8下午8:42:05，Dejan Milosavljevic写道：

Just to put more oil on fire.

GUI imply existing of next libraries:
    - image-vector manipulation,
    - image-raster manipulation,
    - retrieving user action from mouse/keyboard/trackball/joystick/touch-screen/...
    - Styles ( AKA skinning ) ( possibly/greatly imply XML library )

First two of them are already mentioned as 2D libraries.
I think that we can put more and more items on above list.

So real question is: What libraries we need to implement ( add to standard ) before creating standard GUI?

Input device manipulation should come first.

The last can be based on some low level GUI facilities.

On Thu, Oct 13, 2016 at 10:36 AM, Thiago Macieira <thi...@macieira.org> wrote:

Em quinta-feira, 13 de outubro de 2016, às 09:22:05 CEST, D. B. escreveu:
> Yeah, I call it gtkmm. ;-) It has a solid foundation, is adopting modern
> C++ at a rapid pace, and - excuse the cliche - just works. Plus, markup
> semantics are available for those who want it. And it's only going to get
> more modern with GTK+ 4 having just branched to development.
>
> (Shame how most of the internet tries to present GTK+ et al don't exist,
> then. gtkmm especially! I know it's not got a 'real' C++ base, but the key
> thing is it works, and very well.)

We're going off-topic here... we can continue off-list if you want.

The problem with GTK+ and gtkmm is the same as the problem with QtWidgets and
that which I talked about before: right now, all of them are imperative
programming.

I know GTK+ developers are willing to break with the past, sacrificing their
existing user-base, in order to improve their functionality and API. So it's
possible they'll transform their API so that it becomes declarative/retained-
mode. It remains to be seen.

Either way, GTK+/gtkmm is not a good foundation today, any more than Cairo is
(GTK+ 2 and 3 use Cairo).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[FrankHB1989]

在 2016年10月12日星期三 UTC+8下午7:50:29，Ville Voutilainen写道：

On 12 October 2016 at 14:05, Victor Dyachenko

<victor.d...@gmail.com> wrote:
>> I don't recall anyone suggesting putting Qt or wxWidgets into the
>> standard.
>

> I just wanted to say that one can write portable GUI today using C++ without
> having "C++ standard library".

One can write a whole lot of things without using the standard library
for that. The issue
there is that such solutions are less portable than they would be as
standard features,
and the availability is another issue.

That's not true. I have written something containing reusable GUI code portable between platforms with freestanding implementation and hosted implementations of C++, but the standard can't provide enough to cover it. Because the standard can't guarantee the intended GUI APIs being able to be implemented on arbitrary freestanding implementations it already supported, so it simply can't require it, before having some kinds of "client profiles". The latter will not likely come true in the near future.

>> > Standard? To have big deprecated parts in the Standard in the future?

>> Why would such deprecation be necessary?

> Why std::auto_ptr, std::strstream et al were deprecated? Because today we
> have better solutions. GUI and GUI libraries are evolving. Imagine MFC

GUI libraries, and especially their APIs, don't seem to evolve nearly
as fast as some
people like to think. But if your view is that it's better to have
nothing than to have something
in the standard library, I doubt I'm going to agree with that view.

> mid-90's vintage being the part of Standard. GUI system is a very
> sophisticated thing. Much more complex than vector class or sorting
> algorithm.

Yeah, which is actually a fair reason to have a standardized GUI
library or to have standardized
facilities that help GUI programming.

[Matthew Woehlke]

(*Third* try. Apologies if this shows up more than once; for some reason
I seem to have trouble getting posts to this thread to go through...)

On 2016-10-12 16:45, Ville Voutilainen wrote:
> I know how to get a library into the standard. I don't know how to
> get a package manager in.

I'm not convinced the *C++* standard is the right place for this. We
could certainly use one, maybe even as an ISO standard, but I'm less
convinced that bundling it into C++ is TRTTD.

As I said at Jacksonville, I think the first step is to standardize a
mechanism for consuming an external package. I'd like to see something
that standardizes a way to describe a package, what components it
provides and how to use them (probably using JSON or the like), and how
to find such descriptions.

Both pkg-config and CMake (and possibly others) provide such mechanisms,
but they aren't universally supported, and both have drawbacks
(pkg-config's flags-based approach is problematic, CMake is too steeped
in its own syntax). Ideally, someone would propose such a standard,
tools like pkg-config and CMake would be updated to support consuming
it, and build tools (autotools, CMake, scons, etc.) would be updated to
produce it.

There *might* be room, especially in a post-modules era, for the
compiler to consume these directly, though I am less sure, considering
that stuff like include directives and linking are not something the
standard addresses. Traditionally, this is build tool territory.

--
Matthew

[Matthew Woehlke]

(*Third* try. Apologies if this shows up more than once; for some reason
I seem to have trouble getting posts to this thread to go through...)

On 2016-10-12 16:45, Ville Voutilainen wrote:

> I wonder what makes you think a standard GUI would necessarily be a matter
> of standardizing widgets and MVC.

Whatever it is, even if someone proposes today to standardize the
current state of the art, by the time it is in C++xx, the state of the
art will most likely have changed, and C++ will be dragging around a
library based on a paradigm that no one wants to use any more.

C++ "seems" to be moving fast these days, and that's good, but
historically, GUI and graphics (and audio) have moved even faster.
Specifically, they've been moving for some years at a pace that an ISO
process can't realistically match.

That's not to say that the ISO process is fundamentally broken or
anything. For much of what C++ specifies, and especially the core
language, I would say the ISO process works well, and in some senses the
limited degree of flexibility is an *advantage*. However, I strongly
feel that the ISO process is not appropriate for a GUI framework. (Or a
graphics framework (Glide!), or an audio framework (ALSA!), or...)

--
Matthew

[Nicol Bolas]

This is why I think we should have a process for making TS's without the intent to incorporate them into C++. They would represent optional features that have a firm standard from ISO, but can be removed and replaced at any time.

Also, there's the matter of the sheer effort it takes to write an implementation of something with the complexity of C++2D or a GUI framework. To make C++2D efficient requires tons of work, especially if you want GPU hardware processing where available. A GUI framework, across multiple platforms? That requires a tremendous amount of work for anything more complex than the most trivial of cases.

[D. B.]

On Thu, Oct 13, 2016 at 9:36 AM, Thiago Macieira <thi...@macieira.org> wrote:

We're going off-topic here... we can continue off-list if you want.

The problem with GTK+ and gtkmm is the same as the problem with QtWidgets and
that which I talked about before: right now, all of them are imperative
programming.

I know GTK+ developers are willing to break with the past, sacrificing their
existing user-base, in order to improve their functionality and API. So it's
possible they'll transform their API so that it becomes declarative/retained-
mode. It remains to be seen.

Either way, GTK+/gtkmm is not a good foundation today, any more than Cairo is
(GTK+ 2 and 3 use Cairo).

Yeah, probably OT. I just want to point out for other readers, though, that this isn't a reason to avoid these frameworks. Plans are in motion to get rid of Cairo from GTK+ et al - the GTK+ Scene Graph Kit (GSK). The devs are very aware of the limitations of Cairo and how it doesn't suit their needs in a modern landscape. See e.g. https://www.bassi.io/articles/2014/07/29/guadec-2014-gsk/

As an observer, I think i's very likely that GTK+ 4 will use GSK, in addition to being a lot more modern in many other ways (including streamlining by removing deprecated code, as can be seen in the WIP commits)

/OT ;-)

[3dw...@verizon.net]

In 2010, after investigating Cairo, we investigated what Clutter does (COGL),
and redesigned everything. The product was that is the core of the QtQuick
module: the scene graph. That was first released in Qt 5.0 -- it is, quite in
fact, one of the two reasons why we switched from 4.x to 5.x.

So if you want a good API to base on for graphics, look into that. You can
skip the QML bits, just the core scene graph is fine.

So how does thisapproach compare to OpenInventor.  It is a retained mode layer over OpenGL.  You essentially build up a state with vertices and triangles and then render.