This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 106178 - Toggling palette view for java files also toggles it for the form editor
Summary: Toggling palette view for java files also toggles it for the form editor
Status: VERIFIED FIXED
Alias: None
Product: webservices
Classification: Unclassified
Component: REST (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Ayub Khan
URL:
Keywords: PERFORMANCE, REGRESSION, USABILITY
: 106239 106276 (view as bug list)
Depends on: 106353 106354 107297
Blocks:
  Show dependency tree
 
Reported: 2007-06-09 02:18 UTC by _ pcw
Modified: 2007-07-26 13:20 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pcw 2007-06-09 02:18:14 UTC
Apparently, it's now possible to display the Palette when a java editor is the
current focused editor.

Except that closing this palette also closes the palette used for the form
editor view (where the palette is pretty much mandatory).

It should, nay MUST, be possible to close the palette for a java file (including
the java view of a Form editor managed java file) and NOT have form editor's
palette view status changed.

Otherwise, someone who doesn't want the palette for a java editor but needs to
edit forms will either be stuck with hating it, or have to constantly open and
close the palette as they switch between the java and form view of their code.

P2 due to the aggravation this causes.
Comment 1 Pavel Buzek 2007-06-10 02:14:13 UTC
First, do not put experimental code the does not work at all into trunk.
Especially at such a visible place.

Second, if the websvc/rest really needs to provide palette for Java file make
sure it is not visible for _all_ Java files. Most users won't care about this.

Third, I recommend to do a UI review next time before you introduce features
like this.
Comment 2 Pavel Buzek 2007-06-10 02:17:01 UTC
BTW, same goes about the new template category "Client".
Comment 3 _ ludo 2007-06-10 20:31:14 UTC
*** Issue 106239 has been marked as a duplicate of this issue. ***
Comment 4 _ ludo 2007-06-10 20:32:41 UTC
*** Issue 106239 has been marked as a duplicate of this issue. ***
Comment 5 Pavel Buzek 2007-06-11 15:22:42 UTC
*** Issue 106276 has been marked as a duplicate of this issue. ***
Comment 6 Srividhya Narayanan 2007-06-11 19:49:19 UTC
We are working on the Ui review and working with the palette owners to see how
best to resolve this. Thanks for catching this issue.
Comment 7 Ayub Khan 2007-06-12 06:44:37 UTC
Hi  S. Aubrecht,

Thanks for fixing http://www.netbeans.org/issues/show_bug.cgi?id=104705.

Now I can show palette items when user opens a java file.

But addition of this feature in the last minute has caused a lot of UI questions
captured
in the following bug filed by Pavel Buzak.

http://www.netbeans.org/issues/show_bug.cgi?id=106178

(Basically people are annoyed unexpectly seeing a palette with some items for java)

We have come with couple of solutions each has its advantage and disadvantage.

Solution 1:
-----------
Use PaletteFilter to hide/show based on  whether the java file that it belongs is
REST enabled.

Disadvantage:
1. I dont know if this is a bug in core/palette (See attachment), an empty palette
shows up. This may be annoying to people who use form editors frequently.

See issue#106354

2. dont know if this is a bug in PaletteFilter, the filter gets invoked only
once, and
not every time user opens each java file.
   I think may be a work around is to attach to JavaDataObject and do the
show/hide of palette categories/items using node.setHidden() method.

See issue#106353

Solution 2:
-----------
Add an action to JavaEditor Popup/some other action (using layer) "Show REST
Webservices Palette"
that will show the palette. So the idea here is to let the palette to populate
itself
only when user performs this action. User can close this palette at will. I am not
sure after close whether we should cleanup the palettes etc.,

Advantage: Users downloading M10 will see the same behavior of palette for java/form
as M9. Then they can willfully start showing palette for REST using the action.

Code freezed for M10 is Jun 15, please let me know if you have any
solution/workarounds.

Thanks
Ayub

Comment 8 Stanislav Aubrecht 2007-06-12 10:48:31 UTC
there are several solutions to this problem:

1. don't use mime-type palette association and instead create your palette using
PaletteFactory during e.g. module install. then watch for activated editor
windows and inject the PaletteController into editor's Lookup whenever a REST
file is activated. that would be my preferred solution.

2. create your own editor for REST files - based on the default java editor -
and add the palette to its lookup instead of mime-type registration.

3. define your own mime-type for REST files and associate the palette with the
new mime type only

4. i can extend the palette api and add method boolean isPaletteVisible( Lookup
) to PaletteFilter class where the Lookup parameter will be the Lookup of
currently active editor window.
the problem with this solution is that it is a bit too late for api changes and
it would also hide the palette for non-REST if somebody wanted to show code
clips palette for java files.

5. don't show any palette for REST files at all - palette with two items only is
hardly worth showing at all, i'd suggest popup menu or some other mechanism...
(my second favorite solution:)
Comment 9 Marian Mirilovic 2007-06-12 12:10:00 UTC
ayubskhan,
before you pass UI review, please rollback the change

Opening Palette window slows down :
- opening Java files
- Java Project create 
- startup time with Opened Java project/files

so I would like to ask you to change it ASAP, because now our results are
affected by this change.
Comment 10 Ayub Khan 2007-06-13 06:46:38 UTC
Change rolledback
Comment 11 Ayub Khan 2007-06-16 06:37:31 UTC
This issue now depends on 106907.
Comment 12 Ayub Khan 2007-06-20 22:09:40 UTC
Removed the earlier dependency on 106907. This issue now depends on 107297.
Comment 13 Ayub Khan 2007-06-21 18:20:59 UTC
Fixed for NB6.0 M10
Comment 14 Lukas Jungmann 2007-07-26 13:20:27 UTC
v.