[Pharo-project] Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz
Sent to you by Damien via Google Reader: Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz via PharoInbox on 9/8/09 This fix stops MC from asking for a log message for every dependent of the package that you are saving. Instead, it re-uses the log message from the parent. Is it necessary to offer a checkbox in the parent's save dialogue to ask if this is the desired behaviour? Things you can do from here: - Subscribe to PharoInbox using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites
Damien skrev:
Sent to you by Damien via Google Reader:
Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz <http://www.squeaksource.com/PharoInbox.html>
via PharoInbox <http://www.squeaksource.com/> on 9/8/09
Is it necessary to offer a checkbox in the parent's save dialogue to ask if this is the desired behaviour?
With the current behaviour, I'd say no. If you try to cancel the extra dialogs, it leads to an error and unloadable slices... Better then with an atomic operation that is either done or not, and having the comment behaviour forced. Ideally, I think it'd be nice to have an "apply to all" checkbox, and if not checked, change it so comments are all set before anything is stored. (using the comment for the "top" package as default) Cheers, Henry
Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz <http://www.squeaksource.com/PharoInbox.html>
via PharoInbox <http://www.squeaksource.com/> on 9/8/09
Is it necessary to offer a checkbox in the parent's save dialogue to ask if this is the desired behaviour?
With the current behaviour, I'd say no.
If you try to cancel the extra dialogs, yes this is what we tried to achieve
it leads to an error and unloadable slices...
really because we tried and it worked. do you have a scenario showing that it breaks?
Better then with an atomic operation that is either done or not, and having the comment behaviour forced. Ideally, I think it'd be nice to have an "apply to all" checkbox, and if not checked, change it so comments are all set before anything is stored. (using the comment for the "top" package as default)
Yes the problem is that MC uses its own widgetspec and there is no support for checkbox
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse skrev:
Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz <http://www.squeaksource.com/PharoInbox.html>
via PharoInbox <http://www.squeaksource.com/> on 9/8/09
Is it necessary to offer a checkbox in the parent's save dialogue to ask if this is the desired behaviour?
With the current behaviour, I'd say no.
If you try to cancel the extra dialogs,
yes this is what we tried to achieve
it leads to an error and unloadable slices...
really because we tried and it worked. do you have a scenario showing that it breaks Yes, the slice "fixes" this, since you never get the dialog to write a comment for one of the dependent packages, thus are never able to cancel it :) My point was, ideally, I'd like to be able to set individual comments for each package if I want to(checkbox), and not have it break if I cancel one of the later ones. And that, if I had to choose between being able to set comment per package but risking an incomplete save if I cancel one of them, and having the same comment for all of them, I'd rather have the latter.
Cheers, Henry
Ok I got you right now. :)
really because we tried and it worked. do you have a scenario showing that it breaks Yes, the slice "fixes" this, since you never get the dialog to write a comment for one of the dependent packages, thus are never able to cancel it :) My point was, ideally, I'd like to be able to set individual comments for each package if I want to(checkbox), and not have it break if I cancel one of the later ones. And that, if I had to choose between being able to set comment per package but risking an incomplete save if I cancel one of them, and having the same comment for all of them, I'd rather have the latter.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ideally, what I think we want is for all of the packages to be written atomically. However, that is something that MC does not currently know how to do. Next best would be to collect all of he log messages ahead of doing any of the writing to the repository. That would also require some major changes, but at least I can see how to do it. Providing the checkbox is s mere matter of morphic programming ... perhaps, if the box is not checked, and the user cancels one of the ensuing dialogs, the behaviour should be to reuse the log message from the Slice? Andrew On 8 Sep 2009, at 11:39, Henrik Johansen wrote:
My point was, ideally, I'd like to be able to set individual comments for each package if I want to(checkbox), and not have it break if I cancel one of the later ones. And that, if I had to choose between being able to set comment per package but risking an incomplete save if I cancel one of them, and having the same comment for all of them, I'd rather have the latter.
On 09.09.2009 00:11, Andrew P. Black wrote:
Ideally, what I think we want is for all of the packages to be written atomically. However, that is something that MC does not currently know how to do.
Next best would be to collect all of he log messages ahead of doing any of the writing to the repository. That would also require some major changes, but at least I can see how to do it. Yes, that's what I imagined would be most intuitive, never looked at how much work it'd be though...
Providing the checkbox is s mere matter of morphic programming ... perhaps, if the box is not checked, and the user cancels one of the ensuing dialogs, the behaviour should be to reuse the log message from the Slice?
Andrew I don't know about you, but when I press cancel, it's usually because I realize I've screwed something up, and want to abort :) Might also be abit confusing having different behaviour for the cancel button depending on whether you press it on the first Dialog compared to the rest.
Cheers, Henry
participants (5)
-
Andrew P. Black -
Damien -
Henrik Johansen -
Henrik Sperre Johansen
-
Stéphane Ducasse