headers
John M McIntosh | 1 Nov 2008 04:48

Re: mac menus in Pharo

For Scratch we made a change to terminate the VM if you logout
There is an info.plist setting SqueakQuitOnQuitAppleEvent which if set  
to true terminates the VM at logout time, no save.

Likely this is NOT what you want, we could {if people want} pass up an  
event for the logout, and see what happens.
I think there is something maybe for closing the main window on Windows?
Not sure about sleep tho, don't really reading anything about getting  
an event when the user sleeps the system.

On Oct 31, 2008, at 4:13 PM, Michael Roberts wrote:

> very much so yes!
>
> also, how hard would it be to hook into sleep and logout style events
> on the mac?  it would be nice if pharo was aware of that but I don't
> know what is required.  Did you need/solve that in Sophie?
>
> Mike
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@...
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
= 
= 
= 
========================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
John M McIntosh | 1 Nov 2008 05:59

Re: mac menus in Pharo


On Oct 31, 2008, at 1:28 PM, Marcus Denker wrote:

>
> On 31.10.2008, at 21:18, John McIntosh wrote:
>
>> I'm wondering if there is any interest in having mac menus in Pharo.
>> This was done for Sophie
>> and Scratch, and attempted for 3.10. I could drag the required change
>> sets out of storage to
>> implement the proper file/edit menu in Pharo and have it respond to
>> cmd-Q etc if there is
>> any interest...
>
> Yes! I want all the things that are in the new simple world-menu in
> a "real" menu.
>
> 	Marcus

Done (I think)

Next time I'm at ESUG I must stay more than 5 hours so that people can  
buy me some beer.

I've posted pharo10124WithMacMenus.1.image to my idisk
in the /experimental/Pharo/  folder
found via http://www.smalltalkconsulting.com/squeak.html

Macintosh users can take it for a spin.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 09:33
Picon
Picon
Favicon
Gravatar

Re: [update] #1025

What a good feeling to have methods that were obsolete since 10 years  
removed from the system
(I was idiot to believe that they were used...)

Marcus did you change the GC parameters as mentioned by john.

Stef

On Oct 31, 2008, at 8:23 PM, Marcus Denker wrote:

> update1025
> ---------
>
> Issue 303:	TODO: remove profiling methods
> Issue 300:	unimplemented call in  
> AlignmentMorphBob1>>acceptDroppingMorph:event:
> Issue 299:	Mantis 007007 and 007008 correct toggle break on entry
>
>
> --
> Marcus Denker  --  denker@...
> http://www.iam.unibe.ch/~denker
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@...
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 09:37
Picon
Picon
Favicon
Gravatar

Re: We will not accept any changes using initials anymore


> I was looking around at the Author class when issue: 209 was created.
> I noticed there was inconsistency with the way it tests whether the
> initials were present or not (string vs nil).  I have a changeset for
> that which I was planning to upload.  Are you going to deprecate the
> whole class or just the use of initials?
>
> My thoughts were to deprecate the concept of initials, and just put
> the full name in the same place in the method timestamp.  That way you
> would not impact too much at once.  There is a full name, but from
> what I saw that was only related to projects, and you're going to kill
> projects right?
>
> what do you think?

yes project out!
we should not have initials anymore.
The Author class should just be cleaned up a bit and its senders.

We can enter first.name -> firstname / name in author
and use full name the way we want (camel or not)
what lukas did is to make sure that you cannot enter
zork <at>  <at> #$Plys and that MC gets dead because you cannot create a file with
one of the given character.

Stef

>
>
> cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 09:38
Picon
Picon
Favicon
Gravatar

Re: mac menus in Pharo

+ 100

Stef

On Oct 31, 2008, at 10:47 PM, Lukas Renggli wrote:

> Yes, I would like to have that too.
>
> Lukas
>
> On Fri, Oct 31, 2008 at 9:28 PM, Marcus Denker <denker@...>  
> wrote:
>>
>> On 31.10.2008, at 21:18, John McIntosh wrote:
>>
>>> I'm wondering if there is any interest in having mac menus in Pharo.
>>> This was done for Sophie
>>> and Scratch, and attempted for 3.10. I could drag the required  
>>> change
>>> sets out of storage to
>>> implement the proper file/edit menu in Pharo and have it respond to
>>> cmd-Q etc if there is
>>> any interest...
>>
>> Yes! I want all the things that are in the new simple world-menu in
>> a "real" menu.
>>
>>       Marcus
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 09:41
Picon
Picon
Favicon
Gravatar

Re: mac menus in Pharo

>>
> Done (I think)
>
> Next time I'm at ESUG I must stay more than 5 hours so that people  
> can buy me some beer.

Oh Yes!
The next ESUG can really be a huge hacking camp so please book the  
dates :)

> I've posted pharo10124WithMacMenus.1.image to my idisk
> in the /experimental/Pharo/  folder
> found via http://www.smalltalkconsulting.com/squeak.html
>
> Macintosh users can take it for a spin.
>
> I note we should have a more *generic* way to convert morphic menus  
> to the structure needed for macintosh menus
> but it took me a couple of hours to figure out how to make the  
> hierarchy mac menus since I've not done that before, plus
> I wasted some time looking at the complicated target, argument,  
> selector mess on the morphic menu item before

what you are criticizing this piece of art :)

>
> discovering *doButtonAction* did the required menu activation trick  
> on the mophic menu item.
>
> Perhaps someone clever can figure out how to read all the morphic
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 09:50
Picon
Picon
Favicon
Gravatar

Preferences should be optional: aka towards reall OOP preferences

Hi all

Here is a call for good design sharing. I already posted a mail on  
that design issue but I want to restate it.

I really want in the future to be able to remove Preferences (we need  
preferences but not the way they are).

	right now when I'm LittApp an application
	and run my little flow
	I will suddenly invoke the HUGE Global center (Preferences) to see  
what **I** have to do....

So at the end of the day we got, debugger, compiler, Morphic....  
depending on preferences and this is WRONG.

What we should have (illustrated really well with the MC sorting menu)  
is

LittApp is responsible for its own preferences

	So it runs, and check **Itself**: "oh how should I behave, let me see  
***my own*** state
	tell me to turn right, to be novice friendly...
	and I do it.

Notice how little application does NOT reference to the HUGE  
Preference Global
Now the BIG Preferences setter will just change the configuration of  
the little app.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lukas Renggli | 1 Nov 2008 10:21
Picon
Gravatar

Re: RBParser

On Fri, Oct 31, 2008 at 10:42 AM, Gwenael Casaccio <mrgwen@...> wrote:
> I've commit a new version I've removed all the RB*Token

I've loaded your changes, but it seems to break the refactoring
browser. All literals (numbers, symbols, true, false, nil, ...) are
printed as strings ('123', '#foo', 'true', 'false', ...). Did I forget
to load something, or is this a bug?

Cheers,
Lukas

>
> On 10/29/08 6:21 PM, Lukas Renggli wrote:
>>>
>>> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've
>>> fixed these classes and now you can parse the entire image. At this
>>> moment
>>> the refactoring is not yet finished but I've made some good progress.
>>
>> Good news.
>>
>> I was not aware that you were working on RBParser. Stef told me that
>> you also improved the refactorings. I think you should commit and work
>> on the public repository to get more attention. I guess there were
>> many other changes going on in RB codebase in the meantime.
>>
>> Cheers,
>> Lukas
>>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandre Bergel | 1 Nov 2008 10:48
Picon

Re: How to load OmniBrowser into Pharo

Excellent David,

Cheers,
Alexandre

On 30 Oct 2008, at 10:12, David Röthlisberger wrote:

> Hi,
>
>
> during the recent days we worked hard on OmniBrowser to extend,  
> improve and stabilize it.
>
> We also improved the loading process of all required packages to run  
> OmniBrowser (system and package browser).
>
> In the latest version of ScriptLoader you will find three load  
> methods for OB:
>
> #loadOB
> loads the latest stable version linked in Universe. Use this to be  
> on the safe side
>
> #loadOBAlpha
> loads the latest development version of all required packages stored  
> in source.wiresong.ca/ob. Use this if you want to be on the cutting  
> edge. ;)
>
> #loadSuperOB
> does the same as #loadOBAlpha, but also loads additional packages,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Ducasse | 1 Nov 2008 12:46
Picon
Picon
Favicon
Gravatar

about timesRepeat: changes?

Hi

one person is saying the following in the seaside mailinglist

"In Pharo, some OmniBrowser functionality was broken and as I said  
timesRepeat: was broken. It had a '<' rather than '<=' for the loop  
comparison so the loop ran one too few times. I ran an update which  
fixed both problems.  "

Does one of you remember that we got a change changing timesRepeat:

I have serious doubts this is why I"m asking.

stef
Permalink | Reply | 0 comments |

Gmane