Windowing API Standard(s)?

[David Ludwig]

Hello all,

I have been thinking about windowing APIs for a while, whether or not such ought to be standardized for C++, and if so, what goes in, and how is it implemented.  I have also started poking around the APIs defined in the P0267 series of papers (latest is at https://github.com/mikebmcl/io2dts/blob/master/papers/P0267R7.pdf, to my knowledge), and refreshing my knowledge of various window-system abstractions (GLFW, Qt, SDL, SFML, among others).

I am wondering to what degree others might be thinking of similar things.  Looking over older commentary here, and looking over conversations elsewhere (via Reddit, Twitter, etc.), it seems like I might not be the only one.

Do people here (if anyone is still here!) find the prospect of a windowing API in Standard C++ to be appealing?  If so, or if not, why?

Would a windowing API mandate the need for some kind of input-event API?  It seems to me like it would, but maybe I'm wrong?

Assuming there is to be a "Standard" windowing API, should it be tied to a specific graphics API or set of APIs, or could it be reasonably agnostic of any such API?


I'm curious to hear what others think about this (and wondering if I am crazy to be thinking of a possible, "Standard" windowing API!)

Cheers,
-- David Ludwig

[Klaim - Joël Lamotte]

On 3 May 2018 at 23:59, David Ludwig <dlu...@pobox.com> wrote:

Would a windowing API mandate the need for some kind of input-event API?  It seems to me like it would, but maybe I'm wrong?

Yes. Otherwise it would be about a drawing API.

A. Joël Lamotte

[farid....@gmail.com]

در جمعه 4 مهٔ 2018، ساعت 2:29:53 (UTC+4:30)، David Ludwig نوشته:

> I am wondering to what degree others might be thinking of similar things.  Looking over older commentary here, and looking over conversations elsewhere (via Reddit, Twitter, etc.), it seems like I might not be the only one.

Of course not.

> Do people here (if anyone is still here!) find the prospect of a windowing API in Standard C++ to be appealing?

Sure. Plenty of them.

> If so, or if not, why?

GUI Is an important component of any modern OS.
OTH, complexity and diversity of GUI building blocks is a serious obstacle. Diversity and incompatiblity of protocoles used by various OS's is a major concern.

> Would a windowing API mandate the need for some kind of input-event API?  It seems to me like it would, but maybe I'm wrong?
>
> Assuming there is to be a "Standard" windowing API, should it be tied to a specific graphics API or set of APIs, or could it be reasonably agnostic of any such API?

The more generic, the more appealing but the more difficult to design.

AFAIK such GUI API consists of - at least - following features:
1. A widget server (internal or external) that handles abstract windowing primitives(size, location, visiblity...) as well as s messaging system.
2. Event-loop manager and corresponding callback system to receive and covert messages into events an register callbacks to respond for each event. 'boost::signal2' has been around - for a while - to handle the callbacks and there has been interest in extdnding boost::asio for event-loop management.
3.flexible rendering management to be able to choose between different graphic servers(internal, native(OS default), 3rd party alternatives(opengl...)...).

This id already too much to be concluded in just a few proposals. I have not seen any approved API in 'boost' as a great idea pool for std proposals.
QT has been widely used a cross-platform library. But it does not conform to some std coventions:
1. Identifier naming differs and QT does not by-default make use of namespaces.
2. It does not integrate with std, redefines its own independent container and streaming library.

Another downside of QT is IMHO being not open-source and being controlled by a specific company, which makes it hard to implement new/special OS.

Most other existing libraries are designed with structured C API's and share most of downsides of QT as mention earlier.
In short words, I really wish to see an elegant std GUI lib around but I do not hope - at least not in near future. Somebody - please - prove me wrong.

[Thiago Macieira]

On Monday, 18 March 2019 12:21:35 PDT farid....@gmail.com wrote:
> Another downside of QT is IMHO being not open-source and being controlled by
> a specific company, which makes it hard to implement new/special OS.

Both assertions are wrong. It's open source and under an open governance
(although it requires a CLA, but GNU itself requires copyright assignment).

Yes, one particular company does have a massive weight on it, due to the
number of developers they put to work on it. That company also owns the
trademark.

As for not conforming to std conventions, that's intentional.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel System Software Products

[farid....@gmail.com]

در سه‌شنبه 19 مارس 2019، ساعت 1:19:16 (UTC+3:30)، Thiago Macieira نوشته:

> On Monday, 18 March 2019 12:21:35 PDT farid....@gmail.com wrote:
> > Another downside of QT is IMHO being not open-source and being controlled by
> > a specific company, which makes it hard to implement new/special OS.
>
> Both assertions are wrong. It's open source and under an open governance
> (although it requires a CLA, but GNU itself requires copyright assignment).

I did not find the implementing source module of at least one undocumented class whose name was suffixed as Private in one specific build. I consider this not fully open-source. But newer versions might have changed in that regard.

>
> As for not conforming to std conventions, that's intentional.
>

Which means not a good candidate for std.

[Daniel Krügler]

Am Di., 19. März 2019 um 19:51 Uhr schrieb <farid....@gmail.com>:
>
> در سه‌شنبه 19 مارس 2019، ساعت 1:19:16 (UTC+3:30)، Thiago Macieira نوشته:

> > As for not conforming to std conventions, that's intentional.
>
> Which means not a good candidate for std.

That's not true. The formatting/case conventions of any C++ library is
completely irrelevant when its API may be considered for
standardization. The actual standardization process would then of
course apply the std conventions to the API that would be actually
standardized, but that is not a hindrance argument to "standardize
library X".

- Daniel

[Thiago Macieira]

On Tuesday, 19 March 2019 11:51:35 PDT farid....@gmail.com wrote:
> در سه‌شنبه 19 مارس 2019، ساعت 1:19:16 (UTC+3:30)، Thiago Macieira نوشته:
> > On Monday, 18 March 2019 12:21:35 PDT farid....@gmail.com wrote:
> > > Another downside of QT is IMHO being not open-source and being
> > > controlled by a specific company, which makes it hard to implement
> > > new/special OS.>
> > Both assertions are wrong. It's open source and under an open governance
> > (although it requires a CLA, but GNU itself requires copyright
> > assignment).
>
> I did not find the implementing source module of at least one undocumented
> class whose name was suffixed as Private in one specific build. I consider
> this not fully open-source. But newer versions might have changed in that
> regard.

That just means you didn't find it, but it was there.

All sources have been made available in the entire form as they get developed
for the past 10 years, ever since Qt moved to Git. Prior to that, Qt had
already been releasing full sources for a couple of years from the internal
Perforce server. (Trivia: this is why the source package is called
"<modulename>-everywhere", because in the early 2000s there would be different
sources per platform)

The Qt Company has some commercial offerings on top of Qt, which they
sometimes name in a confusing pattern that makes it look like they're part of
Qt. But Qt itself, Qt Creator and most other add-ons are completely open
source and under open governance.

> > As for not conforming to std conventions, that's intentional.
>
> Which means not a good candidate for std.

No one said it would be. Qt has no interest in becoming part of the official
standard. Naming convention and shunning of exceptions, just to name two
important differences, will never change. COW containers may or may not.

But the fact is that Qt is a de facto standard in itself...

[farid....@gmail.com]

در سه‌شنبه 19 مارس 2019، ساعت 22:29:28 (UTC+3:30)، Thiago Macieira نوشته:

> On Tuesday, 19 March 2019 11:51:35 PDT farid....@gmail.com wrote:
> > در سه‌شنبه 19 مارس 2019، ساعت 1:19:16 (UTC+3:30)، Thiago Macieira نوشته:
> > > On Monday, 18 March 2019 12:21:35 PDT farid....@gmail.com wrote:
> > > > Another downside of QT is IMHO being not open-source and being
> > > > controlled by a specific company, which makes it hard to implement
> > > > new/special OS.>
> > > Both assertions are wrong. It's open source and under an open governance
> > > (although it requires a CLA, but GNU itself requires copyright
> > > assignment).
> >
> > I did not find the implementing source module of at least one undocumented
> > class whose name was suffixed as Private in one specific build. I consider
> > this not fully open-source. But newer versions might have changed in that
> > regard.
>
> That just means you didn't find it, but it was there.
>
> All sources have been made available in the entire form as they get developed
> for the past 10 years, ever since Qt moved to Git. Prior to that, Qt had
> already been releasing full sources for a couple of years from the internal
> Perforce server. (Trivia: this is why the source package is called
> "<modulename>-everywhere", because in the early 2000s there would be different
> sources per platform)
>
> The Qt Company has some commercial offerings on top of Qt, which they
> sometimes name in a confusing pattern that makes it look like they're part of
> Qt. But Qt itself, Qt Creator and most other add-ons are completely open
> source and under open governance.
>

Add-ons are not specifically my concern here. But I can see that as a KDE developer, QT might be part of your religion. We are not at war here. We are seeking a std solution for an old problem.

> > > As for not conforming to std conventions, that's intentional.
> >
> > Which means not a good candidate for std.
>
> No one said it would be. Qt has no interest in becoming part of the official
> standard. Naming convention and shunning of exceptions, just to name two
> important differences, will never change. COW containers may or may not.
>
> But the fact is that Qt is a de facto standard in itself...
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products

The fact that I mentioned (as many do) in the 1st place means it is something. But it is not ISO and there is not any warranty that it may or may not be ported to some specefic platform.

[farid....@gmail.com]

در سه‌شنبه 19 مارس 2019، ساعت 22:28:27 (UTC+3:30)، Daniel Krügler نوشته:

Has there been any ongoing work on QT?
If QT is the primary candidate, then a tone of refactoring is needed to regulate those identifiers.

[Daniel Krügler]

Am Mi., 20. März 2019 um 10:21 Uhr schrieb <farid....@gmail.com>:
>
> در سه‌شنبه 19 مارس 2019، ساعت 22:28:27 (UTC+3:30)، Daniel Krügler نوشته:
> > Am Di., 19. März 2019 um 19:51 Uhr schrieb <farid....@gmail.com>:
> > >
> > > در سه‌شنبه 19 مارس 2019، ساعت 1:19:16 (UTC+3:30)، Thiago Macieira نوشته:
> > > > As for not conforming to std conventions, that's intentional.
> > >
> > > Which means not a good candidate for std.
> >
> > That's not true. The formatting/case conventions of any C++ library is
> > completely irrelevant when its API may be considered for
> > standardization. The actual standardization process would then of
> > course apply the std conventions to the API that would be actually
> > standardized, but that is not a hindrance argument to "standardize
> > library X".
> >
> > - Daniel
>
> Has there been any ongoing work on QT?

I don't know.

- Daniel