Hi Emilio,
I don't quite understand what you mean ... the behavior I have for now is to both select the word and attempt to navigate, which deselects the word sometimes.
Just by reading your mail, I was thinking of doing navigation by triple-clicking (was that what you meant btw?), which could maybe be doable. Would everyone (Tim?) find that ok. I don't think Squeak can do triple- click to select a line or paragraph (and can't check because my double-click is modified ;-) ).
Cheers, Romain
On Sep 30, 2005, at 2:52 PM, Emilio Oca wrote:
Hi Romain,
I'd like to keep the behaviour of double-click to select a word. But the behaviour you propose is handy. Is it difficult to make it work over a selected text? In that case we could keep both behaviours. Cheers.
Emilio-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]En nombre de Romain Robbes Enviado el: Viernes, 30 de Septiembre de 2005 06:48 Para: The general-purpose Squeak developers list Asunto: Re: [ANN] new version of services available for preview
On Sep 30, 2005, at 1:57 AM, tim Rowledge wrote:
On 29-Sep-05, at 4:22 PM, Romain Robbes wrote:
On Sep 29, 2005, at 10:02 PM, tim Rowledge wrote:
The obvious question here is how this affects the traditional usage of double-click on a word to select that word for cut/cop/ paste/etc. Is there some extra gesture you missed out?
Well ... that's kind of a problem now ;-)
Ah. This ought to be sorted out pretty quickly then. Introducing modes is a good way to become the subtract of a number of voodoo practices so I'd avoid it if I were you. What is the problem with simply leaving the selection behaviour alone and using the same ctl-m/n hotkeys that we already have as ways of getting the implementors and senders? There isn't much point in making a simpler UI for getting to them at the cost of completely ruining the normal editing actions.
For me, navigating in the code is more "normal" than copy/pasting, ie I use it way more often. Then I recognize than I can get bitten by it from time to time. But I think using the mouse for this really help in quickening the navigation. I'd really like to have something like alt-clicking for this, but most of these keys are taken already. Since I never use the halo (even if I trigger it all the time ...), I was also thinking of including a 'mode' there (as some people still need it). I'd really like to remove the mode, but finding a good keystroke+clicking combination is tough. The same thing applies to keyboard shortcuts by the way.
If you're original impetus for the change was to get to senders/ implementors faster it would probably be more widely useful if you could make the building and opening of the dratted message set browsers faster.
Well the idea is to have the smalltalk browser behaving like a web browser: click on something and go there in the same window (senders, implementors, references to class and instance variables). then you can go back and forward in your history, all of this without opening a new window (and not being bugged when you have some code you were editing still not accepted).
Romain
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
On 09/30/2005 09:47 AM, Romain Robbes apparently said:
Hi Emilio, I don't quite understand what you mean ... the behavior I havefor now is to both select the word and attempt to navigate, which deselects the word sometimes.
Just by reading your mail, I was thinking of doing navigation bytriple-clicking (was that what you meant btw?), which could maybe be doable. Would everyone (Tim?) find that ok. I don't think Squeak can do triple- click to select a line or paragraph (and can't check because my double-click is modified ;-) ).
[snipped]
I am jumping in kind of late on this discussion, so I apologize if it's already been covered.
What about using the function keys or another keystroke combination? My preference would be to *not* modify the double click action. The way I do it in Eclipse is to doubleClick. Then I press F3 or some other key combination and it takes me there. Eclipse also has the concept of the browser back and forward buttons that will help me navigate through my history of navigations -- these actions are also bound to Alt-LeftArrow and Alt-RightArrow.
Eclipse also adds the ability to navigate and get information by just placing the cursor anywhere in the text. So for this code, "someObject.doS[cursor positioned here]omething();", pressing F3 takes me to the method doSomething() in someObject's class. I don't know how hard that would be in Squeak, but it sure would be nice to have.
Just my unwarranted two cents...
On Sep 30, 2005, at 7:55 PM, Jason Rogers wrote:
On 09/30/2005 09:47 AM, Romain Robbes apparently said:
Hi Emilio, I don't quite understand what you mean ... the behavior Ihave for now is to both select the word and attempt to navigate, which deselects the word sometimes.
Just by reading your mail, I was thinking of doing navigationby triple-clicking (was that what you meant btw?), which could maybe be doable. Would everyone (Tim?) find that ok. I don't think Squeak can do triple- click to select a line or paragraph (and can't check because my double-click is modified ;-) ).
[snipped]
I am jumping in kind of late on this discussion, so I apologize if it's already been covered.
What about using the function keys or another keystroke combination? My preference would be to *not* modify the double click action. The way I do it in Eclipse is to doubleClick. Then I press F3 or some other key combination and it takes me there.
yes but I'd rather do it with only clicking, as it seems to me to be faster (the alternative being to keep a key pressed, maybe this can be done somehow).
Eclipse also has the concept of the browser back and forward buttons that will help me navigate through my history of navigations -- these actions are also bound to Alt-LeftArrow and Alt-RightArrow.
with services you can do that by default with meta-[ and and meta-] (or apple-[, windows-[)
Eclipse also adds the ability to navigate and get information by just placing the cursor anywhere in the text. So for this code, "someObject.doS[cursor positioned here]omething();", pressing F3 takes me to the method doSomething() in someObject's class. I don't know how hard that would be in Squeak, but it sure would be nice to have.
Well you kind do that with services (just placing the cursor instead of selecting text), except the shortcut is longer. In fact this is the same thing used for click-navigation.
Romain
Just my unwarranted two cents...
-- Jason Rogers
"I am crucified with Christ: nevertheless I live; yet not I, but Christ liveth in me: and the life which I now live in the flesh I live by the faith of the Son of God, who loved me, and gave himself for me." Galatians 2:20
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
On 09/30/2005 02:18 PM, Romain Robbes apparently said:
[snipped]
I am jumping in kind of late on this discussion, so I apologize if it's already been covered.
What about using the function keys or another keystroke combination? My preference would be to *not* modify the double click action. The way I do it in Eclipse is to doubleClick. Then I press F3 or some other key combination and it takes me there.
yes but I'd rather do it with only clicking, as it seems to me to be faster (the alternative being to keep a key pressed, maybe this can be done somehow).
That's surprising. I thought you were a vim user :) I find that taking my hand off of the keyboard and reaching for the mouse is much slower. As much as possible I like to use keyboard navigation.
Eclipse also has the concept of the browser back and forward buttons that will help me navigate through my history of navigations -- these actions are also bound to Alt-LeftArrow and Alt-RightArrow.
with services you can do that by default with meta-[ and and meta-] (or apple-[, windows-[)
Ah, I didn't know that. I will have to employ it.
Eclipse also adds the ability to navigate and get information by just placing the cursor anywhere in the text. So for this code, "someObject.doS[cursor positioned here]omething();", pressing F3 takes me to the method doSomething() in someObject's class. I don't know how hard that would be in Squeak, but it sure would be nice to have.
Well you kind do that with services (just placing the cursor instead of selecting text), except the shortcut is longer. In fact this is the same thing used for click-navigation.
So, I can't press Alt+n in the following and get to senders?
aCollection sel[cursor here]lect: [:e | true]
What else would I have to do?
On Sep 30, 2005, at 8:55 PM, Jason Rogers wrote:
On 09/30/2005 02:18 PM, Romain Robbes apparently said:
[snipped]
I am jumping in kind of late on this discussion, so I apologize if it's already been covered.
What about using the function keys or another keystroke combination? My preference would be to *not* modify the double click action. The way I do it in Eclipse is to doubleClick. Then I press F3 or some other key combination and it takes me there.
yes but I'd rather do it with only clicking, as it seems to me to be faster (the alternative being to keep a key pressed, maybe this can be done somehow).
That's surprising. I thought you were a vim user :) I find that taking my hand off of the keyboard and reaching for the mouse is much slower. As much as possible I like to use keyboard navigation.
yes I am. but if you take the metaphor of the web browser, it makes more sense. I find myself navigating most of the time through 5-10 methods at the same time, without editing. Then I start editing again. For this the mouse is faster.
Eclipse also has the concept of the browser back and forward buttons that will help me navigate through my history of navigations -- these actions are also bound to Alt-LeftArrow and Alt-RightArrow.
with services you can do that by default with meta-[ and and meta-] (or apple-[, windows-[)
Ah, I didn't know that. I will have to employ it.
you have also alt-shift-[ in message lists (next list of message ...)
Eclipse also adds the ability to navigate and get information by just placing the cursor anywhere in the text. So for this code, "someObject.doS[cursor positioned here]omething();", pressing F3 takes me to the method doSomething() in someObject's class. I don't know how hard that would be in Squeak, but it sure would be nice to have.
Well you kind do that with services (just placing the cursor instead of selecting text), except the shortcut is longer. In fact this is the same thing used for click-navigation.
So, I can't press Alt+n in the following and get to senders?
aCollection sel[cursor here]lect: [:e | true]
What else would I have to do?
I was conservative and did not override the default shortcuts, but maybe I could ;-) They are <m-b>s <m-b>m ...
Romain
-- Jason Rogers
"I am crucified with Christ: nevertheless I live; yet not I, but Christ liveth in me: and the life which I now live in the flesh I live by the faith of the Son of God, who loved me, and gave himself for me." Galatians 2:20
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented.
How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems.
Consider some alternatives - a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems. triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down. hotkey. we already have them and they work quite well. menu. slower but the action needs to be there for completeness. toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort. drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/ many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers.
See? There's lots more exciting ways to improve code exploring than ruining my editing experience.
tim
On Sep 30, 2005, at 8:58 PM, tim Rowledge wrote:
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/ implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented.
How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems.
Consider some alternatives -
Well that's pretty much what I've been doing ... so I'm summing up each proposition here
a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems.
for this, I was thinking of using the halo or morph menu (the morph menu is accessible through the halo). still it removes some functionality
triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down.
this ones seemed to me to be the most reasonable
hotkey. we already have them and they work quite well.
but they are slower when you have to explore deeply (5-10 senders/ implementors)
menu. slower but the action needs to be there for completeness.
yes it can be in both.
toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort.
I could try that too ...
drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers.
could be interesting, but much more long-term ;-)
See? There's lots more exciting ways to improve code exploring than ruining my editing experience.
Well I was not satisfied with the controls, now at least we move forward
Romain
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
Romain Robbes wrote:
hotkey. we already have them and they work quite well.
but they are slower when you have to explore deeply (5-10 senders/ implementors)
I don't understand this. How exactly are they slower? Perhaps you could use KLM-GOMS to sketch out a quantification of some of these design decisions:
http://www.rpi.edu/~glasse/HCI-HOWTO/ar01s03.html http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/printer/goms.html
Tony
On Oct 3, 2005, at 11:05 AM, Tony Garnock-Jones wrote:
Romain Robbes wrote:
hotkey. we already have them and they work quite well.
but they are slower when you have to explore deeply (5-10 senders/ implementors)
I don't understand this. How exactly are they slower? Perhaps you could use KLM-GOMS to sketch out a quantification of some of these design decisions:
http://www.rpi.edu/~glasse/HCI-HOWTO/ar01s03.html http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/printer/goms.html
ok, I did a quick computation
with double-click: reach mouse: 400 reaching a piece of code: 1100 double-clicking: 400 total is 1900
with a keystroke: reach mouse: 400 reaching a piece of code: 1100 pressing alt-n: 280*2 (not sure whether this is two characters, or less) total is 2060, or slightly less
I did not count navigation using keys which would be too variable. This assumes that we define a shortcut (alt-n above) which determines from the context the right action to do: senders, implementors, or references to variable/class.
So the two are close to each other. The thing is that it seems more natural to me to do everything with the mouse in this case, especially when you have to click several times in a row (and, as I said before, this is a Vim user talking ;-) ).
Anyways, we can compare with the current system: reach mouse: 400 reaching start of entity: 1100 "Mental", thinking : 1200 (thinking about whether typing the shortcut now is enough or if you should select the entire entity when messages are nested). "Mental", thinking : 1200 (thinking whether to use alt-n, alt-m, alt-N, or the menu item to get references to the instance variable (no shortcut for this one?) keystroke: 280 * 2 total is 4460, in the best case (no selection of code, and no going to select an item in the menu).
Romain
Tony
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
On 3-Oct-05, at 4:50 AM, Romain Robbes wrote:
ok, I did a quick computation
.. ok and now let's consider the slowdown caused by cognitive dissonance of a long-habitual and widely used facility being usurped.
"In this window over here, I get 'normal' d-click behaviour and in this window over here I get... whoops, why is it doing nothing? Oh it's opening a window. Wassat for? Oh yeah, one of those. Dang. All I wanted was to select the word to copy. Bugger"
Not to mention the other inconsistencies you'd be introducing - d-click next to a surrounding delimiter like {"'([ etc - would that also show sender/implementors of the entire phrase? What does that mean? drag select across a word/symbol; would that show the senders/ implementors? For either answer, why?
I appreciate the large effort you're putting into the whole services thing but this smallish detail is a silly thing to get hung up on when as I previously suggested there are much more valuable improvements you could turn your talents to.
tim
On Oct 3, 2005, at 8:11 PM, tim Rowledge wrote:
On 3-Oct-05, at 4:50 AM, Romain Robbes wrote:
ok, I did a quick computation
.. ok and now let's consider the slowdown caused by cognitive dissonance of a long-habitual and widely used facility being usurped.
"In this window over here, I get 'normal' d-click behaviour and in this window over here I get... whoops, why is it doing nothing? Oh it's opening a window. Wassat for? Oh yeah, one of those. Dang. All I wanted was to select the word to copy. Bugger"
Well, I did the computation for the double-click because that was the question asked, but it IS in my list to find something else. I know it is disturbing to most people, so I'll find something else, probably triple click for now (since I think using the mouse constantly is the best way for that). But it is still not cast in stone if I can find a scheme to easily parametrize this.
Not to mention the other inconsistencies you'd be introducing - d-click next to a surrounding delimiter like {"'([ etc - would that also show sender/implementors of the entire phrase? What does that mean?
For this (not taking into account whether it is a double click or something else), I use the parse tree of the method, so it will be the closest message or variable at the click point.
drag select across a word/symbol; would that show the senders/ implementors? For either answer, why?
With this scheme you don't need to select the text anymore. Then the convention I adopted is that if you see a message in the body of the code, then you'll more likely be interested in the implementors. If you are interested in the senders of a message, you can (n-)click on the method name. This means that you can see the senders by at least choosing an implementor and then clicking on the title of the method.
I also thought of a way to reverse the behavior, but did not came around implementing it yet (well I tried with shift-clicking, but the events seems to be swallowed most of the time).
I appreciate the large effort you're putting into the whole services thing but this smallish detail is a silly thing to get hung up on when as I previously suggested there are much more valuable improvements you could turn your talents to.
As I said, I'm not "hung up", sorry for not being clear about that.
Romain
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
Hi,
I am with Tim here. Clicking and double-clicking inside a text field is a today de-facto standard for positioning and selecting text.
This might not be a good standard (to me it is) but is a standard nonetheless. So changing it will only frustrate every user who don't know, or remember, that squeak has such distinct behaviour.
I also don't think that making things clickable while they don't give visual feedback of clickability will help avoid user confusion.
What do you think about using CTRL+ALT. I read that you couldn´t use ctrl and alt separately, but what about both keys?. If possible I would also underline all clickable words while CTRL+ALT are being pressed. This would give the visual feedback I just mentioned and will advertise to a user that something can be done with that words.
Just my opinion.
Regards, Hernán
tim Rowledge wrote:
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented.
How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems.
Consider some alternatives - a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems. triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down. hotkey. we already have them and they work quite well. menu. slower but the action needs to be there for completeness. toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort. drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/ many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers.
See? There's lots more exciting ways to improve code exploring than ruining my editing experience.
tim
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
On Sep 30, 2005, at 10:27 PM, Hernan Tylim wrote:
Hi,
I am with Tim here. Clicking and double-clicking inside a text field is a today de-facto standard for positioning and selecting text.
This might not be a good standard (to me it is) but is a standard nonetheless. So changing it will only frustrate every user who don't know, or remember, that squeak has such distinct behaviour.
I also don't think that making things clickable while they don't give visual feedback of clickability will help avoid user confusion.
What do you think about using CTRL+ALT. I read that you couldn´t use ctrl and alt separately, but what about both keys?. If possible I would also underline all clickable words while CTRL+ALT are being pressed. This would give the visual feedback I just mentioned and will advertise to a user that something can be done with that words.
Well I have quite a few possibilities there ... I'll try some of these and see what is the best. I think the problem in this respect (using alt or ctrl) is that these events are swallowed by squeak so I'll need to do some treatments at a lower level probably.
But I'll look into this.
Romain
Just my opinion.
Regards, Hernán
tim Rowledge wrote:
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented. How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems. Consider some alternatives - a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems. triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down. hotkey. we already have them and they work quite well. menu. slower but the action needs to be there for completeness. toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort. drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/ many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers. See? There's lots more exciting ways to improve code exploring than ruining my editing experience. tim
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
This is a funny thing about these subjective things like what the event bindings should be, and alternative looks.
On the one hand, these things are intrusive, and people notice them, so there's lots of feedback and argument. On the other hand, they're fragile, so they don't get very well maintained outside the image. On the third hand, since we are eventually incorporating various changes by different people from different periods, we end up having this weird collage of things that don't really quite fit together.
When, oh when, will we have people working on the infrastructure to make all these themable, easily definable by a single UI oriented person, and so forth with half the enthusiasm that people have for yet another tweak...
I will note that services really is exactly such a thing, but the infrastructure aspects (we could define keymapping from a UI, instead of hardcoding them! you could choose your own, and let no one ever change it!) get completely ignored in favor of the "triple-click vs. three-key sequence" arguments. Now this is just my opinion, but I say Blech.
</rant>
Daniel
Hernan Tylim wrote:
Hi,
I am with Tim here. Clicking and double-clicking inside a text field is a today de-facto standard for positioning and selecting text.
This might not be a good standard (to me it is) but is a standard nonetheless. So changing it will only frustrate every user who don't know, or remember, that squeak has such distinct behaviour.
I also don't think that making things clickable while they don't give visual feedback of clickability will help avoid user confusion.
What do you think about using CTRL+ALT. I read that you couldn´t use ctrl and alt separately, but what about both keys?. If possible I would also underline all clickable words while CTRL+ALT are being pressed. This would give the visual feedback I just mentioned and will advertise to a user that something can be done with that words.
Just my opinion.
Regards, Hernán
tim Rowledge wrote:
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented.
How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems.
Consider some alternatives - a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems. triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down. hotkey. we already have them and they work quite well. menu. slower but the action needs to be there for completeness. toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort. drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/ many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers.
See? There's lots more exciting ways to improve code exploring than ruining my editing experience.
tim
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Hi Daniel
I agree. This is why keymapping will be an important package in the future. I always found strange that there was only one shortcut table shared by all the system objects. This is also why services are important.
Stef
This is a funny thing about these subjective things like what the event bindings should be, and alternative looks.
On the one hand, these things are intrusive, and people notice them, so there's lots of feedback and argument. On the other hand, they're fragile, so they don't get very well maintained outside the image. On the third hand, since we are eventually incorporating various changes by different people from different periods, we end up having this weird collage of things that don't really quite fit together.
When, oh when, will we have people working on the infrastructure to make all these themable, easily definable by a single UI oriented person, and so forth with half the enthusiasm that people have for yet another tweak...
I will note that services really is exactly such a thing, but the infrastructure aspects (we could define keymapping from a UI, instead of hardcoding them! you could choose your own, and let no one ever change it!) get completely ignored in favor of the "triple- click vs. three-key sequence" arguments. Now this is just my opinion, but I say Blech.
</rant>
Daniel
Hernan Tylim wrote:
Hi, I am with Tim here. Clicking and double-clicking inside a text field is a today de-facto standard for positioning and selecting text. This might not be a good standard (to me it is) but is a standard nonetheless. So changing it will only frustrate every user who don't know, or remember, that squeak has such distinct behaviour. I also don't think that making things clickable while they don't give visual feedback of clickability will help avoid user confusion. What do you think about using CTRL+ALT. I read that you couldn´t use ctrl and alt separately, but what about both keys?. If possible I would also underline all clickable words while CTRL+ALT are being pressed. This would give the visual feedback I just mentioned and will advertise to a user that something can be done with that words. Just my opinion. Regards, Hernán tim Rowledge wrote:
Please don't do this mangling of click behaviour. It can only confuse most users, especially those of us with a long history. It will slow down editing. It won't really speed up finding senders/implementors since the time to ask for the list is small by comparison to the time for the list to be built and presented.
How would it work with the other uses of d-click? i.e the d-click at the beginning of the line/view/quote-delimited area/etc ? I think you are inappropriately overloading a gesture so common it can only cause problems.
Consider some alternatives - a metakey with the click. shift is already used to extend the selection though and the others are implicitly used for single button systems. triple-clicking. I've used systems with t-click and they tend to be a pain; d-click is pretty much a trivial reflex finger action. t- or quad- click requires you to count and slows you down. hotkey. we already have them and they work quite well. menu. slower but the action needs to be there for completeness. toolbar button. reasonable - after a d-click one pretty much has to have the mouse in-hand and so a small motion to a reasonably sized button not too far away will take very little time and negligable cognitive effort. drag-to tool. slightly off the wall but consider being able to drag the selection to a tool that will do the action. such a tool would be a 'senders browser' and anytime you drop a selection on it it would display the senders. It could be a stacking browser so that all/some/ many recent sets of senders would be available. Similar tools would show implementors, references, class refs, variable usages, commentary, spelling and thesaurus info, etc etc. Instead of adding loads of function to a plain browser you just add the drag/drop and then have new specialised browsers.
See? There's lots more exciting ways to improve code exploring than ruining my editing experience.
tim
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
squeak-dev@lists.squeakfoundation.org
-
Daniel Vainsencher -
Hernan Tylim -
Jason Rogers -
Romain Robbes -
stéphane ducasse -
tim Rowledge -
Tony Garnock-Jones