August 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] this is a test

by StÃ©phane Ducasse

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Camillo Bruni

On 2012-08-23, at 15:05, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 23.08.2012 14:41, Henrik Sperre Johansen wrote: >> You mean someone might LIKE >> - keep getting suggested something they just typed? >> - that the window doesn't close when they've clearly change context by moving the cursor? >> - that the window doesn't respond to mouse input to it by selecting what you clicked on, but rather closing? >> >> Cheers, >> Henry > To explain my thinking: > To me, the autocomplete popup is essentially a menu that opens before I might feel like using it. > As such, I expect it to behave similiarly to a menu. yes, I strongly agree, sadly it is not implemented as a menu, and I don't have time to fix this :D > With regards to mouse input, that means the two last gripes above. > With regards to keyboard input, I never explicitly opened it, thus I expect it to not interfere with normal operation in the widget. > To me, using left and right keys are normal operations in a text editor after inserting characters, while tabbing or pressing up and down less so (in other words I think it's ok those operate the popup without explicitly focusing it first). > > What do you really lose by not hijacking left and right? The ability to view definition of the first entry in the list with a single key-press. > IMHO, that's not too bad, I'd expect the 3-press down->up->right sequence to do that, or alternately a two-press sequence with new shortcut for explicitly switching focus, then right. I completely understand that this is a bothering feature :P but I like it and thus I want to keep it. So I'll add a default setting which will not hijack left/right, but I can enable it for myself... to be honest, I don't like the current implementation too much, but TextEditor is such a mess that I don't have the energy and time to change it in a decent way...

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Camillo Bruni

no options, this what options are for. you can decide on a default. and then change the options. we live in a multidimensional world. it's the same thing with using ENTER instead of TAB to accept completions. I and Igor for instance strongly prefer ENTER, whereas other people like you don't like that... now we can start a swiss democracy over that and decide in 100 years whether we should support ENTER or not. OR we simply add an option, both sides happy! On 2012-08-23, at 14:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think an option would only add to the confusion. Please replace the > option with one decision. If some do not like it, they can shout and > the designer can take the input into account. But, it's the designer > that decides. > > Cheers, > Doru > > > On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? >>> Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... >>> Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. >>> moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? >>> Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. >>> >>> Suggestions: >>> - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. >>> - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ >>> - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. >> >> maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, >> so everybody is happy >> >>> PS: AlphaBlendingCanvas suggested for 'aB'... really? >> for me, clearly yes, substring matching is exactly then important when >> you don't fully remember the selector name. But again, adding an option here >> will make both sides happy... > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 23, 2012

Re: [Pharo-project] [squeak-dev] ObjectAsMethodWrapper >> #uninstall breaks class organisation

by Frank Shearar

On 23 August 2012 12:49, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > On 2012-08-23, at 11:24, Frank Shearar wrote: > >> It looks like PackageInfo possibly isn't catching the AddEvent sent by >> ClassDescription >> #addSelector:withMethod:notifying: but I'm just >> guessing: I don't know enough about this part of the system. > > > No, PackageInfo is not event-based. It does not "store" classes or methods. Instead, when you ask it for classes and methods in the package, it looks at the system. > > What must be happening is that the class's organizer gets out-of-sync with the method dictionary. The System Browser only looks at the organization to display methods. So if a selector is not in the organizer, the Browser does not show it at all. OK. So the organizer loses the reference because ObjectAsMethodWrapper calls #removeSelectorSilently:, which eventually calls ClassDescription >> #removeSelector:. It re-adds the now-unwrapped CompiledMethod to the method dictionary with #addSelector:withMethod: which eventually calls ClassDescription >> #basicAddSelector:withMethod:. However, this does _not_ add the selector to the organization's elementArray, and Bad Things Happen. I'm trying to find how things get _into_ a Categorizer's elementArray. I suspect it's via ClassDescription >> #addAndClassifySelector:withMethod:inProtocol:notifying:. A Browser would do this via accepting code, while if you're hacking on the method dictionary directly, you'll need to do this yourself. This looks like it would do the trick. At least, it makes the failing test pass: ObjectAsMethodWrapper >> uninstall | category | oldMethod isNil ifTrue: [^self]. category := wrappedClass organization categoryOfElement: selector. "<-- store the original category" wrappedClass removeSelectorSilently: selector. wrappedClass addSelector: selector withMethod: oldMethod. wrappedClass organization classify: selector under: category. "<-- categorise the restored method." frank > This is different in Monticello - if you click "browse" in MC it makes a package snapshot by asking PackageInfo, which iterates through the method dictionary. After running the test this blows up, because it finds the "bar" method, but that is not in the organizer, so its category is nil and you get a walkback. > > Events are only used to mark the Monticello working copy dirty. Not to actually keep track of method additions. > > - Bert - > > >

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Henrik Sperre Johansen

On 23.08.2012 14:41, Henrik Sperre Johansen wrote: > You mean someone might LIKE > - keep getting suggested something they just typed? > - that the window doesn't close when they've clearly change context by > moving the cursor? > - that the window doesn't respond to mouse input to it by selecting > what you clicked on, but rather closing? > > Cheers, > Henry To explain my thinking: To me, the autocomplete popup is essentially a menu that opens before I might feel like using it. As such, I expect it to behave similiarly to a menu. With regards to mouse input, that means the two last gripes above. With regards to keyboard input, I never explicitly opened it, thus I expect it to not interfere with normal operation in the widget. To me, using left and right keys are normal operations in a text editor after inserting characters, while tabbing or pressing up and down less so (in other words I think it's ok those operate the popup without explicitly focusing it first). What do you really lose by not hijacking left and right? The ability to view definition of the first entry in the list with a single key-press. IMHO, that's not too bad, I'd expect the 3-press down->up->right sequence to do that, or alternately a two-press sequence with new shortcut for explicitly switching focus, then right. Cheers, Henry

Aug. 23, 2012

Re: [Pharo-project] [update 2.0] #20257

by Sven Van Caekenberghe

On 17 Aug 2012, at 17:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Issue 3459: includesSubstring: aString caseSensitive: caseSensitive / includesSubString: > http://code.google.com/p/pharo/issues/detail?id=3459 (I commented on the issue, but the mail did not come through). I know that we have been here before, but how are library writers that target multiple pharo versions (1.3, 1.4, 2.0) supposed to handle this ? If I track the 2.0 selector name, I break pre-2.0 compatibility. If I don't track the rename, I get massive deprecation warnings in 2.0. I am all for progress and cleanups, but can we ask library writers to deal with this alone ? We could talk about this at ESUG. --- An idea could be to make a 'PharoForwardCompatibility' package to be loaded in 1.3 or 1.4 with minor additions or changes to help here. For example, in this particular case, the differently spelled new methods could be added as synonyms. This way library writer can track the lastest 2.0+ API, while maintaining backwards compatibility. If we maintain this as a community, it would be a very useful shared resource. I also think that it would allow the lastest version to evolve faster. Comments ? Sven

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Henrik Sperre Johansen

On 23.08.2012 13:00, Camillo Bruni wrote: > On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? >> Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... >> Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. >> moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? >> Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. >> >> Suggestions: >> - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. >> - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ >> - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. > maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, > so everybody is happy You mean someone might LIKE - keep getting suggested something they just typed? - that the window doesn't close when they've clearly change context by moving the cursor? - that the window doesn't respond to mouse input to it by selecting what you clicked on, but rather closing? Cheers, Henry

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Tudor Girba

I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides. Cheers, Doru On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? >> Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... >> Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. >> moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? >> Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. >> >> Suggestions: >> - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. >> - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ >> - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. > > maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, > so everybody is happy > >> PS: AlphaBlendingCanvas suggested for 'aB'... really? > for me, clearly yes, substring matching is exactly then important when > you don't fully remember the selector name. But again, adding an option here > will make both sides happy... -- www.tudorgirba.com "Every thing has its own flow"

Aug. 23, 2012

[Pharo-project] Pharo 2.0 #20267

by Sven Van Caekenberghe

Hi Guys, I like to report postive things from time to time, mailing lists shouldn't be about bugs and problems only. I just took a fresh 2.0 image (#20267) and just for fun tried running all tests on my machine, something that didn't work very well in the past. I am happy to report that the _all_ passed ! Great work. All these small and big steps do make a difference. Sven

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Camillo Bruni

On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? > Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... > Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. > moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? > Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. > > Suggestions: > - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. > - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ > - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy > PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...

Aug. 23, 2012