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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > On 11 January 2014 15:20, <[email protected]> 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.
