Community
Participate
Working Groups
Build Identifier: Version: 3.4.2 Build id: M20090211-1700 Source dialogs, such as choosing which fields should have accessors generated, are modal. This prevents using the rest of eclipse, *even* other eclipse windows, to reference the code being worked on. This creates the following workflow: Source>Generate getters and setters... Try to look at those fields in the code Close the Dialog Look up the fields Source>Generate getters and setters... forget what we saw, repeat Reproducible: Always Steps to Reproduce: 1. Open Generate Accessors dialog 2. Without closing dialog, attempt to use eclipse in a useful manner
Is this for Java development or what?
This is intentional and won't be changed.
Workaround is to select the fields in the Outline view and then execute the command.
Actually, I'm quite OK with modal dialogs concentrating me on the task at hand and preventing me from changing anything in the background, that will eventually corrupt the status of the dialog. What I wish for would be more like a read-only view of the workbench while a dialog is open. You could allow browsing/scrolling/switching between open editors to leverage the established tools while working on the contents of the dialog. Of course the dialog would stay on top of the window (similar to the search on Ctrl+F), but at least you could move it aside. My primary use-case is writing a custom code-formatter snippet. Yes, that editor offers code completion, but an outline view of the class or a type-hierarchy are quite valuable. So often I end up closing the dialogs (plural!) multiple times (again plural!), looking things up and reopening again. This is especially tedious as the preferences dialog is in between. And if you are trapped under a stupid operating system you need to carefully plan, where you put that preferences dialog, so it won't cover the information you so heedfully scrolled into the background, while still allowing you to trigger the edit button. What a nuisance! Soon I copy over into a secondary editor that I can switch back and forth to. But this isn't ideal either, as I'm often waiting on a breakpoint in a debug session and want to execute my code right away to see if it works. In addition, the other editor cannot compete on code completion. Sometimes only the stupid notepad is available which doesn't even bring syntax-highlighting. On the other hand it might have an undo which is painfully missing in the details-formatter-editor. As an exercise please write a reflective formatter for JComponent that calls getText() on JButtons *and* JTextComponents ... nope, instanceof won't work, as you may not cast the JButton into a JTextComponent and vice versa ... oh and, as you cannot catch exceptions, make it foolproof to never throw an exception. I wonder how many aged Java-programmers get that code right in the first go without looking up Class? Can you type the fully qualified package name of Method ... code completion won't insert it for you, as it tries to add imports, which are just skipped in the scope of that editor. ... now you should understand my pains! A second use-case is the creation of a new class. I select the correct package in package explorer and trigger the dialog. Now I enter a class name, add a sub package name and damn ... what was the name of the abstract super class again? I derived from it the other day in class X which happens to be open. I should have scrolled the editor up to the top to see its declaration. So I discard what has been entered so far, only to scroll the already open editor. On the other hand, if I was attentive enough to scroll to the top, I see an unknown interface I want to look at or watch it's methods implementation hidden some lines below the screen, to decide if I need that interface. Third use-case try to set up a new project, tuning its properties by looking up properties of another project. If you do this more than once, you'll end up taking a bunch of screen-shots from the template project. For sure, there is always the "workaround", to predict and lookup all the information a dialog might request in advance before opening it. But that's not the way the human mind works, at least not mine. So I end up regularly stuck in a dialog with a question whose answer is hidden only because I didn't carefully scroll the editor to the right line. Another point of view might ask to improve all those mentioned dialogs by adding/overbloating features to better assist in these use-cases. But I really think allowing readonly interaction with the workbench in the background will be: - much cleaner (not duplicating available functionality inside a dialog) - more powerful (allowing access to tools not even thought of at design time of the dialog) - unobtrusive, as it won't disturb anyone used to the current behavior - self-explanatory, as the quasi-modal dialog stays in front to explain why the workbench is locked down - a productivity boost to many new dialogs to come working out of the box To conclude: Strict modality should be reserved for simple dialogs like error messages and confirmation-requests which popup automatically. Whenever there is enough content inside to justify a dedicated entry in the help system for explanation, it's a predestined candidate for quasi-modality!
