Switching context(s) in browser while method is not-yet accepted
this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action. often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :) what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do. And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window). -- Best regards, Igor Stasenko.
I agree but I want to offer something slightly different. Remove the accept button/ command altogether. Anything that is typed by the user is automatically accepted , if user changes his mind he should be able to use undo/redo . Preferably create a history tool (dont know if changes could help here, I know pharo users use this to recover lost changes) similar to ones found in Photoshop or 3d apps that the user can use to return back in time to any change he made without pressing undo continuously. It is annoyance and offers zero advantages as it is to the user. But I am curious to listening to other opinions as well on this. -- View this message in context: http://forum.world.st/Switching-context-s-in-browser-while-method-is-not-yet... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
kilon wrote:
I agree but I want to offer something slightly different. Remove the accept button/ command altogether. Anything that is typed by the user is automatically accepted , if user changes his mind he should be able to use undo/redo . Preferably create a history tool (dont know if changes could help here, I know pharo users use this to recover lost changes) similar to ones found in Photoshop or 3d apps that the user can use to return back in time to any change he made without pressing undo continuously.
It is annoyance and offers zero advantages as it is to the user. But I am curious to listening to other opinions as well on this.
-- View this message in context: http://forum.world.st/Switching-context-s-in-browser-while-method-is-not-yet... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
That sounds dangerous, particularly if you are playing with internals of UI or other system parts. What if half way through an edit you need to leave the keyboard, and that ends up being a few hours or longer, and you don't remember where you were. regards -ben
agreed we should change that since years. Some days we should stop and fix all the glitches that give us these hiccups. stef On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
-- Best regards, Igor Stasenko.
On Sep 3, 2013, at 9:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
agreed we should change that since years. Some days we should stop and fix all the glitches that give us these hiccups.
... and that day is around october, when we freeze pharo3 and start to fix bugs :) Esteban
stef
On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
-- Best regards, Igor Stasenko.
I have a different opinion. This modality issue is not something we fix as a bug. Of course, we can put in place a patch that somehow makes it work in the current browser, but the core problem is a conceptual one. And that requires a redesign of the user interface. If we have a problem with a code model, we do not just put an if to patch the thing. Ok, sometimes we do that just because we cannot see a different solution, but we are not comfortable with it. We have to treat the user interface in the same way. Doru On Wed, Sep 4, 2013 at 9:56 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On Sep 3, 2013, at 9:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
agreed we should change that since years. Some days we should stop and fix all the glitches that give us these hiccups.
... and that day is around october, when we freeze pharo3 and start to fix bugs :)
Esteban
stef
On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
this is most annoying to me, that UI interrupts you in very strange
manner
and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
Yes, systematical approach matters :) But as to me it is quite simple feature, and in right hands (pointing at Ben ;), it can be implemented quite easily. In Nautilus there as many features which has similar concepts (need to change browser's context) - like navigation history. I guess combining it with unaccepted edits won't take much effort to implement. On 4 September 2013 10:40, Tudor Girba <tudor@tudorgirba.com> wrote:
I have a different opinion. This modality issue is not something we fix as a bug. Of course, we can put in place a patch that somehow makes it work in the current browser, but the core problem is a conceptual one. And that requires a redesign of the user interface.
If we have a problem with a code model, we do not just put an if to patch the thing. Ok, sometimes we do that just because we cannot see a different solution, but we are not comfortable with it. We have to treat the user interface in the same way.
Doru
On Wed, Sep 4, 2013 at 9:56 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On Sep 3, 2013, at 9:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
agreed we should change that since years. Some days we should stop and fix all the glitches that give us these hiccups.
... and that day is around october, when we freeze pharo3 and start to fix bugs :)
Esteban
stef
On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
this is most annoying to me, that UI interrupts you in very strange
manner
and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua@gmail.com>:
this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
We have method versions. I don't see a reason why uncommited methods can not go just on the list. They could be marked as unsaved/unommited (in fact they are not compiled so different per se) or even better the method version list should be a timeline where the current version is the present and everything else is a past or a potential future version. Norbert
There were an addon named DontModeMeIn for VisualWorks browser which I believe did the same thing. It was written by Vasilii Bykov and there was an article on it in his blog, but I can't find that blog in the new Cincom's site, and can't find that article in WaybackMachine either⦠The only reference I can find is here [ http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf]. Hopefully, the addon is still in Cincom's Public Repository⦠-- Best regards, Dennis Schetinin 2013/9/4 Norbert Hartl <norbert@hartl.name>
Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua@gmail.com>:
this is most annoying to me, that UI interrupts you in very strange
manner
and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
We have method versions. I don't see a reason why uncommited methods can not go just on the list. They could be marked as unsaved/unommited (in fact they are not compiled so different per se) or even better the method version list should be a timeline where the current version is the present and everything else is a past or a potential future version.
Norbert
Here's [ http://www.cincomsmalltalk.com/publicRepository/VB-Sketch-DontModeMeIn.html] the description: An experimental tweak of the Refactoring Browser to support modeless editing. With this installed, it is possible to go to a different method or class within the same browser. while a method is being edited The "postponed" edit appears as an icon at the bottom of the browser. Clicking it will jump back to the edit in progress. NOTE: Close all browser windows before or immediately after loading this package. This package is currently unloadable and is should not be loaded into image that has RB_Tabs loaded (or vice versa). -- Best regards, Dennis Schetinin 2013/9/4 Dennis Schetinin <chaetal@gmail.com>
There were an addon named DontModeMeIn for VisualWorks browser which I believe did the same thing. It was written by Vasilii Bykov and there was an article on it in his blog, but I can't find that blog in the new Cincom's site, and can't find that article in WaybackMachine either⦠The only reference I can find is here [ http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf]. Hopefully, the addon is still in Cincom's Public Repositoryâ¦
--
Best regards,
Dennis Schetinin
2013/9/4 Norbert Hartl <norbert@hartl.name>
Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua@gmail.com>:
this is most annoying to me, that UI interrupts you in very strange
manner
and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
We have method versions. I don't see a reason why uncommited methods can not go just on the list. They could be marked as unsaved/unommited (in fact they are not compiled so different per se) or even better the method version list should be a timeline where the current version is the present and everything else is a past or a potential future version.
Norbert
On 4 September 2013 08:38, Norbert Hartl <norbert@hartl.name> wrote:
Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua@gmail.com>:
this is most annoying to me, that UI interrupts you in very strange
manner
and asks you to make a decision: - accept, or discard the method, or cancel the action.
often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :)
what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do.
And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window).
We have method versions. I don't see a reason why uncommited methods can not go just on the list. They could be marked as unsaved/unommited (in fact they are not compiled so different per se) or even better the method version list should be a timeline where the current version is the present and everything else is a past or a potential future version.
you forgetting that user may decide to create new method in code pane, instead of editing existing one. and only when users asks to compile the code (by accepting it) you know where it goes, but making any categorization before, as to me, looks counterproductive. i think that drafts should be stored in separate collection, not related to versions.
Norbert
-- Best regards, Igor Stasenko.
participants (8)
-
btc＠openinworld.com -
Dennis Schetinin -
Esteban Lorenzano -
Igor Stasenko -
kilon -
Norbert Hartl -
Stéphane Ducasse -
Tudor Girba