Do you want to accept???????? Discard???????

Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.

There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.

Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.

(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself:

On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <[hidden email]> wrote:

On 9 January 2014 11:10, kilon alios <[hidden email]> wrote:

I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass. 

And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist.

 I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.

because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all.

You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire.

Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.

I think maybe an easy solution is to set all modals to a preference setting so they can be easily disabled, thus making everyone happy. 

Yes, that could be a way to go.

 

Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part. 

really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.

They usually put out the excuse "I am no designer" yet the truth is that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design. 

you lost me on that. I never considered Photoshop as one that has good GUI design..

The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.

 

 

--
Best regards,
Igor Stasenko.

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