Hi Chris,<br>
<br>
sorry for the late reply!<br>
<br>
> Please simply retain the dirty contents of each mode's pane rather than introduce another use interruption.<br>
<br>
I don't understand. That won't be possible for the contents of the value pane because there is no equivalent in the explorer, is it? :-)<br>
<br>
Regarding your proposal of always popping up a new window in this case, I am not sure ... So you want the semantics of a message trace that is trying to insert new messages here? To me, this "explore" button has different semantics: That is not a pop-up, it just replaces the contents of the existing window. I believe that it would less inconsistent if this sometimes opened a new tool and sometimes not ...<br>
<br>
Can we have some third opinions, maybe? :)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-02-07T19:25:18-06:00, asqueaker@gmail.com wrote:<br>
<br>
> Christoph,<br>
> <br>
> Please simply retain the dirty contents of each mode's pane rather than<br>
> introduce another use interruption.<br>
> <br>
> Otherwise, I would like to at least make this conditional on Reuse Windows<br>
> not being set.  Reuse Windows reinforces the behavior throughout the system<br>
> that new windows are opened when pane contents cannot be changed due to<br>
> being dirty, so it would be good to keep that behavior consistent here.<br>
> The newly-opened window IS the "pop up" that enables the user to preserve<br>
> their contents AND continue working, unfettered.<br>
> <br>
> Best,<br>
>   Chris<br>
> <br>
> On Sun, Feb 6, 2022 at 2:24 PM <commits at source.squeak.org> wrote:<br>
> <br>
> > Christoph Thiede uploaded a new version of Tools to project The Trunk:<br>
> > http://source.squeak.org/trunk/Tools-ct.1126.mcz<br>
> ><br>
> > ==================== Summary ====================<br>
> ><br>
> > Name: Tools-ct.1126<br>
> > Author: ct<br>
> > Time: 6 February 2022, 9:24:10.500919 pm<br>
> > UUID: 95ff44c7-b6bf-0e46-b8e4-4d261c4c3806<br>
> > Ancestors: Tools-mt.1125<br>
> ><br>
> > Fixes a bug when switching to an explorer from an inspector that has<br>
> > unaccepted contents in the value pane. Rather than replacing the value of a<br>
> > field (or even replacing the inspected/explored object), ask the user and<br>
> > either withdraw these contents or open a new window for the explorer.<br>
> ><br>
> > Note that I consider this patch rather a temporary hotfix than a final<br>
> > solution. In the long term, we should try to communicate specific selectors<br>
> > (here: #expression) for requests such as #acceptChanges or #wantToChange<br>
> > instead.<br>
> ><br>
> > =============== Diff against Tools-mt.1125 ===============<br>
> ><br>
> > Item was changed:<br>
> >   ----- Method: Inspector>>replaceInspectorWithExplorer (in category<br>
> > 'toolbuilder') -----<br>
> >   replaceInspectorWithExplorer<br>
> >         "Switch to an explorer tool. If there are custom fields, the user<br>
> > can choose to not discard them, which will just spawn a new explorer tool<br>
> > besides this inspector."<br>
> ><br>
> >         | window currentBounds |<br>
> > +       self flag: #todo. "ct: In the long term, we should try to<br>
> > communicate specific selectors (here: #expression) along the observer<br>
> > pattern for requests such as #acceptChanges or #wantToChange instead of<br>
> > exploiting contentsTyped etc."<br>
> > +<br>
> > +       (self okToDiscardCustomFields and: [contentsTyped notNil ==> [self<br>
> > confirm:<br>
> > + 'Changes have not been saved.<br>
> > + Is it OK to cancel those changes?' translated orCancel: [^ self]]])<br>
> > -       self okToDiscardCustomFields<br>
> >                 ifFalse: [^ self object explore].<br>
> ><br>
> >         self customFields removeAll.<br>
> > +       self changed: #contents. "Reset value pane contents before<br>
> > accepting all contents"<br>
> >         self changed: #acceptChanges. "We copy the current state anyway.<br>
> > See below."<br>
> >         currentBounds := ToolBuilder default class getBoundsForWindow:<br>
> > self containingWindow.<br>
> ><br>
> >         "Close first because MVC fiddles around with processes."<br>
> >         self changed: #close.<br>
> ><br>
> >         window := ToolSet explore: self object.<br>
> ><br>
> >         "---- In MVC, the lines after this will not be executed ---"<br>
> ><br>
> >         window model setExpression: self expression.<br>
> >         ToolBuilder default class setBoundsForWindow: window to:<br>
> > currentBounds.!<br>
> ><br>
> ><br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220207/1464aa7b/attachment.html><br>
> <br>
>