Initial thoughts on Selena

1) I absolutely love being able to run inspections in background, and especially being able to see CPU usage of 185% when doing it (dual cores). I love it so much I want to always run inspections in background. Unfortunately, there doesn't seem to be any way of doing that.

2) Shelve changes simple doesn't work yet. I get ".iws/.ipr file was changed in background, do you wish to reload" every time I try, but no other changes. This is sad, because the patches stuff seems to work well, and I was assuming that "Shelve Changes" was a simple combination of "Create Patch" + "Rollback Changes".

3)Drag-and-Drop Move is extremely nice, but it makes it even more important to make the Move refactoring module-aware. If you move a class betweem modules, IDEA needs to offer to Do The Right Thing, adding module and library dependencies as needed to keep the code from breaking.

--Dave Griffith

22 comments
Comment actions Permalink

Hello Dave,

2) Shelve changes simple doesn't work yet. I get ".iws/.ipr file was
changed in background, do you wish to reload" every time I try, but no
other changes. This is sad, because the patches stuff seems to work
well, and I was assuming that "Shelve Changes" was a simple
combination of "Create Patch" + "Rollback Changes".


This is strange because we did test the feature. :) I assume the files you're
trying to shelve aren't the .ipr and .iws? Does anything appear in the shelf
subdirectory of the config directory after you invoke the action?

What doesn't work in 5565 is shelving changes to binary files - this'll be
implemented in the next build.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Ah, that explains it. I was (inadvertantly) trying to shelve the .iws file, which had been checked into Subversion because I'm an idiot. Shelving the .iws file naturally rolls it back, which apparently loses the fact that you've shelved something. The shelf file, however, is created. So I amend my "shelving doesn't work" to "shelving would rule, except that the usability is needs improvement and the implementation is kind of scary"

Suggestions:

1)If deleting a .iws file will make my shelved changes unavailable (or only available if I know the magic directory), it's just too scary to use. Shelved changes need to be auto-detected from the conf directory.

2)If "Shelf Changes" is important enough to deserve a main menu item (and I believe it is), then "Unshelve Changes" deserves one as well. In a perfect world, it would be a two-level menu with the individual changes as sub-menu items, but a modal dialog would work as well. There may be more obscure places to hide functionality than in a tab of the Changes panel, but not many and not by much.

0
Comment actions Permalink

Hello Dave,

We will add an option for all 'Analyse ... ' processes I think

Thank you

1) I absolutely love being able to run inspections in background, and
especially being able to see CPU usage of 185% when doing it (dual
cores). I love it so much I want to always run inspections in
background. Unfortunately, there doesn't seem to be any way of doing
that.

2) Shelve changes simple doesn't work yet. I get ".iws/.ipr file was
changed in background, do you wish to reload" every time I try, but no
other changes. This is sad, because the patches stuff seems to work
well, and I was assuming that "Shelve Changes" was a simple
combination of "Create Patch" + "Rollback Changes".

3)Drag-and-Drop Move is extremely nice, but it makes it even more
important to make the Move refactoring module-aware. If you move a
class betweem modules, IDEA needs to offer to Do The Right Thing,
adding module and library dependencies as needed to keep the code from
breaking.

--Dave Griffith


-


Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

3)Drag-and-Drop Move is extremely nice, but it makes
it even more important to make the Move refactoring
module-aware. If you move a class betweem modules,
IDEA needs to offer to Do The Right Thing, adding
module and library dependencies as needed to keep the
code from breaking.


Dave, I'd rather not overload the refactoring, but suggest to use existing quickfixes for adding dependencies. Otherwise some additional step is probably needed on Move, since adding dependencies silently does not seem right at all.

Eugene.

0
Comment actions Permalink

3)Drag-and-Drop Move is extremely nice, but it makes
it even more important to make the Move refactoring
module-aware. If you move a class betweem modules,
IDEA needs to offer to Do The Right Thing, adding
module and library dependencies as needed to keep the
code from breaking.


Dave, I'd rather not overload the refactoring, but suggest to use existing quickfixes for adding dependencies. Otherwise some additional step is probably needed on Move, since adding dependencies silently does not seem right at all.

Eugene.

0
Comment actions Permalink

Dave, I'd rather not overload the refactoring, but suggest to use existing quickfixes for adding dependencies.

This is tedious, and worse doesn't always work. If you do a cross-module move which also changes the classes package, things get so badly broken that much manual rework is necessary. (When the class becomes inaccessible to one of it's dependencies due to a module move, then any imports for it's package do not get changed.)

Otherwise some additional step is probably needed on Move, since adding dependencies silently does not seem right at all.

I'd recommend a "Here's the dependencies we're going to add if you do this refactoring. Are you sure?" panel, that will come up if a cross-module move requires new dependencies be added. I'd also recommend that the panel have a "Don't show me this panel again" checkbox, which I'd almost certainly check.

While I can see your concern with silently adding dependencies, right now cross-module moves break an important invariant of the application: As far as I know, it's the only way a refactoring can create uncompilable code. That strikes me as well worth avoiding.

--Dave Griffith

0
Comment actions Permalink

Anna,

Excellent. I've suggested in the past that operations which can always be run in the background should have an "always run in background" checkbox on their progress bars. Seeing such a checkbox on the "Inspect code" progress bar would truly rock.

--Dave Griffith

0
Comment actions Permalink

Now cross module move should show a conflict dialog reporting unsatisfied dependencies, if it does not, then it is a bug
It seems a good idea to have quickfix options for various conflicts, what do you think?

0
Comment actions Permalink

I never did understand why you show a conflict panel, but don't offer to fix the conflicts. Mostly they'd be pretty easy to fix as part of the refactoring, I would think.

--Dave Griffith

0
Comment actions Permalink

Hello Dave,

May be simple check box on 'analysis dialog'?

Thank you.

-


Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Anna,

Excellent. I've suggested in the past that operations which can
always be run in the background should have an "always run in
background" checkbox on their progress bars. Seeing such a checkbox
on the "Inspect code" progress bar would truly rock.

--Dave Griffith



0
Comment actions Permalink

>I never did understand why you show a conflict panel, but don't offer to
>fix the conflicts.
>Mostly they'd be pretty easy to fix as part of the refactoring, I would
>think.

That sounds familiar. http://www.jetbrains.net/jira/browse/IDEABKL-1790

/Mikael


0
Comment actions Permalink

That would be extremely sweet. Between that and my answer about backgrounding API, MetricsReloaded metrics runs could be backgrounded with hardly any recoding on my part.

--Dave Griffith

0
Comment actions Permalink

Hello Dave,

1)If deleting a .iws file will make my shelved changes unavailable (or
only available if I know the magic directory), it's just too scary to
use. Shelved changes need to be auto-detected from the conf
directory.


There are several alternatives here:
- Keep it as it is now. (Do people really delete the .iws file that often?)
- Use the project location hash as the key for retrieving the changes for
the particular project. Then you would lose access to the changes after moving
or renaming a project.
- Create a project-specific directory for storing the shelf contents and
store the path to it in the .ipr file. That is a bit less transparent than
what I'd like to see.
- Make the shelf contents global rather than project-specific - show changes
shelved in any project in the "Shelf" tab. It may cause clutter and confusion,
but on the other hand could be used to bring changes between projects without
using create/apply patch explicitly.

Opinions on each of the options are welcome.

2)If "Shelf Changes" is important enough to deserve a main menu item
(and I believe it is), then "Unshelve Changes" deserves one as well.
In a perfect world, it would be a two-level menu with the individual
changes as sub-menu items, but a modal dialog would work as well.
There may be more obscure places to hide functionality than in a tab
of the Changes panel, but not many and not by much.


There's one major step missing in the current "shelve changes" action: opening
the Shelf tab in the Changes view and selecting the shelved change that was
created. I believe that it will be sufficient: you will know where your change
went, and it will be no longer necessary to create two distinct UIs for selecting
which shelved changelist and which files in it should be unshelved.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

+ Keep it as it is now. (Do people really delete the .iws file that often?)+

Every time they do will result in a panicked service call.

+Use the project location hash as the key for retrieving the changes for
the particular project. Then you would lose access to the changes after moving
or renaming a project.+

This was what I assumed, but I hadn't thought about the renaming issue. That sucks.

+Create a project-specific directory for storing the shelf contents and
store the path to it in the .ipr file. That is a bit less transparent than
what I'd like to see.+

Unnacceptable to my mind. It makes .ipr files unsharable.

+Make the shelf contents global rather than project-specific - show changes
shelved in any project in the "Shelf" tab. +

Yuck.

--Dave Griffith

0
Comment actions Permalink

There are several alternatives here:


> - Use the project location hash as the key for retrieving the changes
> for the particular project. Then you would lose access to the changes
> after moving or renaming a project.

How about creating a unique ID for each project (128-bit random number
or whatever), stored in the project file, and use that to identify the
project instead of some hash related to the location? Am I missing some
obvious problem?

0
Comment actions Permalink

Jonas Kvarnström wrote:

How about creating a unique ID for each project


What about branching? It seems different VCS branches of the project
will have same ID since .ipr files are inherited along with the sources.

Max

0
Comment actions Permalink

Hello Dmitry,

AFAIK it is planned for Selena to reorganize the project file, i.e. to
split it up into different parts and to store those parts in a dedicated
directory. So my proposition is to create a shelf directory therein and
to store all shelf files related to this project in this directory.

As I have to copy files between different machines with different disk
layouts, a solution based on the project location isn't usable for me.
And showing all shelf files in every project is a very bad idea IMHO.

Dmitry Jemerov wrote:

Hello Dave,

>> 1)If deleting a .iws file will make my shelved changes unavailable (or
>> only available if I know the magic directory), it's just too scary to
>> use. Shelved changes need to be auto-detected from the conf
>> directory.


There are several alternatives here:
- Keep it as it is now. (Do people really delete the .iws file that often?)
- Use the project location hash as the key for retrieving the changes
for the particular project. Then you would lose access to the changes
after moving or renaming a project.
- Create a project-specific directory for storing the shelf contents and
store the path to it in the .ipr file. That is a bit less transparent
than what I'd like to see.
- Make the shelf contents global rather than project-specific - show
changes shelved in any project in the "Shelf" tab. It may cause clutter
and confusion, but on the other hand could be used to bring changes
between projects without using create/apply patch explicitly.

Opinions on each of the options are welcome.

>> 2)If "Shelf Changes" is important enough to deserve a main menu item
>> (and I believe it is), then "Unshelve Changes" deserves one as well.
>> In a perfect world, it would be a two-level menu with the individual
>> changes as sub-menu items, but a modal dialog would work as well.
>> There may be more obscure places to hide functionality than in a tab
>> of the Changes panel, but not many and not by much.


There's one major step missing in the current "shelve changes" action:
opening the Shelf tab in the Changes view and selecting the shelved
change that was created. I believe that it will be sufficient: you will
know where your change went, and it will be no longer necessary to
create two distinct UIs for selecting which shelved changelist and which
files in it should be unshelved.


--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0
Comment actions Permalink

Running inspections in background is nice.
However, it constantly eats memory and hits GC quite often, and the editor becomes slow more often.
Is it possible to use parallel GC? It's supposed to work after all. File bugs against Sun, chances are that it gets repaired to be usable.

0
Comment actions Permalink

Maxim Shafirov wrote:

Jonas Kvarnström wrote:

>> How about creating a unique ID for each project


What about branching? It seems different VCS branches of the project
will have same ID since .ipr files are inherited along with the sources.


I knew there had to be something simple I had forgotten... though
compared to "Make the shelf contents global rather than
project-specific", this option would at least only make changes
available within different branches of the same project, as opposed to
making them globally available regardless of the project you're working
with.

0
Comment actions Permalink

Seems nobody notices that in first EAP of Selena has a very nice feature: Reload button in Plugin Manager.

YES, I really hate to close Plugin Manager and reopen it when I need to refresh the plugin list or sometime the list cannot be up-to-date 'cause it's timeout.

Thanks JBers ;)

0
Comment actions Permalink

Upon further consideration, the .iws solution is probably the correct one. It just needs to be a bit clearer if some idiot tries to shelve the .iws. It doesn't bode well that the first time an actual user tried to use shelving I did just that...

--Dave Griffith

0
Comment actions Permalink

Hello Dave,

Upon further consideration, the .iws solution is probably the correct
one. It just needs to be a bit clearer if some idiot tries to shelve
the .iws. It doesn't bode well that the first time an actual user
tried to use shelving I did just that...


Indeed, I'll add such a warning.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Please sign in to leave a comment.