Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-08 Thread Esteban Lorenzano
+1

> On 08 Aug 2016, at 11:31, Nicolas Passerini  wrote:
> 
> Hi, 
> 
> I think that whatever default behavior and shortcuts you decide, it would be 
> nice to be able to configure it. So, if someone does not feel comfortable 
> with the default, he has a simple way to change it and configure in a way 
> that gets better along with his way of using Pharo. Don't you think?
> 
> On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs 
> > 
> wrote:
> Nicolai, 
> It is good to encourage this, but it is a reality that it is a lot of work to 
> do a good job of complaining and criticizing and personally I have a talk at 
> ESUG that needs work, so I won't have the luxury of detailed criticisms much 
> longer :) and I'm sure that this is an issue for others as well ...
> 
> But if all of us make a point to "complain" when we hit an annoying issue AND 
> have the time to complain, then eventually you guys will get the kind of 
> feedback that you need to make better decisions, compromises and 
> preferences...
> 
> Dale
> On 8/7/16 7:33 AM, Nicolai Hess wrote:
>> 
>> 
>> 2016-08-07 16:10 GMT+02:00 Tudor Girba > >:
>> Hi Dale,
>> 
>> Thanks for your thoughts. And thanks for giving these new quirks time to 
>> settle :).
>> 
>> Actually, I am looking for what is annoying and I specifically interested in 
>> the reasons why it is annoying. Please feel free to report the bits that 
>> annoy you.
>> 
>> +1
>> Pharo is not an environment where we should live with annoyance.
>> I would encourage people to report anything that disturbs the daily work and 
>> discuss what behavior or gui layout is expected  and what could be done
>> better. I am sure we can not find a way to satisfy all, we have different 
>> workflows and different expectations, but it is better to talk about, 
>> instead of just live with it.
>>  
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs 
>> > > > > wrote:
>> >
>> >
>> >
>> > On 8/7/16 6:16 AM, Tudor Girba wrote:
>> >> Hi Stef,
>> >>
>> >>
>> >> That is why we made the default printing not affect the text editor, and 
>> >> this feature is around since almost 2 years and, except of you, there was 
>> >> no other complain.
>> >>
>> > I believe that this is a logical fallacy ... many developers are too busy 
>> > actually trying to do work with these tools and don't have time or 
>> > inclination to get involved in an argument :)
>> >
>> > There are a number of odd, awkward, hidden, "old way does not work 
>> > anymore" things that I am running into as I have just been using Pharo5.0 
>> > for a couple of months ... I understand that when the GUI changes one must 
>> > give it a little bit of time to "settle in" and see if my annoyance is due 
>> > to the fact that things have changed or if the "old way was better" ...
>> >
>> > I don't like the funky popup prints either --- they often obscure the 
>> > underlying text and when I do something to see the underlying text I lose 
>> > the printout --- occasionally it is useful as a preview but that's not the 
>> > only use case .. often the result is what I want ...
>> >
>> > But I am trying to do real work and I really don't have the time to get 
>> > into an embroiled argument over things so far I feel less productive (the 
>> > debugger buttons are a real annoyance) but perhaps with practice and 
>> > patience I will eventually see the light of putting heavily used menu 
>> > items off in a corner ...
>> >
>> > BTW, I've basically given up on using browser shortcuts altogether ... I 
>> > am assuming that the shortcuts will be changing yet again in 6.0 so I'm 
>> > not going to try to memorize shortcuts that will be changing every 6 
>> > months :)
>> >
>> > While I am complaining --- is there a way to be able to change the width 
>> > of the inspector panes in a debugger? I'm almost never able to see what I 
>> > want to see in the inspector panes because they aren't wide enough and 
>> > unlike every other pane in the universe, I can't grab the pane and change 
>> > its width ... I'm sure you have a good argument for why it can't be moved 
>> > --- but that doesn't stop me from being annoyed ...
>> >
>> > Optimized code is often uglier than the cleanly crafted beautiful code 
>> > that runs too damn slow ...
>> >
>> > I could go on and on, but I'm sure you've good reasons for all of the the 
>> > things that you have changed and this isn't the only GUI in the world that 
>> > is annoying to use :)
>> >
>> > Remember that I am still in the phase of "give it a little bit of time to 
>> > "settle in" and see if my annoyance is due to the fact that things have 
>> > changed or if the "old way was better" ... "
>> >
>> > Dale
>> >
>> >
>> 
>> --
>> www.tudorgirba.com 
>> 

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-08 Thread Dale Henrichs

+1


On 8/8/16 2:31 AM, Nicolas Passerini wrote:

Hi,

I think that whatever default behavior and shortcuts you decide, it 
would be nice to be able to configure it. So, if someone does not feel 
comfortable with the default, he has a simple way to change it and 
configure in a way that gets better along with his way of using Pharo. 
Don't you think?


On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs 
> wrote:


Nicolai,

It is good to encourage this, but it is a reality that it is a lot
of work to do a good job of complaining and criticizing and
personally I have a talk at ESUG that needs work, so I won't have
the luxury of detailed criticisms much longer :) and I'm sure that
this is an issue for others as well ...

But if all of us make a point to "complain" when we hit an
annoying issue AND have the time to complain, then eventually you
guys will get the kind of feedback that you need to make better
decisions, compromises and preferences...

Dale

On 8/7/16 7:33 AM, Nicolai Hess wrote:



2016-08-07 16:10 GMT+02:00 Tudor Girba >:

Hi Dale,

Thanks for your thoughts. And thanks for giving these new
quirks time to settle :).

Actually, I am looking for what is annoying and I
specifically interested in the reasons why it is annoying.
Please feel free to report the bits that annoy you.


+1
Pharo is not an environment where we should live with annoyance.
I would encourage people to report anything that disturbs the
daily work and discuss what behavior or gui layout is expected 
and what could be done

better. I am sure we can not find a way to satisfy all, we have
different workflows and different expectations, but it is better
to talk about, instead of just live with it.


Cheers,
Doru



> On Aug 7, 2016, at 3:57 PM, Dale Henrichs
> wrote:
>
>
>
> On 8/7/16 6:16 AM, Tudor Girba wrote:
>> Hi Stef,
>>
>>
>> That is why we made the default printing not affect the
text editor, and this feature is around since almost 2 years
and, except of you, there was no other complain.
>>
> I believe that this is a logical fallacy ... many
developers are too busy actually trying to do work with these
tools and don't have time or inclination to get involved in
an argument :)
>
> There are a number of odd, awkward, hidden, "old way does
not work anymore" things that I am running into as I have
just been using Pharo5.0 for a couple of months ... I
understand that when the GUI changes one must give it a
little bit of time to "settle in" and see if my annoyance is
due to the fact that things have changed or if the "old way
was better" ...
>
> I don't like the funky popup prints either --- they often
obscure the underlying text and when I do something to see
the underlying text I lose the printout --- occasionally it
is useful as a preview but that's not the only use case ..
often the result is what I want ...
>
> But I am trying to do real work and I really don't have the
time to get into an embroiled argument over things so far I
feel less productive (the debugger buttons are a real
annoyance) but perhaps with practice and patience I will
eventually see the light of putting heavily used menu items
off in a corner ...
>
> BTW, I've basically given up on using browser shortcuts
altogether ... I am assuming that the shortcuts will be
changing yet again in 6.0 so I'm not going to try to memorize
shortcuts that will be changing every 6 months :)
>
> While I am complaining --- is there a way to be able to
change the width of the inspector panes in a debugger? I'm
almost never able to see what I want to see in the inspector
panes because they aren't wide enough and unlike every other
pane in the universe, I can't grab the pane and change its
width ... I'm sure you have a good argument for why it can't
be moved --- but that doesn't stop me from being annoyed ...
>
> Optimized code is often uglier than the cleanly crafted
beautiful code that runs too damn slow ...
>
> I could go on and on, but I'm sure you've good reasons for
all of the the things that you have changed and this isn't
the only GUI in the world that is annoying to use :)
>
> Remember that I am still in the phase of "give it a little
bit 

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-08 Thread Nicolas Passerini
Hi,

I think that whatever default behavior and shortcuts you decide, it would
be nice to be able to configure it. So, if someone does not feel
comfortable with the default, he has a simple way to change it and
configure in a way that gets better along with his way of using Pharo.
Don't you think?

On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Nicolai,
>
> It is good to encourage this, but it is a reality that it is a lot of work
> to do a good job of complaining and criticizing and personally I have a
> talk at ESUG that needs work, so I won't have the luxury of detailed
> criticisms much longer :) and I'm sure that this is an issue for others as
> well ...
>
> But if all of us make a point to "complain" when we hit an annoying issue
> AND have the time to complain, then eventually you guys will get the kind
> of feedback that you need to make better decisions, compromises and
> preferences...
>
> Dale
> On 8/7/16 7:33 AM, Nicolai Hess wrote:
>
>
>
> 2016-08-07 16:10 GMT+02:00 Tudor Girba :
>
>> Hi Dale,
>>
>> Thanks for your thoughts. And thanks for giving these new quirks time to
>> settle :).
>>
>> Actually, I am looking for what is annoying and I specifically interested
>> in the reasons why it is annoying. Please feel free to report the bits that
>> annoy you.
>>
>
> +1
> Pharo is not an environment where we should live with annoyance.
> I would encourage people to report anything that disturbs the daily work
> and discuss what behavior or gui layout is expected  and what could be done
> better. I am sure we can not find a way to satisfy all, we have different
> workflows and different expectations, but it is better to talk about,
> instead of just live with it.
>
>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs <
>> dale.henri...@gemtalksystems.com> wrote:
>> >
>> >
>> >
>> > On 8/7/16 6:16 AM, Tudor Girba wrote:
>> >> Hi Stef,
>> >>
>> >>
>> >> That is why we made the default printing not affect the text editor,
>> and this feature is around since almost 2 years and, except of you, there
>> was no other complain.
>> >>
>> > I believe that this is a logical fallacy ... many developers are too
>> busy actually trying to do work with these tools and don't have time or
>> inclination to get involved in an argument :)
>> >
>> > There are a number of odd, awkward, hidden, "old way does not work
>> anymore" things that I am running into as I have just been using Pharo5.0
>> for a couple of months ... I understand that when the GUI changes one must
>> give it a little bit of time to "settle in" and see if my annoyance is due
>> to the fact that things have changed or if the "old way was better" ...
>> >
>> > I don't like the funky popup prints either --- they often obscure the
>> underlying text and when I do something to see the underlying text I lose
>> the printout --- occasionally it is useful as a preview but that's not the
>> only use case .. often the result is what I want ...
>> >
>> > But I am trying to do real work and I really don't have the time to get
>> into an embroiled argument over things so far I feel less productive (the
>> debugger buttons are a real annoyance) but perhaps with practice and
>> patience I will eventually see the light of putting heavily used menu items
>> off in a corner ...
>> >
>> > BTW, I've basically given up on using browser shortcuts altogether ...
>> I am assuming that the shortcuts will be changing yet again in 6.0 so I'm
>> not going to try to memorize shortcuts that will be changing every 6 months
>> :)
>> >
>> > While I am complaining --- is there a way to be able to change the
>> width of the inspector panes in a debugger? I'm almost never able to see
>> what I want to see in the inspector panes because they aren't wide enough
>> and unlike every other pane in the universe, I can't grab the pane and
>> change its width ... I'm sure you have a good argument for why it can't be
>> moved --- but that doesn't stop me from being annoyed ...
>> >
>> > Optimized code is often uglier than the cleanly crafted beautiful code
>> that runs too damn slow ...
>> >
>> > I could go on and on, but I'm sure you've good reasons for all of the
>> the things that you have changed and this isn't the only GUI in the world
>> that is annoying to use :)
>> >
>> > Remember that I am still in the phase of "give it a little bit of time
>> to "settle in" and see if my annoyance is due to the fact that things have
>> changed or if the "old way was better" ... "
>> >
>> > Dale
>> >
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>>
>>
>>
>
>


Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Dale Henrichs

Nicolai,

It is good to encourage this, but it is a reality that it is a lot of 
work to do a good job of complaining and criticizing and personally I 
have a talk at ESUG that needs work, so I won't have the luxury of 
detailed criticisms much longer :) and I'm sure that this is an issue 
for others as well ...


But if all of us make a point to "complain" when we hit an annoying 
issue AND have the time to complain, then eventually you guys will get 
the kind of feedback that you need to make better decisions, compromises 
and preferences...


Dale

On 8/7/16 7:33 AM, Nicolai Hess wrote:



2016-08-07 16:10 GMT+02:00 Tudor Girba >:


Hi Dale,

Thanks for your thoughts. And thanks for giving these new quirks
time to settle :).

Actually, I am looking for what is annoying and I specifically
interested in the reasons why it is annoying. Please feel free to
report the bits that annoy you.


+1
Pharo is not an environment where we should live with annoyance.
I would encourage people to report anything that disturbs the daily 
work and discuss what behavior or gui layout is expected  and what 
could be done
better. I am sure we can not find a way to satisfy all, we have 
different workflows and different expectations, but it is better to 
talk about, instead of just live with it.



Cheers,
Doru



> On Aug 7, 2016, at 3:57 PM, Dale Henrichs
> wrote:
>
>
>
> On 8/7/16 6:16 AM, Tudor Girba wrote:
>> Hi Stef,
>>
>>
>> That is why we made the default printing not affect the text
editor, and this feature is around since almost 2 years and,
except of you, there was no other complain.
>>
> I believe that this is a logical fallacy ... many developers are
too busy actually trying to do work with these tools and don't
have time or inclination to get involved in an argument :)
>
> There are a number of odd, awkward, hidden, "old way does not
work anymore" things that I am running into as I have just been
using Pharo5.0 for a couple of months ... I understand that when
the GUI changes one must give it a little bit of time to "settle
in" and see if my annoyance is due to the fact that things have
changed or if the "old way was better" ...
>
> I don't like the funky popup prints either --- they often
obscure the underlying text and when I do something to see the
underlying text I lose the printout --- occasionally it is useful
as a preview but that's not the only use case .. often the result
is what I want ...
>
> But I am trying to do real work and I really don't have the time
to get into an embroiled argument over things so far I feel less
productive (the debugger buttons are a real annoyance) but perhaps
with practice and patience I will eventually see the light of
putting heavily used menu items off in a corner ...
>
> BTW, I've basically given up on using browser shortcuts
altogether ... I am assuming that the shortcuts will be changing
yet again in 6.0 so I'm not going to try to memorize shortcuts
that will be changing every 6 months :)
>
> While I am complaining --- is there a way to be able to change
the width of the inspector panes in a debugger? I'm almost never
able to see what I want to see in the inspector panes because they
aren't wide enough and unlike every other pane in the universe, I
can't grab the pane and change its width ... I'm sure you have a
good argument for why it can't be moved --- but that doesn't stop
me from being annoyed ...
>
> Optimized code is often uglier than the cleanly crafted
beautiful code that runs too damn slow ...
>
> I could go on and on, but I'm sure you've good reasons for all
of the the things that you have changed and this isn't the only
GUI in the world that is annoying to use :)
>
> Remember that I am still in the phase of "give it a little bit
of time to "settle in" and see if my annoyance is due to the fact
that things have changed or if the "old way was better" ... "
>
> Dale
>
>

--
www.tudorgirba.com 
www.feenk.com 

"Being happy is a matter of choice."










Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Tudor Girba
Hi,


> On Aug 7, 2016, at 5:48 PM, Ben Coman  wrote:
> 
> On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba  wrote:
>> Hi Stef,
>> 
>> We had a thread on that two months ago, and it is still waiting for your 
>> answer. I made concrete proposals on which bindings can work. It would be 
>> more constructive to focus on those details (see more below).
>> 
>> First, one thing should get clarified. The case in which someone wants to 
>> print and persist inline the result is an edge case. For example, it happens 
>> when you want to write tests to document how the code is working currently. 
>> The typical case for using print-it is to get a sneak peak of what the 
>> object is and in this case, the requirement is specifically to not change 
>> the current code (especially when you are debugging you do not want to get 
>> the code dirty).
>> 
>> That is why we made the default printing not affect the text editor, and 
>> this feature is around since almost 2 years and, except of you, there was no 
>> other complain.
>> 
>> But, to come back to the concrete solution, as I mentioned before, I do 
>> agree that what you mention should be a supported use case. The only 
>> question is how to do it. So, let’s focus on that please.
>> 
>> One solution would be to have a different first level keybinding directly in 
>> the text editor, but that would not be a good idea because that space is 
>> already overloaded with too many key bindings, and this becomes a problem 
>> especially when you place an editor inside a larger tool (like a debugger) 
>> and you run out of available key bindings for other actions.
>> 
>> So, the proposals I had was like this:
>> 
>> Cmd+p ==> the print-it popup
>> - Enter ==> add as a comment
>> - Shift+Enter ==> add as plain text
>> - Cmd+v ==> add as plain text (this would not affect the text that was 
>> copied to clipboard)
>> 
>> Another option would be to change the meaning of the current Enter:
>> 
>> Cmd+p ==> the print-it popup
>> - Enter ==> add as a plain text
>> - Shift+Enter ==> add as comment
> 
> Doing a CMD key then SHIFT key is a bit of a contortion.
> What about...
> Cmd+p ==> the print-it popup, then...
> - Cmd+p ==> add as a plain text  (fingers don't have to move, most
> efficient for old behaviour)
> - Enter ==> add as comment (existing behaviour)

I am fine with that. And I think we can still anyway add Cmd+v to “paste” in 
place the plain text.

Does anyone see a problem with this solution?

Cheers,
Doru


> cheers -ben
> 
>> 
>> 
>> What do you think?
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 7, 2016, at 9:39 AM, stepharo  wrote:
>>> 
>>> Hi
>>> 
>>> Seriously I do not get why printing in the debugger cannot just print the 
>>> text without putting these ^%&*^*&()**(&%^*( double quote around.
>>> 
>>> Why do we change such basic functionality and in particular we do not 
>>> propose ANY alternative.
>>> 
>>> If you need a pop up and do not care of manipulating text this is ok but 
>>> WHY the default behavior has to be changed.
>>> 
>>> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& 
>>> flow is not mine.
>>> 
>>> Should I go and hack to get back the default behavior. WHY do I have to do 
>>> that?
>>> 
>>> Seriously.
>>> 
>>> Especially since the solution was super simple: introduce a new binding 
>>> living nicely close to PrintIt
>>> 
>>> but no "we have to change the default one with something that may fuck your 
>>> flow but who cares because
>>> 
>>> my flow is better."
>>> 
>>> Why do we get systematically this message? Why such changes are damaging 
>>> TDD practices without any notices?
>>> 
>>> May be I should use another Smalltalk at the end.
>>> 
>>> Stef
>>> 
>>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Presenting is storytelling."

--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."







Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Ben Coman
On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba  wrote:
> Hi Stef,
>
> We had a thread on that two months ago, and it is still waiting for your 
> answer. I made concrete proposals on which bindings can work. It would be 
> more constructive to focus on those details (see more below).
>
> First, one thing should get clarified. The case in which someone wants to 
> print and persist inline the result is an edge case. For example, it happens 
> when you want to write tests to document how the code is working currently. 
> The typical case for using print-it is to get a sneak peak of what the object 
> is and in this case, the requirement is specifically to not change the 
> current code (especially when you are debugging you do not want to get the 
> code dirty).
>
> That is why we made the default printing not affect the text editor, and this 
> feature is around since almost 2 years and, except of you, there was no other 
> complain.
>
> But, to come back to the concrete solution, as I mentioned before, I do agree 
> that what you mention should be a supported use case. The only question is 
> how to do it. So, let’s focus on that please.
>
> One solution would be to have a different first level keybinding directly in 
> the text editor, but that would not be a good idea because that space is 
> already overloaded with too many key bindings, and this becomes a problem 
> especially when you place an editor inside a larger tool (like a debugger) 
> and you run out of available key bindings for other actions.
>
> So, the proposals I had was like this:
>
> Cmd+p ==> the print-it popup
> - Enter ==> add as a comment
> - Shift+Enter ==> add as plain text
> - Cmd+v ==> add as plain text (this would not affect the text that was copied 
> to clipboard)
>
> Another option would be to change the meaning of the current Enter:
>
> Cmd+p ==> the print-it popup
> - Enter ==> add as a plain text
> - Shift+Enter ==> add as comment

Doing a CMD key then SHIFT key is a bit of a contortion.
What about...
Cmd+p ==> the print-it popup, then...
- Cmd+p ==> add as a plain text  (fingers don't have to move, most
efficient for old behaviour)
- Enter ==> add as comment (existing behaviour)

cheers -ben

>
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 7, 2016, at 9:39 AM, stepharo  wrote:
>>
>> Hi
>>
>> Seriously I do not get why printing in the debugger cannot just print the 
>> text without putting these ^%&*^*&()**(&%^*( double quote around.
>>
>> Why do we change such basic functionality and in particular we do not 
>> propose ANY alternative.
>>
>> If you need a pop up and do not care of manipulating text this is ok but WHY 
>> the default behavior has to be changed.
>>
>> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& 
>> flow is not mine.
>>
>> Should I go and hack to get back the default behavior. WHY do I have to do 
>> that?
>>
>> Seriously.
>>
>> Especially since the solution was super simple: introduce a new binding 
>> living nicely close to PrintIt
>>
>> but no "we have to change the default one with something that may fuck your 
>> flow but who cares because
>>
>> my flow is better."
>>
>> Why do we get systematically this message? Why such changes are damaging TDD 
>> practices without any notices?
>>
>> May be I should use another Smalltalk at the end.
>>
>> Stef
>>
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Presenting is storytelling."
>
>



Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Alexandre Bergel
Often the reason of annoyance is either time consuming or simply complicated to 
detail.
Anyway, personally, I am not really perturbed by the button location. The 
print-it in the debugger is no more an annoyance when the Cmd-c bidding can 
simply copy the print-it. It is exactly what I wish to do most of the time.

What seriously bother me, is the instability of Athens, which cannot be fixed. 
And the highly-suboptimal Git integration. These are what may make me move away 
from Pharo.

Alexandre

> On Aug 7, 2016, at 10:10 AM, Tudor Girba  wrote:
> 
> Hi Dale,
> 
> Thanks for your thoughts. And thanks for giving these new quirks time to 
> settle :).
> 
> Actually, I am looking for what is annoying and I specifically interested in 
> the reasons why it is annoying. Please feel free to report the bits that 
> annoy you.
> 
> Cheers,
> Doru
> 
> 
> 
>> On Aug 7, 2016, at 3:57 PM, Dale Henrichs  
>> wrote:
>> 
>> 
>> 
>> On 8/7/16 6:16 AM, Tudor Girba wrote:
>>> Hi Stef,
>>> 
>>> 
>>> That is why we made the default printing not affect the text editor, and 
>>> this feature is around since almost 2 years and, except of you, there was 
>>> no other complain.
>>> 
>> I believe that this is a logical fallacy ... many developers are too busy 
>> actually trying to do work with these tools and don't have time or 
>> inclination to get involved in an argument :)
>> 
>> There are a number of odd, awkward, hidden, "old way does not work anymore" 
>> things that I am running into as I have just been using Pharo5.0 for a 
>> couple of months ... I understand that when the GUI changes one must give it 
>> a little bit of time to "settle in" and see if my annoyance is due to the 
>> fact that things have changed or if the "old way was better" ...
>> 
>> I don't like the funky popup prints either --- they often obscure the 
>> underlying text and when I do something to see the underlying text I lose 
>> the printout --- occasionally it is useful as a preview but that's not the 
>> only use case .. often the result is what I want ...
>> 
>> But I am trying to do real work and I really don't have the time to get into 
>> an embroiled argument over things so far I feel less productive (the 
>> debugger buttons are a real annoyance) but perhaps with practice and 
>> patience I will eventually see the light of putting heavily used menu items 
>> off in a corner ...
>> 
>> BTW, I've basically given up on using browser shortcuts altogether ... I am 
>> assuming that the shortcuts will be changing yet again in 6.0 so I'm not 
>> going to try to memorize shortcuts that will be changing every 6 months :)
>> 
>> While I am complaining --- is there a way to be able to change the width of 
>> the inspector panes in a debugger? I'm almost never able to see what I want 
>> to see in the inspector panes because they aren't wide enough and unlike 
>> every other pane in the universe, I can't grab the pane and change its width 
>> ... I'm sure you have a good argument for why it can't be moved --- but that 
>> doesn't stop me from being annoyed ...
>> 
>> Optimized code is often uglier than the cleanly crafted beautiful code that 
>> runs too damn slow ...
>> 
>> I could go on and on, but I'm sure you've good reasons for all of the the 
>> things that you have changed and this isn't the only GUI in the world that 
>> is annoying to use :)
>> 
>> Remember that I am still in the phase of "give it a little bit of time to 
>> "settle in" and see if my annoyance is due to the fact that things have 
>> changed or if the "old way was better" ... "
>> 
>> Dale
>> 
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Nicolai Hess
2016-08-07 16:10 GMT+02:00 Tudor Girba :

> Hi Dale,
>
> Thanks for your thoughts. And thanks for giving these new quirks time to
> settle :).
>
> Actually, I am looking for what is annoying and I specifically interested
> in the reasons why it is annoying. Please feel free to report the bits that
> annoy you.
>

+1
Pharo is not an environment where we should live with annoyance.
I would encourage people to report anything that disturbs the daily work
and discuss what behavior or gui layout is expected  and what could be done
better. I am sure we can not find a way to satisfy all, we have different
workflows and different expectations, but it is better to talk about,
instead of just live with it.


>
> Cheers,
> Doru
>
>
>
> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs  com> wrote:
> >
> >
> >
> > On 8/7/16 6:16 AM, Tudor Girba wrote:
> >> Hi Stef,
> >>
> >>
> >> That is why we made the default printing not affect the text editor,
> and this feature is around since almost 2 years and, except of you, there
> was no other complain.
> >>
> > I believe that this is a logical fallacy ... many developers are too
> busy actually trying to do work with these tools and don't have time or
> inclination to get involved in an argument :)
> >
> > There are a number of odd, awkward, hidden, "old way does not work
> anymore" things that I am running into as I have just been using Pharo5.0
> for a couple of months ... I understand that when the GUI changes one must
> give it a little bit of time to "settle in" and see if my annoyance is due
> to the fact that things have changed or if the "old way was better" ...
> >
> > I don't like the funky popup prints either --- they often obscure the
> underlying text and when I do something to see the underlying text I lose
> the printout --- occasionally it is useful as a preview but that's not the
> only use case .. often the result is what I want ...
> >
> > But I am trying to do real work and I really don't have the time to get
> into an embroiled argument over things so far I feel less productive (the
> debugger buttons are a real annoyance) but perhaps with practice and
> patience I will eventually see the light of putting heavily used menu items
> off in a corner ...
> >
> > BTW, I've basically given up on using browser shortcuts altogether ... I
> am assuming that the shortcuts will be changing yet again in 6.0 so I'm not
> going to try to memorize shortcuts that will be changing every 6 months :)
> >
> > While I am complaining --- is there a way to be able to change the width
> of the inspector panes in a debugger? I'm almost never able to see what I
> want to see in the inspector panes because they aren't wide enough and
> unlike every other pane in the universe, I can't grab the pane and change
> its width ... I'm sure you have a good argument for why it can't be moved
> --- but that doesn't stop me from being annoyed ...
> >
> > Optimized code is often uglier than the cleanly crafted beautiful code
> that runs too damn slow ...
> >
> > I could go on and on, but I'm sure you've good reasons for all of the
> the things that you have changed and this isn't the only GUI in the world
> that is annoying to use :)
> >
> > Remember that I am still in the phase of "give it a little bit of time
> to "settle in" and see if my annoyance is due to the fact that things have
> changed or if the "old way was better" ... "
> >
> > Dale
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>


Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Tudor Girba
Hi Dale,

Thanks for your thoughts. And thanks for giving these new quirks time to settle 
:).

Actually, I am looking for what is annoying and I specifically interested in 
the reasons why it is annoying. Please feel free to report the bits that annoy 
you.

Cheers,
Doru



> On Aug 7, 2016, at 3:57 PM, Dale Henrichs  
> wrote:
> 
> 
> 
> On 8/7/16 6:16 AM, Tudor Girba wrote:
>> Hi Stef,
>> 
>> 
>> That is why we made the default printing not affect the text editor, and 
>> this feature is around since almost 2 years and, except of you, there was no 
>> other complain.
>> 
> I believe that this is a logical fallacy ... many developers are too busy 
> actually trying to do work with these tools and don't have time or 
> inclination to get involved in an argument :)
> 
> There are a number of odd, awkward, hidden, "old way does not work anymore" 
> things that I am running into as I have just been using Pharo5.0 for a couple 
> of months ... I understand that when the GUI changes one must give it a 
> little bit of time to "settle in" and see if my annoyance is due to the fact 
> that things have changed or if the "old way was better" ...
> 
> I don't like the funky popup prints either --- they often obscure the 
> underlying text and when I do something to see the underlying text I lose the 
> printout --- occasionally it is useful as a preview but that's not the only 
> use case .. often the result is what I want ...
> 
> But I am trying to do real work and I really don't have the time to get into 
> an embroiled argument over things so far I feel less productive (the debugger 
> buttons are a real annoyance) but perhaps with practice and patience I will 
> eventually see the light of putting heavily used menu items off in a corner 
> ...
> 
> BTW, I've basically given up on using browser shortcuts altogether ... I am 
> assuming that the shortcuts will be changing yet again in 6.0 so I'm not 
> going to try to memorize shortcuts that will be changing every 6 months :)
> 
> While I am complaining --- is there a way to be able to change the width of 
> the inspector panes in a debugger? I'm almost never able to see what I want 
> to see in the inspector panes because they aren't wide enough and unlike 
> every other pane in the universe, I can't grab the pane and change its width 
> ... I'm sure you have a good argument for why it can't be moved --- but that 
> doesn't stop me from being annoyed ...
> 
> Optimized code is often uglier than the cleanly crafted beautiful code that 
> runs too damn slow ...
> 
> I could go on and on, but I'm sure you've good reasons for all of the the 
> things that you have changed and this isn't the only GUI in the world that is 
> annoying to use :)
> 
> Remember that I am still in the phase of "give it a little bit of time to 
> "settle in" and see if my annoyance is due to the fact that things have 
> changed or if the "old way was better" ... "
> 
> Dale
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."







Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Dale Henrichs



On 8/7/16 6:16 AM, Tudor Girba wrote:

Hi Stef,


That is why we made the default printing not affect the text editor, and this 
feature is around since almost 2 years and, except of you, there was no other 
complain.

I believe that this is a logical fallacy ... many developers are too 
busy actually trying to do work with these tools and don't have time or 
inclination to get involved in an argument :)


There are a number of odd, awkward, hidden, "old way does not work 
anymore" things that I am running into as I have just been using 
Pharo5.0 for a couple of months ... I understand that when the GUI 
changes one must give it a little bit of time to "settle in" and see if 
my annoyance is due to the fact that things have changed or if the "old 
way was better" ...


I don't like the funky popup prints either --- they often obscure the 
underlying text and when I do something to see the underlying text I 
lose the printout --- occasionally it is useful as a preview but that's 
not the only use case .. often the result is what I want ...


But I am trying to do real work and I really don't have the time to get 
into an embroiled argument over things so far I feel less productive 
(the debugger buttons are a real annoyance) but perhaps with practice 
and patience I will eventually see the light of putting heavily used 
menu items off in a corner ...


BTW, I've basically given up on using browser shortcuts altogether ... I 
am assuming that the shortcuts will be changing yet again in 6.0 so I'm 
not going to try to memorize shortcuts that will be changing every 6 
months :)


While I am complaining --- is there a way to be able to change the width 
of the inspector panes in a debugger? I'm almost never able to see what 
I want to see in the inspector panes because they aren't wide enough and 
unlike every other pane in the universe, I can't grab the pane and 
change its width ... I'm sure you have a good argument for why it can't 
be moved --- but that doesn't stop me from being annoyed ...


Optimized code is often uglier than the cleanly crafted beautiful code 
that runs too damn slow ...


I could go on and on, but I'm sure you've good reasons for all of the 
the things that you have changed and this isn't the only GUI in the 
world that is annoying to use :)


Remember that I am still in the phase of "give it a little bit of time 
to "settle in" and see if my annoyance is due to the fact that things 
have changed or if the "old way was better" ... "


Dale




Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Tudor Girba
Hi Stef,

We had a thread on that two months ago, and it is still waiting for your 
answer. I made concrete proposals on which bindings can work. It would be more 
constructive to focus on those details (see more below).

First, one thing should get clarified. The case in which someone wants to print 
and persist inline the result is an edge case. For example, it happens when you 
want to write tests to document how the code is working currently. The typical 
case for using print-it is to get a sneak peak of what the object is and in 
this case, the requirement is specifically to not change the current code 
(especially when you are debugging you do not want to get the code dirty).

That is why we made the default printing not affect the text editor, and this 
feature is around since almost 2 years and, except of you, there was no other 
complain.

But, to come back to the concrete solution, as I mentioned before, I do agree 
that what you mention should be a supported use case. The only question is how 
to do it. So, let’s focus on that please.

One solution would be to have a different first level keybinding directly in 
the text editor, but that would not be a good idea because that space is 
already overloaded with too many key bindings, and this becomes a problem 
especially when you place an editor inside a larger tool (like a debugger) and 
you run out of available key bindings for other actions.

So, the proposals I had was like this:

Cmd+p ==> the print-it popup
- Enter ==> add as a comment
- Shift+Enter ==> add as plain text
- Cmd+v ==> add as plain text (this would not affect the text that was copied 
to clipboard)

Another option would be to change the meaning of the current Enter:

Cmd+p ==> the print-it popup
- Enter ==> add as a plain text
- Shift+Enter ==> add as comment


What do you think?

Cheers,
Doru


> On Aug 7, 2016, at 9:39 AM, stepharo  wrote:
> 
> Hi
> 
> Seriously I do not get why printing in the debugger cannot just print the 
> text without putting these ^%&*^*&()**(&%^*( double quote around.
> 
> Why do we change such basic functionality and in particular we do not propose 
> ANY alternative.
> 
> If you need a pop up and do not care of manipulating text this is ok but WHY 
> the default behavior has to be changed.
> 
> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& 
> flow is not mine.
> 
> Should I go and hack to get back the default behavior. WHY do I have to do 
> that?
> 
> Seriously.
> 
> Especially since the solution was super simple: introduce a new binding 
> living nicely close to PrintIt
> 
> but no "we have to change the default one with something that may fuck your 
> flow but who cares because
> 
> my flow is better."
> 
> Why do we get systematically this message? Why such changes are damaging TDD 
> practices without any notices?
> 
> May be I should use another Smalltalk at the end.
> 
> Stef
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."




Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread Ben Coman
On Sun, Aug 7, 2016 at 3:39 PM, stepharo  wrote:
> Hi
>
> Seriously I do not get why printing in the debugger cannot just print the
> text without putting these ^%&*^*&()**(&%^*( double quote around.

I believe the behaviour was introduced for the Workspace/Playground so
that inserting the result into the text wouldn't screw up the syntax
highlighting or running it again.  Perhaps this behaviour was
copied/inherited by the Debugger without considering it might be a
different use case.

??
cheers -ben

>
> Why do we change such basic functionality and in particular we do not
> propose ANY alternative.
>
> If you need a pop up and do not care of manipulating text this is ok but WHY
> the default behavior has to be changed.
>
> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(&
> flow is not mine.
>
> Should I go and hack to get back the default behavior. WHY do I have to do
> that?
>
> Seriously.
>
> Especially since the solution was super simple: introduce a new binding
> living nicely close to PrintIt
>
> but no "we have to change the default one with something that may fuck your
> flow but who cares because my flow is better."
>
> Why do we get systematically this message? Why such changes are damaging TDD
> practices without any notices?
>
> May be I should use another Smalltalk at the end.
>
> Stef
>
>



[Pharo-dev] when Cmd-P can just display a string in the debugger

2016-08-07 Thread stepharo

Hi

Seriously I do not get why printing in the debugger cannot just print 
the text without putting these ^%&*^*&()**(&%^*( double quote around.


Why do we change such basic functionality and in particular we do not 
propose ANY alternative.


If you need a pop up and do not care of manipulating text this is ok but 
WHY the default behavior has to be changed.


I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your 
&^%*^(& flow is not mine.


Should I go and hack to get back the default behavior. WHY do I have to 
do that?


Seriously.

Especially since the solution was super simple: introduce a new binding 
living nicely close to PrintIt


but no "we have to change the default one with something that may fuck 
your flow but who cares because


my flow is better."

Why do we get systematically this message? Why such changes are damaging 
TDD practices without any notices?


May be I should use another Smalltalk at the end.

Stef