Daniel <danielaparker@gmail.com>: May 30 06:56PM -0700
On Tuesday, May 30, 2017 at 5:35:43 PM UTC-4, Mr Flibble wrote:
> button is a rare use-case. I provide ready baked events for common
> use-cases whilst allowing the flexibility to create events for rare
> use-cases.
There is considerable a priori experience with event handlers. Typically
event handlers take an event source and an event object as parameters. A
clicked event object holds the state of the shift, alt and ctrl keys, the x
and y coordinates of the mouse pointer, which mouse button was clicked, etc.
My suggestion would be to follow that practice.
Does neoGFX support attaching multiple handlers for the same event on the
same widget?
Best regards,
Daniel
|
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 30 09:44PM -0500
> clicked event object holds the state of the shift, alt and ctrl keys, the x
> and y coordinates of the mouse pointer, which mouse button was clicked, etc.
> My suggestion would be to follow that practice.
As I said in my reply this information is available.
> Does neoGFX support attaching multiple handlers for the same event on the
> same widget?
Yes. Note this is not a mouse button clicked event I am talking about but a
button widget "clicked" event which is also triggered by pressing space bar
if widget has focus.
/Flibble
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 30 08:26PM -0700
On Tuesday, May 30, 2017 at 5:35:43 PM UTC-4, Mr Flibble wrote:
> > modification keys like shift, alt, ctrl? Do you have thread-
> > level callbacks which support real-time sampling of those values?
> Such information is available allowing such events to be easily created.
I would think it would be the norm. One API with the extraneous info
being ignored if not used, rather than two or more APIs, one for the
"simple stuff" and one for the "regular stuff."
I'm not being picky or purposefully mean to you, Leigh. I honestly
do not see the advantage.
> button is a rare use-case. I provide ready baked events for common
> use-cases whilst allowing the flexibility to create events for rare
> use-cases.
That's not true. It is in many use cases, but in those use cases
where right-clicking is common / standard, it's not at all true.
You're creating a true graphical UI. You have to expect people
will be coding for right-clicks on most everything, so as to
access settings about things they're clicking on, rather than a
type of normal navigation or selection.
> > algorithm after many seconds have gone by?
> Then you are doing it wrong. A library doesn't have to support doing it
> wrong use cases.
Well, I don't generally code like that. Sometimes you have to
because you receive OS callbacks without that information, but I
mention it here because I didn't see any parameters being passed
to your simplicity version above, hence the need for such functions
in such a case.
I think if you want simplicity, you should just receive a struct
or class that has defined callback functions, and then use those
if they're not NULL. Something simple:
struct SEvents {
bool (*onLeftClick)(SObject* state);
bool (*onRightClick)(SObject* state);
// ... and other such stuff
};
I think neoGrx could prepare a snapshot data object, or pass several
parameters, and have everything setup for the instance handoff, which
may then be propagated through for a while before control returns
from the dispatcher. In fact, you could even setup a dispatcher
which launches each event in its own thread as a nice service that
would prevent the user from having to write that code.
> You appear to have a beef with C++ lambdas which is foolish as they are
> a great improvement to the language. You are not forced to use a lambda
> as you can use use anything convertible to a std::function object.
I do have a beef with lambdas. I've created an alternative which
better documents what's taking place by giving it a name, and allowing
it to be moved away from the syntax of the instruction in use.
I call it an adhoc, which is arbitrary code created at any point, and
it is not normally entered through normal flow, but only when explicitly
called by name or by address:
Search for "adhoc" on this message:
https://groups.google.com/d/msg/caliveprogramminglanguage/pSV7rzGcIeE/Ix3pBmhsBgAJ
Its syntax is basically like a type of local function, but by
creating it as a adhoc, it is documented in code for its explicit
use case:
int main(int argc, char* argv[])
{
// Create a function to reference which is related to this
// code immediately nearby.
adhoc int my_adhoc(int a, int b) {
return(a + b + 9);
}
cout << "5,6 equals " << my_adhoc(5, 6);
return 0;
}
CAlive also allows alternate syntax to create the same thing,
which can appear to be more similar to lambdas, and can be
encoded where lambdas are.
> > function and the development environment, then such simplicity
> > is akin to useless.
> It is both simple and provides utility.
As Einstein once said: "Things should be as simple as possible,
but no simpler." I think you've tried to make things simple, but
you're missed out on the fact that more is required for normal
events processing than your simple model, meaning the model is
now doubly complex because you have simple things and normal
things. I think it will be more confusing to users.
Thank you,
Rick C. Hodgin
|
Juha Nieminen <nospam@thanks.invalid>: May 31 06:13AM
> bool (*onRightClick)(SObject* state);
> // ... and other such stuff
> };
That's the C kludge that tries to emulate interfaces, ie. a base class
with virtual functions.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 03:11AM -0700
Juha Nieminen wrote:
> That's the C kludge that tries to emulate interfaces, ie. a base
> class with virtual functions.
It can be coded however you like. That was just an example. But I
would argue such an implementation is simple and easy to understand.
Thank you,
Rick C. Hodgin
|
Daniel <danielaparker@gmail.com>: May 31 04:23AM -0700
On Tuesday, May 30, 2017 at 10:44:31 PM UTC-4, Mr Flibble wrote:
> > and y coordinates of the mouse pointer, which mouse button was clicked, etc.
> > My suggestion would be to follow that practice.
> As I said in my reply this information is available.
Could you show an example that illustrates how a handler could save the
x and y screen coordinates when the right mouse button is pressed in
combination with the shift key being pressed?
Thanks,
Daniel
|
David Brown <david.brown@hesbynett.no>: May 31 02:05PM +0200
On 31/05/17 05:26, Rick C. Hodgin wrote:
> I would think it would be the norm. One API with the extraneous info
> being ignored if not used, rather than two or more APIs, one for the
> "simple stuff" and one for the "regular stuff."
My understanding is that the "clicked" event is a button or widget
clicked event, not a /mouse/ click event. I don't know anything about
neoGFX, but it is quite common for widget libraries to have a simple
"clicked" event that is triggered by a left mouse click, or a keyboard
press when the widget has the focus. That would different from a more
detailed "mouse" event that would say which mouse button is used,
modifier keys, exact position, etc. And there may be other related
events suchas "right_clicked".
It would be nice to see an example of the neoGFX syntax for how the
details are captured for events that have information such as more
general mouse click events.
> mention it here because I didn't see any parameters being passed
> to your simplicity version above, hence the need for such functions
> in such a case.
Even if there is no information sent in parameters (we need to wait for
Leigh to give more details here for events that have parameters), the
way you would deal with a long-running event function is to first
capture the important information, then to pass it on to an asynchronous
function (perhaps in another thread) that handles the waiting and other
time-consuming work. You don't put a 5 second delay in your event handler.
> CAlive also allows alternate syntax to create the same thing,
> which can appear to be more similar to lambdas, and can be
> encoded where lambdas are.
You can do /exactly/ the same thing with lambdas, bar minor syntactic
details:
#include <iostream>
using std::cout;
int main(void) {
auto my_adhoc = [](int a, int b) -> int {
return a + b + 9;
};
cout << "5, 6 equals " << my_adhoc(5, 6) << "\n";
}
Lambdas can be defined in all sorts of places, and named if you want to.
Does that cover your "beef" against lambdas?
(And as Leigh says, there is no requirement to use lambdas for events -
you can use normal functions, functor objects, or anything else that is
callable.)
> events processing than your simple model, meaning the model is
> now doubly complex because you have simple things and normal
> things. I think it will be more confusing to users.
I think it is just a case of Leigh picking an example event that is so
simple that it has no need of parameters.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:05AM -0700
On Wednesday, May 31, 2017 at 8:05:50 AM UTC-4, David Brown wrote:
> [snip]
I appreciate your desire to help me to be a better person, David.
I also continue to pray for you as well.
Thank you,
Rick C. Hodgin
|
David Brown <david.brown@hesbynett.no>: May 31 03:10PM +0200
On 31/05/17 15:05, Rick C. Hodgin wrote:
>> [snip]
> I appreciate your desire to help me to be a better person, David.
> I also continue to pray for you as well.
I am not trying to make you a better person - I am trying to discuss C++
and a C++ library in a C++ thread on a C++ forum.
You have previously decided not to discuss off-topic issues with me.
Fair enough - I have not always been polite or patient with you. And I
am happy not to engage in discussions that are usually extremely
frustrating for me, and make no visible progress.
But surely we can talk about C++ (and other technical topics in other
groups)? I am not trying to help you be a "better person" - I am trying
to tell you a little more about lambdas that you might not have known,
and learn more about why you don't like them.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:19AM -0700
On Wednesday, May 31, 2017 at 9:10:46 AM UTC-4, David Brown wrote:
> [snip]
I appreciate your desire to help me to be a better person, David,
by giving me guidance in these areas where you feel I am lacking.
I also desire to help you to be a better person, so I continue to
pray for you as well.
Thank you,
Rick C. Hodgin
|
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 31 03:21PM +0200
On 31-May-17 3:19 PM, Rick C. Hodgin wrote:
> by giving me guidance in these areas where you feel I am lacking.
> I also desire to help you to be a better person, so I continue to
> pray for you as well.
The time has come to put you in my kill-file, Rick.
Or, what passes for a kill-file in Thunderbird, but same effect.
Plonk.
Sorry 'bout that,
- Alf
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:36AM -0700
On Wednesday, May 31, 2017 at 9:21:42 AM UTC-4, Alf P. Steinbach wrote:
> The time has come to put you in my kill-file, Rick.
> Sorry 'bout that,
I would like to ask you to consider something, Alf, or to the
other people reading this, when you add someone advocating a life
lived in service to Jesus Christ (and separate yourself from the
lived follow-through of that life's profession in reality, such
as by an outward example of simply praying for people), consider
that by separating yourself from that God-seeking person you are
separating yourself from a person focused on serving the Lord in
real ways rightly here upon this Earth.
Consider also that in so doing, you are also separating yourself
from the Lord because He sends men and women like me out into the
world to help encourage and guide people away from where they are
and toward where they should be.
So in essence, when you "kill-file" me, you are really doing much,
much more. You are effectively cutting yourself off from a voice
of the Lord in your life, which means you're embracing another's
guidance, the one bent on killing your eternal soul in Hell as you
choose a path away from God, and toward that other calling.
Consider what this means to you beyond the confines of this world.
Thank you,
Rick C. Hodgin
|
Mr Flibble <flibble@i42.co.uk>: May 31 06:43PM +0100
On 31/05/2017 04:26, Rick C. Hodgin wrote:
> "simple stuff" and one for the "regular stuff."
> I'm not being picky or purposefully mean to you, Leigh. I honestly
> do not see the advantage
Grow up.
>> use-cases.
> That's not true. It is in many use cases, but in those use cases
> where right-clicking is common / standard, it's not at all true.
It is true. This is an event sent from a button widget: you don't
normally right click on button widgets.
/Leigh
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 10:59AM -0700
On Wednesday, May 31, 2017 at 1:43:37 PM UTC-4, Mr Flibble wrote:
> > I'm not being picky or purposefully mean to you, Leigh. I honestly
> > do not see the advantage
> Grow up.
It's a proper statement ... even for a grow-up. I included it at
all because I thought you might feel I was trying to be picky for
some petty reasons because of our post-relationship on issues of
Jesus Christ. That's not the case. I did not see the advantage
of having that feature when most of the time I would think you
would want additional information for the click event.
> > where right-clicking is common / standard, it's not at all true.
> It is true. This is an event sent from a button widget: you don't
> normally right click on button widgets.
I don't know what you're referring to, but I have defined a full
event stack on my objects, which are largely based upon a tool that
I use daily which has similar events:
It's "SBaseEventsMap" on line 1623, and then 1656:
http://tinyurl.com/accessors-h
Each callback receives a passed object which has property members
with the items required for whatever the event is:
union {
uptr _defaultHandler;
bool (*defaultHandler) (SObject* obj, u32 tnIndex);
};
They are referenced in code by an id which finds them by name.
It is slower than doing it a direct way, but it allows full and
custom expansion of add-on properties, events, methods, and other
objects at runtime.
Thank you,
Rick C. Hodgin
|
Mr Flibble <flibble@i42.co.uk>: May 31 07:14PM +0100
On 31/05/2017 13:05, David Brown wrote:
> It would be nice to see an example of the neoGFX syntax for how the
> details are captured for events that have information such as more
> general mouse click events.
The idea is that a widget of a specific type will translate a generic
mouse clicked event (which comes from the native window/surface and
contains all the meta information asked about here) and translates it
into an event that fits in with the widget's abstraction. It is not
useful (in general), for example, for a push button widget to emit right
mouse click events or to know the x,y position of a left click event on
the push button widget.
If you want to emit event meta information from a custom widget type
then simply override thus:
class my_xy_widget : public neogfx::widget
{
public:
event<const point&> xy;
event<const point&> xy_context;
public:
void mouse_button_pressed(mouse_button aButton, const point& aPosition,
key_modifiers_e aKeyModifiers) override
{
if (aButton == mouse_button::Left)
xy.trigger(aPosition);
else if (aButton == mouse_button::Right)
xy_context.trigger(aPosition);
}
}
I only include events in the API that make sense for the specific widget
abstractions.
It is also possible to be notified of all events coming from
window/surface (with access to all meta information) and there is
provision for filtering those events.
>> things. I think it will be more confusing to users.
> I think it is just a case of Leigh picking an example event that is so
> simple that it has no need of parameters.
Correct. :)
/Flibble
|
Mr Flibble <flibble@i42.co.uk>: May 31 07:18PM +0100
On 31/05/2017 04:26, Rick C. Hodgin wrote:
> CAlive also allows alternate syntax to create the same thing,
> which can appear to be more similar to lambdas, and can be
> encoded where lambdas are.
The problem isn't that neoGFX supports lambdas the problem is that you
don't like lambdas which is your problem not mine or that of anyone who
wants to use lambdas with neoGFX.
You obviously are having a problem embracing modern C++ techniques
because you like to cling on to the old fashioned paradigms.
/Flibble
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 11:55AM -0700
On Wednesday, May 31, 2017 at 2:18:19 PM UTC-4, Mr Flibble wrote:
> The problem isn't that neoGFX supports lambdas the problem is that you
> don't like lambdas which is your problem not mine or that of anyone who
> wants to use lambdas with neoGFX.
I don't like lambdas. I do like lambs, however. They're useful.
> You obviously are having a problem embracing modern C++ techniques
> because you like to cling on to the old fashioned paradigms.
It's not a problem so much as a choice. But, to be fair, I have
embraced many C++ programming techniques, and I'm adding them to
CAlive. I've also come up with several more of my own which I
think C and C++ will eventually adopt.
Thank you,
Rick C. Hodgin
|
scott@slp53.sl.home (Scott Lurndal): May 31 06:57PM
>I don't like lambdas. I do like lambs, however. They're useful.
:%s/useful/tasty/g
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 12:05PM -0700
On Wednesday, May 31, 2017 at 2:57:36 PM UTC-4, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >I don't like lambdas. I do like lambs, however. They're useful.
> :%s/useful/tasty/g
:-)
Thank you,
Rick C. Hodgin
|
Daniel <danielaparker@gmail.com>: May 31 01:16PM -0700
On Wednesday, May 31, 2017 at 2:14:35 PM UTC-4, Mr Flibble wrote:
> useful (in general), for example, for a push button widget to emit right
> mouse click events or to know the x,y position of a left click event on
> the push button widget.
The x,y position of a left or right click event are properties of an
event, not a widget. All other GUI frameworks that I know of (including
pyqt, wxpython, .NET) associate an event object type with each enumerated
event, and pass an instance of that type to the handler.
For example, in wxpython, a handler would be bound to an event on the
widget,
widget.Bind(wx.EVT_MOVE, OnMove)
def OnMove(self, e):
x, y = e.GetPosition()
print "current window position x = ",x," y= ",y
|
Mr Flibble <flibble@i42.co.uk>: May 31 10:25PM +0100
On 31/05/2017 21:16, Daniel wrote:
> event, not a widget. All other GUI frameworks that I know of (including
> pyqt, wxpython, .NET) associate an event object type with each enumerated
> event, and pass an instance of that type to the handler.
Correct the x,y position is a property of an event and this is the case
in neoGFX; it is up to the widget in question how this event is
translated into a widget specific event.
> def OnMove(self, e):
> x, y = e.GetPosition()
> print "current window position x = ",x," y= ",y
That is not how neoGFX works however it is possible to get access to the
base event if required.
/Flibble
|
