Re: [Pharo-users] Trapping the Pharo window close event

[John Pfersich]

> On Apr 16, 2016, at 03:30, Damien Pollet  
> wrote:
> 
>> On 16 April 2016 at 11:33, kmo  wrote:
>> /Pharo is yours, so you can add it. :)/
>> 
>> Yes, but I don't want to add it. I expect it to be there out of the box.
> 
> If you expect a perfect system out of the box, you will never get it.
>  
>> think it's quite enough work for me to add my own code on window close. I
>> don't want to have to write the framework for doing it as well.
> 
> Point is, it's not by design if the feature you're asking for is absent out 
> of the box; nobody in Pharo decided you should HAVE to implement it yourself. 
> I think everyone agrees that the platform should provide that feature, 
> however everyone is focused on different issues, and you seem to be the first 
> one for whom it's an itch worth scratching. It's open-source, so the system 
> is yours too and it's the responsibility of everyone to improve it.
> 
> If you really need the feature but don't want to implement it yourself, you 
> could sponsor someone via the Pharo association or the consortium.

Or Bountysource or Bountysource Salt 
(https://salt.bountysource.com/teams/pharo).

Re: [Pharo-users] List with Border

[peaslee]

> PluggableListMorph>borderStyleToUse
> "Answer the borderStyle that should be used for the receiver."
>
> ^self enabled
> ifTrue: [self theme listNormalBorderStyleFor: self]
> ifFalse: [self theme listDisabledBorderStyleFor: self]
>
> If you then look at the different implementors of borderStyleToUse,
> you'll notice that there are a lot of them that only ask the theme for
> a style.
>
Stephan


This last bit solved my problem for now. I had no luck with the subclass,
etc., but I changed this method to dropListNormalBorderStyleFor:That
gives me a border. ;>)



--
View this message in context: 
http://forum.world.st/List-with-Border-tp4889556p4890356.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] [Pharo-dev] GTDebugger shortcuts usability

[Peter Uhnák]

>
> Let’s turn this energy into something positive. Please propose a concrete
> set of default keybindings that you think would work better. In this
> process, please take into account all keybindings that are already defined
> in the code editor (it might not be so easy as it appears).
>

As I've said:

1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
2. can we use the default shortcuts pattern where one of the letters is
underlined?

as for the shortcuts themselves, problem is proceed, restart & into

proceed: ctrl+shift+p is not taken, so I don't see why it has shortcut
confusing with restart
restart: ctrl+shift+r indents, but I'd argue that uniformity is more
important here... indent is just convenience
into: ctrl+shift+i is taken (I've never used it, but it maybe it's
important), but we can still use ctrl+shift+n and underline n (point 2)

If points 1 & 2 are implemented, then the letter is not as important,
although first letter is always preferable.

Peter


> Cheers,
> Doru
>
>
> > On Apr 16, 2016, at 8:37 PM, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > I'm getting fed-up with GTDebugger shortcuts since they are completely
> random.
> >
> > Can we have them more meaningful and/or somehow visible?
> >
> > For now I ended up overriding the labels so I can at least see them...
> but doing this is also stupid, because I still have to look at them since I
> cannot remember random shortcuts.
> >
> > 
> > ​
> > 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
> > 2. can we use the default shortcuts pattern where one of the letters is
> underlined?
> >
> > Peter
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Value is always contextual."
>
>
>
>
>
>

Re: [Pharo-users] [Pharo-dev] GTDebugger shortcuts usability

[Tudor Girba]

Hi Peter,

Let’s turn this energy into something positive. Please propose a concrete set 
of default keybindings that you think would work better. In this process, 
please take into account all keybindings that are already defined in the code 
editor (it might not be so easy as it appears).

Cheers,
Doru


> On Apr 16, 2016, at 8:37 PM, Peter Uhnák  wrote:
> 
> Hi,
> 
> I'm getting fed-up with GTDebugger shortcuts since they are completely random.
> 
> Can we have them more meaningful and/or somehow visible?
> 
> For now I ended up overriding the labels so I can at least see them... but 
> doing this is also stupid, because I still have to look at them since I 
> cannot remember random shortcuts.
> 
> 
> ​
> 1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
> 2. can we use the default shortcuts pattern where one of the letters is 
> underlined?
> 
> Peter

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

"Value is always contextual."

Re: [Pharo-users] RBAddClassRefactoring ensuring existence

[Nicolai Hess]

2016-04-16 20:59 GMT+02:00 Peter Uhnák :

> Hi,
>
> is it possible to "ensure" that class exists with RBAddClassRefactoring?
>
> Right now RBAddClassRefactoring will throw up if the class already exists.
>
> I would like it to create the class if it doesn't exist and just do
> nothing if it already exists.
>
> Is it possible? (if not I will just work around it on my side).
>
> Thanks,
> Peter
>


The ugly way:

[ refactoring execute ] on: RBRefactoringError do:[:ex | ex resume].

[Pharo-users] Merging refactoring changes

[Peter Uhnák]

Is it possible to merge changesets?

For example when I am creating a new class and adding a new instance
variable, I would like to see it as one change set, not two.

Similarly if I am overriding a method twice, it would be good to see only
what actually gets applied.

For example

~
"
Sandbox removeFromSystem.
"
(model := RBNamespace new)
name: 'ChangeSet'.

r1 := RBAddClassRefactoring
model: model
addClass: #Sandbox superclass: Object subclasses: #() category: #Sandbox.
r1 primitiveExecute.

r2 := RBAddInstanceVariableRefactoring
model: model
variable: 'attr'
class: #Sandbox.
r2 primitiveExecute.

r3 := RBAddMethodRefactoring
model: model
addMethod: 'attr' toClass: #Sandbox inProtocols: 'accessing'.
r3 transform.

r4 := RBAddMethodRefactoring
model: model
addMethod: 'attr
^ attr' toClass: #Sandbox inProtocols: 'accessing'.
r4 transform.

(ChangesBrowser changes: model changes changes) open.
~

I will get four changes


​
But the second (top right) could be merged into the first one, and the
third one (bottom left) is superfluous.

So ideally I would like to have


​

Is it possible to merge it in such a way?

Thanks,
Peter

[Pharo-users] GTDebugger shortcuts usability

[Peter Uhnák]

Hi,

I'm getting fed-up with GTDebugger shortcuts since they are completely
random.

Can we have them more meaningful and/or somehow visible?

For now I ended up overriding the labels so I can at least see them... but
doing this is also stupid, because I still have to look at them since I
cannot remember random shortcuts.


​
1. can we unify the shift vs ctrl+shift nonsense? (I'm using linux btw)
2. can we use the default shortcuts pattern where one of the letters is
underlined?

Peter

Re: [Pharo-users] [ANN] Introspect web content (Soup with some GT extensions)

[Siemen Baader]

On Thu, Apr 14, 2016 at 1:01 PM, Torsten Bergmann  wrote:

> Hi,
>
> I added a few GT inspector extensions to Soup and cleaned up a little bit.
> Released as a new version 1.8 of Soup - you will find easily in Catalog
> for Pharo 5 or by opening Spotter and entering "Soup" to load.
>

That is very nice, thanks!

-- Siemen

Re: [Pharo-users] Dawn Theme on Pharo 4.0

[Siemen Baader]

Hi again,

I have cloned the Pharo3DawnTheme on github and updated the installation
instructions to work for Pharo 4.0. It is on
https://github.com/siemenbaader/Pharo3DawnTheme.

Would it be better for the community to use Smalltalkhub, or is Github the
new thing people prefer?

Have a nice weekend all,

Siemen


On Wed, Apr 13, 2016 at 11:56 AM, Siemen Baader 
wrote:

>
>
> On Tue, Apr 12, 2016 at 8:54 PM, stepharo [via Smalltalk] <
> ml-node+s1294792n4889618...@n4.nabble.com> wrote:
>
>> Super!
>> Could you publish it somewhere because for my vision I cannot use the
>> dark theme.
>>
>
>
> Sure - I'll do that. I'm new to Pharo and have to look a bit into how, but
> I can make a fork on github and update the installation instructions or
> publish a package for pharo4 on Smalltalkhub. Do you prefer either site?
>
> -- Siemen
>
>
>
>> I cannot see what is written in red :).
>>
>> Stef
>>
>> Le 12/4/16 20:47, Siemen Baader a écrit :
>>
>> On Tue, Apr 12, 2016 at 7:43 PM, stepharo <[hidden email]
>> > wrote:
>>
>>> Check the code because it should just be a subclass of the dark theme
>>> with different colors.
>>>
>>> Stef
>>>
>>
>> Thanks, that helped me to adapt the instructions and make it work!
>>
>> -- Siemen
>>
>>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4889618.html
>> To unsubscribe from Dawn Theme on Pharo 4.0, click here
>> 
>> .
>> NAML
>> 
>>
>
>




--
View this message in context: 
http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541p4890307.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Pharo-users] RBRefactoring docs

[Peter Uhnák]

Hi,

is there any documentation for RBRefactoring?
Since there are not even class comments the only thing I found is judging
from tests.

Thanks,
Peter

Re: [Pharo-users] First impressions, was About Box

[Cyril Ferlicot]

On Saturday, 16 April 2016, Alistair Grant  wrote:
>
>
> Thanks.  I had started reading Pharo by Example, but it looks like Deep
> into Pharo is more up to date.
>
>
A new version of PBE is almost ready. You can find it at
https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result/UpdatedPharoByExample.pdf
 .
Other formats
https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/book-result



> Thanks again,
> Alistair
>
>
>From my phone~~


-- 
Cheers
Cyril Ferlicot

Re: [Pharo-users] First impressions, was About Box

[Alistair Grant]

On Thu, Apr 14, 2016 at 08:37:39AM +0200, stepharo wrote:
> Have a look at the chapter about command handler in Deep into Pharo
> because you have all you need
> 
> You can script the loading and execution of expressions easily.
> 
> People like julien, damien at Pharodays started to resume a better DSL for
> command descriptions.

Thanks.  I had started reading Pharo by Example, but it looks like Deep
into Pharo is more up to date.

Thanks again,
Alistair

Re: [Pharo-users] Trapping the Pharo window close event

[kmo]

Well, my reply was rather tongue-in-cheek. I was mocking my own laziness and
the laziness of developers like me. But really I have no problem in doing
these things for myself. And I hope that soon I will be in a position to
contribute to pharo myself.

But overriding the close event is something any application developer is
going to want to do. And every time you make a developer work harder than
necessary to implement a basic feature you make the pharo platform less
attractive. If you want more developers to use pharo you have to make basic
things like this easy to do and easy to find out how to do.

I do think that deployment of applications gets very little attention in
pharo - yet it's a major issue of you want to make pharo a widely-used
application platform.

I'm not the only lazy developer, you know .



--
View this message in context: 
http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890285.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Trapping the Pharo window close event

[Damien Pollet]

On 16 April 2016 at 11:33, kmo  wrote:

> /Pharo is yours, so you can add it. :)/
>
> Yes, but I don't want to add it. I expect it to be there out of the box.
>

If you expect a perfect system out of the box, you will never get it.


> think it's quite enough work for me to add my own code on window close. I
> don't want to have to write the framework for doing it as well.
>

Point is, it's not by design if the feature you're asking for is absent out
of the box; nobody in Pharo decided you should HAVE to implement it
yourself. I think everyone agrees that the platform should provide that
feature, however everyone is focused on different issues, and you seem to
be the first one for whom it's an itch worth scratching. It's open-source,
so the system is yours too and it's the responsibility of everyone to
improve it.

If you really need the feature but don't want to implement it yourself, you
could sponsor someone via the Pharo association or the consortium.

Re: [Pharo-users] Trapping the Pharo window close event

[kmo]

/Pharo is yours, so you can add it. :)/

Yes, but I don't want to add it. I expect it to be there out of the box. I
think it's quite enough work for me to add my own code on window close. I
don't want to have to write the framework for doing it as well.



--
View this message in context: 
http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890283.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Trapping the Pharo window close event

[Peter Uhnák]

Ah, right, that certainly sounds interesting. :)

Pharo is yours, so you can add it. :)
We already have a SystemAnnouncer so maybe it would be quite easy to add…
it might be a nice exercise to get a bit more familiar with the system.

Peter

On Sat, Apr 16, 2016 at 11:01 AM, kmo  wrote:

> The Dolphin approach was described by Estaban earlier in this thread. I've
> never used Dolphin myself so cannot expand on it.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890281.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Trapping the Pharo window close event

[kmo]

The Dolphin approach was described by Estaban earlier in this thread. I've
never used Dolphin myself so cannot expand on it.



--
View this message in context: 
http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890281.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Trapping the Pharo window close event

[Peter Uhnák]

What's Doplin's approach?

Also adding a configuration option for this situation is rather trivial.

On Sat, Apr 16, 2016 at 9:42 AM, kmo  wrote:

> As a developer you need to be able to control the program shut down. That
> is
> a given.
>
> I think I was expecting something like the Dolphin approach but it doesn't
> exist in pharo. Having to overwrite an existing method is not elegant but
> it
> works.
>
> A similar issue exists with Growl notifications - I have a post on this as
> well.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890279.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Trapping the Pharo window close event

[kmo]

As a developer you need to be able to control the program shut down. That is
a given.

I think I was expecting something like the Dolphin approach but it doesn't
exist in pharo. Having to overwrite an existing method is not elegant but it
works.

A similar issue exists with Growl notifications - I have a post on this as
well.



--
View this message in context: 
http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079p4890279.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Turning off Growl notifications

[kmo]

Thanks for taking a look.

It's not good that there is no easy way. If you are deploying an application
to a user you will almost certainly want to run some kind of startup script
- and you will want to suppress any messages.

Looking at the code I think I can probably overwrite an inform method
somewhere which should do the trick. But it's not an elegant solution. 



--
View this message in context: 
http://forum.world.st/Turning-off-Growl-notifications-tp4890227p4890278.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.