I disputed the most recent of these issues with the following comment: “Works as expected? Are you kidding me? That navigation bar is a mouse centric waste of space and there needs to be a setting to remove it! “
Yeah – because I ran out of PC politeness … although I did remove one word from the initial draft – that word was “useless”.
Nav bar: Two drop down button menus, and two combo boxes and a search button – all operable by mouse only – because that is how a coder works… with a mouse… and not keyboard short cuts… …sheesh…
Originally shared by Achim Kalwa
There are some entries in Quality Portal about enabling/disabling the Code Navigation toolbar:
https://quality.embarcadero.com/browse/RSP-12398
https://quality.embarcadero.com/browse/RSP-12511
And guess what:
“Closed”, “Works As Expected”.
Comment from internal system: Yes in XE8 the Editor Navigator Toolbar should be visible or hidden, but it has been changed. It works as expected now in Seatle 10. It will work in this way in the next versions
English is not my native language, so perhaps I don’t understand that comment. In XE8 there was a working option to enable or disable that toolbar; that option was removed in D10, and it will not come back with an update?
And BTW:
Even Embarcadero stuff has problems with the product name “Seattle”. See quote above.
Er, is it appropriate to mention Parnassus Navigator here? Keyboard shortcuts, no dropdowns, etc? Or am I spamming? I think the toolbar was written to copy Visual Studio, but IMO a better approach with these kind of things is to address the needs directly, not copy features, and sometimes you come up with a better solution. Which is the direct thought process behind why I wrote Nav. It did navigation in a way that suited me, keyboard-driven being a big part of that, and so a way I thought would suit other coders too thus making it available.
I directly addressed shortcomings with the toolbar in the initial blog post announcing it. I was a bit more polite about it of course 😉 but I do feel the toolbar is not a good approach.
I actually mentioned it in the dispute 🙂
I hate to be the EMB supporter, but they are right in the first situation. The issue that’s closed is filed as a “bug”.
To be able to show/hide a toolbar that is useless to you ( btw I totally agree that it’s useless, CNpack’s is much better) is a feature request, not a bug.
With that said, I personally find this toolbar annoying and I kinda found out that is also causing extreme lag while coding, especially while the Editor is initializing the auto complete popup.
The other issue is indeed a bug, and they are WRONG!
Apostolis Tympakianakis There is no UI in QP to file a feature request, and items are changed from bugs to feature requests by Embarcadero staff.
Edit: Isn’t CnPack’s toolbar pretty much exactly the same thing? It’s the same idea / concept / way of interacting, anyway?
Lars Fosdal I didn’t see that. But, thanks!
David Millington I know, I don’t impose that QP is perfect, not by a long shot.
CnPack’s toolbar is much faster/lighter for me, and it has two extra buttons, “Jump to Implementation” and “Jump to Interface” that I use frequently.
But the main thing is that you can choose to turn it off. Everybody codes in his own way, and space wasters such as this “navigation toolbar” should be optional.
/sub
This isn’t a bug report but a feature request. This is how it is in this release. I disagree that this will never change in the future, it might as well. I think there are good reasons to make it optional. We’ll see.
The Seattle navigation toolbar isn’t mouse-centric. Everything in it is accessible via keyboard shortcuts. See http://docwiki.embarcadero.com/RADStudio/Seattle/en/Code_Editor#Navigation_Toolbar
Just for the version: There is still some internal confusion with the name https://quality.embarcadero.com/browse/RSP-12381
Jacob Thurman There is no kind way of putting this: Double three-key combos are not shortcuts in my book, unless you count shortcuts to carpal tunnel syndrome – or compared to Ctrl+G||Enter as in Parnassus.
Marco Cantù Are you going to close all feature requests on basis they are not bugs? You seriously need New Feature issue type in QP.
I have been informed that it would somehow mess up your workflow, but seriously, change your workflow then. You had New Features and some other issue types besides Bug and Documentation Issue in Quality Central, so I really have hard time understanding what is the problem here.
I’m with Apostolis Tympakianakis . If they don’t want it to be hidden, it works as designed. You may like it or not.
Marco Cantù Might want to have a look at User Voice for feature requests. So you can use QP for bugs only
Markus Müller Dalija Prasnikar Adding a Feature Request type of issues in Quality Portal is planned and should happen in the coming weeks.
Marco Cantù Great!
That will be very useful and allow us to upvote the feature suggestions we like the most!
Marco Cantù Unless requesting the addition of Feature Request is considered a new feature and not a bug and gets closed. 🙂