[Pharo-dev] Keyboard events is broken.

Guillermo Polito guillermopolito at gmail.com
Tue Aug 6 15:51:34 EDT 2013


On Tue, Aug 6, 2013 at 9:33 PM, Stéphane Ducasse
<stephane.ducasse at inria.fr>wrote:

> I imagine that having a branch is the way to go.
>

To me, a branch is a fork in the code. That is, you split and they evolve
differently. If you want to tag a version as stable, you use a tag :). And
git already supports all that. But we don't use it ;).

However, branches make sense to me if we have for example

- vm for pharo2
- vm for pharo3
- vm ....

With that setup, in the pharo2 branch we can backport fixes from the pharo3
branch, but they may evolve differently.
And more importantly, we do not need to maintain all the compatibility with
the world. Whoever wants a pharo2 vm, they go to the pharo2 branch, which
on release is freezed (as well as the image).

Now, in Git, I do not think there is a need for having many repositories
for that. It's enough with branches and tags...


> Like that esteban can integrate the fixes of eliot and you do not stress
> to finish.
>

Yes, but esteban has already lots of things to do :). And every time I made
a pull request, a had to push it myself into the main branch because if
not, nobody did it. And ask Camillo, he was in the same situation... In the
image side we have Stef, Marcus and Esteban that integrate fixes. In the vm
side it's only Esteban :/.

Once this is ready there is a merge.
>

But that's what happen today, only the naming is bad in the git branch :).

- We have a stable VM, which you can download as stable. That VM does not
have the latest changes. I do not know if there is a tag, but there should
be.
- We have a unstable VM, which we call latest. It has the latest sources
which we should test and prove before "blessing" it as the stable.


>
> At least this is what I was thinking the process was:
> one main blessed stream
>
several others at different level of maturity with the ultimate goal to
> avoid bottleneck.
>

Yes, but with that we lack also a good management of the issue tracking and
stuff :). Above in this thread I was asking where do I submit an issue.
Maybe we should put everything in the pharo issue tracker and be happy with
only one tool.

BTW, tomorrow I go to lille, we can discuss if you have some minutes :).


> Stef
>
>
> On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>> On 6 August 2013 17:47, Guillermo Polito <guillermopolito at gmail.com>
>> wrote:
>> > ah, forgot to say. Latest vms from jenkins should be ready in a while,
>> not
>> > yet :).
>> >
>> yes, and that's why i want you to answer a following question:
>>  why you think the repository was named 'blessed' as in [1]?
>>
>
> I don't know... That some saint has come and blessed it? :)
> If not, point me to where it is explained, is there a wiki page or
> something?
>
> Igor, I do not know how to read that question. Now, really:
>
> - I thought that moving the VM repository to gitorious was meant to open
> it. If only a couple of people (lets say you, Camilo and Esteban) have the
> rights to commit, then I feel it defeats the purpose
>
> - Maybe I should make a pull-request, but you can see that there are three
> there, one for at least one year, waiting for integration and probably out
> of date [1]
>
> - to me one benefit of using a CVS is that it gives you the ability to
> revert and going back in the history, and there are not much commits in cog
> to traverse... So, if it is really broken we go back and there are no
> problems. Should I be afraid of committing something?
>
> - As Stef says, you only can break if you do...
>
> - Now, maybe I should continue not trying to fix some stuff in the vm if
> people get pissed off when using latest and a bug is found
>
> [1] https://gitorious.org/cogvm/blessed/merge_requests
>
>
>> [1] https://gitorious.org/cogvm/blessed/
>>
>> >
>> > On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <
>> guillermopolito at gmail.com>
>> > wrote:
>> >>
>> >>
>> >> On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse
>> >> <stephane.ducasse at inria.fr> wrote:
>> >>>
>> >>> thanks guillermo :)
>> >>> Cleaning events at VM level is important.
>> >>
>> >>
>> >> Cleaning is not sooooo easy :).
>> >>
>> >> I've been able to reproduce some of these problems (the delete key and
>> the
>> >> double keyUp:). I've tried to fix them, bah, actually I did in here,
>> but I'd
>> >> like someone else tests in their keyboard layouts in their homes :).
>> >>
>> >> Regarding the difference of the keyValues between keyUp and keyDown, I
>> did
>> >> not address it, and it kinda orthogonal, nothing to do with this
>> particular
>> >> issue.
>> >>
>> >> To see my changes, people can have a look at the diff in here:
>> >>
>> >>
>> >>
>> https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553b1b11c2/diffs/9e2a77928edf0144f0d5c42ada66eb18918af64b
>> >>
>> >> I'd like to start putting this in some issue tracker. Cog issue
>> tracker or
>> >> Pharo one? :) Esteban?
>> >>
>> >>>
>> >>> On Aug 6, 2013, at 4:32 PM, Guillermo Polito <
>> guillermopolito at gmail.com>
>> >>> wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua at gmail.com>
>> wrote:
>> >>>>
>> >>>> I changed this method to see better what happens:
>> >>>> HandMorph class>>showDebugEvent: evt
>> >>>>
>> >>>>         ShowEvents == true ifTrue: [
>> >>>>                 | ofs|
>> >>>>                 Display fill: (0 at 0 extent: 500 at 120) rule: Form over
>> >>>> fillColor: Color white.
>> >>>>                 ofs := (owner hands indexOf: self) - 1 * 60.
>> >>>>                 evt printString displayAt: (0 at ofs) + (evt isKeyboard
>> >>>> ifTrue: [0 at 30]
>> >>>> ifFalse: [0 at 0]).
>> >>>>                 self keyboardFocus printString displayAt:
>> >>>> (0 at ofs)+(0 at 45).
>> >>>>
>> >>>>                 evt isKeyboard ifTrue: [  Transcript show: evt
>> >>>> printString;cr ]
>> >>>>                 ].
>> >>>>
>> >>>>
>> >>>> KeyboardEvent>> printOn: aStream
>> >>>>         "Print the receiver on a stream"
>> >>>>
>> >>>>         aStream nextPut: $[.
>> >>>>         aStream nextPutAll: type; nextPutAll: ' '''.
>> >>>>         self printKeyStringOn: aStream.
>> >>>>         aStream nextPut: $'.
>> >>>>
>> >>>>         aStream space; nextPutAll: 'keyValue: ', self keyValue
>> >>>> asString.
>> >>>>
>> >>>>         aStream nextPut: $]
>> >>>>
>> >>>> set
>> >>>> HandMorph showEvents:true
>> >>>>
>> >>>> Now, pressing single space, gives me this:
>> >>>>
>> >>>> [keyDown ' ' keyValue: 49]
>> >>>> [keystroke ' ' keyValue: 32]
>> >>>> [keyUp ' ' keyValue: 49]
>> >>>> [keyUp ' ' keyValue: 49]
>> >>>>
>> >>>> Pressing delete key (or fn-backspace , for those who having a lot of
>> >>>> spare fingers to use bad keyboards):
>> >>>>
>> >>>> [keyDown ' ' keyValue: 117]
>> >>>> [keystroke '⌦' keyValue: 188]
>> >>>> [keyUp ' ' keyValue: 117]
>> >>>> [keyUp ' ' keyValue: 117]
>> >>>>
>> >>>> now, can someone tell me , why there is 2 keyUp events for each
>> keyDown?
>> >>>
>> >>>
>> >>> That I don't know
>> >>>
>> >>>>
>> >>>>
>> >>>> and of course, main question is why key values are different for
>> >>>> keydown and keystroke events?
>> >>>
>> >>>
>> >>> That I'll dive right now into the vm to see what it is :).
>> >>>
>> >>>>
>> >>>> (and why delete key is not 127, but 117 or 188?)
>> >>>>
>> >>>> Editor expecting 127:
>> >>>>
>> >>>>         cmdMap at: (127 + 1) put: #forwardDelete:.              "del
>> >>>> key"
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Best regards,
>> >>>> Igor Stasenko.
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130806/be281940/attachment-0002.html>


More information about the Pharo-dev mailing list