Hello,
Don't know if any of you tried to use long click event with pluggable button. At first it looks pretty easy, as: btn on: #mouseStillDown send: #hello to: self. does the job. The hell is comming because btn aspect is changed but it states is not changed. This is what I want but the aspect changed, but not the state, so it get unsynchronized. I cannot find how to get the btn back to its aspect reflected by its sate (#getModelState). I look at #update: but did not find. Of course it will be even better if its aspect is not changed when #mouseStillDown event is triggered, but only at mouseUp. Thanks Hilaire PS: - I found state to be misleading, should not it be selected? - Also the use of symbol to describe the morph is a hell - the morph extension add a layer of obscurity - update/change is catastrophic in term of readability to maintain large application Yes, I fell Morph does not scale when you get large application. At least I got lost in my own code only when dealing with this specific part. -- Dr. Geo -- http://www.drgeo.eu |
Responding to myself as it may be useful to other:
btn showSelectionFeedback: false. btn changed. but well. Hilaire Le 18/04/2012 11:32, Hilaire Fernandes a écrit : > Hello, > > Don't know if any of you tried to use long click event with pluggable > button. > > At first it looks pretty easy, as: > > btn on: #mouseStillDown send: #hello to: self. > > does the job. > > The hell is comming because btn aspect is changed but it states is not > changed. This is what I want but the aspect changed, but not the state, > so it get unsynchronized. > > I cannot find how to get the btn back to its aspect reflected by its > sate (#getModelState). I look at #update: but did not find. > > Of course it will be even better if its aspect is not changed when > #mouseStillDown event is triggered, but only at mouseUp. > > > Thanks > > Hilaire > > > PS: > - I found state to be misleading, should not it be selected? > - Also the use of symbol to describe the morph is a hell > - the morph extension add a layer of obscurity > - update/change is catastrophic in term of readability to maintain large > application > > Yes, I fell Morph does not scale when you get large application. At > least I got lost in my own code only when dealing with this specific part. > > -- Dr. Geo -- http://www.drgeo.eu |
In reply to this post by Hilaire Fernandes
Something for the next UI remake perhaps, with lessons learned.
Support for more "gestures" etc., long click being one... (am using a drag as a substitute for those myself, in the meantime...) Regards, Gary Sent from my iPad On 18 Apr 2012, at 10:32, Hilaire Fernandes <[hidden email]> wrote: > Hello, > > Don't know if any of you tried to use long click event with pluggable > button. > > At first it looks pretty easy, as: > > btn on: #mouseStillDown send: #hello to: self. > > does the job. > > The hell is comming because btn aspect is changed but it states is not > changed. This is what I want but the aspect changed, but not the state, > so it get unsynchronized. > > I cannot find how to get the btn back to its aspect reflected by its > sate (#getModelState). I look at #update: but did not find. > > Of course it will be even better if its aspect is not changed when > #mouseStillDown event is triggered, but only at mouseUp. > > > Thanks > > Hilaire > > > PS: > - I found state to be misleading, should not it be selected? > - Also the use of symbol to describe the morph is a hell > - the morph extension add a layer of obscurity > - update/change is catastrophic in term of readability to maintain large > application > > Yes, I fell Morph does not scale when you get large application. At > least I got lost in my own code only when dealing with this specific part. > > > -- > Dr. Geo -- http://www.drgeo.eu > > |
In reply to this post by Hilaire Fernandes
Hilaire
we should just continue and slowly but steadily fix and simplify. We have been doing it and we will continue. Now if you have concrete with examples suggestions please let us know. Stef > Responding to myself as it may be useful to other: > > > btn showSelectionFeedback: false. > btn changed. > > but well. > > Hilaire > > Le 18/04/2012 11:32, Hilaire Fernandes a écrit : >> Hello, >> >> Don't know if any of you tried to use long click event with pluggable >> button. >> >> At first it looks pretty easy, as: >> >> btn on: #mouseStillDown send: #hello to: self. >> >> does the job. >> >> The hell is comming because btn aspect is changed but it states is not >> changed. This is what I want but the aspect changed, but not the state, >> so it get unsynchronized. >> >> I cannot find how to get the btn back to its aspect reflected by its >> sate (#getModelState). I look at #update: but did not find. >> >> Of course it will be even better if its aspect is not changed when >> #mouseStillDown event is triggered, but only at mouseUp. >> >> >> Thanks >> >> Hilaire >> >> >> PS: >> - I found state to be misleading, should not it be selected? >> - Also the use of symbol to describe the morph is a hell >> - the morph extension add a layer of obscurity >> - update/change is catastrophic in term of readability to maintain large >> application >> >> Yes, I fell Morph does not scale when you get large application. At >> least I got lost in my own code only when dealing with this specific part. >> >> > > > -- > Dr. Geo -- http://www.drgeo.eu > > |
Interacting with tablets and touch is indeed a different experience (just inputting numbers properly is big - gestures would be great for example).
Longpress or double touch is also to be discussed. For editing a point, you'd be better off with two fingers or a double touch.
I am experimenting with this with my iPad app (not in Smalltalk but for the end user it is the same). Also, swiping gestures require some recording and effects over time.
Best is to have a low level thing that picks up the touch events and a set of event handlers that do get the notification when all the low level messy thinking is done. Otherwise the app code gets cluttered as hell. Well, that's my 0.02 EUR.
I am *very* interested in prototyping such things, beta testing and so on. Phil
2012/4/19 Stéphane Ducasse <[hidden email]> Hilaire Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog:
High Octane SPRL rue cour Boisacq 101 1301 Bierges |
In reply to this post by Stéphane Ducasse
Le 19/04/2012 20:04, Stéphane Ducasse a écrit :
> We have been doing it and we will continue. Now if you have concrete with examples suggestions > please let us know. It is not easy for me, it required long though on the matter. One think I really really don't like is the use of symbol, because I fell like lost, and no tool to discover what's going on. And symbol are largely used in the UI framework. May be it is not avoidable, don't really know. Hilaire -- Dr. Geo -- http://www.drgeo.eu |
In reply to this post by philippeback
In 2.0 we will integrate the event refactorings we did to start to be able to think about event dispatch.
Fernando built state machine on top of our enhanced events. Fernando state machine idea for handling events is probably the way to go. Stef On Apr 19, 2012, at 8:19 PM, [hidden email] wrote: > Interacting with tablets and touch is indeed a different experience (just inputting numbers properly is big - gestures would be great for example). > > Longpress or double touch is also to be discussed. For editing a point, you'd be better off with two fingers or a double touch. > > I am experimenting with this with my iPad app (not in Smalltalk but for the end user it is the same). > > Also, swiping gestures require some recording and effects over time. > > Best is to have a low level thing that picks up the touch events and a set of event handlers that do get the notification when all the low level messy thinking is done. Otherwise the app code gets cluttered as hell. Well, that's my 0.02 EUR. > > I am *very* interested in prototyping such things, beta testing and so on. > > Phil > > 2012/4/19 Stéphane Ducasse <[hidden email]> > Hilaire > > we should just continue and slowly but steadily fix and simplify. > We have been doing it and we will continue. Now if you have concrete with examples suggestions > please let us know. > > Stef > > > Responding to myself as it may be useful to other: > > > > > > btn showSelectionFeedback: false. > > btn changed. > > > > but well. > > > > Hilaire > > > > Le 18/04/2012 11:32, Hilaire Fernandes a écrit : > >> Hello, > >> > >> Don't know if any of you tried to use long click event with pluggable > >> button. > >> > >> At first it looks pretty easy, as: > >> > >> btn on: #mouseStillDown send: #hello to: self. > >> > >> does the job. > >> > >> The hell is comming because btn aspect is changed but it states is not > >> changed. This is what I want but the aspect changed, but not the state, > >> so it get unsynchronized. > >> > >> I cannot find how to get the btn back to its aspect reflected by its > >> sate (#getModelState). I look at #update: but did not find. > >> > >> Of course it will be even better if its aspect is not changed when > >> #mouseStillDown event is triggered, but only at mouseUp. > >> > >> > >> Thanks > >> > >> Hilaire > >> > >> > >> PS: > >> - I found state to be misleading, should not it be selected? > >> - Also the use of symbol to describe the morph is a hell > >> - the morph extension add a layer of obscurity > >> - update/change is catastrophic in term of readability to maintain large > >> application > >> > >> Yes, I fell Morph does not scale when you get large application. At > >> least I got lost in my own code only when dealing with this specific part. > >> > >> > > > > > > -- > > Dr. Geo -- http://www.drgeo.eu > > > > > > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > |
Free forum by Nabble | Edit this page |