Is it possible to change view part contents depending on selection? I have a view part that is subscribed to selection events and depending on some conditions different set of controls is shown in the view.
This sounds rather like swing cardlayout, however I am not sure if there is an analogue in swt and I do not want to hardcode view contents in java code.
Something like eclipse command framework <visibleWhen> expression is really anticipated.
I think StackLayout is what you're looking for. It's very simple to Swing's CardLayout.
Is it possible to have declarative expression that will chose view part contents? I am trying to achieve something like History view where one view part may contain controls contributed with different plugins (e.g. org.eclipse.egit.ui, org.eclipse.team.ui)
No, you'll need to create your own extension point for that. The good news is that it isn't too hard.
Related
I'm using NetBeans 8 IDE to design a desktop application. How can I transit among different forms (e.g. login page and homepage)? Should I design multiple .java JForms or is it possible to completely delete previous components and bring new ones?
Is there something like hidden tabs that aren't shown to the user but really exist? I am looking for a high performance way to toggle forms.
Were you to have the form constructed programmatically - although this is a bit inefficient - you could use a switch statement in a loop with cases that contain the individual forms, and statements to clear the existing form components. There's also an easy JavaFX navigation solution using a larger-than-viewport area (containing each form in a horizontal series) wherein the forms get the viewport one-by-one, but it looks like you're using swing; sorry if it's of no help in this case.
Both the Book of Vaadin and the Vaadin training course recommend using acom.vaadin.ui.CustomComponent to contain a Layout.
I can understand this in pure theory, to encapsulate the contents without needlessly exposing a specific layout such as GridLayout or HorizontalLayout. Encapsulating has benefits of:
Encouraging de-coupling between classes
Makes it easier to change the layout without having to change the declarations in the outer class.
But in terms of practicality, I assume the rendering of a CustomComponent means extra HTML/CSS layout instructions such as perhaps an another div. The last thing Vaadin rendering needs is yet another layering of HTML structure.
I wonder if this might be old folklore. Perhaps using the visual composing tool in Eclipse accepts only CustomComponent objects rather than Layout objects? (Just a wild guess, I have no knowledge)
➤ Alternatively, why not just declare in the outer class a reference variable of type com.vaadin.ui.Layout to get the same encapsulation?
➤ Am I exaggerating the impact of adding a CustomComponent to Vaadin rendering?
➤ Is there some other benefit of CustomComponent which I’ve failed to perceive?
You can compose the content of a CustomComponent with the Visual Designer. This saves a lot of time in the development process
The main advantage of the CustomLayout is, that you can place your components inside HTML code which you otherwise can't generate via vaadin means.
If this adds more div/html as with native Layouts depends on the specific case.
We ususally use it only when a clean Vaadin only solution would introduce more components/div's or is not possible to implement.
The second idea is the separation of layout and logic, which can be implemented partially with this Layout. You just specify which components you have and then a UI designer (in theorie) could make your HTML code, with the correct blocks where your components will be placed.
In real life I do not find this a real advantage, since the whole CSS, sizing etc. is anyway done with vaadin.
I want to change tabs location from left to center. How can I do this? I think I must change Look&Feel, but I don't know how.
From this:
To this:
As you already pointed out, you have to use an LookAndFeel which supports this design (centered Tab-Button).
When your selected LaF does not support this, you have to write your own TabbedPaneUI.
(But this may not be very easy.)
If you do not want to create your own TabbedPaneUI, you have to look for an existing custom TabbedPaneUI or TabbedPane-Component, which support this kind of layout.
You can take a look at this article, to get started:
http://www.javaworld.com/article/2072927/swing-gui-programmingloseandmaxtabbedpane--an-enha/swing-gui-programming/closeandmaxtabbedpane--an-enhanced-jtabbedpane.html
The placement of tabs is determined by the JTabbedPane UI delegate, typically based on BasicTabbedPaneUI. Not every Look & Feel implementation supports centered tabs, so there's no property that will work by default across platforms.
As a concrete example, com.apple.laf.AquaLookAndFeel supports centered tabs, as shown below. The class com.apple.laf.AquaTabbedPaneUI, which implements the effect, is shown here.
Because the implementation is non-trivial, a better choice is to support the user's Look & Feel choice using Preferences. A suitable Look & Feel selection control is shown here and here.
The source for the example above is seen here.
When specific action is performed, I want to replace button with text field. I know that I have to call button1.setVisible(false); but I don't know how to create text field on the exact same place. I am using NetBeans designer, if you can give me a hint, how to add 2 components at same place, and switch between then, something like switching between layers in photoshop, if something like that is possible, would be great. Thanks
For many components in one space, use a CardLayout as see in this short example.
I have the following requirement for a GUI, that the user will have a number of available actions to perform.
Currently, it is implemented a series of JButtons that the user presses.
But the actions are a lot, and in each version more "actions" would be possibly offered.
I am not sure how this is better presented/done in GUIs.
I have read that there are ways to form a gui describing relevant information in an xml file.
I am using Netbeans and swing. Is the xml a good idea, to describe the actions available and for example create the same number of buttons? If yes, how would I start on this?Additionally would a jtoobar be a good idea for the actions? I mean add as many buttons as needed in the Jtoolbar.
I guess this is a general question but I am not experienced in GUIs.
Any help would be appreciated!
Thank you.
There seems to be two separate issues involved:
How to describe and create a large number of actions?
How to represent a large number of actions in GUI?
#Tom's answer is for #1, and #Fabio's for #2.
You can use any textual format for #1, xml, csv, whatever you like. It's indeed a good idea to separate that from code. XML is great for hierarchical data, so it may be overkill if you just need a flat list:
<doc>
<action name="Action 1" id="ACT1" description="blah blah" icon="icon1.gif"/>
<action name="Action 2" id="ACT2" description="yada yada" icon="icon2.gif"/>
...
</doc>
But parsing such a simple XML is basically free, so you may as well just use it. You do not, however, need a full-featured XML GUI toolkit like SwiXML, unless you want to add many other GUI widgets with complex layout to your app.
Note the attributes I have in the above sample. id would map to a unique action command. You can display description and icon (I suppose you use icon already) any way you want. You could also have other properties like mnemonic, accelerator, etc., at which point using XML starts to pay off: you can add arbitrary attributes that you need.
One obvious omission in the XML is the actual actions themselves. I do not think you should put Java code in XML. It defeats the separation of concern. Instead you can define your action code in a generic way (e.g. extend AbstractAction) and map them with the action IDs. If you do use AbstractAction, you can trivially map your attributes to action property keys like Action.NAME, Action.LONG_DESCRIPTION, etc.
Now you have parsed the XML into a list of action objects, and here comes the second question: how do you display them?
JList (per #Fabio) is indeed the most efficient way. It's much more compact than a whole bunch of individual buttons, yet unlike JComboBox you can see many items at once, and you can easily add sort/search/filter.
But list is not very flexible. You could use a custom ListCellRenderer to display icon and tooltip (for description), but you'll start to stretch it when you want to group items.
I think the most flexible way would be a tree table, which allows you to have multi-level hierarchy. You can start with 2 columns, the first column showing action names hierarchically, the second column showing description.
You could put the table in a collapsible panel so that it can be hidden when user wants to focus on the results.
Now w.r.t. JToolBar, you're right that it's standard, however as Fabio's comment pointed out, it's bad usability when you have too many buttons on a toolbar (like M$ Word before ribbon).
What would be a great use of a toolbar, however, is to allow user to place actions of their choice onto the toolbar, like most popular desktop apps do. You could use a "Customize Toolbar" dialog, or simply let user drag-n-drop items from your list or table.
Unfortunately, many of the GUI constructs that I mentioned above are not available in JDK. You can find all of them (tree table, search/filter, collapsible panel, customizable toolbar, etc.) from the excellent commercial JIDE libraries (disclaimer: I don't work for them, though I sometimes wish I do), or you can find FOSS alternatives.
I don't know if i did understand your question well, but it seems to me that the JButton approach isn't the most efficient way to do such thing. Imagine that the number of actions starts to be really big, drawing too much buttons leads to an unintuitive and non-appealing interface. An alternative would be using a JComboBox or a JList, to list all the actions not requiring much space and having a single button "do!" to execute the action.
I hope it was useful ;)
Contrary to popular belief around a decade ago, XML is not usually a good idea. An appropriate language to express this "programming" in is Java.