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 58859 - Implement a reusable component palette
Summary: Implement a reusable component palette
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Stanislav Aubrecht
Keywords: API
Depends on: 60192 60188 60189 60190 60191 61017 61018 61019 61020 61021 77387
  Show dependency tree
Reported: 2005-05-13 09:52 UTC by Stanislav Aubrecht
Modified: 2008-12-22 15:52 UTC (History)
7 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

answers to arch questions (50.53 KB, text/html)
2005-06-10 16:01 UTC, Stanislav Aubrecht
updated arch document (52.12 KB, text/html)
2005-07-08 16:14 UTC, Stanislav Aubrecht
JavaDoc (73.92 KB, application/x-compressed)
2005-07-11 14:41 UTC, Stanislav Aubrecht
test coverage (emma) (150.72 KB, application/x-compressed)
2005-07-13 15:34 UTC, Stanislav Aubrecht

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Aubrecht 2005-05-13 09:52:42 UTC
Provide a new implementation of component palette that can display multiple
categories of visual (e.g. swing components) and non-visual (e.g. code snippets)

(ui specification to be added soon)
Comment 1 Stanislav Aubrecht 2005-06-10 16:01:13 UTC
Created attachment 22613 [details]
answers to arch questions
Comment 2 Stanislav Aubrecht 2005-06-13 17:57:44 UTC
source code with javadocs is in cvs branch 'palette_58859' in module 'core/palette'.
there are only two public packages:
Comment 3 Stanislav Aubrecht 2005-06-13 17:58:45 UTC
link to UI specification draft:
Comment 4 Todd Fast 2005-06-14 02:26:23 UTC
Overall, I'm impressed with what I see in the arch questions and the palette UI
spec.  Some questions:

- Will the palette eagerly respond to changes to an editor's selected node when
the editor incorporates a multiview and the user selects a new view within the
editor?  I assume this is the case since the Form editor will use the common
palette as well.

- Palette Manager: I'm not sure how such a feature could be implemented when
multiple editors may display arbitrary elements in the palette.  In previous
versions, the palette was biased towards JavaBean components for use by the Form
module, but with the addition of code snippets and other component models (e.g.
Beehive controls), this assumption is no longer valid.  What form will Palette
Manager take with the common palette implementation, or does it even make sense
to keep it?

- I'm concerned about the way the palette will obtain the list of elements to
display.  The arch questions mention pointing to a folder in the layer (or I
assume a FileObject).  This may work fine for statically configured palette
elements, but JSE has the requirement to discover the list of palette elements
in other ways.  For example, when developing a loosely-coupled Web service, the
available set of components comes from classes discovered in the project's
classpath (components are associated with a project as JAR files, and these JAR
files must be present in the project at deploy time).  If the only way to
populate the palette is via a pointer to a FileObject, then this design imposes
considerably burden on this module; it would need to discover the list of
components, mirror that list in FileObject form, and then worry about
reconciling this second list if the actual set of components changes.  Instead,
could you instead allow PaletteController to simply return a root node (or
nodes) that will be used to display the palette elements, and avoid any built-in
assumptions about the layer or FileObjects?  I realize this may impose an
additional burden on the provider of the PaletteController to persist the state
of the palette, but this seems minor in comparison to the extra bookkeeping the
provider would need to do to synchronize a secondary list of components.  To
avoid building in assumptions, perhaps there could be an abstract version of
PaletteController that just returns the node as I suggest, allowing the
implementor to supply that node, and then a LayerPaletteController subclass that
allows editors to easily configure the palette from a layer/FileObject.
Comment 5 Libor Kotouc 2005-06-14 09:10:25 UTC
1. We will need differ between the objects dragged from explorer and objects
dragged from the palette.
Does the current arch support this distinction? There is only something about
reusability of current dnd impl from Nodes. How should we understand that?

It would be nice to have a flavor specific to the Transferable encapsulating the
palette items...
Comment 6 Stanislav Aubrecht 2005-06-14 10:04:00 UTC
1. switching palette contents when user activates a different editor/view should
be fast enough. pls see the palette in the form module.

2. the manager is not fully designed in the ui spec yet. the idea is to provide
a dialog window where users can change order of categories, add/remove/rename
categories and it will also offer actions (buttons) to open a palette import
wizard. the import actions are provided by palette clients.
however i don't have a strong opinion on this - i think it's also possible to
have custom palette manager for each palette client (and maybe some default
implementation as well).

3. this is a valid point. i suggest to keep api and spi interfaces intact and
only add a method to the PaletteFactory class:
public static PaletteController createPalette( Node root, PaletteActions
customActions );
you can define your dynamic content using Node functionality and i'll just
implement a new storage schema for palette settings (transparent to you).

1. ok, when a palette item is being dragged from the palette to the editor, a
new dnd flavor will be registered and used. the Transferable will encapsulate a
Lookup instance.
Comment 7 Todd Fast 2005-06-15 03:23:55 UTC

2. Perhaps we are cross-talking?  Except for a few points, I agree with the
concept of the "Palette Customizer" as described here:

What I was not clear about was the continued existence of the top-level "Palette
Manager" that currently appears in NB 4.x as an action from the Tools menu. 
Having such a top-level action/dialog doesn't seem appropriate when many modules
have different palettes and different ways of managing them.  Are we talking
about the same thing, and do you agree with my last statement?

3. I haven't reviewed the API yet, but what you propose sounds very reasonable,
as long as there is no use case for subclassing PaletteController.
Comment 8 Stanislav Aubrecht 2005-06-15 09:53:18 UTC

2. i think we're talking about the same thing. i agree with you.
Comment 9 Praveen Savur 2005-06-16 04:53:11 UTC
1. Will the Palette top component automatically close if the user goes to an
editor that does not provide the palette. Similarly open when he goes to an
editor that provides the palette.

 Samething for a multiview, will the palette topcomponent close itself when the
user goes into to a view within the multiview which does not provide the palette.
Comment 10 Stanislav Aubrecht 2005-06-16 08:53:21 UTC

1. there's no api for this. the palette module defines a TopComponent and Mode
in its layer (i'll update the arch document accordingly) and it's up to each
editor to setup a group of TopComponents in their layers as needed. the editor
then must use WindowManager functionality to find and open this group when the
editor is activated.
Comment 11 Todd Fast 2005-06-17 01:27:46 UTC
Regardless of the mechanism, does the palette team agree or disagree that the
palette should be auto-hidden as Praveen suggests?  It seems to me that a common
palette becomes much more like the property sheet--the user decides when it
should be shown or not, and if there is no content for the palette to display,
it remains but shows a friendly message like the empty property sheet does.
Comment 12 Stanislav Aubrecht 2005-06-17 09:58:07 UTC

one of the TCRs from the inception review is to make the palette
document-sensitive, i.e. it should auto-open and auto-close when a document
supporting the palette is opened/closed. i'm investigating the best way to
implement this.
however i think there should be a 'show palette' action in the main menu to
allow user to open palette window even though no supported editor is active. in
this case the palette window will show just some kind of 'no palette content
available' message. 
Comment 13 Todd Fast 2005-06-18 01:45:47 UTC
Where did the TCR originate?  If it originated from the JSE team (Trey Spiva or
Praveen Savur), then maybe it hasn't been discussed fully with the other groups.
Comment 14 Stanislav Aubrecht 2005-06-20 08:57:16 UTC

i think it was originally raised by praveen. pls see issue #60189 and add your
comments there.
Comment 15 Stanislav Aubrecht 2005-07-08 16:14:58 UTC
Created attachment 23043 [details]
updated arch document
Comment 16 Stanislav Aubrecht 2005-07-11 14:41:42 UTC
Created attachment 23052 [details]
Comment 17 Stanislav Aubrecht 2005-07-13 15:34:20 UTC
Created attachment 23089 [details]
test coverage (emma)
Comment 18 Jaroslav Tulach 2005-07-14 13:01:09 UTC
Y01 what is going to be stability of the API? Use <arch group='java' 
type='export' /> in arch document 
Y02 We usually try to not refer from API to SPI, this is not the case. Can you 
fix it please? 
Y03 api-changes need some fixes (they should not talk about progress api) and 
also please do not forget to add there one initial change item 
Y04 I'd like the tests to define the expected behavior of the 
FileSystem->DataObject->Node mapping, as that is the one that is going to be 
used the most, imho. Currently it seems tested very little. 
Comment 19 David Kaspar 2005-07-14 15:48:20 UTC
I have 3 comments/questions on current Palette API/implementation:

We are using palette with following structure:
In the layer.xml we have a "Components" folder with items each represented by
InstanceDataObject. Each InstanceDataObject contains also information about
display name, icon, tooltip.
Also we have another folder called "Palette" which contains shadow links to some
(not all) items in the "Components" folder.

We want to show the "Palette" folder in the palette. Therefore we have to
implement FilterNodes and create PaletteConfiguration using these FilterNodes.
Also we have to implement IndexCookie for each category and root node for
correct behaviour of "Change Order" action.

I think it would be better to have something like PaletteDecoration
interface/abstract_class with following methods:
getDisplayName (Lookup item)
getIcon (Lookup item, int type)
getTooltip (Lookup item)
All method could be used for categories as well.
Instance of this interface could be used for creating PaletteConfiguration.
This support would help us to remove dependency on the Nodes API.

In the API there is only one DataFlavor used for all items of all clients in the
palette. Sometimes it is needed to identify a dragged item (e.g. in J2ME you
cannot drop Forms on Lists), so you would like to accept/reject and change mouse
cursor while a Form item is dragged over a List object on the target scene.

Current implementation of Palette UI could cause that one category shows items
in 3 columns and another category has just 2 columns. The number of columns
depends on the width of the widest item in a category. I think it would be
better to have the same number of columns used in all categories.
Comment 20 Jesse Glick 2005-07-14 17:36:08 UTC
To Yarda: Why not refer from API to SPI? API -> SPI is usually OK I think (e.g.
SourceForBinaryQuery -> SourceForBinaryQueryImplementation), though referring
directly to a "support SPI" (convenience impl) is not OK, because such classes
should be possible to duplicate exactly in another module without change in
behavior. What was the context?
Comment 21 Stanislav Aubrecht 2005-07-19 10:47:07 UTC
component palette has just been merged to trunk.