20267
-
Issue 6591: TextInputFieldModel acceptOnCR: not working
http://code.google.com/p/pharo/issues/detail?id=6591
--
Marcus Denker -- http://marcusdenker.de
1. In Pharo if you expand a keyword message like #replaceAll:with:
the cursor is set already to the first argument (so one can continue
typing) but to enter the second argument one has to move left using
arrow keys "manually".
How often you have to move left is dependent on the size of
Hi all,
I plan to attend Smalltalk camp sunday and perhaps also the saturday
afternoon. I'm only an Smalltalk apprentice. In any case, I expect to be
able to participate and help with some basic topics.
Looking forward to attending the ESUG week.
Rafael Luque
2012/8/22 Stéphane Ducasse
> Hi p
I'll be in for Sunday, possibly a bit of saturday as well.
It would be nice to be able to do some podcast interviews and videos of
practioners to up the social proof side of Pharo a bit. Can bring the cam
and the editing system along.
Philippe
2012/8/23 Rafael Luque
> Hi all,
>
> I plan to att
ObjectAsMethodWrapper's test suite breaks ObjectAsMethodWrapperDummy's
organization - its #foo and #bar methods disappear even though the
method dictionary still has them. As a result, after you've run OAMW's
tests, you can't do anything with the OAMW PackageInfo - you can't
check to see what chang
On 23 August 2012 10:24, Frank Shearar wrote:
> ObjectAsMethodWrapper's test suite breaks ObjectAsMethodWrapperDummy's
> organization - its #foo and #bar methods disappear even though the
> method dictionary still has them. As a result, after you've run OAMW's
> tests, you can't do anything with t
Whats the feedback so far?
--
View this message in context:
http://forum.world.st/poll-reminder-tp4645002p4645073.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Aug 23, 2012, at 9:31 AM, p...@highoctane.be wrote:
> I'll be in for Sunday, possibly a bit of saturday as well.
>
> It would be nice to be able to do some podcast interviews and videos of
> practioners to up the social proof side of Pharo a bit. Can bring the cam and
> the editing system a
On Aug 23, 2012, at 9:20 AM, Torsten Bergmann wrote:
> 1. In Pharo if you expand a keyword message like #replaceAll:with:
> the cursor is set already to the first argument (so one can continue
> typing) but to enter the second argument one has to move left using
> arrow keys "manually".
>
On 2012-08-22, at 20:22, Henrik Sperre Johansen
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 ope
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 _a
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 wrote:
>
> On
On 23.08.2012 13:00, Camillo Bruni wrote:
On 2012-08-22, at 20:22, Henrik Sperre Johansen
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,
On 17 Aug 2012, at 17:55, Esteban Lorenzano 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 bee
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 y
On 23 August 2012 12:49, Bert Freudenberg 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 th
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
On 2012-08-23, at 15:05, Henrik Sperre Johansen
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?
>> -
There is a class category called 'Zinc-HTTP-Deprecated'. It contains some old
classes that were replaced/superceded by newer ones almost a year ago.
I plan to actually delete these and their unit tests in a commit in the next
couple of days.
Specifically, the following classes will be removed:
On 23.08.2012 15:40, Camillo Bruni wrote:
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
I definitely do not adhere to this point of view, but I think I
understand it well.
Let's think of code design now. When you see non-object-oriented
design, you go and refine. When you see conceptual duplication, you go
for it and unify. Until you get a better abstraction that matches the
paradigm
So you're saying modifiable keyboard shortcuts are a bad design?
On 2012-08-23, at 16:04, Tudor Girba wrote:
> I definitely do not adhere to this point of view, but I think I
> understand it well.
>
> Let's think of code design now. When you see non-object-oriented
> design, you go and refine.
no idea :/
you can just resave them to go back to normal
On 23 August 2012 16:15, Mariano Martinez Peck wrote:
> In Pharo 2.0
>
> (CompiledMethod allInstances select: [:each | each trailer kind =
> #EmbeddedSourceZip ]) size -> 15
>
> (CompiledMethod allInstances select: [:each | each trailer ki
Doru 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.
+1
Stephan
Camillo wrote:
>So you're saying modifiable keyboard shortcuts are a bad design?
Yes.
That is to say, using them outside of developing a good set of
key bindings (possibly for each language/keyboard). We need them
to get to this consistent set. Options could be on the level of
vi/wordstar/emacs s
Yes, the rumors are true: WebSocket support is coming to Zinc HTTP Components
and thus to Pharo Smalltalk !
Several people asked for it, but Andy Burnett of Knowinnovation USA provided a
financial incentive (thanks a lot Andy for sponsoring open-source Smalltalk
software like that), so I am now
On 23 August 2012 21:27, Sven Van Caekenberghe wrote:
> Yes, the rumors are true: WebSocket support is coming to Zinc HTTP Components
> and thus to Pharo Smalltalk !
>
> Several people asked for it, but Andy Burnett of Knowinnovation USA provided
> a financial incentive (thanks a lot Andy for sp
Excellent news Sven!
--
View this message in context:
http://forum.world.st/In-Progress-WebSocket-support-being-added-to-Zinc-HTTP-Components-tp4645109p4645111.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I'm arriving on Friday morning (about 9am)... anyone else around?
Sean
On 2012-08-23, at 19:50, Stephan Eggermont wrote:
> Camillo wrote:
>> So you're saying modifiable keyboard shortcuts are a bad design?
>
> Yes.
>
> That is to say, using them outside of developing a good set of
> key bindings (possibly for each language/keyboard). We need them
> to get to this
(a bit orthogonal)
i don't understand why we cannot have own, consistent set which is good for us?
vim, emacs..
why this is so important ? Those editors were not written for editing
smalltalk code in mind..
they are best suited for big, hundreds lines of code, files..
while something like that in o
On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
> (a bit orthogonal)
> i don't understand why we cannot have own, consistent set which is good
> for us?
> vim, emacs..
better use sets which are already extremely familiar than invent yet
another set. to those of us who use these editors (
On 24 August 2012 01:19, Eliot Miranda wrote:
>
>
> On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
>>
>> (a bit orthogonal)
>> i don't understand why we cannot have own, consistent set which is good
>> for us?
>> vim, emacs..
>
>
> better use sets which are already extremely familiar than
Igor, as usual your true object-oriented thinking helps us see a better path...
We need a customized UI interaction for Smalltalk, instead of asking
for TEXT editors devised for a different setup. What's missing is a
Smalltalk method shape(morph, etc...), highly customized for
editing/navigating s
On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote:
> On 24 August 2012 01:19, Eliot Miranda wrote:
> >
> >
> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
> >>
> >> (a bit orthogonal)
> >> i don't understand why we cannot have own, consistent set which is good
> >> for us?
>
On 24 August 2012 02:25, David T. Lewis wrote:
> On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote:
>> On 24 August 2012 01:19, Eliot Miranda wrote:
>> >
>> >
>> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
>> >>
>> >> (a bit orthogonal)
>> >> i don't understand why we can
37 matches
Mail list logo
