| Author |
 Topic  |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
 Posted - May 26 2004 : 11:36:09 AM
|
There have been a couple of threads about ALT-G recently, and it got me thinking. What if ALT-G always jumped to the definition of a function, not the declaration — except if you're already on the definition, when it can continue to jump to the declaration as at present.
99% of the time I want to jump to the definition. If I want to see the declaration, I can do it more easily with hovering. If ALT-G always jumped to the defintion, I wouldn't have to keep selecting the .cpp instead of the .h from the list.
What do you all think? |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - May 26 2004 : 12:12:54 PM
|
sounds good to me. of course, you would need to handle alt_g on enum's and other non functions slightly differently.
about the only time i want to jump to the .h is when i actually want to edit structures or enum's in the .h
changing the parameters or return value of a function is a special case anyway, which is the only other time i am interested in jumping to the .h |
zen is the art of being at one with the two'ness |
 |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - May 27 2004 : 05:06:25 AM
|
| Yeah, enums and variables are different. So are functions which are defined when they are declared. I was only referring to functions where there is both a declaration and a definition. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - May 28 2004 : 12:16:00 AM
|
| We agree jumping to definitions is most common. Hence, definitions appear before declarations. But like feline, there are times we do want to go to the declaration. We would hate to learn another command to make that happen. |
Whole Tomato Software, Inc. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - May 28 2004 : 07:25:05 AM
|
| Under my suggestion, you can get to the declaration by pressing ALT-G twice. The first time gets you to the definition, and the second time to the declaration (because you're already on the definition). This is probably still quicker than pressing ALT-G once and selecting the .h choice, so I think you win even in the uncommon case. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - May 28 2004 : 08:16:08 AM
|
i like Stephen's suggestion. i was pointing out that it should only be applied to functions which have definitions in a .h
one issue with the popup menu is that this appears next to the mouse cursor. however, since i don't use the mouse when programming, and having the mouse over the build window (set to auto hide at the bottom of my screen) keeps it open once the build has finished, i keep my mouse over the VS toolbar, out of my way when i am not using it.
so, i press ALT-G and the menu normally pops up at the top of my screen, quite a distance from where i am typing and looking.
i can see a possible problem with getting to the .h via two ALT-G presses. pressing ALT-G on:
browser->navigate(pszFileName);
to jump to navigate(), i get:
void browserClass::navigate(const QString& url)
${
// body
}
where $ is my caret. another alt_g at this point wont work, since i am not sitting on anything VAX can jump to. you would need a special case, to say "if no other key has been pressed, and you get a second alt_g, then ignore the caret position"
alt_g + alt_g is definitely less thinking and fuss to get to the .h file. it saves me considering the menu of options. if course, when you don't get one .cpp reference and one .h reference then you will still need to ask me where i want to go. |
zen is the art of being at one with the two'ness |
|
|
|
Ondrej Spanel
Senior Member
40 Posts |
Posted - Jun 09 2004 : 03:07:18 AM
|
quote:
There have been a couple of threads about ALT-G recently, and it got me thinking. What if ALT-G always jumped to the definition of a function, not the declaration G?? except if you're already on the definition, when it can continue to jump to the declaration as at present.
For the record:
I think this would work very well. |
Edited by - Ondrej Spanel on Jun 09 2004 03:11:34 AM |
|
|
|
[email protected]
Senior Member
28 Posts |
Posted - Jun 09 2004 : 03:39:07 AM
|
Indeed... the popup box where you can select which definition / declaration you want to jump to is down-right difficult to use (it's difficult to distinguish the 4-odd choices).
I would certainly like having ALT-G jump to the definition. |
|
|
|
rblondeau
Tomato Guru
Canada
102 Posts |
Posted - Jun 09 2004 : 12:42:14 PM
|
| I agree, this would be a welcome feature. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jun 09 2004 : 7:06:12 PM
|
We are still dwelling on the topic.
case=64 |
Whole Tomato Software, Inc. |
|
|
|
diarrhio
Ketchup Master
53 Posts |
Posted - Jun 30 2004 : 2:43:13 PM
|
Options. Options. Options.
It's what our users beg for. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Jul 01 2004 : 04:43:57 AM
|
Users always beg for options, and if you listen to all of them you end up with a product which is unwieldy, bloated, hard to configure and hard to debug. I'm glad to see that WT generally agree with this philosophy too.
I do think my proposed behaviour is better, but it's another example where I'd rather see either behaviour than another option. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
diarrhio
Ketchup Master
53 Posts |
Posted - Jul 02 2004 : 11:49:59 PM
|
quote:
...and if you listen to all of them you end up with a product which is unwieldy, bloated, hard to configure and hard to debug...
I gotta admit, I didn't quite know what to think of this when I first read it. I gave it a few days to digest. I can't say I agree with that statement, though I definitely do see it's merits. Without trying to turn this into a religious war, here is my take on it.
I can see "unwieldly" and "hard to configure" being good justifications for simplicity when dealing with novice users. However, VA is by no means a tool for a novice user. It's a tool for software developers, and I at least hope that they are competent enough to figure out most, if not all of the configuration options. Look at all of the successful development packages, or even text editors, for that matter. They are all *highly* configurable. Imagine how much you would hate working in VC if you couldn't customize your own hot keys. Another example is Maya. Maya is ridiculously configurable, and necessarily so because it's used by power users. It's by far the most successful 3D animation package out there, as opposed to 3D Studio Max, which for years, forced you to work "their way".
As for lots of options being "hard to debug"... I don't know what to say. I've never come across that situation. How exactly does allowing the user to configure a bunch of options make debugging significantly more difficult? I've never found myself thinking, "man, if I didn't have to allow the user to customize all these options, my life would be so much easier". Maybe it's just the way I work, but I've never heard any other developer share that sentiment.
As for options producing "bloated" code... pardon me if I'm blunt but, who cares? What will adding more options add to code size? Depending on the scope of the project, maybe a few thousand lines of code? How about to executable size? I don't think adding a few if statements will add more than a few K to the final executable size? Even if I'm being terribly optimistic with these figures, IMHO, it's worth it.
A piece of software is nothing more than a tool which a user uses to get a job done. Why would you want to restrict somebody's productivity just because you want to avoid bloated code? I mean, isn't that the whole reason VA exists in the first place? To increase speed and productivity? Why force somebody to have to "hit backspace twice" when that will invariably slow them down. At least it will at first. But you add up those few things that affect your productivity, and they can be quite annoying hindrences.
Maybe I'm mistaken, but wasn't VA created to add *more* options than the VC IDE natively provides? VC by itself is highly configurable, so the simplicity argument should have preempted VA from ever being embraced by devs in the first place. I don't think VA would have been nearly as successful if it wasn't as configurable as it is, and IMO, still not configurable enough.
Even if you still wanted to avoid complexity, there is a simple solution. Have preferences for Beginners vs. Advanced users. I'm aware of more than a few apps out there that successfully do that. You can have the best of both worlds.
Lastly, if you don't want to have to go and wade through 1000 options, don't. Nobody is forcing you to change the default settings. But why restrict that freedom from other people who do want to configure everything? If you really demand a simple GUI for preferences, then either create only a simple GUI, with a complementary ini file or something that the user can edit to their needs, or go with the Simple/Advanced options GUI.
Sorry for the diatribe. I'm sure it came across as antagonistic, but I assure you it's not meant to be. Though, I am curious as to what you, and others, have to say. I've never heard anybody make the argument that you have, so maybe I'm missing something you or others can fill me in on.
Cheers,
D |
Edited by - diarrhio on Jul 02 2004 11:51:50 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jul 04 2004 : 5:35:11 PM
|
*considers*
both Stephen and diarrhio make good points.
the main project i program at work has a load of options. it has to work in two modes:
* theoretical mode, where it has to conform to a long, complex and contradictory spec 
* real world mode, where the users hate just about every single feature that is required by the spec
this results in a separate (normally hidden) switch to turn on or off each major spec required feature. there are a lot of switches (options) as a result.
theoretically diarrhio is correct, this adds very little code. the problem is when you have to retro fit an option, you end up having to insert the check in 10, 20, sometimes 50 different places all through the code  don't tell me about code design, i inherited the original code base, and it has had a very checkered past 
adding a setting to a new option, this is normally quick, easy, and sensible.
the problem comes at the testing phase, since each option can add significantly to the pathways through the code that should be checked.
however, our testing department get around this by not testing most of them
also, it is down to limited resources. do we want WT:
* adding options
* bug fixing
* adding features
all right, back to the question.
presuming alt_g jumps to the definition, and then to the declaration on a second alt_g on function calls, and asks me for any complex case's i am happy without an option for this, since this default behaviour suits what i want to do 99.9% of the time.
for more contentious behaviour an option is a good idea. |
zen is the art of being at one with the two'ness |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Jul 05 2004 : 04:34:34 AM
|
Well, I didn't mean to start such a long debate! I've often thought that WT could have a separate forum for people to discuss general programming or Visual Studio questions. This would be a good example.
I accept there is often a difficult balance to strike between giving the users more options, and, as Uniwares said in another thread, making it a design decision. But there are always more options you could add, and somewhere you have to draw the line. To suggest that you can just add a new option whenever a user disagrees with a design decision is rather naive. You quickly end up with hundreds of options, and lose the coherence of your design. Personally I prefer to use a product that has fewer options so that I can configure it quickly. I'd rather it just did the right thing, or a right thing, without my having to worry about it.
The point about being "hard to debug" is easy to answer. There are often unexpected interactions between different options. If you have lots of options, testing can't feasibly test all combinations, and if a bug comes up, it's unclear what particular set of options triggered it. Furthermore, rarely-used options correspond to code which is rarely exercised. Such code can often be overlooked by developers and testers.
Having said all that, sometimes even people who understand the product well disagree about what the correct behaviour of a feature is, and then an option is certainly desirable. The skill lies in being willing to add options when they're useful, without scattering them around like confetti as a substitute for making any decisions. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
Edited by - Stephen on Jul 05 2004 04:35:37 AM |
|
|
|
diarrhio
Ketchup Master
53 Posts |
Posted - Jul 05 2004 : 2:34:37 PM
|
quote:
But there are always more options you could add, and somewhere you have to draw the line. To suggest that you can just add a new option whenever a user disagrees with a design decision is rather naive. You quickly end up with hundreds of options, and lose the coherence of your design.
I guess I should have addressed the main point of your original reply. I definitely agree with that... I should have been clearer about favoring more options instead of less, especially in cases where there seem to be two or more clear camps of users.
Can't say I really disagree with the rest of your points (both Stephen and feline). All good stuff.
Thanks for the discussion.
D |
|
|
|
Baga
Tomato Guru
122 Posts |
Posted - Jul 06 2004 : 01:52:40 AM
|
This topick seems to touch quite a number of sensitive areas... Anyway...
"... you have to draw a line ..." - fine with me, but i would be grateful if you allow me to see/access things below that line - like some .INI file. Comments/explanation welcome, but most of the time just descriptive names are OK.
"... hard to test ..." - true, but few companies have such a pool of loyal and motivated beta testers as WT does. Not that I want WT to dump untested code on us, but still - if I ask for a feature and they implement it, I will feel oblidged to test it to some extent. |
Edited by - Baga on Jul 06 2004 01:54:25 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jul 07 2004 : 6:47:41 PM
|
quote:
Originally posted by Baga
"... hard to test ..." - true, but few companies have such a pool of loyal and motivated beta testers as WT does.
i suspect that we are also responsible for most of the "impossible" bugs that WT is trying to deal with 
i know i have seen some real doozies in my time at this forum  |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jul 07 2004 : 9:16:11 PM
|
Yes, we prefer the least number of options that do not cramp your coding style. We always look for the chance to "do it right" without an option. If impossible, we buckle and add an option.
Fewer options imply fewer "if" statements in our code. The fewer, the more likely we don't mess up. Unlike standalone programs, our "if" statements are unusually complex because we must test for IDE environments and options -- there are a slew of them. If you see two options in our dialog, you can assume we have to test for ten. The combinations grow quickly.
We do like to test with and without setting relevant options. This implies we test with ours, and with those in the IDE. Very painful. We certainly are forced to do more than the average, standalone product. (Hint for those looking to create a product -- don't create an IDE add-in. Then again, you will have little competition.)
As for Alt+G, we believe Alt+G followed by Enter does exactly what was requested in the first place. VA X goes to the definition. (Assume the first item in a menu is where VA X would take you if it didn't open a menu.)
Alt+G followed immediately by Alt+G typically goes to the declaration. (We already considered the special case, ie the one suggested earlier in this thread.) |
Whole Tomato Software, Inc. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jul 10 2004 : 1:19:04 PM
|
this comment about alt_g followed by alt_g sounds interesting
*experiments*
alt_g alt_g produces a "don't do that" beep from VS .NET 2002
however, feeling inspired by this i have just found that sitting on:
sa|veDirectory(doc, xmlDirectory);
and pressing: alt_g enter
produces:
void CdIndexDirData::saveDirectory(mtQtDomDocument &doc, QDomElement &xmlDirectory)
|{
....
}
now pressing alt_g again moves me to the definition of this function  
all this time i have been manually moving my caret from the open curly bracket up a line, and into the middle of saveDirectory in order to get to the definition when i didn't have to.
it just goes to show, there is more to VAX than you might think. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
Topic Locked
