ViewerSupport and ITableColorProvider or ITableFontProvider - java

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.

Related

GEF OutlineView

i built a GEF-Editor (like the OPM-Editor) and i need your help with the OutlineView, because my try doesn’t work. I built the ContentOutlinePage like the GEF-example in the ShapeEditor.
I return my new OutlinePage in getAdapter, when the type is IContentOutlinePage.class.
Then i call createControl and setContent(model), there is the error. I cannot set the addPropertyChangeListener, my model isn't designed for this Listener
The solution in the ShapeEditor seems to be very complicated.
Is there not a simple solution for the ContenToutlinePage or have somebody a solution with this OPM Editor?
Thanks for our help
See ShapesEditor#createControl(Composite parent) line 355:
getViewer().setEditPartFactory(new ShapesTreeEditPartFactory());
This is probably what you're missing the right implementation for. You'd have to implement your own EditPart factory to construct your own tree edit parts (subclass GEF's AbstractTreeEditPart).
ShapeTreeEditPart #activate() and #deactivate() methods add/remove property change listeners. These listeners are to react to model changes (name label has changed for example) so you'd register your own model change listeners there or leave the method empty if you don't care of the changes to the model.

How can I get a new Window instance on Android?

I am attempting to create a custom Media Controller by duplicating the source and providing my own layout. The final component is a substitute for PolicyManager.makeNewWindow(mContext);
The PolicyManager class is an internal class and I can not seem to find a way to get a new Window. The documentation suggests new Window(mContext) but eclipse complains that it 'Cannot instantiate the type Window'. Any ideas?
Unless you use the NDK to access private implementations, you cannot actually create a Window. I have done exactly what you are trying with an embedded system, but it is not safe to do for a general purpose app (the underlying implementations have changed and will change again).
Regardless of whether you are using a SurfaceView or TextureView for the MediaPlayer, you should be able to a achieve a similar effect with a regular old transparent custom View. The separate Window shouldn't be necessary. It won't be as easy as copying Android's MediaController code, but it shouldn't be too complicated.
Also, if all you want is a different layout and not a drastic change in functionality, have a look at these two links (the second refers to the first, but it adds commentary & an example project).

UndoRedo.Manager and JCheckBox

I am using the UndoRedo.Manager to implement Undo/Redo functionality in a Netbeans RCP application. The undoableEditListener can be added to any Document, that limits its use to text-related fields. Does anyone know how i can add such a listener to elements without a Document, like a JCheckBox?
Just create custom CompoundEdits or even separate edits. See for example the edits merging in one http://java-sl.com/tip_merge_undo_edits.html
I think all you need is to keep own events stack and implement custom UndoableEdits which don't change model (Document) but change state. In other words you need more complicated model to keep checkbox state as well as Document in one. All the complicated model changes (state change or docuemnt change) should be represented by custom UndoableEdit class. The class instance could be wrapper for Docuemnt edit event or just custom event.

What is the Renderer class for UIXIterator

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.

How's View gonna know what component to create?

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.

Categories