Packages view: details

Hi All,

We are going to implement "Packages View"
(http://www.intellij.net/tracker/idea/viewSCR?publicId=3132) feature. There
are some questions though:

1. Whether it should show only project's classes or also library classes.
Currently we are going to provide a toogle button "Include library classes"
with off state by default.

2. Multi-module projects. Should it just mix together classes from all
modules or have separate nodes for each module with corresponding packages
below.

3. Should it allow both "flatten packages" and "non-flatten packages" mode
(as Project View).

Any other suggestions about functionality of this view are welcome.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


20 comments
Comment actions Permalink

+1 It sounds great!

Valentin Kipiatkov wrote:

Hi All,

We are going to implement "Packages View"
(http://www.intellij.net/tracker/idea/viewSCR?publicId=3132) feature. There
are some questions though:

1. Whether it should show only project's classes or also library classes.
Currently we are going to provide a toogle button "Include library classes"
with off state by default.


I like having a toggle button. Most of the time I'll only want to see the
classes for my project, but sometimes I want to see the library classes too
(it could help when getting to grips with a new library, for example).

2. Multi-module projects. Should it just mix together classes from all
modules or have separate nodes for each module with corresponding packages
below.


I'd prefer to be able to toggle this as well. I have a feeling that it will
be very much a matter of individual taste as to which view is preferred: 50%
will want it one way and 50% the other. For me, I can imagine finding both
views quite useful.

3. Should it allow both "flatten packages" and "non-flatten packages" mode
(as Project View).


Yes please!

Any other suggestions about functionality of this view are welcome.


Add an option to the Alt-F1 menu to show the current class in the package
view (but I'm sure you already thought of that...).

Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

Vilya Harvey wrote:

>>
>> 1. Whether it should show only project's classes or also library classes.
>> Currently we are going to provide a toogle button "Include library
>> classes"
>> with off state by default.


I like having a toggle button. Most of the time I'll only want to see
the classes for my project, but sometimes I want to see the library
classes too (it could help when getting to grips with a new library, for
example).


I like that too, but it would be inconsistent with the current classpath
and sourcepath views which show the combined project+libraries content.
I value uniformity a lot because it helps me not thinking about the tool.
Actually, can't the package view be just a "toggle button" on the
current source and class paths views ??

>> 2. Multi-module projects. Should it just mix together classes from all
>> modules or have separate nodes for each module with corresponding
>> packages
>> below.

I haven't worked with multiple modules yest, so I can't give an accurate
answer. I said elsewhere that as a user, I only know what I want after
I get it ;)
But would like to see the uniformity principle applied there as well.

I'd prefer to be able to toggle this as well. I have a feeling that it
will be very much a matter of individual taste as to which view is
preferred: 50% will want it one way and 50% the other. For me, I can
imagine finding both views quite useful.

>> 3. Should it allow both "flatten packages" and "non-flatten packages"
>> mode
>> (as Project View).


Yes please!

me too.

>> Any other suggestions about functionality of this view are welcome.


Add an option to the Alt-F1 menu to show the current class in the
package view (but I'm sure you already thought of that...).

Vil.

repeating myself, can't the package view be just a "toggle button" on
the current source and class paths views ?? I am unsure how the package
view would aply to the project tree (which must remain a faithful view
over the filesystem, IMO).

Edo

0
Comment actions Permalink

I have to agree with Edoardo. Consistency across the UI is important. On the other hand, options are good and I can see that a toggle button to see (or not) the library classes or flatten the packages would be good.

0
Comment actions Permalink

1. Whether it should show only project's classes or
also library classes. Currently we are going to provide
a toogle button "Include library classes" with off
state by default.


Sounds great to me.

2. Multi-module projects. Should it just mix together
classes from all modules or have separate nodes for
each module with corresponding packages below.


Both options might be nice. Any chance for a toggle button for this, too?

3. Should it allow both "flatten packages" and
"non-flatten packages" mode (as Project View).


Yes, especially if there's an option to hide empty middle packages (HEMP). If HEMP isn't planned, then I don't really have an opinion, since for some reason I find the current implementation of flatten packages really hard to use/navigate.

0
Comment actions Permalink

Edoardo Comar wrote:

repeating myself, can't the package view be just a "toggle button" on
the current source and class paths views ?? I am unsure how the package
view would aply to the project tree (which must remain a faithful view
over the filesystem, IMO).


I think the package view has a different purpose to any of the existing
views and operates on different data, which is why it ought to be separate
from them (IMHO).

The difference in purpose is that it shows a unified tree for multiple parts
of the project, whereas all the others show multiple trees across multiple
parts of the project.

The difference in data is that it needs to operate on both the sourcepath
and classpath.

So I respectfully disagree with you. :)

Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

1. Whether it should show only project's classes or also library classes.
Currently we are going to provide a toogle button "Include library classes"
with off state by default.


That would be useful.

2. Multi-module projects. Should it just mix together classes from all
modules or have separate nodes for each module with corresponding packages
below.


I would have it done also with a toggle button. I think it pretty much depends
on what would you like to see right now.

3. Should it allow both "flatten packages" and "non-flatten packages" mode
(as Project View).


I think it's the same - depends on one's personal taste and current goal.
I would certanly use both, although I prefer flatten view with an option to hide
epmty packages.

Any other suggestions about functionality of this view are welcome.


My suggestion is to deal nicely with duplicates. One simple yet IMHO
satisfactory solution is to include in the view the very first class encountered
in the classpath/sourcepath and ignore all the others with the same name. At
least it would work just fine for all my projects where I have this problem.
Sure I can image the situation/project where it won't work, but it usually the
result of poorly organized project/sources and thus should not be
supported/encouraged :)

--
Dmitry Skavish
-


Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com

0
Comment actions Permalink

I find Edoardo's opinion quite reasonable. Really, current three views shows
packages starting from several "roots" and adding option to unite these
roots to all views looks more consistent than adding new view (e.g. in this
view we'll get problems with creating classes "Where it should be placed?",
that we haven't in others, or what classes should be and should not be shown
(project sources, test sources, external sources, all classes from
classpath, ...).
On the other hand such option is badly compatible with Project view. Turn it
on, select some package than turn it off, now where is selection should be?
Or, Project view is some kind of file system view (which shows logical java
infomation in some cases - under source roots), but when new option is
turned on where is this root on file system? and how it should be named?
What real source roots should look like?

--
Best regards,
Dmitry Peshehonov
JetBrains, Inc, http://www.intellij.com

"Develop with pleasure!"
"Vilya Harvey" <vilya.harvey@digitalsteps.com> wrote in message
news:ba0bdk$s0e$1@is.intellij.net...

Edoardo Comar wrote:

repeating myself, can't the package view be just a "toggle button" on
the current source and class paths views ?? I am unsure how the package
view would aply to the project tree (which must remain a faithful view
over the filesystem, IMO).

>

I think the package view has a different purpose to any of the existing
views and operates on different data, which is why it ought to be separate
from them (IMHO).

>

The difference in purpose is that it shows a unified tree for multiple

parts

of the project, whereas all the others show multiple trees across multiple
parts of the project.

>

The difference in data is that it needs to operate on both the sourcepath
and classpath.

>

So I respectfully disagree with you. :)

>

Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

>

Disclaimer

>

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

>


0
Comment actions Permalink

I like that too, but it would be inconsistent with the current classpath
and sourcepath views which show the combined project+libraries content.


They will be dropped anyway soon.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Edoardo Comar" <e.comar.no.spam@no.spam.btinternet.com> wrote in message
news:ba0417$1dh$1@is.intellij.net...

Vilya Harvey wrote:

>

>>
>> 1. Whether it should show only project's classes or also library

classes.

>> Currently we are going to provide a toogle button "Include library
>> classes"
>> with off state by default.
>
>

I like having a toggle button. Most of the time I'll only want to see
the classes for my project, but sometimes I want to see the library
classes too (it could help when getting to grips with a new library, for
example).

>

I like that too, but it would be inconsistent with the current classpath
and sourcepath views which show the combined project+libraries content.
I value uniformity a lot because it helps me not thinking about the tool.
Actually, can't the package view be just a "toggle button" on the
current source and class paths views ??

>

>
>> 2. Multi-module projects. Should it just mix together classes from all
>> modules or have separate nodes for each module with corresponding
>> packages
>> below.

>

I haven't worked with multiple modules yest, so I can't give an accurate
answer. I said elsewhere that as a user, I only know what I want after
I get it ;)
But would like to see the uniformity principle applied there as well.

>

I'd prefer to be able to toggle this as well. I have a feeling that it
will be very much a matter of individual taste as to which view is
preferred: 50% will want it one way and 50% the other. For me, I can
imagine finding both views quite useful.

>
>> 3. Should it allow both "flatten packages" and "non-flatten packages"
>> mode
>> (as Project View).
>

Yes please!

me too.

>

>
>> Any other suggestions about functionality of this view are welcome.
>
>

Add an option to the Alt-F1 menu to show the current class in the
package view (but I'm sure you already thought of that...).

>

Vil.

repeating myself, can't the package view be just a "toggle button" on
the current source and class paths views ?? I am unsure how the package
view would aply to the project tree (which must remain a faithful view
over the filesystem, IMO).

>

Edo

>


0
Comment actions Permalink

Note: Some snipping done below to keep size down.

Edoardo Comar <e.comar.no.spam@no.spam.btinternet.com> wrote in
news:ba0417$1dh$1@is.intellij.net:

Vilya Harvey wrote:

>>>
>>> 1. Whether it should show only project's classes or also library
>>> classes. Currently we are going to provide a toogle button "Include
>>> library classes"
>>> with off state by default.

I like that too, but it would be inconsistent with the current
classpath and sourcepath views which show the combined
project+libraries content. I value uniformity a lot because it helps
me not thinking about the tool. Actually, can't the package view be
just a "toggle button" on the current source and class paths views ??


Actually, I agree that it's somewhat inconsistent, but this is a
different view, with different goals as someone else stated. All of the
other views are inherently based upon the file system. This one is more
logical (as opposed to physical). Could it be done as an option on the
source view and classpath views? Probably, but the number of options to
pick might grow too large. Regardless, if you're worried about
inconsistency, I'd prefer to be able to not show the library information
in the other views rather than making me always see the library info in
this one.

>>> 2. Multi-module projects. Should it just mix together classes from
>>> all modules or have separate nodes for each module with
>>> corresponding packages
>>> below.


Like most everyone right now, I haven't played with the multi-module
stuff yet either. As a guess, I'll be consistent and say that this view
is supposed to be "logical" in nature, so they should be mixed. However,
I don't see much harm in having the option to switch back and forth.

>>> 3. Should it allow both "flatten packages" and "non-flatten
>>> packages" mode
>>> (as Project View).


I think this is part of the HEMP. I agree with Chris Bartley that this
makes the most sense when HEMP is used. Otherwise, I don't think I'd ever
use the "flattened" view. (I don't now in the existing views.)

>>> Any other suggestions about functionality of this view are welcome.
>>
>>
>> Add an option to the Alt-F1 menu to show the current class in the
>> package view (but I'm sure you already thought of that...).


Agreed. (And I'm sure they thought of that too.)

repeating myself, can't the package view be just a "toggle button" on
the current source and class paths views ?? I am unsure how the
package view would aply to the project tree (which must remain a
faithful view over the filesystem, IMO).


Again, I think the goals for this view are slightly different. This
should be the simplest possible view of the project with as little regard
as possible for the file structure. That said, I'm not entirely against
making it an option on the source view.


~Mike

0
Comment actions Permalink

My suggestion is to deal nicely with duplicates.


I suppose it's better to show all classes including duplicates. However I
think it should be rare situation when you jave duplicates.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Dmitry Skavish" <dmitry@jzox.com> wrote in message
news:ba0bd5$rvl$1@is.intellij.net...

1. Whether it should show only project's classes or also library

classes.

Currently we are going to provide a toogle button "Include library

classes"

with off state by default.

>

That would be useful.

>

2. Multi-module projects. Should it just mix together classes from all
modules or have separate nodes for each module with corresponding

packages

below.

>

I would have it done also with a toggle button. I think it pretty much

depends

on what would you like to see right now.

>

3. Should it allow both "flatten packages" and "non-flatten packages"

mode

(as Project View).

>

I think it's the same - depends on one's personal taste and current goal.
I would certanly use both, although I prefer flatten view with an option

to hide

epmty packages.

>

Any other suggestions about functionality of this view are welcome.

>

My suggestion is to deal nicely with duplicates. One simple yet IMHO
satisfactory solution is to include in the view the very first class

encountered

in the classpath/sourcepath and ignore all the others with the same name.

At

least it would work just fine for all my projects where I have this

problem.

Sure I can image the situation/project where it won't work, but it usually

the

result of poorly organized project/sources and thus should not be
supported/encouraged :)

>

--
Dmitry Skavish
-----------------------
Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com

>


0
Comment actions Permalink

>> I like that too, but it would be inconsistent with the current classpath
>> and sourcepath views which show the combined project+libraries content.


They will be dropped anyway soon.


Interesting choice. Right now, I almost exclusively use the "sourcepath"
view. Once the packages view is available, I personally won't see much use
in the others, but I'm sure others will disagree.

To stem the tide of dissenters, can you tell us if the packages view the
only replacement, or if you have more in mind?


~Mike

0
Comment actions Permalink

To stem the tide of dissenters, can you tell us if the packages view the
only replacement, or if you have more in mind?


Not the only but one of. In addition, the Project view witll be changed as
well. So along with content of each module it will show its libraries under
"Libraries" node.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Mike Abney" <michaelno.abneyspam@retek-nospam-.com> wrote in message
news:Xns937C8307BCC42michaelabney1990@213.182.181.98...

>> I like that too, but it would be inconsistent with the current

classpath

>> and sourcepath views which show the combined project+libraries content.
>

They will be dropped anyway soon.

>

Interesting choice. Right now, I almost exclusively use the "sourcepath"
view. Once the packages view is available, I personally won't see much use
in the others, but I'm sure others will disagree.

>

To stem the tide of dissenters, can you tell us if the packages view the
only replacement, or if you have more in mind?

>
>

~Mike



0
Comment actions Permalink

1) I would say a toggle, just on general principles, but I can't really imagine a circumstance when I would turn the toggle on.

2) Again, a toggle would be nice, but I doubt if I would ever want to see anything but the all-modules view.

3) Don't care. I can't stand "flatten packages", and never use it.

0
Comment actions Permalink

Valentin Kipiatkov wrote:
>>My suggestion is to deal nicely with duplicates.


I suppose it's better to show all classes including duplicates. However I
think it should be rare situation when you jave duplicates.

I agree. If duplicate classes exist in a project that should be flagged
as an error
EXCEPT
that if I am hacking existing code say I need to fix a class in a jar so
that it works for me, I like to create a project where the original
classes (jar and sources) are placed in a library and the NEW class is
placed in the project proper.

Edo

0
Comment actions Permalink

1. Whether it should show only project's classes or
also library classes.


A toggle button, please.

2. Multi-module projects. Should it just mix together
classes from all
modules or have separate nodes for each module with
corresponding packages
below.


A toggle button, please.

3. Should it allow both "flatten packages" and
"non-flatten packages" mode
(as Project View).


A toggle button, please.

0
Comment actions Permalink

I don't have any strong opinions on a package view specifically.

I concurr with the toggle button.

If it is going to be a package view, it should be a package view, in the same sense as interpreting the classpath.

So for example, If I had a the following two paths pointing at the same package

src/utest/app/media/MediaItem.java

and

src/app/media/MediaItem.java

And the src/app/media was first in my classpath, I would expect to see:

app.media.MediaItem (from src/app/media)

And not the other one. Or, if we were going to show it, we should indicate that the utest version is occluded.

I don't use the flatten packages view.

On a slightly different note, it is my belief (and those of you more in the know can challenge me on this), that package dependencies are an important and often overlooked tool for understanding the structure of a program.

It would be useful to have such a display available in the context of a package view. (perhaps a "find usages" on packages?)

Ideally I would like some kind of package dependency view, but I'll save that for the simpleUML plug-in. Find usages, and ctrl-alt-h would be perfectly acceptable (and consistent).

If you think this is far enough away from your vision that it should be a separate feature request, please let me know, and I'll create one.

Mike

0
Comment actions Permalink

If it is going to be a package view, it should be a package view, in the
same sense as interpreting the classpath.


Seems to be an interesting idea. Maybe hidden resources can still be shown,
but grayed?

Tom

0
Comment actions Permalink

>> If it is going to be a package view, it should be a package view, in
>> the same sense as interpreting the classpath.


Seems to be an interesting idea. Maybe hidden resources can still be
shown, but grayed?


Yes, I like this concept as well. Depending upon their order in the
classpath (it might be sourcepath order if everything is compiled to the
same place), pick the "right" one, but show the others grayed out.
Possibly as a sub-element in the tree view. So for the following
situation:

C:\proj1\src\com\myco\util\FileUtil.java
C:\proj2\src\com\myco\util\FileUtil.java

Where C:\proj1\src and C:\proj2\src are both on the sourcepath, we
should see something like:

com.myco.util
FileUtil
FileUtil (C:\proj2\src) <-- grayed out

Where the parenthetical part is either the path to this version or some
identifier for which module or source path element this version comes
from.


~Mike

0
Comment actions Permalink

com.myco.util
FileUtil
FileUtil (C:\proj2\src) <-- grayed out


On second thought, that might make the unused versions look too much
like inner classes or something. Perhaps something like:

FileUtil
Duplicates <- Always closed by default
FileUtil (C:\proj2\src)


~Mike

0
Comment actions Permalink

1. Whether it should show only project's classes or
also library classes.
Currently we are going to provide a toogle button
"Include library classes"
with off state by default.

Sounds good. More comments later

2. Multi-module projects. Should it just mix together
classes from all
modules or have separate nodes for each module with
corresponding packages
below.

A package view is a logical view not a physical one. So my first reaction would say unify the packages and do not add nodes for each modules.
However the only use case I could find to support this is if I wanted to know where a class come from. You could have a toggle that adds a top level node or like the package greyed annotation in the class hierarchy you could annotate package with their associated modules info.

3. Should it allow both "flatten packages" and
"non-flatten packages" mode
(as Project View).

flatten packages make only sense if you implement an option to hide empty middle packages like in Eclipse.

Any other suggestions about functionality of this
view are welcome.


The package view should support filtering to show library classes in addition to sources. I completely agree that a toggle fill that need but...
It could be combined in a more general filtering mechanism that in addition would allow to constraint what packages to show (like the Ant target filtering). Especially on large projects it would be helpful to only see packages that you are working on/with (you use com.intellij.aspectj, com.intellij.psi and com.intellij.util and have 400 packages in between)

Another idea is to be able to create multiple filtered package views. It would be kind of like the Workspace plugin in the package view.

Jacques

0

Please sign in to leave a comment.