Issue 4762 in pharo: Should we reintroduce AutoStart

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 4762 in pharo: Should we reintroduce AutoStart

pharo
Status: Accepted
Owner: [hidden email]
Labels: Milestone-1.4

New issue 4762 by [hidden email]: Should we reintroduce AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

AutoStart and AbstractLaucnher were removed. should we reintroduced them?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4762 in pharo: Should we reintroduce AutoStart

pharo

Comment #1 on issue 4762 by [hidden email]: Should we reintroduce  
AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

no.

As in example with XMLRPC package, an AutoStart were used as a default  
insertion point, where startup for this package should happen.
But it doesn't requires an exact place/order for startup, and this package  
can startup sooner or later.
Very few packages requiring an ordering in startup and i think that  
AutoStart were served as a default anchor point for startup code, where  
people was uncertain, which order should be there.
But for just statup (without any specific order), they can simply use
Smalltalk addToStartup: ..
but not
addToStartup: after:




_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4762 in pharo: Should we reintroduce AutoStart

pharo

Comment #2 on issue 4762 by [hidden email]: Should we reintroduce  
AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

AbstractLauncher is another matter though, no?
Rewriting it a bit to not use AutoStart, but rather register in startup  
list using addToStartup: , so custom subclasses which used its  
functionality to be added to the startup list continue to work shouldn't be  
a big problem?



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4762 in pharo: Should we reintroduce AutoStart

pharo
Updates:
        Cc: [hidden email]

Comment #3 on issue 4762 by [hidden email]: Should we reintroduce  
AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

the problem is that abstract laucnher was used for the commandline and we  
rewrote it.
Now I would like to collect changes from coral so that we have a solid  
solution once for all.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4762 in pharo: Should we reintroduce AutoStart

pharo
Updates:
        Labels: Type-Feature

Comment #4 on issue 4762 by [hidden email]: Should we reintroduce  
AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Reply | Threaded
Open this post in threaded view
|

Re: Issue 4762 in pharo: Should we reintroduce AutoStart

pharo
Updates:
        Status: Closed

Comment #5 on issue 4762 by [hidden email]: Should we reintroduce  
AutoStart
http://code.google.com/p/pharo/issues/detail?id=4762

I would not...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker