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.