Unannounced features in 6733
- the "xml navigation bar" is great. You've proven to have mind reading capabilities: I thought about that feature but was too busy to file a Jira issue for it ;)
- VSS seems to shows files that aren't checked out, but are locally modified, in another color. Great! Idea still wants to check them in when commiting the project, though. Also they should probably appear in another changelist.
- Is the menu item "Open SourceSafe Explorer" also new? Great time saver. At least I haven't noticed it before. It should be in the editor context menu, also!
- Debugger tool window: I liked the layout from the previous build better. Most importantly I got used to doing single clicks on the the "sub-tool-window" titles to maximize them. Having to double click is slightly more work.
Anybody found more hidden goodies?
请先登录再写评论。
Stephen Friedrich wrote:
I too preferred the layout in #6708 (but I'm not such a fan as you of
the single-click action).
The new layout seems to have a lot of wasted vertical space,
particularly noticeable to the right of the Console tab (where the
toolbar contains, for me at least, just a single, disabled button).
Are tabs for the "Frames", "Variables", "Watches" and "Console" labels
really necessary? I don't think they're the correct widget if there'll
never be other tabs in the same tab groups.
It does make sense to have the toolbar buttons next to the views they
affect though.
--
Mark Scott
mark@codebrewer.com
This is indeed a nice feature. My only comment would be that the yellow buttons
are a bit hard on the eyes. How about displaying it with more of a breadcrumb
or XPath look using hyperlinks instead of buttons?
eg:
root / firstLevel / secondLevel / leaf
This has always been a feature with IDEA, at least with CVS. Perhaps this
was just a bugfix for VSS?
Chris
i don't really care wether i have to click once or twice, and wether it's tabs or not isn't really a difference. in my personal opinion, tabs look better, but i wouldn't run amok if it would have stayed the 6708-way.
what i like is the new layout of the buttons. it makes more sense.
For me the new layout is wasting too much space, the debugger window is
hiding too much code in the editor.
Maybe it would be better to have the buttons on the left side of each
window.
And I agree with Mark that tabs are not the correct gui element here.
The small title bar from #6708 seemed more 'right'.
Personally I think it is a waste of screen estate and I hope it will be possible to turn it off. For me it does not add anything. Just visual eye candy.
S.
The debugger takes up WAY too much space and it practically unusable on a screen that is 800 pixels high. Like most laptops. There barely is enough room to show some source code, the debugger view and the console.
There must be a better layout.
I have a bigger screen at the office but that is not really a solution. Many of us work on small screens or laptops.
S.
I think I agree. I think the current path/context within a document is usually
implicitly clear, there's no need to show it on the screen.
Here's a JIRA for turning breadcrumbs off: IDEA-11755
-tt
Full ack. Though ironically for me the situation is vice versa: My office monitor runs ast 1280*1024, but my notebook with 1900x1200.
It's quite usable on the notebook, but a pain on the other machine.
I don't want to think about running at 800px.
It's interesting to note that there is a fundamental problem lingering here:
A solution would of be to allow watches, variables etc. to be dragged around freely to other sides of the main window.
Ultimately however you'd be ending with a feature like Eclipse's views.
Currently there's a single debugger tool window that is shown and hidden automatically and has tabs for several debug runs. Nice and clean.
If we had those debugger windows everywhere (left, right, bottom, ...) you would loose the easy connection to a particular debug run and probably automatically hiding/showing everything would be too much, so that you need Debug and Java views to switch between.
There is actually more than enough room on the very lower left of the screen to put this path. Next to the view that shows the current line/character position. think that is a much better place for things like this.
S.
hiding too much code in the editor.
i have 2 monitors (16001200 & 12801024), so i can detach the debugger view and have no problem at all :)
i don't think there is a solution for this problem except buying a bigger or an additional monitor. you can't create unlimited space by changing the layout.
By changing the layout you can use the available space more efficiently. NetBeans, Eclipse and XCode all have no problems showing all relevant info for debugging on this 1200x800 screen. There is no reason why IDEA can not do the same.
S.
On 2007-03-01 17:44:39 +0300, Stefan Arentz <no_reply@jetbrains.com> said:
>>> For me the new layout is wasting too much space,
>> the debugger window is
>> hiding too much code in the editor.
>>
>> i have 2 monitors (16001200 & 12801024), so i can
>> detach the debugger view and have no problem at all
>> :)
>> i don't think there is a solution for this problem
>> except buying a bigger or an additional monitor. you
>> can't create unlimited space by changing the layout.
Please try clicking middle mouse button on any tab. That should help alot.
for me, eclipse does not use the space better - it wastes space.
it tries to show me anything all the time - code, console output, threads, the stack, variables and watches (which results in lots of (too) small windows), but in most cases i want to see only a few of them (in most cases console output OR variables/watches OR threads), and these should take as much space as possible. it's exactly what idea's double click on tabs inside the debugger view does.
to do this in eclipse, i'd have to create perspectives for every case.
What is the OS X equivalent of the middle mouse button?
S.
Stephen Friedrich wrote:
Perforce - you can now go to the Time Lapse and Revision Graph views of
Perforce from within IntelliJ - hurray!
I like that bar in XML files, but I would like to be able to navigate
back to where I was after I click an outer element.
Amnon
Totally agreed. That would solve many problems with debugger layout.
On 2007-03-01 13:02:50 +0300, Chris Miller
<chris_overseasNOSPAM@hotmail.com> said:
>> - the "xml navigation bar" is great. You've proven to have mind
>> reading capabilities: I thought about that feature but was too busy to
>> file a Jira issue for it ;)
Hello, Chris
Breadcrumbs colors were fixed to more suitable (light gray, etc) soon
after the initial commit, but this fix wasn't included into the current
EAP build, so please wait until next EAP.
Thanks.
--
Alexey Pegov
Java Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Bread crumbs are nice but I've noticed one thing about them - you can go "Back" but you can't go ... mmm ... "Back".
What do I mean - say, you have "A > B > C > D" and you click on "B". Now you only have "A > B" and you can't go to "C" or "D" anymore. Where breadcrumbs are implemented for Web navigation this makes sense (and even there, there's a browser's "Back" button) - someone who decided to return to one of his previous points in the flow - abandons the current one. But XML document context is somewhat different - someone who decided to go up in it's hierarchy isn't necessarily gave up on the point he was before a moment ago.
So what if after pressing "B" in above example we still had "A > B > C > D" but now "C > D" colored differently so that one could still click "C" or "D" and go there at any moment ? This way, one could easily go "up" and "down" in his document while today it's only possible to go "up" ...
Thank you !
Oh, I see Amnon (below) is also talking about it.
This is also already implemented.
Nice !
Dear Stephen,
SF> - VSS seems to shows files that aren't checked out, but are locally
SF> modified, in another color. Great! Idea still wants to check them in
SF> when commiting the project, though. Also they should probably appear
SF> in another changelist.
SF>
SF> - Is the menu item "Open SourceSafe Explorer" also new? Great time
SF> saver. At least I haven't noticed it before. It should be in the
SF> editor context menu, also!
Glad to hear it! I had a flu all last week and did not have an ability to
write this feature down in the announcement.
Another feature which will be available in the next release: when you have
some file opened for editing and in some moment of time it appeared to be
deleted from the server, it will be shown with a special coloring.
After our LocalVcs component will be ready, the huge ss.exe load will be
eliminated as well...
best wishes,
Michael Gerasimov,
JetBrains Omea Developer
PS. I remember your issue for deleting local files during update...
Me too!
Francesco
After using the debugger in 6733 a lot, I found that what I really dislike the most is how the "resume" and the "step over/into/..." buttons are separated.
I frequently step over/into a couple of statements, then resume, then on the next breakpoint repeat that scenario shuffling the mouse back and fro.