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.
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) components. (ui specification to be added soon)
Created attachment 22613 [details] answers to arch questions
source code with javadocs is in cvs branch 'palette_58859' in module 'core/palette'. there are only two public packages: org.netbeans.modules.palette.api org.netbeans.modules.palette.spi
link to UI specification draft: http://ui.netbeans.org/docs/ui/palette/index.html
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.
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...
tfast: 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). lkotouc: 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.
saubrecht: 2. Perhaps we are cross-talking? Except for a few points, I agree with the concept of the "Palette Customizer" as described here: http://ui.netbeans.org/docs/ui/palette/index.html#customizer 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.
tfast: 2. i think we're talking about the same thing. i agree with you.
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.
praveen: 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.
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.
tfast: 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.
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.
tfast: i think it was originally raised by praveen. pls see issue #60189 and add your comments there.
Created attachment 23043 [details] updated arch document
Created attachment 23052 [details] JavaDoc
Created attachment 23089 [details] test coverage (emma)
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.
I have 3 comments/questions on current Palette API/implementation: D01 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. D02 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. D03 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.
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?
component palette has just been merged to trunk.