- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to dispatch mouseWheel?

by Gary Chambers

Hi, Ideally we need to change EventHandler to support mouseWheel events and at the same time, perhaps, integrate EventHandlerPlus upwards too. Otherwise, you will need to do as you suggested, make a Morph subclass to handle stuff and use that as the in-betweener. Regards, Gary ----- Original Message ----- From: "Martin Drautzburg" <Martin.Drautzburg(a)web.de> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, May 05, 2012 7:49 PM Subject: Re: [Pharo-project] How to dispatch mouseWheel? > On Saturday, 5. May 2012 19:06:38 Martin Drautzburg wrote: > Sorry, that was a bit fuzzy. > > My Morph is in a GeneralScrollPane. The GeneralScrollPane first sends > mouseWheel event to the scroller (my Morph). My Morph can scroll > horizonally > infinitely and handles the horizontal scrolling itself. Its mouseWheel > method > makes sure this only happens when the mouse is over it. Otherwise the > event > remains unhandled and the GeneralScrollPane handles it and scrolls > vertically. > > Now I have another Morph (really just a plain Morph) in betwen. The > scroller > again sends it a mouseWheel, but its just a plain Morph and it does not > handle > it. The effect is that scrolling is always controlled by the scroll pane > (i.e. > vertically). I cannot seem to tell the scroll pane: don't ask your > scroller, > ask my Morph, nor can I tell this plain Morph: when someone asks you to > handle > a mouseWheel, don't just say no, ask my Morph instead. > > Of course I can just create another Morph Class which passes all events to > its > owner. Is there anything more elegant? > > -- > Martin >

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Norbert Hartl

Am 08.05.2012 um 16:20 schrieb Sven Van Caekenberghe: > <rant>Notice how f*cked up TextConverters are: when given a binary stream, their natural input one would think, they just don't do any conversion!</rant> Isn't that obvious? In a time where there was text or binary and your biggest problem was line ending conversion it is normal to do not any processing on a binary stream. It is its definition. The world has changed since then and since we have encodings there is no such thing as a text/ascii stream anymore. I think we have to slowly convert those things to modern stuff. How hard that is? Look at Grease it is a piece of modern software but still encodes string -> string. There are always caveats not to ignore. Norbert

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Sven Van Caekenberghe

Here is an example with the file out of the equation: | stream | stream := (ByteArray readHexFrom: '5465696c72fc636b7a61686c756e67') asString readStream. stream next: 5. (ISO885915TextConverter new nextFromStream: stream) codePoint. => 71303420 | stream | stream := (ByteArray readHexFrom: '5465696c72fc636b7a61686c756e67') readStream. stream next: 5. ((ZnCharacterEncoder newForEncoding: 'iso-8859-15') nextFromStream: stream) codePoint. => 252 <rant>Notice how f*cked up TextConverters are: when given a binary stream, their natural input one would think, they just don't do any conversion!</rant> On 08 May 2012, at 15:30, Norbert Hartl wrote: > Can you paste the code you used to come to this result? > > Norbert > > Am 08.05.2012 um 14:46 schrieb Torsten Bergmann: > >> Sven wrote >>> On my Mac I get: >>> ... >>> (stream contents at: 6) codePoint 71303420 >>> ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 >> >> Hi Sven, >> >> on Windows I get: >> >> (stream contents at: 6) codePoint 252 >> ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 >> >> For >> >> $Ã¼ codePoint I also get 252 >> >> So on Windows (at least for my test) it does >> not have the "leadingChar". >> >> Bye >> T. >> >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> > >

May 8, 2012

Re: [Pharo-project] Running in background with OSProcess

by Sean P. DeNigris

David T. Lewis wrote > > I'm afraid that the simulation of unix shell behavior is far from perfect > ... > BTW, I would welcome patches to improve things like this, as long as > they are supported with unit tests. > I'd def be willing to take a look... But, for my current pressing problem, I'm looking for the opposite from OSP. Instead of being able to pass any valid Bash syntax and have OSP parse it, I'm willing to restrict myself as long as I can do the parse myself. I don't want globbing or any other fancy processing. I will do all that myself before hand and only be supplying absolute paths. How do I circumvent all the processing and tell OSP what args to actually pass to the underlying system? Thanks for all the help! Sean -- View this message in context: http://forum.world.st/Running-in-background-with-OSProcess-tp4615534p461759… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Norbert Hartl

Am 08.05.2012 um 15:37 schrieb Henrik Sperre Johansen: > TLDR of non-bug related stuff; If it were up to me, I'd say nuke leadingChar from orbit (which, as you say, is already done in most cases), > then find some other way than what is currently done in LanguageEnvironment (if possible) to query the correct encoding of strings you pass to the system. + any number you can imagine It is easy to state that it is broken now and leadingChar causes harm. So nuking it will probably just inverse the problem situation but then it can be cured somehow by fixing the bugs. Handling the characters right in encoding is only one side of the medal. Characters and strings are still need to be comparable. To get this right it would mean to have support ICU [1] in pharo which is a good idea anyway. Well, if it is doable in a pluggable fashion of course. Norbert [1] http://site.icu-project.org/

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Sean P. DeNigris

Mariano Martinez Peck wrote > > No, the directory is actually /Users/mariano/.config/pharo/general > It seems in linux they are stored that way so to avoid lots of .xxx in the > $HOME. So you use one directory for all your conf ;) > Oh, I see, thanks. I was thinking like ~/.jenkins, but I checked Ubuntu and OS X and it looks like ~/.config is a well-known convention. Sean -- View this message in context: http://forum.world.st/Improved-version-of-StartupPreferences-tp4615713p4617… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 8, 2012

[Pharo-project] [update 2.0] #20060

by Esteban Lorenzano

20060 ----- Issue 5846: register correct message browser http://code.google.com/p/pharo/issues/detail?id=5846 Issue 5845: MCRepositoryGroup>>removeHTTPRepositoryLocationNamed: bad category http://code.google.com/p/pharo/issues/detail?id=5845

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Henrik Sperre Johansen

On 08.05.2012 14:00, Nicolas Cellier wrote: > leadingChar was here merely for handling Han unification > http://en.wikipedia.org/wiki/Han_unification. > As I understand it, the language variant is encoded in leadingChar, > while the generic ideogram is encoded in the unicode value. From what I can tell, it (based on the indexes) initially also allowed for non-unicode WideStrings (see Character asUnicode, and it's use of EncodedCharSet). That was probably a bad idea in the first place since there is no 16-bit string type in Pharo, I guess adding that would be the original thought behind it... Later on it was changed to do Han unification, but: - The code for selecting/displaying font based on leadingChar is a mess, never tested, and no compatible font come installed in Pharo by default. - There is no code to, say, automatically add leadingChars based on current environment to character events, so even if it works, input might still display incorrectly. - Using it in Translation support requires storing in a special format which includes the leading characters. - The LanguageEnvironments that currently deal with this also have other roles, which is purely empirical and, in some cases, outdated (I'm looking at you, defaultSystemConverter) > We tried to clean a lot already and avoid using leadingChar, except > maybe for east-asian languages, so in case of umlaut, I would classify > this as a bug. > > Nicolas Yeah, that's clearly something gone entirely wrong when the translation table was initialized. 17 has never been a valid leadingChar. FWIW, it was reinitialized and works as expected in 1.4. TLDR of non-bug related stuff; If it were up to me, I'd say nuke leadingChar from orbit (which, as you say, is already done in most cases), then find some other way than what is currently done in LanguageEnvironment (if possible) to query the correct encoding of strings you pass to the system. Cheers, Henry

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Norbert Hartl

Can you paste the code you used to come to this result? Norbert Am 08.05.2012 um 14:46 schrieb Torsten Bergmann: > Sven wrote >> On my Mac I get: >> ... >> (stream contents at: 6) codePoint 71303420 >> ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 > > Hi Sven, > > on Windows I get: > > (stream contents at: 6) codePoint 252 > ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 > > For > > $Ã¼ codePoint I also get 252 > > So on Windows (at least for my test) it does > not have the "leadingChar". > > Bye > T. > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Mariano Martinez Peck

On Tue, May 8, 2012 at 3:03 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > /Users/mariano/.config/pharo/general you have a script that does: > > > > Should be "/Users/mariano/.pharo/config/general", no? > No, the directory is actually /Users/mariano/.config/pharo/general Of course it can be changed if that's what people want. I have no idea, StartupPreference was like this before I touch it ;) It seems in linux they are stored that way so to avoid lots of .xxx in the $HOME. So you use one directory for all your conf ;) (thanks Pavel) Cheers > > -- > View this message in context: > http://forum.world.st/Improved-version-of-StartupPreferences-tp4615713p4617… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 8, 2012