Reading Seva Lapsha's blog got me thinking about my multi-monitor screen usage today. In the past, depending on the type of work I'm doing, I might have one monitor for code and another for testing... eg., Eclipse + a browser for web testing, or main dev Eclipse + a second eclipse for plugin testing, etc.
Or multiple Eclipse instances sharing plugins (one with a workspace which actually contains plugins, the other with a second, empty workspace in which the other projects are imported with Import > Existing Projects). (Why? To keep the contents of the workspaces smaller and to make startup faster, esp. considering bugs like this happy li'l PDT bug.) :)
Since the Eclipse 4.0 path has now started, here's a few ideas for ways to improve the UI experience. I'd like to see Eclipse one day work like GIMP, where detached views show up in the task bar (or maybe they do, it's just KDE that's filtering them? -- I can ALT-TAB between detached windows, but I only see one Eclipse item in my task bar). Or allow detached views to dock against each other into composite view blobs like they do when they're not detached. Or allow me to grab a set of docked tabbed views and detach them all in one go, instead of having to drag each one out, one by one. Or, even better, just let the whole editor area be detachable. And while we're at it, how about the toolbars?
If anyone else agrees with these ideas, please consider opening a bug to track them. Or better yet, bug your PMC so you can become a committer on E4 and contribute to the work effort.
At any rate, I agree with Seva: putting all your panels on one screen and the editor on the other is certainly a handy way to take advantage of all those extra pixels, esp. when your 20" 1600x1200 monitor dies and you're stuck dropping back to a 19" 1280x1024 one. :(
3 comments:
"I'd like to see Eclipse one day work like GIMP"
You lost me there. GIMP has one the most horrible user interfaces ever, especially for graphics software.
But if this were implemented in a way that doesn't bother users who don't want it, I wouldn't mind if this feature existed.
putting all your panels on one screen and the editor on the other is certainly a handy way to take advantage of all those extra pixels, esp. when your 20" 1600x1200 monitor dies and you're stuck dropping back to a 19" 1280x1024 one.
Good post, but I have to disagree about this one. I'm regulary pissed off by people simply "using the space inside their screen", and therefore writing their code and javadoc 150 characters wide. And it is not going to be better due to all these wide screens invading the workplace. I thought this was an evidence that code has to fit in 80 characters. It has nothing to do with back-compatibility with punch cards but with readability. Where is the last novel you read printed with 120 characters per line? I don't remember having seeing one. I would rather like having some plugin that constrain the editing to a certain number of characters - the 80 characters boundary is even part of the eclipse coding guidelines (http://wiki.eclipse.org/Coding_Conventions, see Sun's Coding Conventions)!
Sorry for the rude post ;) Maybe this topic should be discussed in the newsgroups.
I agree that horizontal scrolling is evil, and that in an ideal world all lines would wrap/break around 80 chars...
However, this is not an ideal world, and there are no Sun Coding Conventions for the umpteen OTHER languages supported in Eclipse. For example, the Ant editor regularly takes narrow, nicely formatted broken lines and removes whitespace so that every task is its own much, much wider line (if you use ESC,CTRL-F to autoformat).
That said, who in their right mind *PRINTS* code? What is this, 1975? You can't compare the hardcopy format of a book to the softcopy format of a text editor. They serve different needs, and as such, are formatted (and used) differently.
No offense taken, BTW. As to where to have such a discussion, I suggest opening a bug against the various editor(s) that don't support setting a print margin / line break width, if you see it as something that needs to be fixed. Making the tools default to following conventions would go a long way toward forcing people to code to those conventions.
Post a Comment