Two projects approved: Mobile Tools for Java (MTJ) and Native Application Builder (eWideStudio)

Yesterday I attended the the creation review of two projects, both are part of the DSDP (Device Software Development Platform) top level project:

• Mobile Tools for Java (MTJ): The project provides tools for java development on mobile devices. A kind of PDE for mobile devices. It does not provide any library on the devices, but tools for developers to create software on those devices. It deals with deployment to a development target (emulator or real target), device emulators, the build process and debugging. Nokia, from Finland, is the driving force.
• Native Application Builder (eWideStudio): There is a cool Japanese open source UI library called WideStudio/MWT. It runs on all kind of operating systems but is also tuned for mobile devices. If you have ever been in Japan, you might know that Japan are far ahead when it comes to mobile devices compared to US and Europe. This project will integrate this library into eclipse and CDT. There's also a UI builder for eclipse (I should have asked if it is integrated into VE or if it is independent). There is some overlap with eRCP and eSWT, but this is a C/C++ library. Since it's Japanese (sponsored by Fujitsu), you don't have to worry about problems with 16 bit characters ;-).

A List of all Component Areas of Platform UI

Platform UI is divided into more than 50 areas, like JFace, KeyBindings, ProgressBar, Viewers, Wizards, IDE etc. In bugzilla, bugs are tagged with square brackets in the bug report subject headings to indicate the affected area.

TheComponent Areas for Platform UI lists the name, a short description, a link to the related bugs and the owner of the component area.

It's also a cool starting point to understand what is in the eclipse platform....

Eclipsecon recommendations...

Eclipse-con allows you to write your personal recommendations which talks you think are interesting and what you want to attend. Just look at this, at the bottom you can choose which recommendations you want to highlight. It's a cool idea. So, I did it. I created an new eclipsezilla entry of type "Recommendation". Then I read the program and I wrote down my thoughts while deciding which talks I want to attend. Just use the eclisezilla id of the talk (the ...id=123) and put cite it as 'submission #123' in the text. My recommendation got be accepted :-)

How to speed up eclipse on a Laptop: disable virus-scanner, partition disk, upgrade memory

I have a Dell Lattitude 600 with 1GB of memory. Starting eclipse and building workspaces is slow. So I was looking for ways to improve speed. Here is what I did over time:

• Disabled the virus scanner for the eclipse directory and the workspace. McAfee's on-access-scan scans the entire file when a process accesses it. When eclipse starts is only reads small fractions of .jar files. However McAffee scanned the entire file which really slows down start-up by a factor of 2: cold start-up (=newly booted machine) 95 sec without versus 215 secs with virus scanner on.
• Partitioned my disk: I tried all kinds of defragmentation (oodefrag and diskkeeper), but nothing really helped, some made it even worse.. However one problem is that compiling creates new files and that leads to new fragmentation. Now I created a relatively small partition with my workspace. Even if this gets totally fragmented, the disk head in confined within the partition. It gave me some speedup, but I have not measured it, but it was dramatic. I wish there was a defragmentation tool, that could observe the startup of eclipse and then rearrange the files so that the access is optimal. I know such tools exist for the startup .exe files, but we need something for the startup of a system like eclipse....
• Upgraded the memory to 2Gb and disabled the page file: Yesterday, I did the upgraded and it's great. With 2 eclipse open, outlook, trillian, thunderbird, firefox, and a few other programs, I use about 1.5Gb of memory with enough space for the disk cache. That's a real blast: because no application gets paged out anymore, I don't have to worry about switching between applications. No more long interruptions when eclipse garbage collects. It's so new, I still can't believe that I don't have to wait anymore when I switch between applications. And 2 workspaces open in parallel is no problem anymore....

In a nutshell: It's all about minimizing disk access.

MDSD: A European Phenomenon?

Yesterday, I wrote about my confusion with the 4 metamodel layers of MOF. Ed Willink )GB!) pointed me to a nice (French) paper about MOF. Their application of the layer is very similar to my understanding :-).

When searching for concepts around MOF and MDSD there very many European hits:

• MOF m0 m1 m2 m3 metamodel
  
• MDSD MOF
  
• MDSD MOF
  
• MDSD Model-Driven Software Development

Is this a European Phenomenon? There is a kind of pattern: many new concepts are invented and researched in Europe, but commercial success often comes when American companies pick it up....

I am confused by OMG MOF 4 layers applied to MDSD and UML...

Today I tried to explain to some colleges the 4 layers of the OMG Meta-Object Facility (MOF). At first it sounds quite trivial:

• Level M0: User Object Layer (Instances)
  
• Level M1: Model (DSL – Domain Specific Language)
  
• Level M2: Meta-Model (Schema description Language)
  
• Level M3: Meta-Meta-Model (The Schema of the Schema)

Surprisingly applying the levels to concrete problems is not always obvious or straight forward.
I used the plugin.xml file as an example. I take here a MDSD centric approach, by assuming that the plugin.xml file "generates" the plugin....

• Level M0: (Instance) The deployable component
  
• Level M1: (Model) The plugin.xml file itself
  
• Level M2: (Meta-Model) The extension point schema description (.exsd) files
  
• Level M3: (Meta-Meta-Model) Schema of the .exsd files (implemented somehow in the .exsd editor)

Someone (a compiler person) asked me, how I would apply this to a programming language like C.

• Level M0: (Instance) Executable code
  
• Level M1: (Model) .C file (or a AST (Abstract Syntax Tree) representation)
  
• Level M2: (Meta-Model) C language syntax definition (e.g. in yacc)
  
• Level M3: (Meta-Meta-Model) Yacc language syntax definition

In this case, the meta model describes the constraints on the are AST (that's what the CDT does). This shows, that it makes sense to have a DSL (Domain Specific Language) at some levels. The DSL of C is simply the c syntax. The DSL of the c-syntax is yacc (or EBNF)... It is also interesting to have transformation between different representations of a model at the same level. C versus AST, yacc versus EBNF... The "code generation" happens between M1 and M0 (compiling). Another code generation happens between M2 and M1 when using a compiler-compiler like yacc.

But whenever I read about UML and MOF I get confused. This might have to do with the fact that I never really used UML....

• Level M0: (Instance) Generated C/Ada code
  
• Level M1: (Model) Concrete UML diagrams
  
• Level M2: (Meta-Model) UML "language"
  
• Level M3: (Meta-Meta-Model) ??

Again, a generator/transformer is applied between M1 and M0. Is this a correct application of MOF to UML?

But explaining both (the MDSD and the UML approach) to someone who has not been exposed to modeling gets very confusing.

So, in "my world" I prefer to see the MOF hierarchy very MDSD centric. I wonder if the MDSD centric view is confusing for UML experts is is the a natural way to see the world....

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?