------=_Part_4732_2113471025.1476264333604
Content-Type: multipart/alternative;
 boundary="----=_Part_4733_1526023076.1476264333605"

------=_Part_4733_1526023076.1476264333605
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e7ef2a9-cc07-41bf-b802-6e7ea795f880%40isocpp.org.

------=_Part_4733_1526023076.1476264333605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sir,=C2=A0<div><br></div><div>I am a die-hard c++ fan. I h=
ave 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 libr=
aries carefully examined and merged into a new one. Or, else standardize a =
library and include in c++ standards.</div><div><br></div><div>Thank you.</=
div><div><br></div><div>Yours faithful,</div><div>Hemil R.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e7ef2a9-cc07-41bf-b802-6e7ea795f880%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e7ef2a9-cc07-41bf-b802-6e7ea795f880=
%40isocpp.org</a>.<br />

------=_Part_4733_1526023076.1476264333605--

------=_Part_4732_2113471025.1476264333604--

.

--089e01228c122b91a7053ea7cf69
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEf-NACZHKyfdiWf9BtvQ%2B-xnSRtCDFxq-RTpXyF9pL7A%40mail.gmail.com.

--089e01228c122b91a7053ea7cf69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>A full GUI library is way, <i>way </i>beyond the scop=
e of the Standard.<br><br></div><div>but even if it wasn&#39;t, this is fun=
ny:<br><br><blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wh=
at we can do is have all the libraries carefully examined and merged into a=
 new one</blockquote></blockquote></div><div><br></div><div>Who&#39;s going=
 to do this? Have you made a start? Good luck.<br>=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEf-NACZHKyfdiWf9BtvQ%2B-xnSRtC=
DFxq-RTpXyF9pL7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEf-NACZH=
KyfdiWf9BtvQ%2B-xnSRtCDFxq-RTpXyF9pL7A%40mail.gmail.com</a>.<br />

--089e01228c122b91a7053ea7cf69--

.

On 12 October 2016 at 12:42, D. B. <db0451@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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZkGQJJ78vEpV9SHTQXJoiJNtxt0%2BN12n7NRHm2WpVDNg%40mail.gmail.com.

.

------=_Part_1708_1206022818.1476269449275
Content-Type: multipart/alternative;
 boundary="----=_Part_1709_348482274.1476269449275"

------=_Part_1709_348482274.1476269449275
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/45d02760-81b8-4039-b306-75266197b420%40isocpp.org.

------=_Part_1709_348482274.1476269449275
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 12:25:34 PM UTC+3, nucle=
arr...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">Sir,=C2=A0<div><br></div><div>I am a die-hard c++ fan. I have not=
iced that languages like Java and C# have a built-in GUI libraries.</div></=
div></blockquote><div>There is no single &quot;Java GUI library&quot;. See =
here http://stackoverflow.com/questions/7358775/java-gui-frameworks-what-to=
-choose-swing-swt-awt-swingx-jgoodies-javafx<br><br>For C++ we have at leas=
t Qt and wxWigets. Why do we need to put them into Standard? To have big de=
precated parts in the Standard in the future?<br><br>Why don&#39;t we have =
universal GUI library in C++? Because there is no the only way to implement=
 GUI.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45d02760-81b8-4039-b306-75266197b420%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45d02760-81b8-4039-b306-75266197b420=
%40isocpp.org</a>.<br />

------=_Part_1709_348482274.1476269449275--

------=_Part_1708_1206022818.1476269449275--

.

On 12 October 2016 at 13:50, Victor Dyachenko
<victor.dyachenko@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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbTkk3LLmU5iyVXi1T9%2BQjCj_Qq08Ty6BjMACZ3LeDOnA%40mail.gmail.com.

.

------=_Part_1445_2019143989.1476270325959
Content-Type: multipart/alternative;
 boundary="----=_Part_1446_565441397.1476270325959"

------=_Part_1446_565441397.1476270325959
Content-Type: text/plain; charset=UTF-8

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 <javascript:>> 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.

> 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.
>

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24eac99c-2d60-4c31-8815-0936674c9d1b%40isocpp.org.

------=_Part_1446_565441397.1476270325959
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 1:54:53 PM UTC+3, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 Octobe=
r 2016 at 13:50, Victor Dyachenko
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
qErxKrhXAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">victor.d...@gmail.com</a>&gt; wrote:
<br>&gt; For C++ we have at least Qt and wxWigets. Why do we need to put th=
em into
<br>
<br>I don&#39;t recall anyone suggesting putting Qt or wxWidgets into the s=
tandard.
<br></blockquote><div>I just wanted to say that one can write portable GUI =
today using C++ without having &quot;C++ standard library&quot;.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Standard? To have bi=
g deprecated parts in the Standard in the future?
<br>
<br>Why would such deprecation be necessary?
<br></blockquote><div>Why std::auto_ptr, std::strstream et al were deprecat=
ed? Because today we have better solutions. GUI and GUI libraries are evolv=
ing. Imagine MFC mid-90&#39;s vintage being the part of Standard. GUI syste=
m is a very sophisticated thing. Much more complex than vector class or sor=
ting algorithm.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&=
gt; Why don&#39;t we have universal GUI library in C++? Because there is no=
 the only
<br>&gt; way to implement GUI.
<br>
<br>There&#39;s not only one way to implement most of the standard library,
<br>which is one reason why
<br>it doesn&#39;t mandate any particular implementation, so that&#39;s a n=
on-issue.<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/24eac99c-2d60-4c31-8815-0936674c9d1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24eac99c-2d60-4c31-8815-0936674c9d1b=
%40isocpp.org</a>.<br />

------=_Part_1446_565441397.1476270325959--

------=_Part_1445_2019143989.1476270325959--

.

------=_Part_1517_438697311.1476270490654
Content-Type: multipart/alternative;
 boundary="----=_Part_1518_570995039.1476270490654"

------=_Part_1518_570995039.1476270490654
Content-Type: text/plain; charset=UTF-8


>
> 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"

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/067bbd5c-7859-4d4c-8543-3b244aaf1f83%40isocpp.org.

------=_Part_1518_570995039.1476270490654
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>I just wanted to say that one can write portable GUI today using C=
++ without having &quot;C++ standard library&quot;.</div></div></blockquote=
><div>Must be &quot;C++ standard <b>GUI</b> library&quot; <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/067bbd5c-7859-4d4c-8543-3b244aaf1f83%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/067bbd5c-7859-4d4c-8543-3b244aaf1f83=
%40isocpp.org</a>.<br />

------=_Part_1518_570995039.1476270490654--

------=_Part_1517_438697311.1476270490654--

.

------=_Part_1650_1159782650.1476270817142
Content-Type: multipart/alternative;
 boundary="----=_Part_1651_1389504678.1476270817142"

------=_Part_1651_1389504678.1476270817142
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/099f34aa-76ef-4678-90cf-9600f27c6cba%40isocpp.org.

------=_Part_1651_1389504678.1476270817142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 2:05:26 PM UTC+3, Victor=
 Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">&gt; Standard? To have big deprecated parts in the Standard in the futu=
re?
<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>Why would such deprecation be necessary?
<br></blockquote><div>Why std::auto_ptr, std::strstream et al were deprecat=
ed? Because today we have better solutions. GUI and GUI libraries are evolv=
ing. Imagine MFC mid-90&#39;s vintage being the part of Standard. GUI syste=
m is a very sophisticated thing. Much more complex than vector class or sor=
ting algorithm.</div></div></blockquote><div>And again. There were attempt =
in the Java-world to create universal GUI - AWT. They are failed. And Swing=
 as replacement failed too.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/099f34aa-76ef-4678-90cf-9600f27c6cba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/099f34aa-76ef-4678-90cf-9600f27c6cba=
%40isocpp.org</a>.<br />

------=_Part_1651_1389504678.1476270817142--

------=_Part_1650_1159782650.1476270817142--

.

------=_Part_1744_682845832.1476272691631
Content-Type: multipart/alternative;
 boundary="----=_Part_1745_1707062430.1476272691631"

------=_Part_1745_1707062430.1476272691631
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/09d07be1-f83a-4bad-9433-63ff9f09e58f%40isocpp.org.

------=_Part_1745_1707062430.1476272691631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The reason why there is no standard GUI module has be=
en answered by the committee directly - there is no ready library, which ev=
eryone will agree upon to be included.</div><div>Writing=C2=A0one from scra=
tch is out of question - it is way too much work without a clear, well defi=
ned scope.=C2=A0</div><div><br></div><div>So, the committee stepped back an=
d decided to include Graphics 2D lib, the logic being, one should be able t=
o draw on the screen, not just output to the console. </div><div>I personal=
ly am skeptical about this one as well, but that&#39;s another story. </div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09d07be1-f83a-4bad-9433-63ff9f09e58f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09d07be1-f83a-4bad-9433-63ff9f09e58f=
%40isocpp.org</a>.<br />

------=_Part_1745_1707062430.1476272691631--

------=_Part_1744_682845832.1476272691631--

.

On 12 October 2016 at 14:05, Victor Dyachenko
<victor.dyachenko@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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYrmHKuNHs9Z3S5e2X4xjtma5FOGuG4J0jyFDRLJymFyw%40mail.gmail.com.

.

------=_Part_1689_1352444273.1476275003816
Content-Type: multipart/alternative;
 boundary="----=_Part_1690_1676396736.1476275003816"

------=_Part_1690_1676396736.1476275003816
Content-Type: text/plain; charset=UTF-8

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 :-)

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6983bc13-e5cd-4b0b-851a-a2401cb3e790%40isocpp.org.

------=_Part_1690_1676396736.1476275003816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 2:50:29 PM UTC+3, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But if your =
view is that it&#39;s better to have
<br>nothing than to have something
<br>in the standard library, I doubt I&#39;m going to agree with that view.
<br></blockquote><div>No, my view is that not everything in the world must =
be in the programming language standard. Even C++ language features today c=
an be shipped separately - as TS. Don&#39;t get me wrong, I like ISO C++ st=
andard but it&#39;s impossible and impractical try to put everything into i=
t. It is good place for fundamental programming components but not for fram=
eworks. It should provide tools for framework writers like reflection, stri=
ngs support, filesystem etc, but not to declare one of frameworks &quot;sta=
ndard&quot; or (even worse) make yet another &quot;design by committee&quot=
;. So I personally don&#39;t believe in standard C++ killer-API for GUI. Ho=
wever one can blame me in the future if it will be implemented :-)<br></div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6983bc13-e5cd-4b0b-851a-a2401cb3e790%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6983bc13-e5cd-4b0b-851a-a2401cb3e790=
%40isocpp.org</a>.<br />

------=_Part_1690_1676396736.1476275003816--

------=_Part_1689_1352444273.1476275003816--

.

On 12 October 2016 at 15:23, Victor Dyachenko
<victor.dyachenko@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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbgR%2B-4zfcuMo_Us0CMuzofOMPksJDhY24654JEv_xyzA%40mail.gmail.com.

.

------=_Part_1459_773761286.1476279769785
Content-Type: multipart/alternative;
 boundary="----=_Part_1460_1119240518.1476279769785"

------=_Part_1460_1119240518.1476279769785
Content-Type: text/plain; charset=UTF-8



<https://lh3.googleusercontent.com/-O4HdjRl3sxs/V_49moQdioI/AAAAAAAAARU/7o9nhvrbTDAjSsq2OaCNflC_A7qdlofMACLcB/s1600/windo2.png>
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.....

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/92889f28-ec6b-4d31-a45d-0968c447b486%40isocpp.org.

------=_Part_1460_1119240518.1476279769785
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"separator" style=3D"text-align: center; clear:=
 both;"><a imageanchor=3D"1" href=3D"https://lh3.googleusercontent.com/-O4H=
djRl3sxs/V_49moQdioI/AAAAAAAAARU/7o9nhvrbTDAjSsq2OaCNflC_A7qdlofMACLcB/s160=
0/windo2.png" style=3D"margin-left: 1em; margin-right: 1em;"><img src=3D"ht=
tps://lh3.googleusercontent.com/-O4HdjRl3sxs/V_49moQdioI/AAAAAAAAARU/7o9nhv=
rbTDAjSsq2OaCNflC_A7qdlofMACLcB/s320/windo2.png" border=3D"0" style=3D"" wi=
dth=3D"320" height=3D"150"></a></p>For to have a gui is needled a real worl=
d naming convention, and a fully integration with Modern C++.<div>And a new=
 C++ standardy library is needled, to be consistent, robust, simple to lear=
n.....</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92889f28-ec6b-4d31-a45d-0968c447b486%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/92889f28-ec6b-4d31-a45d-0968c447b486=
%40isocpp.org</a>.<br />

------=_Part_1460_1119240518.1476279769785--

------=_Part_1459_773761286.1476279769785--

.

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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ntlg7q%24js2%241%40blaine.gmane.org.

.

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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ntlgn4%243tk%241%40blaine.gmane.org.

.

--001a113ebf8cadf221053eabdad6
Content-Type: text/plain; charset=UTF-8

2016-10-12 15:42 GMT+02:00 HarD Gamer <rodrigojose690@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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLP6TUzW0Hv_gTyLGEZ_72uHyejCYhs49c_Fka9LZ6d4w%40mail.gmail.com.

--001a113ebf8cadf221053eabdad6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2016-10-12 15:42 GMT+02:00 HarD Gamer <span dir=3D"ltr">&l=
t;<a target=3D"_blank" href=3D"mailto:rodrigojose690@gmail.com">rodrigojose=
690@gmail.com</a>&gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quo=
te"><div dir=3D"ltr">For to have a gui is needled a real world naming conve=
ntion, and a fully integration with Modern C++.<div>And a new C++ standardy=
 library is needled, to be consistent, robust, simple to learn.....</div></=
div></blockquote><div><br></div><div>GUI is not necessarily what you see on=
 your phone/PC every day...<br></div><div>=C2=A0</div><div>In your example =
there is a button class. Button as far as I&#39;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&#39;s the same for checkboxes (multiselect dropdown, mul=
tiselect list, group of checkbox fields or group of toggle buttons) or radi=
o buttons (single select dropdown, single select list, group of radio butto=
ns, ...) with boolean variable and on click callback. Then there is layout,=
 rendering and styling that are loosely related to the data...<br><br></div=
><div>I&#39;m not certain if a simple gui library would be something that w=
ould cower all the issues and also be simple to use... The data representat=
ion is already C++ itself, ranges could probably be used for conversion of =
data in different representations (D3.js library style)... There is a 2D re=
ndering library proposal and if I recall correctly some people are also wor=
king on event library proposal...<br><br></div><div>It would be hard to con=
vince 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&#39;d have to define automatic or man=
ual conversions from one layout to another and element hiding as I doubt th=
at everybody would agree on default fallbacks... It would also be hard to d=
efine which widgets are the basic building blocks (is one type of a graph a=
 basic widget or already advanced stuff?).<br><br></div><div>It&#39;s been =
pre C++11 since I wrote a simple GUI lib and I&#39;m just writing down my c=
urrent thoughts so I could be mistaken but I&#39;m guessing that besides th=
e 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 help=
ers for widget creation (event moves line on one or another side of some ot=
her element and you&#39;ve got yourself a carrot for text field - not neces=
sarily 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 dr=
awn). The rest of the stuff should remain in the domain of different librar=
ies/os-es/websites/games.<br><br></div><div>Just my 2 cents.<br><br></div><=
div>Regards,<br></div><div>Domen<br></div><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLP6TUzW0Hv_gTyLGEZ_72uHyejCYhs=
49c_Fka9LZ6d4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLP6TUzW0Hv=
_gTyLGEZ_72uHyejCYhs49c_Fka9LZ6d4w%40mail.gmail.com</a>.<br />

--001a113ebf8cadf221053eabdad6--

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 13:54:48 CEST, Ville Voutil=
ainen=20
escreveu:
> Why would such deprecation be necessary?

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6179833.5EeAZCx2QF%40tjmaciei-mobl1.

.

On 12 October 2016 at 18:05, Thiago Macieira <thiago@macieira.org> wrote:
> Em quarta-feira, 12 de outubro de 2016, =C3=A0s 13:54:48 CEST, Ville Vout=
ilainen
> escreveu:
>> Why would such deprecation be necessary?
>
> Well, the SG working on a standard library proposal for a graphics librar=
y 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?

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbe_1a%2BpAG12UEZQXjO%2B0FADLtKy_rUbVsUCDF=
eLKiN9w%40mail.gmail.com.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:07:04 CEST, Ville Voutil=
ainen=20
escreveu:
> > Well, the SG working on a standard library proposal for a graphics libr=
ary
> > was designing a library to be deprecated-on-arrival (it was a 2D, non-H=
W-
> > accelerated lib).
>=20
> They are still working on it. Which part of it is non-HW-accelerated?

The 2D part.

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4025486.2YVPLbUkBl%40tjmaciei-mobl1.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:07:04 CEST, Ville Voutil=
ainen=20
escreveu:
> > Well, the SG working on a standard library proposal for a graphics libr=
ary
> > was designing a library to be deprecated-on-arrival (it was a 2D, non-H=
W-
> > accelerated lib).
>=20
> They are still working on it. Which part of it is non-HW-accelerated?

The 2D part with imperative-style programming.

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/15067047.jHVJzqrvNu%40tjmaciei-mobl1.

.

On 12 October 2016 at 18:18, Thiago Macieira <thiago@macieira.org> wrote:
> Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:07:04 CEST, Ville Vout=
ilainen
> escreveu:
>> > Well, the SG working on a standard library proposal for a graphics lib=
rary
>> > 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?

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZq_e2zMVORNyR%2BZRFzJ8AgGhR-6FysCqjS18nJ_=
GZF-g%40mail.gmail.com.

.

------=_Part_1068_418739630.1476290109771
Content-Type: multipart/alternative;
 boundary="----=_Part_1069_2027799043.1476290109771"

------=_Part_1069_2027799043.1476290109771
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 12, 2016 at 11:21:24 AM UTC-4, Ville Voutilainen=20
wrote:
>
> On 12 October 2016 at 18:18, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:=20
> > Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:07:04 CEST, Ville=20
> Voutilainen=20
> > escreveu:=20
> >> > Well, the SG working on a standard library proposal for a graphics=
=20
> library=20
> >> > was designing a library to be deprecated-on-arrival (it was a 2D,=20
> non-HW-=20
> >> > accelerated lib).=20
> >>=20
> >> They are still working on it. Which part of it is non-HW-accelerated?=
=20
> >=20
> > The 2D part with imperative-style programming.=20
>
>
> Cairo HW-accelerates that part, so why wouldn't this library they are=20
> proposing, since it's based=20
> on Cairo?=20
>

Hardware accelerated in what sense?

According to this post from 2012=20
<https://lists.cairographics.org/archives/cairo/2012-October/023609.html>,=
=20
`cairo-gl` is not fully hardware accelerated. It only accelerate "GPU=20
compositing and some rasterisation". Is that the fault of the cairo API or=
=20
the fault of the implementation of `cairo-gl`?

By contrast, NVIDIA's NV_path_rendering OpenGL extension=20
<https://www.opengl.org/registry/specs/NV/path_rendering.txt> is not only=
=20
fully hardware accelerated, it permits the use of shaders.

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

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

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

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

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/82ad8551-73ab-45e7-b11d-9e38b7e56377%40isocpp.or=
g.

------=_Part_1069_2027799043.1476290109771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 11:21:24 AM UTC-4, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12 Octob=
er 2016 at 18:18, Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"MBx8VkNmAQAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">thi...@macieira.org</a>&gt; wrote:
<br>&gt; Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:07:04 CEST, Vil=
le Voutilainen
<br>&gt; escreveu:
<br>&gt;&gt; &gt; Well, the SG working on a standard library proposal for a=
 graphics library
<br>&gt;&gt; &gt; was designing a library to be deprecated-on-arrival (it w=
as a 2D, non-HW-
<br>&gt;&gt; &gt; accelerated lib).
<br>&gt;&gt;
<br>&gt;&gt; They are still working on it. Which part of it is non-HW-accel=
erated?
<br>&gt;
<br>&gt; The 2D part with imperative-style programming.
<br>
<br>
<br>Cairo HW-accelerates that part, so why wouldn&#39;t this library they a=
re
<br>proposing, since it&#39;s based
<br>on Cairo?
<br></blockquote><div><br>Hardware accelerated in what sense?<br><br>Accord=
ing to <a href=3D"https://lists.cairographics.org/archives/cairo/2012-Octob=
er/023609.html">this post from 2012</a>, `cairo-gl` is not fully hardware a=
ccelerated. It only accelerate &quot;GPU compositing and some rasterisation=
&quot;. Is that the fault of the cairo API or the fault of the implementati=
on of `cairo-gl`?<br><br>By contrast, NVIDIA&#39;s <a href=3D"https://www.o=
pengl.org/registry/specs/NV/path_rendering.txt">NV_path_rendering OpenGL ex=
tension</a> is not only fully hardware accelerated, it permits the use of s=
haders.<br><br>I have not taken anything remotely like a thorough examinati=
on of Cairo, C++ 2D, or NV_path_rendering. But Cairo as an API doesn&#39;t =
seem like it is designed around the question of whether an operation is har=
dware-acceleratable or not.<br><br>It also doesn&#39;t look anything like m=
odern APIs. If you look at the evolution of graphics APIs from a performanc=
e standpoint, there is a strong move from &quot;call a bunch of functions t=
o set state, then render&quot; to &quot;set up a small number of objects, t=
hen render&quot;. Cairo is far more like OpenGL than Vulkan.<br><br>To me, =
this sort of thing is the big reason why large-scale projects like 2D libra=
ries and GUIs cannot work in the C++ standardization environment. Yes, you&=
#39;ll eventually get <i>something</i>. But is it something that people wil=
l use?<br><br>How many people would use C++2D to do <i>actual work</i>? Whi=
le I appreciate Herb Sutter&#39;s desire to make pure C++ more effective at=
 doing things, the particular impetus he pointed out is simply not somethin=
g that actual people have a genuine need for. C++2D feels like a stunt rath=
er than a tool that solves a genuine problem.<br><br>Could a C++ GUI librar=
y be used to make GUI applications? Sure. Would they be anything like profe=
ssional GUI applications? How responsive to the change in GUI environments =
would they be? Mobile platforms introduced a <i>substantial</i> shift in ho=
w 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 respons=
ive would it be? And so forth.<br><br>The standard library can work for thi=
ngs with have a solid foundation, which isn&#39;t going to change very rapi=
dly. Networking, basic filesystem access, XML/JSON processing, etc. The sta=
ndard library is not a good place for a quickly-changing environment like G=
UIs.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/82ad8551-73ab-45e7-b11d-9e38b7e56377%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82ad8551-73ab-45e7-b11d-9e38b7e56377=
%40isocpp.org</a>.<br />

------=_Part_1069_2027799043.1476290109771--

------=_Part_1068_418739630.1476290109771--

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 18:21:22 CEST, Ville Voutil=
ainen=20
escreveu:
> > The 2D part with imperative-style programming.
>=20
> 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=
=20
fully utilise the GPU acceleration. GPUs haven't operated in a way that Cai=
ro=20
uses since the early 1990s. GPUs operate in retained mode, which means ther=
e's=20
a big impedance mismatch between imperative programming and how they operat=
e,=20
and they're designed for 3D.

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

In 2010, after investigating Cairo, we investigated what Clutter does (COGL=
),=20
and redesigned everything. The product was that is the core of the QtQuick=
=20
module: the scene graph. That was first released in Qt 5.0 -- it is, quite =
in=20
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=
=20
skip the QML bits, just the core scene graph is fine.

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/246052172.QKyKGjTxh4%40tjmaciei-mobl1.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 09:35:09 CEST, Nicol Bolas=
=20
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 plac=
e
> for a quickly-changing environment like GUIs.

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

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


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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2403391.Qx4XMPciah%40tjmaciei-mobl1.

.

On 12 October 2016 at 21:06, Thiago Macieira <thiago@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. :)

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbjKBN468F6%3DGYfSay%3DAK5ZYn4b5-BkyZM%2BCOJ-JKTHEw%40mail.gmail.com.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 21:17:30 CEST, Ville Voutil=
ainen=20
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.
>=20
> 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=20
accelerate some operations.

But you can't get the most out of the hardware with that impedance mismatch=
..=20
The whole point is that we should design an API that *can* get the most out=
 of=20
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 t=
o
> > 5.x.
> >=20
> > 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.
>=20
> You're more than welcome to let SG13 know about these insights. :)

We did, when it formed.

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8738394.lVZcBSLVcz%40tjmaciei-mobl1.

.

------=_Part_1696_519564912.1476297379902
Content-Type: multipart/alternative;
 boundary="----=_Part_1697_1227865415.1476297379902"

------=_Part_1697_1227865415.1476297379902
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0a6e151d-ba52-4a5b-aea8-066f283f88bb%40isocpp.org.

------=_Part_1697_1227865415.1476297379902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I am with Thiago on this one=C2=A0- today is <b>the w=
orst time </b>to have <i>standard</i> drawing (or GUI for that matter)=C2=
=A0library. </div><div>That ship has sailed more then 10 years ago. Today i=
s the time of the most rapid development in that area, both hardware and ne=
w APIs to access it.<br></div><div>Indeed, everything will be outdated the =
moment it is released. </div><div><br></div><div>Having said that, probably=
 an &quot;old school&quot; lib has its place as well, just to be able to dr=
aw stuff on screen. </div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a6e151d-ba52-4a5b-aea8-066f283f88bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a6e151d-ba52-4a5b-aea8-066f283f88bb=
%40isocpp.org</a>.<br />

------=_Part_1697_1227865415.1476297379902--

------=_Part_1696_519564912.1476297379902--

.

------=_Part_1918_1671072731.1476304228304
Content-Type: multipart/alternative;
 boundary="----=_Part_1919_1580363307.1476304228304"

------=_Part_1919_1580363307.1476304228304
Content-Type: text/plain; charset=UTF-8

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/494491f9-ad74-4381-8b45-bae292d2d959%40isocpp.org.

------=_Part_1919_1580363307.1476304228304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 8:21:24 AM UTC-7, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Cairo HW=
-accelerates that part, so why wouldn&#39;t this library they are
<br>proposing, since it&#39;s based
<br>on Cairo?
<br></blockquote><div><br></div><div>This was a point I was trying to make =
to that working group. Cairo is super sub-optimal. Every major vendor who s=
tarted using Ciaro dropped it and replaced it with a better library, often =
having to home-grow their own.</div><div><br></div><div>Cairo is a stateful=
/contextful library built around GL-like models of programming. Which isn&#=
39;t how hardware works, nor how drivers work, nor even how good software w=
orks. Good canvas drawing libraries operate in as stateless a fashion a pos=
sible.</div><div><br></div><div>This is both about speed and interface desi=
gn. 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.</div>=
<div><br></div><div>The composition problem results in different pieces of =
code not being able to cooperate seamlessly. Hand off a Cairo canvas to a h=
elper routine/library and you have no idea what state may be changed out fr=
om under you. So to avoid surprise bugs you have to do a full state save/re=
store. Which is expensive when you don&#39;t need it. So the library has to=
 do a ton of work to de-bounce unnecessary state changes that the library i=
tself is forcing users to make for correctness. And that&#39;s assuming tha=
t users remember to do all the extra steps to achieve said correctness and =
don&#39;t just get all the bugs.</div><div><br></div><div>Basing a modern c=
anvas library that will be standardized in 2020+ off of Cairo would be a ba=
ffingly poor decision. It was an out-dated model of graphics programming 5 =
years ago and isn&#39;t going to be any less antiquated 4 years from now. I=
t will be difficult to use and it will be inefficient, thus solving few rea=
l use cases; beginners or quick uses need easy and pros need efficient.</di=
v><div><br></div><div><br></div><div>I don&#39;t even want to get into the =
GUI parts. You claimed earlier that GUIs don&#39;t change that often, which=
 is just outright wrong. You can&#39;t go a week without Apple or Facebook =
or Google or Microsoft or Twitter or Uber or whoever releasing a new librar=
y 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 stat=
eless reactive UIs. Let&#39;s not even get into how &quot;C++&quot; UIs are=
 transitioning to doing everything in HTML5, QML, XAML, or so on with barel=
y any C++ even in the application UI code.</div><div><br></div><div><br></d=
iv><div>Putting Cairo into the stdlib makes barely more sense than putting =
3dfx Glide into the stdlib, IMO. :)<br></div><div><br></div><div><br></div>=
<div>We just need a package manager. The problem with third party libraries=
 isn&#39;t fundamentally that they&#39;re not in the standard; the problem =
is that using non-standard libraries involves steps that vary wildly by com=
piler and environment. Rather than pulling individual libraries one-by-one =
into the standard and signing up to maintain them in perpetuity, fix the fu=
ndamental root problem. Then folks who decide they want C++ Cairo can just =
import cairomm and be done with it.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/494491f9-ad74-4381-8b45-bae292d2d959%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/494491f9-ad74-4381-8b45-bae292d2d959=
%40isocpp.org</a>.<br />

------=_Part_1919_1580363307.1476304228304--

------=_Part_1918_1671072731.1476304228304--

.

On 12 October 2016 at 23:30, Sean Middleditch
<sean.middleditch@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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbdcjLBjqyU-PzTuGcnAUFmyzZE_oJRJTSNdxVr5w68jQ%40mail.gmail.com.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 11:36:19 CEST,=20
mihailnajdenov@gmail.com escreveu:
> Having said that, probably an "old school" lib has its place as well, jus=
t
> to be able to draw stuff on screen.

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

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2579385.mp9Y8FDQSx%40tjmaciei-mobl1.

.

Em quarta-feira, 12 de outubro de 2016, =C3=A0s 23:45:03 CEST, Ville Voutil=
ainen=20
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.
>=20
> Ah, yes, thus creating UIs that are bad both in performance and in qualit=
y
> as far as bugs go. What C++ needs is a modern GUI library, standard or no=
t,
> 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=
,=20
it's actually quite neat. It's using C++ to do retained (declarative)=20
programming. It even has a C++ API for manipulating the graph, adding nodes=
 to=20
it, even the one node that operates 90s-style (QQuickPaintedItem).

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

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

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2903348.mytIWDRnDh%40tjmaciei-mobl1.

.

On 13 October 2016 at 10:46, Thiago Macieira <thiago@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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUakVos_ZaGHuXbEErSAE9%3DFYUCsHSSmjexALBDAHgtaKw%40mail.gmail.com.

.

--001a114033608065be053ebfcc13
Content-Type: text/plain; charset=UTF-8

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

>
> On Wed, Oct 12, 2016 at 9:45 PM, Ville Voutilainen <
> ville.voutilainen@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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GhryLhiUzLK%3DRxsW7ZkukH6nHQF35PzZLjyENCPYka41Q%40mail.gmail.com.

--001a114033608065be053ebfcc13
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Oct 13, 2016 at 3:22 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_=
quote"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><span class=3D""><span>On Wed, Oct 12, 2016 at 9:45 PM, Ville Voutilaine=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" targ=
et=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<span><br>
&gt; how &quot;C++&quot; UIs are transitioning to doing everything in HTML5=
, QML, XAML, or<br>
&gt; so on with barely any C++ even in the application UI code.<br>
<br>
</span>Ah, yes, thus creating UIs that are bad both in performance and in q=
uality as<br>
far as bugs go.</blockquote><div><br></div></span></span><div>+1! Personall=
y, give me programmatic/procedural control of the GUI any day. XML et al wo=
n&#39;t cut it most of the time, for various reasons. <br></div></div></div=
></div></div></div></blockquote><div><br></div><div>Sorry to burst your bub=
ble.. But the better GUI designs separate the visual design from the progra=
matic task design. Where the presentation is as much data driven as possibl=
e. Hence using things like HTML, JSON, XML, etc as presentation description=
s (and some times the dynamics of the presentation).</div><div><br></div><d=
iv>And to truly burst your bubble.. Programmers are horrific GUI designers.=
 And anything that makes it such that programmers aren&#39;t aligning butto=
ns, and laying out tables, etc. is a &quot;really good thing&quot;.</div><d=
iv><br></div></div><div><br></div>-- <br><div class=3D"gmail_signature" dat=
a-smartmail=3D"gmail_signature"><div dir=3D"ltr">-- Rene Rivera<br>-- Grafi=
k - Don&#39;t Assume Anything<br>-- Robot Dreams -=C2=A0<a href=3D"http://r=
obot-dreams.net/" target=3D"_blank">http://robot-dreams.net</a><br>-- rrive=
ra/<a href=3D"http://acm.org/" target=3D"_blank">acm.org</a>=C2=A0(msn)=C2=
=A0-=C2=A0grafikrobot/aim,yahoo,skype,efnet,gmail</div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHEh_GhryLhiUzLK%3DRxsW7ZkukH6nHQF35=
PzZLjyENCPYka41Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GhryLhiUz=
LK%3DRxsW7ZkukH6nHQF35PzZLjyENCPYka41Q%40mail.gmail.com</a>.<br />

--001a114033608065be053ebfcc13--

.

------=_Part_1048_1210783638.1476443178013
Content-Type: multipart/alternative;
 boundary="----=_Part_1049_1910611188.1476443178013"

------=_Part_1049_1910611188.1476443178013
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=886:54:53=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 12 October 2016 at 13:50, Victor Dyachenko=20
> <victor.d...@gmail.com <javascript:>> wrote:=20
> > For C++ we have at least Qt and wxWigets. Why do we need to put them=20
> into=20
>
> I don't recall anyone suggesting putting Qt or wxWidgets into the=20
> standard.=20
>
> At least Qt is not fit here, definitely. Technically you have to do toooo=
o=20
much work to work around with [intro.refs], for example.

=20

> > Standard? To have big deprecated parts in the Standard in the future?=
=20
>
> Why would such deprecation be necessary?=20
>
> > Why don't we have universal GUI library in C++? Because there is no the=
=20
> only=20
> > way to implement GUI.=20
>
> There's not only one way to implement most of the standard library,=20
> which is one reason why=20
> it doesn't mandate any particular implementation, so that's a non-issue.=
=20
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/575c7b95-217c-4139-be7a-26b99ab4a126%40isocpp.or=
g.

------=_Part_1049_1910611188.1476443178013
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=886:54:53=EF=BC=8CVille Vouti=
lainen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On 12 October 2016 at 13:50, Victor Dyachenko
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
qErxKrhXAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">victor.d...@gmail.com</a>&gt; wrote:
<br>&gt; For C++ we have at least Qt and wxWigets. Why do we need to put th=
em into
<br>
<br>I don&#39;t recall anyone suggesting putting Qt or wxWidgets into the s=
tandard.
<br>
<br></blockquote><div>At least Qt is not fit here, definitely. Technically =
you have to do=20
tooooo much work to work around with [intro.refs], for example.<br><br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Standard? To hav=
e big deprecated parts in the Standard in the future?
<br>
<br>Why would such deprecation be necessary?
<br>
<br>&gt; Why don&#39;t we have universal GUI library in C++? Because there =
is no the only
<br>&gt; way to implement GUI.
<br>
<br>There&#39;s not only one way to implement most of the standard library,
<br>which is one reason why
<br>it doesn&#39;t mandate any particular implementation, so that&#39;s a n=
on-issue.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/575c7b95-217c-4139-be7a-26b99ab4a126%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/575c7b95-217c-4139-be7a-26b99ab4a126=
%40isocpp.org</a>.<br />

------=_Part_1049_1910611188.1476443178013--

------=_Part_1048_1210783638.1476443178013--

.

------=_Part_1078_234710597.1476443378884
Content-Type: multipart/alternative;
 boundary="----=_Part_1079_1261489601.1476443378884"

------=_Part_1079_1261489601.1476443378884
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=8811:05:47=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> Em quarta-feira, 12 de outubro de 2016, =C3=A0s 13:54:48 CEST, Ville=20
> Voutilainen=20
> escreveu:=20
> > Why would such deprecation be necessary?=20
>
> Well, the SG working on a standard library proposal for a graphics librar=
y=20
> was=20
> designing a library to be deprecated-on-arrival (it was a 2D, non-HW-=20
> accelerated lib).=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1df400ec-efa8-43d1-bab7-1096ffb7bfbd%40isocpp.or=
g.

------=_Part_1079_1261489601.1476443378884
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is a bit off topic. Besides the concrete implementati=
on, GUI has nothing necessary to do with any particular set of graphics API=
..<br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=89 UTC+8=E4=B8=8B=E5=8D=8811:05:47=EF=BC=8CThiago Macieira=E5=86=99=E9=
=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em quarta-feira=
, 12 de outubro de 2016, =C3=A0s 13:54:48 CEST, Ville Voutilainen=20
<br>escreveu:
<br>&gt; Why would such deprecation be necessary?
<br>
<br>Well, the SG working on a standard library proposal for a graphics libr=
ary was=20
<br>designing a library to be deprecated-on-arrival (it was a 2D, non-HW-
<br>accelerated lib).
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1df400ec-efa8-43d1-bab7-1096ffb7bfbd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1df400ec-efa8-43d1-bab7-1096ffb7bfbd=
%40isocpp.org</a>.<br />

------=_Part_1079_1261489601.1476443378884--

------=_Part_1078_234710597.1476443378884--

.

------=_Part_546_1244414449.1476445145266
Content-Type: multipart/alternative;
 boundary="----=_Part_547_1979040706.1476445145266"

------=_Part_547_1979040706.1476445145266
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT=
C+8=E4=B8=8B=E5=8D=887:50:29=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 12 October 2016 at 14:05, Victor Dyachenko=20
> <victor.d...@gmail.com <javascript:>> wrote:=20
> >> I don't recall anyone suggesting putting Qt or wxWidgets into the=20
> >> standard.=20
> >=20
> > I just wanted to say that one can write portable GUI today using C++=20
> without=20
> > having "C++ standard library".=20
>
> One can write a whole lot of things without using the standard library=20
> for that. The issue=20
> there is that such solutions are less portable than they would be as=20
> standard features,=20
> and the availability is another issue.=20
>
> That's not true. I have written something containing reusable GUI code=20
<https://github.com/FrankHB/YSLib> portable between platforms with=20
freestanding implementation and hosted implementations of C++, but the=20
standard can't provide enough to cover it. Because the standard can't=20
guarantee the intended GUI APIs being able to be implemented on arbitrary=
=20
freestanding implementations it already supported, so it simply can't=20
require it, before having some kinds of "client profiles". The latter will=
=20
not likely come true in the near future.

>> > Standard? To have big deprecated parts in the Standard in the future?=
=20
> >> Why would such deprecation be necessary?=20
> > Why std::auto_ptr, std::strstream et al were deprecated? Because today=
=20
> we=20
> > have better solutions. GUI and GUI libraries are evolving. Imagine MFC=
=20
>
> GUI libraries, and especially their APIs, don't seem to evolve nearly=20
> as fast as some=20
> people like to think. But if your view is that it's better to have=20
> nothing than to have something=20
> in the standard library, I doubt I'm going to agree with that view.=20
>
> > mid-90's vintage being the part of Standard. GUI system is a very=20
> > sophisticated thing. Much more complex than vector class or sorting=20
> > algorithm.=20
>
> Yeah, which is actually a fair reason to have a standardized GUI=20
> library or to have standardized=20
> facilities that help GUI programming.=20
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5644e922-d6c9-411c-9e06-4a5302e0de58%40isocpp.or=
g.

------=_Part_547_1979040706.1476445145266
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B410=E6=9C=8812=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=887:50:29=EF=BC=8CVille Vouti=
lainen=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On 12 October 2016 at 14:05, Victor Dyachenko
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
NZCyzcBaAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">victor.d...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; I don&#39;t recall anyone suggesting putting Qt or wxWidgets i=
nto the
<br>&gt;&gt; standard.
<br>&gt;
<br>&gt; I just wanted to say that one can write portable GUI today using C=
++ without
<br>&gt; having &quot;C++ standard library&quot;.
<br>
<br>One can write a whole lot of things without using the standard library
<br>for that. The issue
<br>there is that such solutions are less portable than they would be as
<br>standard features,
<br>and the availability is another issue.
<br>
<br></blockquote><div>That&#39;s not true. I have written <a href=3D"https:=
//github.com/FrankHB/YSLib">something containing reusable GUI code</a> port=
able between platforms with freestanding implementation and hosted implemen=
tations of C++, but the standard can&#39;t provide enough to cover it. Beca=
use the standard can&#39;t guarantee the intended GUI APIs being able to be=
 implemented on arbitrary freestanding implementations it already supported=
, so it simply can&#39;t require it, before having some kinds of &quot;clie=
nt profiles&quot;. The latter will not likely come true in the near future.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt; &gt; St=
andard? To have big deprecated parts in the Standard in the future?
<br>&gt;&gt; Why would such deprecation be necessary?
<br>&gt; Why std::auto_ptr, std::strstream et al were deprecated? Because t=
oday we
<br>&gt; have better solutions. GUI and GUI libraries are evolving. Imagine=
 MFC
<br>
<br>GUI libraries, and especially their APIs, don&#39;t seem to evolve near=
ly
<br>as fast as some
<br>people like to think. But if your view is that it&#39;s better to have
<br>nothing than to have something
<br>in the standard library, I doubt I&#39;m going to agree with that view.
<br>
<br>&gt; mid-90&#39;s vintage being the part of Standard. GUI system is a v=
ery
<br>&gt; sophisticated thing. Much more complex than vector class or sortin=
g
<br>&gt; algorithm.
<br>
<br>Yeah, which is actually a fair reason to have a standardized GUI
<br>library or to have standardized
<br>facilities that help GUI programming.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5644e922-d6c9-411c-9e06-4a5302e0de58%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5644e922-d6c9-411c-9e06-4a5302e0de58=
%40isocpp.org</a>.<br />

------=_Part_547_1979040706.1476445145266--

------=_Part_546_1244414449.1476445145266--

.

(*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

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5800F137.2040300%40gmail.com.

.

------=_Part_932_314492087.1476457195503
Content-Type: multipart/alternative;
 boundary="----=_Part_933_31031577.1476457195503"

------=_Part_933_31031577.1476457195503
Content-Type: text/plain; charset=UTF-8

On Friday, October 14, 2016 at 10:52:41 AM UTC-4, Matthew Woehlke wrote:
>
> (*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...)
>

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.

--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e329f4f-4c76-4948-ba55-10b409bf88b3%40isocpp.org.

------=_Part_933_31031577.1476457195503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 14, 2016 at 10:52:41 AM UTC-4, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(*Third* try. Ap=
ologies if this shows up more than once; for some reason
<br>I seem to have trouble getting posts to this thread to go through...)
<br>
<br>On 2016-10-12 16:45, Ville Voutilainen wrote:
<br>&gt; I wonder what makes you think a standard GUI would necessarily be =
a matter
<br>&gt; of standardizing widgets and MVC.
<br>
<br>Whatever it is, even if someone proposes today to standardize the
<br>current state of the art, by the time it is in C++xx, the state of the
<br>art will most likely have changed, and C++ will be dragging around a
<br>library based on a paradigm that no one wants to use any more.
<br>
<br>C++ &quot;seems&quot; to be moving fast these days, and that&#39;s good=
, but
<br>historically, GUI and graphics (and audio) have moved even faster.
<br>Specifically, they&#39;ve been moving for some years at a pace that an =
ISO
<br>process can&#39;t realistically match.
<br>
<br>That&#39;s not to say that the ISO process is fundamentally broken or
<br>anything. For much of what C++ specifies, and especially the core
<br>language, I would say the ISO process works well, and in some senses th=
e
<br>limited degree of flexibility is an *advantage*. However, I strongly
<br>feel that the ISO process is not appropriate for a GUI framework. (Or a
<br>graphics framework (Glide!), or an audio framework (ALSA!), or...)
<br></blockquote><div><br>This is why I think we should have a process for =
making TS&#39;s <i>without</i> the intent to incorporate them into C++. The=
y would represent optional features that have a firm standard from ISO, but=
 can be removed and replaced at any time.<br><br>Also, there&#39;s the matt=
er of the sheer effort it takes to write an implementation of something wit=
h the complexity of C++2D or a GUI framework. To make C++2D efficient requi=
res tons of work, especially if you want GPU hardware processing where avai=
lable. A GUI framework, across multiple platforms? That requires a tremendo=
us amount of work for anything more complex than the most trivial of cases.=
<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2e329f4f-4c76-4948-ba55-10b409bf88b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e329f4f-4c76-4948-ba55-10b409bf88b3=
%40isocpp.org</a>.<br />

------=_Part_933_31031577.1476457195503--

------=_Part_932_314492087.1476457195503--

.

------=_Part_4801_1865518617.1497993566103
Content-Type: multipart/alternative;
 boundary="----=_Part_4802_1730024327.1497993566103"

------=_Part_4802_1730024327.1497993566103
Content-Type: text/plain; charset="UTF-8"



>
> 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.

>
> --
> 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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0c046842-fdf9-4725-9725-95f36d36c905%40isocpp.org.

------=_Part_4802_1730024327.1497993566103
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>In 2010, after investigating Cairo, we investigated what Clutter does (=
COGL),=20
<br>and redesigned everything. The product was that is the core of the QtQu=
ick=20
<br>module: the scene graph. That was first released in Qt 5.0 -- it is, qu=
ite in=20
<br>fact, one of the two reasons why we switched from 4.x to 5.x.
<br>
<br>So if you want a good API to base on for graphics, look into that. You =
can=20
<br>skip the QML bits, just the core scene graph is fine.
<br></blockquote><div><br>So how does thisapproach compare to OpenInventor.=
=C2=A0 It is a retained mode layer over OpenGL.=C2=A0 You essentially build=
 up a state with vertices and triangles and then render. <br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0c046842-fdf9-4725-9725-95f36d36c905%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c046842-fdf9-4725-9725-95f36d36c905=
%40isocpp.org</a>.<br />

------=_Part_4802_1730024327.1497993566103--

------=_Part_4801_1865518617.1497993566103--

.