IDEA Background Tasks (As of IDEA 6.0.3 build 6141)

IDEA Background Tasks (As of IDEA 6.0.3 build 6141)
or
How to get IDEA to maximize user's investment in
Intel® Core™ 2 Dual and Quad processor workstations, and
maintain IDEA's status as the professional's choice for
java development.
-



*Introduction
-


*

Intel and AMD dual core workstations went mainstream in 2006, and I would
expect most professional developers to be using dual core machine by the end of
this year or soon after.

Intel reported its results this week, and said that Intel® Core™ 2 Duo made up
over 50% of total and 90% of performance Q4 microprocessor shipments. And they
expect to ship 1 million Intel® Core™ 2 Quad processors by the middle of next
year.

When you have a dual-core desktop, you can do two or more things at the same
time, e.g. edit/browse your code while you run a search/analysis/compilation,
or you can do one thing up to 50% faster. Jetbrains needs to enhance IDEA to
allow the user to take full advantage of both options.

In IDEA 6.0, several major improvements were made in this area, and from
the looks of Selena roadmap, some more are coming.

      • General->Search in background -- If enabled the Find in Path and Structural

Search will now happen in the background, i.e. no modal progress dialog is
displayed.

      • Version Control->Perform update from VCS in background,

Version Control->Perform commit to VCS in background,

      • File Synchronization is now in the background.


In the following sections, I am going to discuss changes which can make
launching background tasks more pleasurable and better utilize all our shiny
new Intel® Core™ 2 Dual and Quad core processor workstations.

Previous Post: IDEA Background Tasks (As of 5261)
http://www.intellij.net/forums/thread.jspa?threadID=222675

22 comments
Comment actions Permalink

*Step 1
-


*

First off, every Jetbrains developer working on IDEA needs be working on a dual-core
workstations, if they aren't already. Sometime during 2007, you should purchase some
Intel® Core™ 2 Quad workstations, too, for testing before IDEA 7.0 ships.
And how about a couple Sun Fire T2000 Server with 32 processing threads
(http://www.sun.com/servers/coolthreads/t2000/) for running TeamCity?

0
Comment actions Permalink

*Current Behavior
-


*

I need to first clarify what it means to run a task in the foreground and
background, both as currently implemented in IDEA, and the desired behavior.

Let's take an example.
1. Start with Setting General->Search in Background turned off.

2. Run Find in Path, enter some text which will result in many matches like "
Integer", and click Find button. (or hit ENTER).

3. Two things happens:
a. The "Find - Occurrences" results window is displayed which immediately
starts showing the match results as they are found.

b. A modal progress bar dialog "Searching in project..." pops up with a
Background and Cancel button.

4. If you hit the Background button, two things happen:
a. The modal progress dialog goes away, replaced by progress updates in the
status bar. (There is also a red cancel button in the status bar to cancel
the command.)

b. IDEA automatically sets your Setting General->Search in Background so
that all future searches are in the background.

Ok, now repeat the above exercise, except this time start with "General->
Search in background" turned on.

1. Start with Setting General->Search in Background turned on.
2. Run Find in Path, enter some text which will result in many matches like "
Integer", and click Find button. (or hit ENTER).

3. Two things happens:
a. The "Find - Occurrences" results window is displayed which immediately
starts showing the match results as they are found.

b. The status bar shows the progress of the task, and there is a red cancel
button to allow the user to cancel the task.

4. At the conclusion of the Find in Path, the "Find - Occurrences" results
window steals the focus.

Most of IDEA's tasks (compilation, ant task execution, inspect code, etc.) work
similar to the above. What I want to point out is that all of these commands
are not really running in the background. All that is different when you enable
"Search in background", "Compile in background", etc. is that the modal progress
dialog is replaced by progress reported in the status bar.

The tasks are still behaving as interactive tasks performed in the foreground
because they are displaying their message or results window and they are still
stealing the focus upon completion of the task.

*So what "Search in background" really means is just "Show search progress in
the status bar instead of in a modal progress dialog", "Compile in background"
means only "Don't lock up the console while compiling."* From this perspective,
IDEA currently does not truly run any search, compile, ant tasks, etc. in the
background -- they are still running in the foreground. Only the task progress
updates have been moved into the background. The only task I would classify as
truly a background task is the file synchronization (as of 6.0.3).

Okay, so that is what IDEA is doing today.
Now, I am going to talk about how it can be improved.



Attachment(s):
find_in_path_foreground.png
0
Comment actions Permalink

That's all nice and well, however AFAIK very many tasks are not so much
CPU bound, but are doing lots of disk IO (take a look at the large cache
files Idea is building on disk).

Performance suffers dramatically when two processes are doing disk access
concurrently.

0
Comment actions Permalink

*Definitions
-


*
First, there are some differences between the types of tasks that IDEA runs.
There are tasks like compilation, ant task execution, and vcs which perform a
non-interactive operation. All of these have output message windows, but the
output is usually not interesting unless there is an error. I will call these
INTERACTIVE_ON_ERROR tasks.

There are other tasks which are interactive because they output information in
a results window which the user is expected to examine/interact with. Examples
of these types of tasks are Find in Path, Find Usages, Inspect Code, Analyze
Dependencies, Locate Duplicates, etc. I will call these INTERACTIVE tasks.

Within that last group, some of the analyze tasks can take minutes or hours to
run when the scope is large. Even though their output is interactive, the user
won't want to keep these in the foreground. The user will continue on with
other work, and then click on the results window when the task is finished.

There are also NON-INTERACTIVE tasks such as file synchronization and the
hilighter thread (mr. inspector). The file synchronization thread currently
provides no feedback that it is running. The hilighter thread displays an eye
at the top of the gutter bar on the right-hand-side of the Editor pane.

0
Comment actions Permalink

*No modal progress dialogs
-


*

All tasks should always run in "background", i.e. show the progress in the task
bar instead of popping up a modal progress dialog which locks the console.

For tasks which already have a "Perform X in 'background'" setting, this
setting can just be removed.

Jetbrains seems to acknowledge the ridiculousness of this setting themselves,
because they silently flip "Search in Background" setting ON as soon as you run
one search in the background.

We have IDE Settings General->Search in Background, Project Settings Compiler->
Compile in background, Version Control->Perform update from VCS in background,
Version Control->Perform commit to VCS in background, and Ant Settings (per
build.xml file) Make build in background. All of these settings default to OFF.
It has been annoying that for each new project and each new ant build.xml added,
we have to flip the background setting to ON. Before this gets even more ridiculous
with "Perform Find Usages in Background" "Perform Analyze in Background", etc.,
let's just get rid of all these settings.

For tasks which don't even allow running in the background, e.g. Inspect Code,
Analyze Dependencies, Locate Duplicates, etc., these tasks need to be enhanced
so they can run in the 'background'.

The users with dual core workstations are even more annoyed with tasks with
modal progress dialogs because they have one cpu sitting idle while IDEA is
blocking input! I personally use the Inspect Code feature less than I would
like because I can't launch it in the background while I do other work.

0
Comment actions Permalink

*INTERACTIVE_ON_ERROR tasks should run in the background (for real!).
-


*

The INTERACTIVE_ON_ERROR tasks, e.g. compilation, ant task execution, and vcs
should by default run in the background (in the true sense of the word), with
the results window only popping up in there was an error. The status bar would
still show the progress of the command. The results window would still get
created and populated in the case the user wanted to review it even after
successful completion, but it won't be automatically displayed unless there
is an error.

As of 6.0.3, almost all of these tasks which display a results tool window will
steal the focus upon completion, changing the focus to the tool window. Some
even steal the focus at the start of the task also. I guess someone thinks
these are features? I find the behavior very annoying.

For example, I have a keybinding for one of my Ant tasks "deploy_server". If I
invoke "deploy_server" ant task while the focus is in my editor pane, then I
see the "Messages - Ant Build" tool window popup, and this tool window grabs
the cursor focus. If I click back on my editor to continue working, the "
Messages - Ant Build" tool window grabs the focus again upon completion of the
ant task.

If I have the "Close message view if no error occurred" checked for this Ant
build.xml properties in the "Ant Build" tool window on right-hand-side of IDEA,
then upon successful completion of the command, the focus is stolen by the "Ant
Build" tool window. (I guess because the Messages - Ant Build window is
disposed?)

Even for the INTERACTIVE tasks, I see dubious value of the task stealing the
focus to the results window upon completion. Since even INTERACTIVE tasks can
take a long time, I may be working on something else when the command completes.

0
Comment actions Permalink

*Status Bar and Task Manager Tool Window
-


*
The status bar should show the progress of the last background task started. If
this task is finished, then display the next most recently launched background
task, and so on. Basically the background tasks are pushed onto a stack, and
when a task is finished, it is removed from the stack. Only the current task at
the top of the stack has it's status display in the status bar. Then, it is
clear which task you are canceling if you press the big red cancel button
in the status bar.

Add a new Task Progress tool window which would show the progress of all
background tasks. This will look similar to the Eclipse Progress View. Each
background task should show progress and have a cancel button. Also, clicking
on the progress could take you to the corresponding results toolwindow.

All tasks, e.g. hilighter thread, file synchronization, compilation, ant task
execution, find usages, inspect code, etc. should show up in the Task Progress
toolwindow. The current state of each task will be visible, e.g. "Running",
"Queued", "Suspended", etc. The user will have button to cancel each task.

0
Comment actions Permalink

*Message/Results window need to have consistent toolbar status/actions.
-


*
If the results window for the task is being updated to reflect the currently
found results, it should also give indication that the command is still running
and have toolbar button to stop it.

The Ant "Messages - Ant Build" message window has a good implementation because
it has three buttons to control the task:

Run/ReRun (green double arrow) - This button can be used to rerun the task.
While task is running this button is disabled.

Stop (red square) - This button will stop the task, while keeping the messages
window open with all the output accumulated up until that point. When the task
is finished this button is disabled.

Close (red X) - This button will stop the task and dispose of the message
window.

Some of the other message windows for other tasks behave differently.

For example, the "Find - Occurrences" message window for the Find in Path
command only has the "Rerun" and "Close" button and no "Stop button".
Furthermore, the "Rerun" button remains enabled even while the task is already
running and the "Close" button disposes of the message window but the Find in
Path task continues running until completion! (You can see the Find in Path
task still running in the status bar even though the "Find - Occurrences" window
has been disposed.)

For example, the "Messages - Make" window used by Compiler task has the "Stop"
and "Close" buttons but no "Rerun" button. The main issue is that the "Stop"
and "Close" buttons should be on each window and should have consistent
behavior.

0
Comment actions Permalink

*Background Task Priority
-


*

When launching some tasks, esp. Inspect Code, I would like to optionally
set a priority:
Low - Task should be suspended if other tasks are running.
Normal - Task should just run without interruption, but should only use a
single thread.
High - Task should split into multiple subtasks to speed up processing. (
Default 2 subtasks). Only if the task supports divide and conqure
subtasks; otherwise it behaves as Normal priority.

The user should be able to set the default value in the Settings. If you
have a single core computer, you will stick with Normal. If you have a dual
core or higher workstation, you would pick High.
When launching some of the long running analyze tasks like Analyze Dependencies,
Locate Duplicates, Inspect Code, etc. I would like to be able to change the
priority right there in the task launch dialog and appy it to only this
invocation.

For example, I use ALTSHIFTI shortcut to automatically run Inspect Code
on the current file with the editor inspection profile. I would want this
to run with High priority which would be my default.
But, I might want to run an Inspect Code on a whole package(s) which I know
will take minutes, so I might want to set the priority to Low and launch it
in the background.

Any task launched with Low priority would be launched in the background (for real!),
with the results window not popped up automatically and no focus stealing upon
start or completion. I will know the task completed when the status bar is empty,
and then I can click the Inspection tab to see the results.

For other INTERACTIVE tasks which usually tend to be short in duration like
Find in Path, Find Usages, etc. it may not be worth it to display a Priority field
in the task launch dialog, but you could for completeness.
For NONINTERACTIVE_UNLESS_ERROR tasks, like compilation or ant tasks, I think these
would just use Normal priority.

The priority should be visible in the Task Progress window. Ideally, you
should be able to adjust the priority of the task, but that may not be feasible.
It would be nice, for example, if I originally launched an Analyze task as Low
priority, if I finish my other work and become impatient for the results, then
I can bump it up to High priority.

For some tasks, there may be no difference between Normal and High. The UI
could allow High for any task, but it would be up to the task's implementation
whether it supported it or not.

This priority tagging may also be useful for the TeamCity product to prioritize
jobs, or do they already support this?

0
Comment actions Permalink

*Setting - Hilighter Priority
-


*

Currently, when you switch from IDEA to another application, the hilighter
thread is paused until you switch back to IDEA. For example, trying loading a
large file into the editor pane and then switch to another application before
the hilighter is still running. Notice IDEA's cpu drops to 0% after you put it
into the background. IDEA suspends the hilighter thread until you put IDEA back
into the foreground.

At a minimum, I would like IDEA to continue marking up the current file even if
IDEA is no longer in the foreground, because most of the time when I switch
back to IDEA I will want to look at that file. And now with dual core machines,
this hilighter thread won't impact as much whatever else I am doing in the
foreground.


You could go a step farther and let IDEA "look ahead" by marking up files IDEA
thinks the user might look at. You could have different levels like this:

Hilighter Priority:
Low - Run Highlighter on current file in Editor and only with IDEA in
foreground.
Normal - Run Highlighter on current file in Editor.
High - Run Highlighter on all files opened as tabs in the Editor and keep
them up-to-date. (Max 1 parse at a time, and file in the current tab
has precedence.)
Extreme - Same as High, but also lookahead by loading and highlighting files
listed in Find Results and Inspect Results. (Max 1 parse at a time,
and file in the current tab has precedence.) There would have to some
limit to this, though.

For example, if I have it set to High. From my Project Tree, I click several
files, causing them to be loaded as tabs into the Editor. Currently, if the
hilighter doesn't finish on a file before another one is loaded as the current
file, the hilighting is suspended for that tab. With the new behavior, the
hilighting would be suspended while the new current file is highlighted,
but then IDEA will go back and finish hilighting all other open tabs unless
I click another file.

As another example, if I have it set to High, and I run Inspect Code on a package.
Then I invoke a quickfix which modifies 10 files, some of which are loaded in the
editor tabs. IDEA will reparse and mark up those modified files in the background
as idle time permits.

This might seem kind of wasteful, but if you have spare cpu cycles to spare, it
is nice if IDEA highlights these files because then if I click back on them,
the inspections have already been been marked up.

0
Comment actions Permalink

*Setting - Parallization Num Subtasks
-


*

I would like to specify how many maximum number of subtasks (threads) a task
can be subdivided into (if supported). This setting is used for tasks with
High priority.

For example, if the user has set Maximum Number of Subtasks to 2, and the user
runs Inspect Code on a package, then the Inspect task could divide the work
into up to 2 subtasks. The unit of work could be each file/class in the package.

0
Comment actions Permalink

*What does Eclipse Do?
-


*

Eclipse did a major overhaul in 3.0 M9 to add a new UI framework for background
operations. See http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-responsiveUI.htm
In particular, Eclipse properly shows two or more background tasks in the Progress window.
(see attached pics).

I don't know the nuts and bolts of how well it works, but on the face of it it seems Eclipse
has a better thought out framework for scheduling multiple background tasks.



Attachment(s):
eclipse32_waiting_for_build_workspace_to_complete.png
eclipse32_progerss_bar_multiple_tasks.png
0
Comment actions Permalink

*Open API ??
-


*
Depending on what is done, you may need to expose some of these task features so
plugin developers can take advantage of them.

Eclipse also an API contained in org.eclipse.core.runtime.jobs to allow 3rd party plugins
to schedule jobs to run asynchronously.
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/guide/runtime_jobs.htm
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/guide/runtime_jobs_scheduling.htm

They have provision for job states (waiting, running, sleeping, none) and job priorities
(interactive, short,long,build,decorate). This would be useful for Jetbrains to peruse for implementing
their own version of this.

  • INTERACTIVE jobs generally have priority over other jobs. They should be short-running or low on processor usage, so that they don't block other INTERACTIVE jobs from running.

  • SHORT jobs typically complete within a second, but may take a little longer. They run in the background and have priority over all jobs except INTERACTIVE jobs.

  • LONG jobs are for longer running background jobs. They run only after INTERACTIVE and SHORT jobs have been run.

  • BUILD jobs are for jobs associated with building tasks. They are a lower priority than LONG. BUILD jobs only run when all LONG jobs are complete.

  • DECORATE jobs are the lowest priority in the system. They are used for tasks that provide information that may help supplement the UI, but that the user is not generally waiting for.

0
Comment actions Permalink

Then, it is clear which task you are canceling if you press the big red cancel button
in the status bar.


If the current thread is finishing and the next one occurs, you may
accidently cancel that one. At least this often happens for me when closing
an application: I launch another one, switch back to the old one, click in
the right top corner and the new application which suddenly pops up in front
will be closed.

Tom

0
Comment actions Permalink

Ok, after trying out Selena EAP and trying some things out, I realized that
all the Analyze commands (inspect,analyze dedendencies, locate duplicates, etc.)
behave differently from the all the Search commands, i.e. Find in Path, Find Usages, and Structural search.

Inspect Code et. al. do not immediately create the results window and start populating it. All the analyze tasks wait until they are finished, and then they create a results window and populate it, and then steal the focus to that window.

--

For all the Search commands, I still see no point in every displaying the Modal Progress Dialog, because these commands always create the find results window immediately, and populate it as the results come in, so they user is already getting feedback about the progress of the command.

But with the Analyze tasks, if they are not going to show the results immediately, then I think by default you still need to show the modal progess dialog, mainly so new users won't be confused.

For Analyze tasks, it would still make sense to have an option "Analyze in the background".

Also, I might like an option "Display Results upon Completion" (default ON). If I
didn't care for the results window to popup and grab focus, I could uncheck this.

This is related to the discussion about task priority. If you allow the user to set
a Task Priority, then the Low priority could automatically not display results upon
completion.

It's almost like if the task is going to take more than 30 seconds or long enough to where my attention is going to diverted to working on something else, then I no longer want the results pane to automatically pop itself up and grab the keyboard focus when I'm in the middle of something else.

You may be able to use balloon tooltips to good effect, e.g. popping up "Inspect Code: complete." tooltip above the processes activity icon in the status bar.

0
Comment actions Permalink

*Selena (as of 6656)
-


*

I tried out the Selena EAP today, and I was pleasantly surprised that Jetbrains
has already background-enabled more commands, and reworked the status bar
with a new Processes window to show the progress for multiple commands running
concurrently.

Find Usages, Inspect Code, Analyze Dependencies, and Locate Duplicates all
now have a Background button on their modal progress dialogs! That's a big
improvement!

Not only that, you can already launch multiple Analyze jobs in the background
and monitor their progress in the "Processes" window.

*General
-


*

  • I would recommend to use the word Job or Task or Command rather than Process

because Process term is closely tied to Operating System Process.

  • After starting a couple jobs in the background, I popped up the Processes

window, and then I switched IDEA to the background. Quite often, when I
switched back, IDEA appeared to be frozen. The UI eventually came back but
after a minute or more. During this time, I could switch to other applications
like Firefox instantly, so it didn't appear to be a system problem. The
workstation is a Intel dual-core with 4 GB memory. I don't know if the issue
is a thread priority problem, or what. If I never switched IDEA to background,
I never saw a problem.

*
Status Bar
-


*

The Status bar looks good. If you have one command in the background, the name
of the task appears in the status bar. If more than one task is running, it
will say "2 processes running". You can click the text to popup the Processes
window.

There is also a cancel icon and a circular progress icon that animates when at
least one background command is running. The cancel icon goes away if more than
one job is running, so you can't accidentally cancel the wrong job. With
multiple jobs, you have to pop up the Processes window and then pick the one to
cancel.

  • Cancel icon -- The icon used to stop a task is a grey circle with a white X

in the middle. This is the same as found in other parts of the UI like the
settings search box. But this is different from toolbar icon on the
Compilation and Ant Task tool windows used to stop the job; There, a Red Square
icon is used. I think the red square icon is more appropriate. The grey circle
X seems almost too peaceful looking -- shouldn't it have a little more
dangerous look to it like the RCOD (Red Circle of Death) icon? :) In any case,
I would use the same icon on Compile/Ant Task as here, either way.

*
Processes window
-


*

Each task in the Processes window is displayed with a title description,
progress bar indicator, and detail description of the current file/class being
processed, e.g.

Analyzing package dependencies


  • I would rename this to "Tasks/Jobs/Commands" or "Task/Job/Command Progress"

or "Task/Job/Command Manager/Scheduler".

  • I didn't really like that the Processes window popped up in the middle

of the IDEA. Since I had to click on the status text "2 proceses running" text
or the spinning progress indicator in the status bar, shouldn't the window be
anchored to the status bar? Then, I don't have to move my cursor from the
status bar to the middle. But I guess if you add a keyboard shortcut to popup
the processes window, it is a moot point.

Also, it was odd that the Processes window was a popup window rather than
a tool window docked on the bottom. But, after the initial strangeness, I
liked it because if it was a tool window on bottom, it is likely you already
have a results/message window there and you would have to switch between it
and the progress toolwindow.

  • One thing I noticed is that if I specify a Scope for an analyze task, then for

awhile it will just say "Scanning scope..." in the topline. I think the
topline should always contain the main task name, e.g.

Instead of :

Scanning scope...



Analyzing package dependencies: Scanning scope...


  • You may be able to make good use of balloon tooltips anchored to the spinning

progress icon in the status bar. You could have a popup display a message when
a task was done, possibly only for longer tasks, e..g > 10 seconds. For example,
"Analyze task: " done. This would have to be optional, as some people
might not like it.

0
Comment actions Permalink

One more correction! All the Search commands display the Results tool window only once the first match is found.

If nothing is found, then the results tool window is never displayed. Instead an error dialog pops up. For example, Find in Path will say "No occurrences of 'string' found' in Project.", and Find Usages will say "No usages found in Project and Libraries."

So it is not true that the search results window immediately pops up, so there is a similar issue to the Analyze commands that new users might be confused if the modal progress dialog isn't there by default. So, it seems I've now come full circle on this! LOL

Compilation and Ant Task Execution always display the message window, so I still believe those commands never need to show the modal progress dialog. But, I would like a new setting esp. for ant tasks called "Execute Ant Tasks in background" which really does run the ant task in the background, i.e. no message window pops up unless there is an error.

0
Comment actions Permalink

Below I will summarize the remaining changes desired for IDEA 7.0, based on
the current Selena EAP 6656.


*UI General
-


*
- Terminology - I would recommend to use the word Job or Task or Command rather than Process
because Process term is closely tied to Operating System Process.

- Terminology - Change naming of "XXX in the background" to "XXX Progress in background."
or "XXX Progress in Status Bar", e.g. "Search Progress in the background".
This would better describe what this setting does.


Also, I wonder if you could just collapse all of these settings into a single one
"General->Command Progress in the background"?

*
Find in Path, Structural Search, Find Usages
-


*

BUG - The Close toolbar button on the "Find - Occurrences" and "Find - Usages"
windows close the results window but don't cancel the search task running in
the background. The search task will just keep running to completion!

Consistency - The "Find - Occurrences" and "Find - Usages" tool windows need a
stop button similar to the Compilation/Ant task execution windows.

Consistency - The ReRun button should be disabled while the search is running, to
match behavior on Compilation/Ant task execution windows.

Consistency - For some reason, while one Find in Path command is running, you
cannot launch another Find in Path command. Can this be relaxed now? Other
commands like Inspect Code are allowed to be launched multiple times.

Settings - General->Search in background should be renamed to
"General->Show Search Progress in Status Bar" to better reflect the meaning of
this option.

UI Standards - As soon as you click the Background button on one Search, IDEA
silently turns General->Search in the background option ON. This non-standard,
unintuitive behavior. (IDEADEV-8727,Evgeny Goldin).

I would almost say this setting should be removed all together, except since
the display of the results window is not coincident with the start of the
operation (only displays if and when there is a match), this may be confusing
for a new user, so the modal progress dialog should still be shown by default.
Still, IDEA shouldn't automatically modify this setting without prompting the user.

See related "Backgroundable operations should have an "always run in background"
checkbox on their progress bar" (IDEADEV-11588,Dave Griffith).

Useability - Stop Stealing Focus.
All the Search commands will steal the focus from the Editor pane to the "Find -
Occurrences" or "Find - Usages" window when the search is completed. I guess
the original thought was to move the cursor to the results window so you can
navigate to the ones you are interested in? But even with the cursor stealing,
I find it faster to use Goto->Next Occurrence and Goto->Previous Occurrence which
jump to the first match. I think it is better to not steal the cursor focus
automatically, so in cases where a search takes a long time, and the user starts
working on something else in the meantime, IDEA doesn't interrupt their workflow.

*Analyze Commands (Inspect Code, Analyze Dependencies, Locate Duplicates)
-


*
Settings - We need a setting "General->Show Analyze Progress in Status Bar".

Useability - Stop Stealing Focus.
The Inspect Code commadn will steal the focus from the Editor pane to the
"Inspection - Results" window when the inspection is completed. I guess the
original thought was to move the cursor to the results window so you can select
the ones you are interested in? This wasn't an issue when the analyze tasks
were running the foreground pre-Selena EAP, but now it is a nuisance.

I try to use the keyboard instead of the mouse, but even for me, I just
use Goto-> Go Next Problem and Goto->Go Prev Problem to navigate the
results. Goto->Go Next Problem takes you right to the first problem
whereas the automatic cursor stealing puts the cursor at the top fo the
inspection results tree, requiring you to open multiple levels of
subfolders to get to the first problem.

The downside of always stealing the cursor focus is that in cases where
the analyze takes a long time, the user is likely working on something
else, so IDEA's cursor stealing can interrupt their work. And most
Inspect Code and other analyze tasks very often take minutes to complete.

0
Comment actions Permalink

*Compilation
-


*

New Feature - Build->Make Project doesn't get listed as a background job.

Settings - "Compile in background"
1. This should be an IDE setting not a project setting.
2. The default should be ON.
3. I don't see a need for this option because modal progress dialog adds no
value even for new users. Make Project always shows the "Messages -
Make" message window immediately, so the user is already seeing the
progress in that window.


Settings - "Only open Message View on error"
There is a setting "Close Message view if no error occurred" which closes the
tool window automatically if no errors occurs. This is OK, but the fact that
it opens the tool window and then closes it is annoying. What I really want is
"Only open Message View on error" (default OFF). If enabled, when the user
starts a compilation, no message tool window is opened unless an error occurs. (
The messages window should still be created in case the user wants to review
the log -- it just isn't' popped up if there were no errors.)
What I like about this option is that compilation will become a
truly background task (unless an error occurs) since no message window
would be displayed and therefore no cursor stealing is going on.

Usability - Stop the Cursor Stealing.
The "Messages - Make" window currently steals cursor focus from the editor
pane at the start and at the end of compilation. I don't understand why
it is doing this? The cursor should stay exactly where it is. This is
more noticeable when you use a keystroke to start the compile and also if
you compile is long so that you are often back in the Editor pane when the
compilation finishes. Please stop IDEA from stealing the cursor focus or
make this an option "Compiler->Focus Message View at start of compilation"
and "Compiler->Focus Message View at end of compilation"

*Ant Task Execution
-


*
Note: Items closely parallel those for Compilation.

New Feature - Ant tasks don't get listed as a background job.

Settings - "Make build in background"
1. This is poorly named. Should be "Execute Ant Tasks in background"
2. This should be an IDE setting not a per build.xml setting.
3. The default should be ON.
4. I don't' see a need for this option because modal progress dialog adds no
value even for new users. Executing an Ant task always shows the "Messages -
Ant Build" message window immediately, so the user is already seeing the
progress in that window.

Settings - "Only open Message View on error"
There is a setting "Close Message view if no error occurred" which closes
the tool window automatically if no errors occurs. This is OK, but the
fact that it opens the tool window and then closes it is annoying. What I
really want is "Only open Message View on error" (default OFF). If enabled,
when the user executes an ant task, no message tool window is opened
unless an error occurs. ( The messages window should still be created in
case the user wants to review the log -- it just isn't popped up if there
were no errors.)
What I like about this option is that ant task execution will become a
truly background task (unless an error occurs) since no message window
would be displayed and therefore no cursor stealing is going on.


Usability - Stop the Cursor Stealing.
The "Messages - Ant Build" window currently steals cursor focus from the
editor pane at the start and at the end of compilation. I don't
understand why it is doing this? The cursor should stay exactly where it
is. This is more noticeable when you use a keystroke to start an ant task
and also if the task is long enough so that you are often back in the
Editor pane doing something else when the task finishes.

Please stop IDEA from stealing the cursor focus or make this an option "
Ant->Focus Message View at start of ant task" and "Ant->Focus
Message View at end of ant task". Note that this problem still occurs
even if "Close Message view if no error occurred" is enabled; What happens
in that case, is the Ant build.xml tool window steals the focus instead
upon completion of the ant task.

0
Comment actions Permalink

*
File Synchronization
-


*

New Feature - File Synchronization should be shown as a background process so the user could
monitor it. Currently, it is great that file synchronization is in the background, but it should
be more obvious when it is going on.

New Feature - In Selena EAP 6656, I still sometimes see a modal progress dialog popup with the
title "Updating Modified Files..." and progress text "Parsing files. Please wait.." This seems to
happen when there are new files in my workspace. So, it seems not all file synchronization is
in the background yet.


*Printing
-


*
New Feature - File->Print can take awhile if you are printing out multiple files. It would be nice if
this had a Background button also. (IDEABKL-2762, Robert S. Sfeir)


*Hilighter (Mr. Inspector) Thread.
-


*

Performance - Hilighter thread should continue to run even if IDEA is in the background.
May require a setting?

Performance - See discussion above about proposal to offer additional more aggressive
hilighter like always keep all files with open tabs hilighted, not just the file in the active
tab, and possibly lookahead hilighting of files returned in search results, compilation errors,
analyze stacktraces, etc.


*Loading a Project
-


*

New Feature - Is it possible now to make the loading of a project in the background? (IDEABKL-4490,Victor Grazi)

*Processes window (Selena EAP 6656)
-


*

- I would rename this to "Tasks/Jobs/Commands" or "Task/Job/Command Progress"
or "Task/Job/Command Manager/Scheduler".

- One thing I noticed is that if I specify a Scope for an analyze task, then for
awhile it will just say "Scanning scope..." in the topline. I think the
topline should always contain the main task name.

For example, instead of :

Scanning scope...



It should look like this:

Analyzing package dependencies: Scanning scope...




*Advanced Features
-


*
Here I'm lumping the more advanced features which probably aren't necessary.

- Setting - Parallelization Num Subtasks to have some control over tasks which use multiple threads.
Currently, only Inspect Code may be multithreaded, so may be of limited use.

- Task Priority - Would be useful to tag some tasks as Low if those tasks could be suspended while other
Normal/High tasks are running. As mentioned above, High priority could turn on multi-threaded processing
if available. There are alot of details involved in supporting task priority.

- Queuing of Tasks. In some cases, you may want to queue up tasks rather than just have them all
run at once.

0
Comment actions Permalink

Hello, Alex,

*
File Synchronization
---------------------*

New Feature - File Synchronization should be shown as
a background process so the user could
monitor it. Currently, it is great that file
synchronization is in the background, but it should
be more obvious when it is going on.


Parsing files is not a part of synchronization phase, it is updating caches based on modified files information. There is indeed a plan to make this and updating caches at startup background (see http://www.jetbrains.net/jira/browse/IDEADEV-12074), though it is much work and won't make it to the first milestone.

0

Please sign in to leave a comment.