The new jface.databinding needs users....

Yesterday I met Boris Bokowski. He is member of the core UI team in Ottawa and he worked on the jface.databindings framework. The databinding frameworks simplifies linking between UI elements and data models. You essentially link an attribute of a model with a widget, like a text field, checkbox or a tree ore table viewer. The framework registers listeners to the model and the widget and when one changes the other gets updated. It has also support for validation.

It is not clear if it will be API or experimental in 3.2. Feature freeze is soon, and users of the framework are needed.

One interesting idea in jface.databinding is that UI elements and data models are treated the same. That means, the same mechanism (IUpdatable) is used to talk to the UI and to the data model. IUpdatableFactory creates an IUpdatable for an Object. Default IUpdatableFactory for SWT widgets and java classes (using bean properties) exist. This makes jface.databinding very flexible. But this flexibility makes it too complicated for my taste. I think it suffers a bit from trying to solve too many problems. If it would be limited to provide binding needed for typical dialogs (standard SWT elements), it would cover the 80% case. Getting 100% and being very simple is probably not possible.

I have created several similar databinding frameworks in my career. The first ones were based on ET++. Later I create a binding framework for swing and recently one for SWT. The major difference between my binding frameworks and the jface.databinding is that there are widgets on one side and a datamodel on the other (no attempt to unify data access and UI access). A "ValueAccessor" represents an attribute in a model. ValueAccessor provides information typically needed for dialogs: value, valueAsString, isEnabled, isDefault, default, labelProvider (jface.databinding.IUpdatable in contrast, does not model enablement nor defaults nor label providers). My bindings is much less generic but it is much more targeted to bind a model to a UI. You then essentially bind a widget with a valueaccessor. My Binding class knows how to bind SWT widgets to ValueAccessors.

There is already a kind of very simple databinding in eclipse: The preferences.FieldEditor classes. This is limited to binding to preferences and it also provides some automated layout. And it is not flexible enough to be a general binding fremawork. But I wish the jface.databinding would have some simplicity of the FieldEditors...

Maybe a simple layer on top of jface.databinding could help....

Anyway, I wonder what others think about the jface.databinding framework...

Resources:

• jface.databindings wiki page
  
• The main bugzlla entry: Data binding framework for SWT and RCP needed
  
• bugzilla entries
  

Stop Windows Update to Reboot Nag Dialog: sc stop wuauserv

When installing updates on Windows XP SP2, sometimes there is this annoying dialog that forces you to reboot your system. If you say "No" it will come up after a few minutes again and again....

To stop this, run the command sc stop wuauserv. This will stop the update service. After the service is stopped, the nag message stops, too. Then you can reboot when you have time. The service will restart when you reboot.

When seamless integration becomes a nightmare...

Eclipse is a great integration platform. There are many plugins that work together very nicely. As a user you don't have to worry where a menu item, a new wizard, a preference page, a view or an editor, etc comes from. You install a plugin (or add-in or extension) , and it's integrated. Great!

However, the dark side is, that it's very hard to figure out what a particular "plugin" is contributing to eclipse. Just make the experiment: install 30 plugins you have never used before from eclipse-plugins.info into your eclipse installation. Now you have new views, editors, context menu entries, toolbar items, menu items, new wizard items, export/import wizard entries, preference pages, perspectives, help pages, cheat sheets, property pages, keyboard shortcuts, perspectives... But you have no idea which contribution belongs to which plugin. But without a map in your mind what a particular plugin is contributing it is very hard to use and it's hard to understand what to expect from a new plugin.

My personal strategy is to install plugins one by one into a well known eclipse environment. I take some time trying to figure out what the contributions of a plugin are. That's tough enough for me as an experienced eclipse user. It must be a nightmare for someone who starts using eclipse, because he typically starts with a "product" that consists of a set of pre-installed plugins (just like installing 30 plugins at once)... I also install each "plugin" in its own eclipse extension location so I can easily uninstall it later (but that's another story). Really problematic are contributions to wizard pages and context menus of some objects in tree views. Unless you have selected the right obeject you don't see the contribution. I often install a plugin and then I ask myself: "And now? How do I find out where it contributes?". This is particularly problematic with small not well documented plugins: I install it and I have no clue where search for its contributions.

What could be done to help users identifying the things that have been added by a plugin? Maybe a kind of plugin inspector (feature inspector), that lists in a view all the contributions of a plugin (feature, add-in, extenison).

Windows highlights newly installed programs in the start menus. Maybe there could be a setting to highlight the contributions of a particular feature.

Any ideas how to solve the problem?

"Plugin": an overloaded and confusing term in eclipse

When people talk about "plugins" in the context of eclipse, they mean two very different things:

1. Technically speaking a "plugin" is an installable OSGi plugin, which ends up in the plugins direcory of an eclipse installation (or one of its extension location) and gets loaded when eclipse starts. It can either be a directory or a .jar file. It must contain a MANIFEST.MF and/or a plugin.xml file. Multiple plugins can be assembled into an installable "feature". (Which is also confusing, that a "feature" consists of a set of plugins. As a navive person I would expect a plugin to have multiple features).
   
   
2. Eclipse users think of "plugins" at a higher level of granularity. If you go to eclipse-plugins.info, there are over 1000 "plugins" to install. But those plugins usually consist of multiple OSGi plugins and installable features...

You often hear: "Oh, if found this new and cool eclipse plugin, you should install it and try it". In this case the speaker rarely means a single OSGi plugin, but an "eclipse extension". If you hear: "My plugin depends on plugin org.foo.bar", we are talking about OSGi plugins.

Therefore it can be very confusing to talk about "plugins". And I think "user plugins" should be called eclipse extensions or add-ins or something that can not be confused with technical plugins.

Any ideas how to resolve this confusion?

Future Trends (for C/C++): AOP and MDSD...

I think two trends will change the way we develop software in the future: Aspect Oriented Programming (AOP) and Model Driven Software Development (MDSD). Being an OO programmer for 20 years and working on Java and eclipse, that's not surprising. Eclipse hosts the AspectJ project and there is a AspectC/C++ plugin. The eclipse Generative Model Transformer project (GMT) is an interesting research ground for MDSD. OpenArchitectureWare also provides eclipse plugins for MDSD.

However, most of the programmers that only develop in C have no clue what's coming. It might sound for them like another hype (similar to OOP) and they feel it won't change their world because it's so far away and esoteric. But AOP and MDSD is closer to their world than they think. In some sense AOP and MDSD act like an "advanced" C preprocessor. Adding "aspects" today is often done #ifdefs and complex macros are used to "generate" code. Those lost in #ifdes and #defines might find it helpful to get new tools at their hand that allow them to do what they always did but at a higher level....