[Pharo-project] Dealing with Preferences in external packages?
Now that setting is starting to get integrated (great) we will also face the problem of branching. For example, how do we manage that OB uses Preferences.... and that we don't. Any idea or process is welcome. Of course we can have a package full of override but this is the ultimate solution before complete fork. Stef
"Shared" settings will introduce another kind of package dependency... Perhaps there is some benefit of all settings being local to a package but cross-linked in some way such that the compatible preferences all change value at the same time in the settings browsers? There will always be some kind of compromise, one way or the other, but it might work ;-) Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, December 07, 2009 1:50 PM Subject: [Pharo-project] Dealing with Preferences in external packages?
Now that setting is starting to get integrated (great) we will also face the problem of branching. For example, how do we manage that OB uses Preferences.... and that we don't. Any idea or process is welcome.
Of course we can have a package full of override but this is the ultimate solution before complete fork.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You lost me gary :) On Dec 7, 2009, at 6:56 PM, Gary Chambers wrote:
"Shared" settings will introduce another kind of package dependency... Perhaps there is some benefit of all settings being local to a package but cross-linked in some way such that the compatible preferences all change value at the same time in the settings browsers?
There will always be some kind of compromise, one way or the other, but it might work ;-)
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, December 07, 2009 1:50 PM Subject: [Pharo-project] Dealing with Preferences in external packages?
Now that setting is starting to get integrated (great) we will also face the problem of branching. For example, how do we manage that OB uses Preferences.... and that we don't. Any idea or process is welcome.
Of course we can have a package full of override but this is the ultimate solution before complete fork.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I was thinking ahead to the point where there would be "shared" settings amongst disparate packages... would be nice to not introduce a superficail dependency. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, December 07, 2009 10:22 PM Subject: Re: [Pharo-project] Dealing with Preferences in external packages? You lost me gary :) On Dec 7, 2009, at 6:56 PM, Gary Chambers wrote:
"Shared" settings will introduce another kind of package dependency... Perhaps there is some benefit of all settings being local to a package but cross-linked in some way such that the compatible preferences all change value at the same time in the settings browsers?
There will always be some kind of compromise, one way or the other, but it might work ;-)
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, December 07, 2009 1:50 PM Subject: [Pharo-project] Dealing with Preferences in external packages?
Now that setting is starting to get integrated (great) we will also face the problem of branching. For example, how do we manage that OB uses Preferences.... and that we don't. Any idea or process is welcome.
Of course we can have a package full of override but this is the ultimate solution before complete fork.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
That's a serious problem, but given that OmniBrowser is pretty modular I guess that the preferences can be factored out into an OBPharoPlatform. Lukas 2009/12/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Now that setting is starting to get integrated (great) we will also face the problem of branching. Â Â Â Â For example, how do we manage that OB uses Preferences.... and that we don't. Â Â Â Â Any idea or process is welcome.
Of course we can have a package full of override but this is the ultimate solution     before complete fork.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
would be nice. On Dec 7, 2009, at 7:11 PM, Lukas Renggli wrote:
That's a serious problem, but given that OmniBrowser is pretty modular I guess that the preferences can be factored out into an OBPharoPlatform.
Lukas
2009/12/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Now that setting is starting to get integrated (great) we will also face the problem of branching. For example, how do we manage that OB uses Preferences.... and that we don't. Any idea or process is welcome.
Of course we can have a package full of override but this is the ultimate solution before complete fork.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Gary Chambers -
Lukas Renggli -
Stéphane Ducasse