Summary
What is the renderer class for UIXIterator(af:iterator)?
Background
I am writing a component and I am planning to extend UIXIterator just like UIXTable does. My component will basically accept the same kind of data binding as UIXIterator/UIXTable does. The only difference will be in the rendering and the client behavior.
I am conducting some preliminary checks to see if this is feasible and how I will go about doing this. I have already determined that most likely I can just extend the component and tag classes(UIXIterator and UIXIteratorTag respectively). The only thing that I am not able to find is the renderer class for UIXIterator.
There is no default Renderer. It renders himself, unless you did not set rendererType in UIXIterator class.
Related
I'm writing an RCP-Application and trying to use databinding to link the controls of the GUI with the model. This includes for example binding data to a table.
As far as I understood, org.eclipse.jface.databinding.viewers.ViewerSupport is the recommended method to bind a model to a table viewer. This will however only allow me to put the data as text into the table. I'd also like to change the foreground and background color aswell as the font of some cells, depending on other observables. I'd also be happy if I could somehow get a ITableFontProvider or ITableColorProvider into what ViewerSupport.bind(...) produces.
So far I've not found a nice way to do that. I could copy the contents of ViewerSupport.bind() and override the LabelProvider with my own class. This seems a bit messy.
I could also after calling ViewerSupport.bind retrieve the LabelProvider and replace it with a delegating LabelProvider which also implements ITableFontProvider and ITableColorProvider. This leaves me creating a lot of methods that do nothing but delegate things to another object. Not very elegant aswell.
All of that doesn't seem so nice. Any idea how to do it in an elegant way? Am I overlooking some factory class to do that?
ViewerSupport just provides simplified methods based on the various data binding content and label providers. It is perfectly acceptable to use these content and label providers directly when ViewerSupport does not provide what you want.
For example, ViewerSupport.bind(StructuredViewer viewer, IObservableList input,
IValueProperty[] labelProperties) is just:
ObservableListContentProvider contentProvider = new ObservableListContentProvider();
if (viewer.getInput() != null)
viewer.setInput(null);
viewer.setContentProvider(contentProvider);
viewer.setLabelProvider(new ObservableMapLabelProvider(Properties
.observeEach(contentProvider.getKnownElements(),
labelProperties)));
if (input != null)
viewer.setInput(input);
So you could just use this code but with a sub-class of ObservableMapLabelProvider with your font and color providers.
Greetings fellow Stackoverflownians!
I am building an Eclipse RCP application, and have come across an issue:
I want to set a tooltip text on a TreeItem, but this class does not inherit Control, which is the class that has the setTooltipText
EDIT: It seems that jface is supposed to take care of this seamlessly, through a LabelProvider.
I am using a ColumnLabelProvider with getToolTipText method on each column of a complex TreeViewer, but it isn't working. I wonder why...
The probleme here is that you use the SWT-Tree.
You should use a TreeViewer (JFace) which wraps the tree and gives you more sophisticated options.
Inside the label provider of the TreeViewer, you can define your tooltips.
Learn more about viewers here and here
An code example (tool tip) is here
I strongly recommend you to use the viewers!
With TreeViewer use
ColumnViewerToolTipSupport.enableFor(viewer);
Use a label provider derived for CellLabelProvider or one of it subclasses and override getToolTipText (there are also several other methods to control the font, time out and the like).
I have started trying to create normal MVC Swing components. I have no problems with M and C, but V had thrown at me one problem which I cannot normally solve.
The problem is: Controller is main class of the component (MyComponent, for example), and it extends JComponent. View is ui delegate (MyCompanentUI) extended from ComponentUI class. All what delegate does is adds JTextField in MyCompanent and provides data binding between MyComponentModel and this field. It works just fine. But how I can bind events from JTextField to MyComponent?
If user wants to handle some events he adds listeners to MyComponent, but all real events (mouse, focus, keys, etc.) intercepted by JTextField, about which user does not really knows.
So is there any normal way to do this, except catching events and translate it to original component by hands? Or is there another way to create delegate and I just really do it all wrong?
UPD:
Thanks for your response, trashgod.
But I had something different in my mind. I was talking about something like "events inheritance", like in the case of "inheritsPopupMenu" method. So that then key, focus or mouse event happens to the component one does not process it itself, but directly transfer it to parent component. But it seems impossible, because I have noticed JSpinner has exactly the same issue - you cannot get almost any event notification from this very component.
If you are writing your own JComponent subclass and want to allow for custom UI delegates, I'd start with Kirill Grouchnikov's How to Write a Custom Swing Component.
If you are writing a composite that includes an existing JComponent subclass, such as JTextField, see if you can leverage the existing Action instances described in How to Use Key Bindings. ScrollAction is an example. You can learn the names of such actions from the component's source(s) or using #camickr's handy utility seen in the article Key Bindings.
I am currently working on a set of custom controls for a product of the company I'm working in. For this, I am extending a lot of Swing controls and also overriding a lot of paint methods.
In order to maintain a consistent color scheme, I receive the colors for my paint, setBackground etc. methods using UIManager.getColor.
This was perfectly fine until we noticed that the Nimbus LookAndFeel, which is shipped with current JRE versions, uses totally different color keys, thus many things looks totally out of place.
For instance, while all other stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) have defined the key "text" as a bright background for texts and "textText" as the corresponding foreground color, "text" in Nimbus is actually a black foreground color, and a standard text background color does not seem to exist.
"TextField.background" would work, but that, for instance, doesn't exist for the Windows LookAndFeels.
I suppose you get the problem by now. I don't want to have to maintain a set of color keys for each LAF, who knows what LAFs will be added in the future and which my company may decide to use.
A simple solution would be getting rid of Nimbus, of course, but understandably my boss doesn't like this idea at all, besides Nimbus is part of the JRE these days and should be supported.
So I wonder whether there is any standardized way to get LAF-dependent colors like, say, "text background / foreground", "selected text bg/ fg", etc.?
I'm not sure that there is a "standardized" way of getting these values.
As you noticed, Nimbus uses its own names for colors. Specifically, the properties textForeground and textBackground.
This oddness is likely because Nimbus uses a small selection of basic colors (listed as Primary in the chart), which have Secondary colors calculated from them, which in turn are used as the basis for all the remaining colors.
Yea, as #josefx implied, unfortunately this isn't how the UIs work. They're not a pool of generic portable properties, rather they're a set of actual components and specific implementations for each of those components. It's not really an extensible system that's friendly to custom components.
The level of abstraction IS the component, not something finer grained. If you try to ask for a ComponentUI for a component that the L&F does not know about, you're out of luck. And the ComponentUI is little more than a wrapper for a paint method, so it's not obligated to expose any meta data at all.
Simply put, you're stuck basically doing the JTextField (or some other appropriate component) "color scrape" technique that josefx suggests, or adding specific support in your code to handle the eccentricities of the property names of the L&F's that you wish to support well.
Another suggestion is to "pre-empt" the L&F change, and subclass the L&Fs you wish to support to make your components more of a first class citizen within those L&Fs. When the L&F changes to a L&F that you support, silently switch out their class name with your subclasses class name, and then implement ComponentUIs for your custom components, and extend the parent LookAndFeel.createUI method so that it "knows" about your new components.
None of these are pretty, but the Swing component system isn't designed to be extensible at run time to handle custom components. The entire component suite is done all at once when the L&F is created.
There is no way around it - you have to create your own abstraction layer for color names (and possibly other property names).
Basically you have stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) that use their own color names and Nimbus that uses different names.
Create a class e.g. LafProperties so that for each property/color you have method (e.g. "getTextColor"). This class returns properties for classic Laf styles. Then extend this class for Nimbus, and change only methods that differ in Nimbus.
If stock Lafs and Nimbus have most of the properties differently named, than use you might use an interface and two implementing classes.
Not a nice way but it should work for the basics:
Create a JTextField
call getForeground,getBackground,getSelectionColor to get the laf dependent values
Update:
The ComponentUI class and its subclasses which are the base classes for all look and feels only provide a method to initialise the laf dependent default values, they provide no direct way to access these values.
The java.awt.SystemColor class provides variables for a lot of the common attributes.
For text foreground/background use the member fields text/textText; for selected text, use textHighlight/textHighlightText.
Few things ppop into my mind reading your question, which is a tad spiced with underbelly frustration if I have sensed well:
dependancy on JRE standards/support versus independancy/freedom solutions
standards & conformity versus creativity & customisation
And thus ultimately:
practical approach of your boss versus programmers far future insights
I'm developing this application where you can put text and drawings in a page. My application is in MVC pattern, and I need all the model parts, text and shapes to be of the same notion. They all extend an abstract ReportElement clas, for example.
But the problem is I crate a JPanel for every shape in the page, but to handle text I need to use JTextArea or something. To render the elements the View directly gets the report elements list from the Model and draws one by one. How can I distinguish a text element without hurting the MVC pattern.
I mean, it's impossible, right? I don't know, any ideas?
I think you're looking for the "Factory Pattern"
You need to have a wrapper method that returns a JComponent based in your own ReportElement conditions.
I would handle this situation by building a factory method that produces the right type of Swing component for any given ReportElement, like this:
public static JComponent buildViewForReportElement(ReportElement element)
Inside this method, you will need to actually inspect the ReportElement objects to see what type of component to build. This inspection might mean checking a field or a flag on each object, or might even mean using instanceof to distinguish different subclasses of ReportElement from one another.
Note that inspecting ReportElement objects like this violates the philosophy of object-oriented programming. A simple "object-oriented" solution would require all of your ReportElement objects to have a buildView() or getView() method, and so your GUI code could just call getView() on every ReportElement without knowing which implementation of getView() was actually being called.
Unfortunately, the object-oriented solution forces you to mix your view code with your model code, and it's good that you are trying to keep the two separate. That's why I would advocate keeping the GUI-building code out of ReportElement objects and instead using a factory method to build the right view for any given ReportElement.