Topic: About the naming of Signals and Slots (General Thoughts)
Author: mhamilton@playq.net
Date: Fri, 25 Mar 2016 12:23:11 -0700 (PDT)
Raw View
------=_Part_2517_1543002691.1458933791830
Content-Type: multipart/alternative;
boundary="----=_Part_2518_1552340124.1458933791830"
------=_Part_2518_1552340124.1458933791830
Content-Type: text/plain; charset=UTF-8
So, I skimmed
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0249r0.pdf and saw
plenty of references to QT and Boost signal/slot patterns.
It seems the paper avoids using that terminology itself which is nice,
instead preferring event base names.
I guess I just wanted to throw this out there, Signal/Slot are not very
good names for what they represent.
What's a slot do? It is actually the object that sends signals! What's a
signal? It's an object which listens to a slot's signals and receives
those messages. Or you can think of it like a slot is something hooked
into, and then a signal is something that sends signals to user supplied
functions? I don't know. It's so backwards named it's hard to really keep
straight in your head.
Yuck. A lot of this confusion comes in because slot doesn't really speak
to the active role it plays in disseminating events to multiple listeners.
The naming is passive and vague and if not widely adopted already, would
not be obvious to anyone.
I call my small custom signal/slot class setup:
Signal/Receiver
Where Signal sends a message, and Receiver accepts the message. When a
receiver goes out of scope it disconnects from the signal and stops
receiving.
It's also beneficial to limit who can send signals by making the Signal
object itself private, and wrapping it in a SignalHookup or SignalRegister
class which allows Receivers to connect to the wrapped signal object, but
which does *not* allow call syntax from outside of the class that owns the
Signal.
--
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/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%40isocpp.org.
------=_Part_2518_1552340124.1458933791830
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So, I skimmed http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2016/p0249r0.pdf and saw plenty of references to QT and Boost signal=
/slot patterns.<div><br></div><div>It seems the paper avoids using that ter=
minology itself which is nice, instead preferring event base names.<br><br>=
I guess I just wanted to throw this out there, Signal/Slot are not very goo=
d names for what they represent.<br><br>What's a slot do? =C2=A0It is a=
ctually the object that sends signals! =C2=A0What's a signal? =C2=A0It&=
#39;s an object which listens to a slot's signals and receives those me=
ssages. =C2=A0Or you can think of it like a slot is something hooked into, =
and then a signal is something that sends signals to user supplied function=
s? =C2=A0I don't know. =C2=A0It's so backwards named it's hard =
to really keep straight in your head.</div><div><br></div><div>Yuck. =C2=A0=
A lot of this confusion comes in because slot doesn't really speak to t=
he active role it plays in disseminating events to multiple listeners. =C2=
=A0The naming is passive and vague and if not widely adopted already, would=
not be obvious to anyone.</div><div><br></div><div>I call my small custom =
signal/slot class setup:</div><div><br></div><div>Signal/Receiver</div><div=
><br></div><div>Where Signal sends a message, and Receiver accepts the mess=
age. =C2=A0When a receiver goes out of scope it disconnects from the signal=
and stops receiving.</div><div><br></div><div>It's also beneficial to =
limit who can send signals by making the Signal object itself private, and =
wrapping it in a SignalHookup or SignalRegister class which allows Receiver=
s to connect to the wrapped signal object, but which does *not* allow call =
syntax from outside of the class that owns the Signal.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6154fbd-07a8-475b-a96b-8bf57c66e3fe=
%40isocpp.org</a>.<br />
------=_Part_2518_1552340124.1458933791830--
------=_Part_2517_1543002691.1458933791830--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 25 Mar 2016 15:53:36 -0700
Raw View
On Fri, Mar 25, 2016 at 12:23 PM, <mhamilton@playq.net> wrote:
> So, I skimmed
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0249r0.pdf and saw
> plenty of references to QT and Boost signal/slot patterns.
>
> It seems the paper avoids using that terminology itself which is nice,
> instead preferring event base names.
>
> I guess I just wanted to throw this out there, Signal/Slot are not very good
> names for what they represent.
>
> What's a slot do? It is actually the object that sends signals! What's a
> signal? It's an object which listens to a slot's signals and receives those
> messages.
You have these backwards. The signal is the sender side, the slot is
the receiver side.
> Or you can think of it like a slot is something hooked into, and
> then a signal is something that sends signals to user supplied functions? I
> don't know. It's so backwards named it's hard to really keep straight in
> your head.
>
> Yuck. A lot of this confusion comes in because slot doesn't really speak to
> the active role it plays in disseminating events to multiple listeners. The
> naming is passive and vague and if not widely adopted already, would not be
> obvious to anyone.
>
> I call my small custom signal/slot class setup:
>
> Signal/Receiver
>
> Where Signal sends a message, and Receiver accepts the message. When a
> receiver goes out of scope it disconnects from the signal and stops
> receiving.
>
> It's also beneficial to limit who can send signals by making the Signal
> object itself private, and wrapping it in a SignalHookup or SignalRegister
> class which allows Receivers to connect to the wrapped signal object, but
> which does *not* allow call syntax from outside of the class that owns the
> Signal.
>
> --
> 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/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%40isocpp.org.
--
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/CAOfiQqkRX5yaKRV7XepdZy5cp%3DPyeVedsdZKWcgrpgCLGDQOQw%40mail.gmail.com.
.
Author: Michael Hamilton <mhamilton@playq.net>
Date: Fri, 25 Mar 2016 17:09:47 -0700
Raw View
--001a11c3165e5cc5fb052ee87fbe
Content-Type: text/plain; charset=UTF-8
I guess that's kind of my point. I always get them wrong.
On Fri, Mar 25, 2016 at 3:53 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On Fri, Mar 25, 2016 at 12:23 PM, <mhamilton@playq.net> wrote:
> > So, I skimmed
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0249r0.pdf and
> saw
> > plenty of references to QT and Boost signal/slot patterns.
> >
> > It seems the paper avoids using that terminology itself which is nice,
> > instead preferring event base names.
> >
> > I guess I just wanted to throw this out there, Signal/Slot are not very
> good
> > names for what they represent.
> >
> > What's a slot do? It is actually the object that sends signals! What's
> a
> > signal? It's an object which listens to a slot's signals and receives
> those
> > messages.
>
> You have these backwards. The signal is the sender side, the slot is
> the receiver side.
>
> > Or you can think of it like a slot is something hooked into, and
> > then a signal is something that sends signals to user supplied
> functions? I
> > don't know. It's so backwards named it's hard to really keep straight in
> > your head.
> >
> > Yuck. A lot of this confusion comes in because slot doesn't really
> speak to
> > the active role it plays in disseminating events to multiple listeners.
> The
> > naming is passive and vague and if not widely adopted already, would not
> be
> > obvious to anyone.
> >
> > I call my small custom signal/slot class setup:
> >
> > Signal/Receiver
> >
> > Where Signal sends a message, and Receiver accepts the message. When a
> > receiver goes out of scope it disconnects from the signal and stops
> > receiving.
> >
> > It's also beneficial to limit who can send signals by making the Signal
> > object itself private, and wrapping it in a SignalHookup or
> SignalRegister
> > class which allows Receivers to connect to the wrapped signal object, but
> > which does *not* allow call syntax from outside of the class that owns
> the
> > Signal.
> >
> > --
> > 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/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%40isocpp.org
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/ZM24JWTyeMc/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAOfiQqkRX5yaKRV7XepdZy5cp%3DPyeVedsdZKWcgrpgCLGDQOQw%40mail.gmail.com
> .
>
--
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/CAPYnPt0CVhFxSMO6T6zXg4tH2ggQRCDrtAXGoxaSBOL0OUofjg%40mail.gmail.com.
--001a11c3165e5cc5fb052ee87fbe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I guess that's kind of my point.=C2=A0 I always get th=
em wrong.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
Fri, Mar 25, 2016 at 3:53 PM, Richard Smith <span dir=3D"ltr"><<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
Fri, Mar 25, 2016 at 12:23 PM,=C2=A0 <<a href=3D"mailto:mhamilton@playq.=
net">mhamilton@playq.net</a>> wrote:<br>
> So, I skimmed<br>
> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p02=
49r0.pdf" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0249r0.pdf</a> and saw<br>
> plenty of references to QT and Boost signal/slot patterns.<br>
><br>
> It seems the paper avoids using that terminology itself which is nice,=
<br>
> instead preferring event base names.<br>
><br>
> I guess I just wanted to throw this out there, Signal/Slot are not ver=
y good<br>
> names for what they represent.<br>
><br>
> What's a slot do?=C2=A0 It is actually the object that sends signa=
ls!=C2=A0 What's a<br>
> signal?=C2=A0 It's an object which listens to a slot's signals=
and receives those<br>
> messages.<br>
<br>
</span>You have these backwards. The signal is the sender side, the slot is=
<br>
the receiver side.<br>
<span class=3D""><br>
> Or you can think of it like a slot is something hooked into, and<br>
> then a signal is something that sends signals to user supplied functio=
ns?=C2=A0 I<br>
> don't know.=C2=A0 It's so backwards named it's hard to rea=
lly keep straight in<br>
> your head.<br>
><br>
> Yuck.=C2=A0 A lot of this confusion comes in because slot doesn't =
really speak to<br>
> the active role it plays in disseminating events to multiple listeners=
..=C2=A0 The<br>
> naming is passive and vague and if not widely adopted already, would n=
ot be<br>
> obvious to anyone.<br>
><br>
> I call my small custom signal/slot class setup:<br>
><br>
> Signal/Receiver<br>
><br>
> Where Signal sends a message, and Receiver accepts the message.=C2=A0 =
When a<br>
> receiver goes out of scope it disconnects from the signal and stops<br=
>
> receiving.<br>
><br>
> It's also beneficial to limit who can send signals by making the S=
ignal<br>
> object itself private, and wrapping it in a SignalHookup or SignalRegi=
ster<br>
> class which allows Receivers to connect to the wrapped signal object, =
but<br>
> which does *not* allow call syntax from outside of the class that owns=
the<br>
> Signal.<br>
><br>
> --<br>
</span>> You received this message because you are subscribed to the Goo=
gle Groups<br>
<span class=3D"">> "ISO C++ Standard - Future Proposals" group=
..<br>
</span>> To unsubscribe from this group and stop receiving emails from i=
t, send an<br>
<span class=3D"">> email to <a href=3D"mailto:std-proposals%2Bunsubscrib=
e@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit<br>
> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%40isocpp.org" rel=3D"noreferrer" tar=
get=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/d6154fbd-07a8-475b-a96b-8bf57c66e3fe%40isocpp.org</a>.<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ZM24JWTyeMc/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/ZM24JWTyeMc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkRX5yaKRV7XepdZy5cp%3DP=
yeVedsdZKWcgrpgCLGDQOQw%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkRX=
5yaKRV7XepdZy5cp%3DPyeVedsdZKWcgrpgCLGDQOQw%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAPYnPt0CVhFxSMO6T6zXg4tH2ggQRCDrtAXG=
oxaSBOL0OUofjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPYnPt0CVhFxSMO6=
T6zXg4tH2ggQRCDrtAXGoxaSBOL0OUofjg%40mail.gmail.com</a>.<br />
--001a11c3165e5cc5fb052ee87fbe--
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Sat, 26 Mar 2016 11:46:29 +0100
Raw View
On 03/25/2016 08:23 PM, mhamilton@playq.net wrote:
> So, I skimmed
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0249r0.pdf and
> saw plenty of references to QT and Boost signal/slot patterns.
I am more concerned with the content of this proposal than its naming,
because it does not appear to be well-researched.
The proposal attempts to address two topics:
1. Input device: Obtaining an input event (from keyboard, mouse, etc.)
2. Input dispatching: Allowing several input event listeners to be
added or removed dynamically.
Regarding the input device (section V.E), the proposal seems to be
unaware of the related work in the Networking TS proposal (N4575) which
is already far ahead in the standardization pipeline. The latter deals
with synchronous and asynchronous I/O, as well as timers.
P0249R0 does not specify which thread executes the input event
callback, or indeed if the callback is executed in a normal execution
context or some "signal" context (see C++ section [intro.execution]
paragraph 6.) In Networking TS this is well-defined.
If there are good reasons for having different I/O classes for network
and 2D, then I would expect that they integrate seamlessly.
Regarding the input dispatching (section V.A-D), the proposal does
refer to a couple of other signal programming designs (e.g. Qt and
Boost.Signals.) However, it does not discuss how it integrates with
other C++ proposals, such as future continuations, coroutines, or
pattern matching. Nor does it refer to newer developments such as the
non-intrusive idea of Boost.Synapse (not an official Boost library):
http://zajo.github.io/boost-synapse/
--
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/56F66885.9010006%40mail1.stofanet.dk.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 26 Mar 2016 07:04:15 -0700 (PDT)
Raw View
------=_Part_102_1867429649.1459001055471
Content-Type: multipart/alternative;
boundary="----=_Part_103_1541239214.1459001055471"
------=_Part_103_1541239214.1459001055471
Content-Type: text/plain; charset=UTF-8
On Saturday, March 26, 2016 at 6:46:36 AM UTC-4, Bjorn Reese wrote:
>
> Regarding the input dispatching (section V.A-D), the proposal does
> refer to a couple of other signal programming designs (e.g. Qt and
> Boost.Signals.) However, it does not discuss how it integrates with
> other C++ proposals, such as future continuations, coroutines, or
> pattern matching.
Should it? It was only recently that the writers of the Networking TS bothered
to come up with a way to make networking work with the P0057 coroutine
continuation system <http://wg21.link/P0286R0> (and to be honest, I think
the main point of that was to be yet another way for the author to show
disdain for P0057, by showing what you have to do in order to give those
coroutines the right amount of execution control). So it seems to me that
expecting such commentary from an initial proposal is an unnecessary
expectation that other proposals haven't had to make.
And there isn't even a formal proposal for "pattern matching", so it's
silly to say how any proposal could integrate with something that is little
more than a sketch at this point. Also, it's not clear why it would
integrate with pattern matching at all. Signals are point-to-point. You
fire a signal, X functions get called. I don't see where pattern matching
would be involved. At least with continuations, I could see someone wanting
to `co_await` on a signal, which could make your code more readable.
Nor does it refer to newer developments such as the
> non-intrusive idea of Boost.Synapse (not an official Boost library):
>
> http://zajo.github.io/boost-synapse/
.... so? The principle functional difference between Synapse and Signals 2
is that in Synapse, all signals are *global*, not local like in
Boost.Signals2. I have no idea why the designer touts that choice like it
were some kind of achievement, since it makes it impossible to use signals
locally. Well, not without defining a bunch of "typedef structs" (ugh)
locally to try to segregate your signals from everyone else's by return
type.
I see no reason to expect the maker of this proposal to sift through random
Github repos, just to talk about minor differences from what we already
have. Yes, we want proposals to be well researched, but there's a
difference between well researched and exhaustively researched.
--
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/3cda4813-0efe-4aad-bae1-0ff8912fb96f%40isocpp.org.
------=_Part_103_1541239214.1459001055471
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 26, 2016 at 6:46:36 AM UTC-4, Bjorn Ree=
se wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Regarding the input d=
ispatching (section V.A-D), the proposal does
<br>refer to a couple of other signal programming designs (e.g. Qt and
<br>Boost.Signals.) However, it does not discuss how it integrates with
<br>other C++ proposals, such as future continuations, coroutines, or
<br>pattern matching.</blockquote><div><br>Should it? It was only recently =
that the writers of the Networking TS <a href=3D"http://wg21.link/P0286R0">=
bothered to come up with a way to make networking work with the P0057 corou=
tine continuation system</a> (and to be honest, I think the main point of t=
hat was to be yet another way for the author to show disdain for P0057, by =
showing what you have to do in order to give those coroutines the right amo=
unt of execution control). So it seems to me that expecting such commentary=
from an initial proposal is an unnecessary expectation that other proposal=
s haven't had to make.<br><br>And there isn't even a formal proposa=
l for "pattern matching", so it's silly to say how any propos=
al could integrate with something that is little more than a sketch at this=
point. Also, it's not clear why it would integrate with pattern matchi=
ng at all. Signals are point-to-point. You fire a signal, X functions get c=
alled. I don't see where pattern matching would be involved. At least w=
ith continuations, I could see someone wanting to `co_await` on a signal, w=
hich could make your code more readable.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">Nor does it refer to newer developments such as the
<br>non-intrusive idea of Boost.Synapse (not an official Boost library):
<br>
<br>=C2=A0 =C2=A0<a href=3D"http://zajo.github.io/boost-synapse/" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fzajo.github.io%2Fboost-synapse%2F\46sa\75D\46sntz=
\0751\46usg\75AFQjCNER6dH-MOKO91ltJTEkE1dp1iJYng';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fzajo.github=
..io%2Fboost-synapse%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNER6dH-MOKO91ltJTE=
kE1dp1iJYng';return true;">http://zajo.github.io/boost-<wbr>synapse/</a=
></blockquote><div><br>... so? The principle functional difference between =
Synapse and Signals 2 is that in Synapse, all signals are *global*, not loc=
al like in Boost.Signals2. I have no idea why the designer touts that choic=
e like it were some kind of achievement, since it makes it impossible to us=
e signals locally. Well, not without defining a bunch of "typedef stru=
cts" (ugh) locally to try to segregate your signals from everyone else=
's by return type.<br><br>I see no reason to expect the maker of this p=
roposal to sift through random Github repos, just to talk about minor diffe=
rences from what we already have. Yes, we want proposals to be well researc=
hed, but there's a difference between well researched and exhaustively =
researched.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/3cda4813-0efe-4aad-bae1-0ff8912fb96f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3cda4813-0efe-4aad-bae1-0ff8912fb96f=
%40isocpp.org</a>.<br />
------=_Part_103_1541239214.1459001055471--
------=_Part_102_1867429649.1459001055471--
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Sat, 26 Mar 2016 16:53:46 +0100
Raw View
Nicol, I most likely am misinterpreting your reply as I am having
difficulty determining exactly what your point is. You omitted my main
concerns (about threading) and instead commented on the parts that I
regard as good advice (dispatching) for improving the proposal, so
it seems to boil down to different views about what good advice is in
this instance. I can live with that.
Let me instead ask, what is your opinion about P0249R0?
--
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/56F6B08A.6060203%40mail1.stofanet.dk.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 26 Mar 2016 10:03:14 -0700 (PDT)
Raw View
------=_Part_296_2143666427.1459011794720
Content-Type: multipart/alternative;
boundary="----=_Part_297_103891318.1459011794720"
------=_Part_297_103891318.1459011794720
Content-Type: text/plain; charset=UTF-8
On Saturday, March 26, 2016 at 11:53:52 AM UTC-4, Bjorn Reese wrote:
>
> Nicol, I most likely am misinterpreting your reply as I am having
> difficulty determining exactly what your point is. You omitted my main
> concerns (about threading)
That's because I agreed with it. Saying "Yes" wouldn't really add much to
the thread.
> Let me instead ask, what is your opinion about P0249R0?
>
My general opinion of it is "meh". It's not nearly as well founded or
designed as the 2D graphics proposal. It's a functional starting point, but
clearly it needs some more thought put into the details of it.
Really, I think it should be broken down into two separate proposals:
signaling of arbitrary events, and handling user input. The design of the
latter should make it easy to plug it into the former, but we should not
intertwine the former with the latter.
Threading behavior for firing signals should be trivial: it happens on the
thread that emitted the signal, exactly as if it had called each signal
handler individually. The larger question is what thread UI interrupts
happen on with non-polling UI APIs. That's something that needs to be
sorted out.
--
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/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%40isocpp.org.
------=_Part_297_103891318.1459011794720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 26, 2016 at 11:53:52 AM UTC-4, Bjorn Re=
ese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Nicol, I most likely=
am misinterpreting your reply as I am having
<br>difficulty determining exactly what your point is. You omitted my main
<br>concerns (about threading)</blockquote><div><br>That's because I ag=
reed with it. Saying "Yes" wouldn't really add much to the th=
read.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Let me in=
stead ask, what is your opinion about P0249R0?<br></blockquote><div><br>My =
general opinion of it is "meh". It's not nearly as well found=
ed or designed as the 2D graphics proposal. It's a functional starting =
point, but clearly it needs some more thought put into the details of it.<b=
r><br>Really, I think it should be broken down into two separate proposals:=
signaling of arbitrary events, and handling user input. The design of the =
latter should make it easy to plug it into the former, but we should not in=
tertwine the former with the latter.<br><br>Threading behavior for firing s=
ignals should be trivial: it happens on the thread that emitted the signal,=
exactly as if it had called each signal handler individually. The larger q=
uestion is what thread UI interrupts happen on with non-polling UI APIs. Th=
at's something that needs to be sorted out.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b=
%40isocpp.org</a>.<br />
------=_Part_297_103891318.1459011794720--
------=_Part_296_2143666427.1459011794720--
.
Author: Brett Searles <nwcpp.vp@gmail.com>
Date: Sun, 27 Mar 2016 12:27:22 -0700
Raw View
--e89a8f23457508914b052f0cc994
Content-Type: text/plain; charset=UTF-8
Nicol,
That is what will be done for Oulu is that this proposal will be broken
into 5 proposals.
1) Event handling
2) Interface between events and an UI
3) Portable Interrupts
4) Interface between events and interrupts
5) events that are handled outside UI
Thanks,
Brett
On Sat, Mar 26, 2016 at 10:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Saturday, March 26, 2016 at 11:53:52 AM UTC-4, Bjorn Reese wrote:
>>
>> Nicol, I most likely am misinterpreting your reply as I am having
>> difficulty determining exactly what your point is. You omitted my main
>> concerns (about threading)
>
>
> That's because I agreed with it. Saying "Yes" wouldn't really add much to
> the thread.
>
>
>> Let me instead ask, what is your opinion about P0249R0?
>>
>
> My general opinion of it is "meh". It's not nearly as well founded or
> designed as the 2D graphics proposal. It's a functional starting point, but
> clearly it needs some more thought put into the details of it.
>
> Really, I think it should be broken down into two separate proposals:
> signaling of arbitrary events, and handling user input. The design of the
> latter should make it easy to plug it into the former, but we should not
> intertwine the former with the latter.
>
> Threading behavior for firing signals should be trivial: it happens on the
> thread that emitted the signal, exactly as if it had called each signal
> handler individually. The larger question is what thread UI interrupts
> happen on with non-polling UI APIs. That's something that needs to be
> sorted out.
>
> --
> 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/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAN1bbVKRXE64pek9X1uzwhRnoBsB7wb56o%2Biz1bc3Qwsj9yMEw%40mail.gmail.com.
--e89a8f23457508914b052f0cc994
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Nicol,</div><div><br></div><div>That is what will be =
done for Oulu is that this proposal will be broken into 5 proposals.</div><=
div><br></div><div>1) Event handling</div><div>2) Interface between events =
and an UI</div><div>3) Portable Interrupts</div><div>4) Interface between e=
vents and interrupts</div><div>5) events that are handled outside UI</div><=
div><br></div><div>Thanks,</div><div><br></div><div>Brett</div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Mar 26, 2016 at=
10:03 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gm=
ail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Saturday, March 26, 2=
016 at 11:53:52 AM UTC-4, Bjorn Reese wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid">Nicol, I most =
likely am misinterpreting your reply as I am having
<br>difficulty determining exactly what your point is. You omitted my main
<br>concerns (about threading)</blockquote></span><div><br>That's becau=
se I agreed with it. Saying "Yes" wouldn't really add much to=
the thread.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">Let me instead ask, wh=
at is your opinion about P0249R0?<br></blockquote></span><div><br>My genera=
l opinion of it is "meh". It's not nearly as well founded or =
designed as the 2D graphics proposal. It's a functional starting point,=
but clearly it needs some more thought put into the details of it.<br><br>=
Really, I think it should be broken down into two separate proposals: signa=
ling of arbitrary events, and handling user input. The design of the latter=
should make it easy to plug it into the former, but we should not intertwi=
ne the former with the latter.<br><br>Threading behavior for firing signals=
should be trivial: it happens on the thread that emitted the signal, exact=
ly as if it had called each signal handler individually. The larger questio=
n is what thread UI interrupts happen on with non-polling UI APIs. That'=
;s something that needs to be sorted out.<br></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-=
4da9-ac8a-a306cbc4b19b%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAN1bbVKRXE64pek9X1uzwhRnoBsB7wb56o%2=
Biz1bc3Qwsj9yMEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN1bbVKRXE64pe=
k9X1uzwhRnoBsB7wb56o%2Biz1bc3Qwsj9yMEw%40mail.gmail.com</a>.<br />
--e89a8f23457508914b052f0cc994--
.
Author: Brett Searles <nwcpp.vp@gmail.com>
Date: Sun, 27 Mar 2016 12:32:49 -0700
Raw View
--001a11402a9e8f21b3052f0cdcea
Content-Type: text/plain; charset=UTF-8
Bjorn,
That is because QT and signals have a reference point for P0249, yet they
are incomplete in truly handling events based on input devices as discussed
in the proposal. Actually, the event handling is more designed around
jQuery and sequencing of events. Would love to discuss with you further.
Brett
On Sun, Mar 27, 2016 at 12:27 PM, Brett Searles <nwcpp.vp@gmail.com> wrote:
> Nicol,
>
> That is what will be done for Oulu is that this proposal will be broken
> into 5 proposals.
>
> 1) Event handling
> 2) Interface between events and an UI
> 3) Portable Interrupts
> 4) Interface between events and interrupts
> 5) events that are handled outside UI
>
> Thanks,
>
> Brett
>
> On Sat, Mar 26, 2016 at 10:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Saturday, March 26, 2016 at 11:53:52 AM UTC-4, Bjorn Reese wrote:
>>>
>>> Nicol, I most likely am misinterpreting your reply as I am having
>>> difficulty determining exactly what your point is. You omitted my main
>>> concerns (about threading)
>>
>>
>> That's because I agreed with it. Saying "Yes" wouldn't really add much to
>> the thread.
>>
>>
>>> Let me instead ask, what is your opinion about P0249R0?
>>>
>>
>> My general opinion of it is "meh". It's not nearly as well founded or
>> designed as the 2D graphics proposal. It's a functional starting point, but
>> clearly it needs some more thought put into the details of it.
>>
>> Really, I think it should be broken down into two separate proposals:
>> signaling of arbitrary events, and handling user input. The design of the
>> latter should make it easy to plug it into the former, but we should not
>> intertwine the former with the latter.
>>
>> Threading behavior for firing signals should be trivial: it happens on
>> the thread that emitted the signal, exactly as if it had called each signal
>> handler individually. The larger question is what thread UI interrupts
>> happen on with non-polling UI APIs. That's something that needs to be
>> sorted out.
>>
>> --
>> 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/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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/CAN1bbVLfqun8Ug1D5UJuxDQJ1T%3Dsq1eXV6JzONP%3D7My0s%3Dsa_A%40mail.gmail.com.
--001a11402a9e8f21b3052f0cdcea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Bjorn,</div><div><br></div><div>That is because QT an=
d signals have a reference point for P0249, yet they are incomplete in trul=
y handling events based on input devices as discussed in the proposal. Actu=
ally, the event handling is more designed around jQuery and sequencing of e=
vents. Would love to discuss with you further.</div><div><br></div><div>Bre=
tt</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Sun, Mar 27, 2016 at 12:27 PM, Brett Searles <span dir=3D"ltr"><<a href=
=3D"mailto:nwcpp.vp@gmail.com" target=3D"_blank">nwcpp.vp@gmail.com</a>>=
</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"><div>Nico=
l,</div><div><br></div><div>That is what will be done for Oulu is that this=
proposal will be broken into 5 proposals.</div><div><br></div><div>1) Even=
t handling</div><div>2) Interface between events and an UI</div><div>3) Por=
table Interrupts</div><div>4) Interface between events and interrupts</div>=
<div>5) events that are handled outside UI</div><div><br></div><div>Thanks,=
</div><div><br></div><div>Brett</div></div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, M=
ar 26, 2016 at 10:03 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailt=
o:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid"><div dir=3D"ltr"><span>On Saturday, March 26, 2=
016 at 11:53:52 AM UTC-4, Bjorn Reese wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid">Nicol, I most =
likely am misinterpreting your reply as I am having
<br>difficulty determining exactly what your point is. You omitted my main
<br>concerns (about threading)</blockquote></span><div><br>That's becau=
se I agreed with it. Saying "Yes" wouldn't really add much to=
the thread.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">Let me instead ask, wh=
at is your opinion about P0249R0?<br></blockquote></span><div><br>My genera=
l opinion of it is "meh". It's not nearly as well founded or =
designed as the 2D graphics proposal. It's a functional starting point,=
but clearly it needs some more thought put into the details of it.<br><br>=
Really, I think it should be broken down into two separate proposals: signa=
ling of arbitrary events, and handling user input. The design of the latter=
should make it easy to plug it into the former, but we should not intertwi=
ne the former with the latter.<br><br>Threading behavior for firing signals=
should be trivial: it happens on the thread that emitted the signal, exact=
ly as if it had called each signal handler individually. The larger questio=
n is what thread UI interrupts happen on with non-polling UI APIs. That'=
;s something that needs to be sorted out.<br></div></div><span>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-4da9-ac8a-a306cbc4b19b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0deb5fe-9fad-=
4da9-ac8a-a306cbc4b19b%40isocpp.org</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAN1bbVLfqun8Ug1D5UJuxDQJ1T%3Dsq1eXV6=
JzONP%3D7My0s%3Dsa_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN1bbVLfqu=
n8Ug1D5UJuxDQJ1T%3Dsq1eXV6JzONP%3D7My0s%3Dsa_A%40mail.gmail.com</a>.<br />
--001a11402a9e8f21b3052f0cdcea--
.
Author: Stephen Kelly <steveire@gmail.com>
Date: Sun, 27 Mar 2016 22:52:40 +0200
Raw View
Brett Searles wrote:
> Bjorn,
>
> That is because QT and signals have a reference point for P0249,
Hi Brett,
I've just had a quick look over P0249. Thanks for your work on this.
I have feedback for you to improve the accuracy of your paper and your
understanding of Qt.
The context of my feedback is that I have almost a decade of experience
using Qt and I found your paper confusing in how it references Qt, and in
claims of fact made about it.
1) QT is Apple QuickTime. Qt has a lowercase 't'.
2) You refer to Qt 4.8, but should instead refer to Qt 5. If there are any
differences, the Qt 5 semantics/behaviors represent an updated design.
3) Your paper contains the following text:
QT has a library that supports event handling with a base object, QEvent,
and have incorporated the Boost Library how to handle actions around
certain window features, like menus. [QT1]
As an english native speaker, I do not know what this text is attempting to
communicate. Grammatically it doesn't seem to mean anything.
The [QT1] reference simply refers to a Qt documentation page which makes no
reference to Boost.
As a matter of fact, no Qt version incorporates any Boost Library for
anything. For the avoidance of doubt, Qt doesn't use Boost to handle actions
around certain window features, like menus.
4) The paper contains the following text:
In order to create a custom event in QT, the developer needs to create
an object based on the parent event.
You probably mean 'create an object inheriting QEvent'. You have already
referred to QEvent, so it would be less confusing than 'based on the parent
event'. If 'based on the parent event' is not referring to inheritance of
QEvent, I suggest you use different wording to communicate what it really
means. Strive for accuracy and clarity.
5) The paper contains the following text:
QT has a virtual base class that registers event types defined either by
QT or a developer creating custom events. QT uses the Observer Pattern
where the QApplication object notifies any events in a collection
that are registered in the base class.[QT2]
At least part of this is redundant with content a few lines above.
Events are not 'registered with the base class'. I don't know what you are
referring to.
Again, your [QT2] reference seems to be a link to a docs page which is
unrelated 'registering in the base class' or any other claims of fact that
seem implicit in what you wrote. Or, maybe I misunderstand what you wrote
because it is not clear as written and you could consider rewriting it.
6) The paper contains the following text:
QT also offers an adaptation of the Boost Signal Library. The usage is
limited to a few objects, yet it does have that feature.
As a claim of fact, I have no idea what you are referring to. Qt does not
offer an 'adaption of the Boost Signal Library'.
Again, maybe what you want to say is actually something different, and you
should strive for more accuracy and clarity in what you write.
7) Qt signals and slots are very different to events
The reference to QSignalMapper doesn't seem to be relevant. Especially the
claim that it is a strange class because it invokes one slot is itself
strange - the class behaves exactly as designed. A different class can be
implemented to invoke multiple slots, but again that has nothing to do with
the event system.
In summary, for your next draft I suggest you get a thorough proof read from
someone who is a native speaker and who is familiar with Qt to help you
write accurately about it, remove things that are not relevant etc.
Thanks,
Steve.
--
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/56f8481d.918e1c0a.fe25d.ffffae81%40mx.google.com.
.