[Pharo-project] Monticello Changes Dialog
Is there a clean way to get back the original changes dialog of Monticello? The new dialog looks cool, but for me it is totally inefficient. - I don't have an overview of the applied changes anymore. It is very painful to review a big set of changes where everything is hidden inside a tree that I have to traverse manually. - Another problem is the arrangement of the panes. Even if I work on a screen that is 2560 pixel wide there are many methods that get clipped at the right side. It is impossible to review changes in long lines. - Also I cannot easily browse the involved classes. In the old dialog I could press Apple+B on any item and it opened a browser on the particular class/method. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Remember for trees - you can right-click on an arrow to expand all at that level. Pane arrangement - line-by-line comparison isn't really possible in any other arrangement. Keys are a problem with ParagraphEditor being all or nothing... Polymorph-Tools-Diff-gvc.10 adds a preference: useNewDiffToolsForMC just for you! (apologies for my email name in CAPITALS, the webmail won't let me change it!) Regards, Gary. ________________________________ From: Lukas Renggli <renggli@gmail.com> To: Pharo Development <pharo-project@lists.gforge.inria.fr> Sent: Tuesday, 3 February, 2009 8:44:36 AM Subject: [Pharo-project] Monticello Changes Dialog Is there a clean way to get back the original changes dialog of Monticello? The new dialog looks cool, but for me it is totally inefficient. - I don't have an overview of the applied changes anymore. It is very painful to review a big set of changes where everything is hidden inside a tree that I have to traverse manually. - Another problem is the arrangement of the panes. Even if I work on a screen that is 2560 pixel wide there are many methods that get clipped at the right side. It is impossible to review changes in long lines. - Also I cannot easily browse the involved classes. In the old dialog I could press Apple+B on any item and it opened a browser on the particular class/method. Cheers, Lukas -- 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
Remember for trees - you can right-click on an arrow to expand all at that level.
Ok, didn't know that one.
Pane arrangement - line-by-line comparison isn't really possible in any other arrangement.
Maybe show the tree above? Or replace it with a flat list?
Polymorph-Tools-Diff-gvc.10 adds a preference: useNewDiffToolsForMC just for you!
Excellent, thank you very much. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I will integrate soon. On Feb 3, 2009, at 2:39 PM, GARY CHAMBERS wrote:
Remember for trees - you can right-click on an arrow to expand all at that level. Pane arrangement - line-by-line comparison isn't really possible in any other arrangement. Keys are a problem with ParagraphEditor being all or nothing...
Polymorph-Tools-Diff-gvc.10 adds a preference: useNewDiffToolsForMC just for you!
(apologies for my email name in CAPITALS, the webmail won't let me change it!)
Regards, Gary.
From: Lukas Renggli <renggli@gmail.com> To: Pharo Development <pharo-project@lists.gforge.inria.fr> Sent: Tuesday, 3 February, 2009 8:44:36 AM Subject: [Pharo-project] Monticello Changes Dialog
Is there a clean way to get back the original changes dialog of Monticello?
The new dialog looks cool, but for me it is totally inefficient.
- I don't have an overview of the applied changes anymore. It is very painful to review a big set of changes where everything is hidden inside a tree that I have to traverse manually.
- Another problem is the arrangement of the panes. Even if I work on a screen that is 2560 pixel wide there are many methods that get clipped at the right side. It is impossible to review changes in long lines.
- Also I cannot easily browse the involved classes. In the old dialog I could press Apple+B on any item and it opened a browser on the particular class/method.
Cheers, Lukas
-- 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code. Instead of having the current situation ie MyTool>>doSomething .... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj] and not been able to remove the preferences (or that the preference is just a configuration layer). I would like to have the preference made that way MyTool class>>useNewDiff MyTool class>> useOldDiff **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! Preferences useNewDiffTool MyTool useNewDiff I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so. Stef
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are. The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks... So, in new scheme (no dependency on Preferences) the doSomething might be: self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj] and MyTool class>>preferences would answer something suitable for a preference browser. Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands... ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
Why not use pragmas on accessors of the class side that would be picked up by the preference browser? Then all state would be local to the affected code. Something along these lines: MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean <preference: 'Show advanced diff tool' group: 'Monticello' type: #Boolean> advancedDiffTool := aBoolean Lukas On Wed, Feb 4, 2009 at 5:50 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands...
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class
Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
_______________________________________________ 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
Yes this would be much better. stef On Feb 4, 2009, at 5:57 PM, Lukas Renggli wrote:
Why not use pragmas on accessors of the class side that would be picked up by the preference browser? Then all state would be local to the affected code.
Something along these lines:
MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean <preference: 'Show advanced diff tool' group: 'Monticello' type: #Boolean>
advancedDiffTool := aBoolean
Lukas
On Wed, Feb 4, 2009 at 5:50 PM, Gary Chambers <gazzaguru2@btinternet.com
wrote: Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands...
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class
Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
_______________________________________________ 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
Sorry gary you lost me. I do not get change informee. On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote:
Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands...
If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference). Stef
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class
Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
See Preference>>preferenceValue: (that is what happens when a preference is changed). This sends notifyInformeeOfChange which can perform a zero argument selector on the "model" object/class which then eventually has to query Preferences for the value. See senders of, for instance, #addPreference:categories:default:balloonHelp:projectLocal:changeInformee:changeSelector:viewRegistry: and their associated changeSelectors. This is how things are at the moment. Lukas' idea about pragmas is nice, essentially the same as a discovery interface. Either way the PreferenceBrowser would need changing. Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 8:55 PM Subject: Re: [Pharo-project] About Preference Flow: was Re:MonticelloChangesDialog Sorry gary you lost me. I do not get change informee. On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote:
Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands...
If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference). Stef
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class
Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
_______________________________________________ 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
Thanks I will have a look. stef On Feb 5, 2009, at 10:48 AM, Gary Chambers wrote:
See Preference>>preferenceValue: (that is what happens when a preference is changed). This sends notifyInformeeOfChange which can perform a zero argument selector on the "model" object/class which then eventually has to query Preferences for the value. See senders of, for instance, #addPreference:categories:default:balloonHelp:projectLocal:changeInformee:changeSelector:viewRegistry : and their associated changeSelectors.
This is how things are at the moment.
Lukas' idea about pragmas is nice, essentially the same as a discovery interface. Either way the PreferenceBrowser would need changing.
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 8:55 PM Subject: Re: [Pharo-project] About Preference Flow: was Re:MonticelloChangesDialog
Sorry gary you lost me. I do not get change informee.
On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote:
Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands...
If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference).
Stef
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog
On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote:
Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are.
no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime.
The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks...
No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow.
So, in new scheme (no dependency on Preferences) the doSomething might be:
self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools.
and MyTool class>>preferences
would answer something suitable for a preference browser.
Could be but the package could also install the preferences in the preferences class
Stef
Regards, Gary.
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog
Gary
I have a request about the way we use preference. And this is kind of really really important if we want to stop having spaghetti code.
Instead of having the current situation ie
MyTool>>doSomething
.... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj]
and not been able to remove the preferences (or that the preference is just a configuration layer).
I would like to have the preference made that way
MyTool class>>useNewDiff
MyTool class>> useOldDiff
**NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!!
Preferences useNewDiffTool MyTool useNewDiff
I really think that we can do it that way and this way we would have a much more object-oriented system Do you think that this is possible with polymorph? I think so.
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
_______________________________________________ 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
participants (4)
-
GARY CHAMBERS -
Gary Chambers
-
Lukas Renggli -
Stéphane Ducasse