Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-ui-dev] Patch: Task list filtering of resources in the same project, bug in filtering children?

Cagatay,

The diff doesn't seem to handle the initial case where focusResource is 
null but showSelections() is true.  This will result in updateNeeded being 
false, although it will get it the next time around.
Don't worry, I'll fix it up.  There were a couple of other places where 
getProject() is used which need checks too.

As for the getting the right markers for the packages view, I don't think 
there's an existing PR for this, so feel free to file one.
There's a similar problem with showing version labels which the JDT team 
is aware of.  The modified marks follow the folder containment hierarchy, 
which does not map exactly to packages.

Nick





Cagatay Kavukcuoglu <cagatayk@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
01/22/02 02:05 PM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        RE: [platform-ui-dev] Patch: Task list filtering of resources in the same 
project, bug in filtering children?


See below for my comments...

--CK.


> -----Original Message-----
> From: platform-ui-dev-admin@xxxxxxxxxxx
> [mailto:platform-ui-dev-admin@xxxxxxxxxxx] On Behalf Of
> Nick_Edgar@xxxxxxx
> Sent: Tuesday, January 22, 2002 10:59 AM
> To: platform-ui-dev@xxxxxxxxxxx
> Subject: Re: [platform-ui-dev] Patch: Task list filtering of
> resources in the same project
>
>
> Cagatay,
>
> I have applied your patch and it will appear in today's
> integration build.
>
> The only change I made was to resolve a conflict in the
> mnemonics in the
> dialog.  You had chosen &p for your item which conflicts with
> &priority. I actually changed the priority item to priorit&y
> since I like to follow
> the heuristic that mnemonics earlier in a dialog use the more obvious
> choices for which letter to use.
>

Oh, didn't notice that. Thanks.

> The code looks good.  It's important to avoid unneeded
> refreshes, so I
> like the fact that it handles this properly when selecting different
> resources in the same project.
> My only concern is with the code in
> TaskList.updateFocusResource, which
> does not handle a possibly null return value from
> resource.getProject()
> and focusResource.getProject().
> getProject() can return null if the resource is the workspace
> root.  I
> know of no place in the UI where a workspace root is actually shown,
> however the code should handle this possibility (who knows
> what views will
> be written in the future)?  I can fix this up.

Yes, I hadn't considered that possibility. I assumed any resource that
shows up in the workbench UI is either a project or belongs to a
project. Workspace root definitely is neither. I suspect other plugin
writers would make this (implicit) assumption too, so it might be good
to note this somewhere in workbench javadoc comments.

I'm attaching a diff for the fix.

>
> Congratulations!  You're the first person outside OTI/IBM to
> have a patch
> applied to the Eclipse UI component!

*That* certainly made my day! Thanks!

>
> Nick
>
>

I think I also came upon a bug(?) in the task list and/or the JDT
extension to it. The filtering function uses DEPTH_INFINITE to find all
tasks for a resource and its children. For Java packages, this means all
packages "under the hierarchy" are included in the marker search as
well. This is not the right thing since there isn't a hierarchical
relationship between packages in Java. It comes about only because a
folder hierarchy is used to represent packages. You can test this out,
for instance, by setting up Apache log4j as an Eclipse project. After
you make a breaking change in org.apache.log4j.Category class, you can
see all the errors in all org.apache.log4j.* packages when you select
org.apache.log4j package.

It seems there are two alternatives to fix this as far as I can see.
Provide another resource filtering option that will use
Iresource.DEPTH_ONE to search for markers, or extend the
ITaskListResourceAdapter interface to ask the adapter the maximum depth
a marker search for the given resource can go.

I wanted to see what people on the list think before opening a bug
report, I can open the bug if this description is accurate.

[snip the rest]






Back to the top