i have an impression, that people simply don't understand the function of cmd-l,
and how convenient it is, especially when debugging:

in debugger i more often operate with method's source pane than inspectors:

��i simply select the subexpression i wanting to inspect and then press Cmd-P which

evaluates it and prints it right in place, and then, after i done
inspecting result, simply i pressing Cmd-L and ready to go...

Less often i use Cmd-I and inspector panes, because it takes much more time

and more interactions to get what i want.

Note, that in such way of use (cmd-p/cmd-l) there is no chance why i would want to save changes instead of thrashing them, and asking me about it is just silly.

Now this is crippled by damn yes/no popups.

On 12 January 2014 01:08, Chris Muller <asqueaker@gmail.com> wrote:

I finally read this whole thread. ��I don't normally get involved in
Pharo discussions but, I can't help to say: ��Igor is 100% right, and
his best rationale why at the beginning:

==========

at the end, it is just silly: the point is that i am always sure about
things i do, when interacting with my computer. if i'm not, i simply
don't (or i save and then proceed with caution).. and in any case, i
don't need stupid UI asking me about things i already decided to do
(yes i am sort of man, who disables file deletion warning, if it
provided).

===========

Unless there's a possibility of an accidental mishap with great
consequences, software should simply do what its told without
question.

kilos doesn't want to be punished for a "mistake". ��Much simpler, if
you don't want to "lose your changes", is to simply not press
Command+L in the first place. ��It sounds like kilos is pressing
buttons before knowing the effects. ��That's just impatience that
should be appropriately spanked as Igor said.

What if, upon being asked, "are you sure" you made your mistake right
then and there, by pressing "Yes" instead of "No"? ��This is very easy
to happen since, as Igor pointed out, mechanical reactions to pop-ups
develop over time..

I disagreed with, "A editor key combination that looses code because
is does not support undo is *wrong*." ��Losing the code is the _entire
purpose_ of Command+L. ��Every version of every method is still saved
in history so one could simply save their work then revert to the
prior version to avoid "losing code".

Undo on Command+L would be of no use except for people pressing
buttons before thinking. ��That needs to be corrected to, "think first,
THEN press buttons." ��:)

Bye.

On Sat, Jan 11, 2014 at 8:33 AM, Igor Stasenko <siguctua@gmail.com> wrote:
>
>
>
> On 11 January 2014 15:20, <btc@openinworld.com> wrote:
>>
>> Igor Stasenko wrote:
>>>
>>> and guess what i currently working on?
>>> OSWindow interface, which will allow us to control creating of windows
>>> and managing them from the image, and handling the events.
>>>
>> OSWindow sounds really exciting. Perhaps it will help facilitate
>> multi-monitor support?
>>
> eventually, yes.
> at least we care about it from very beginning:
>
> Object subclass: #OSWindowAttributes
> �� instanceVariableNames: 'bounds title fullscreen screenId
> preferableDriver'
> �� classVariableNames: 'DefaultBounds DefaultFullscreen DefaultTitle'
> �� poolDictionaries: ''
> �� category: 'OSWindow'
>
> this object is used to describe a window attributes. sure thing not all of
> them
> listed there and much more will be added later, but as you can see,
> screenId is already there, so potentially you can control which screen your
> window must use.
> it is not clear now, how we will facilitate the screen selection and what
> values/api to use to identify them, but at this early stage we lying a
> foundations to make this option come into play one day.
>
>
>>
>> cheers -ben
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.

--
Best regards,
Igor Stasenko.