Tag: notes8

Theme for Notes 8

I’m cleaning out unpublished blog entries and this is one. Don’t know why I made a note of this…

plugin_customization.ini – edit the following:

com.ibm.rcp.ui/WED_THEME_PREFERENCE=<theme desc id>

TwitNotes stopped working today :-(

Don’t know if twitter.com changed the API or the service is just unreliable but today the service stopped working for me using TwitNotes. I get a “CWPST0071E: The maximum number of login attempts has been exceeded.” and some funny stacktraces in the log of the Notes client. I also see a “java.net.UnknownHostException: twitter.com” message. Using the website works fine though using the same username/password combination.

I will look into it.

Notes 8 – impossible is nothing


Part of going out and preaching the extensible nature of Notes 8 is having a presentation and demos to back it up. The demos I have but I have been working on the presentation and a graphic for the closing slide. You can see the result so far on the right. It’s clear that I’m not a graphics wizard but I did manage to follow a description on how to create a rubber stamp effect on top of the Notes 8 graphics.

How I survive using Notes 8 sidebar plugins on my 4:3 display at home

Lets face it! The advent of Notes 8 and the sidebar really requires you to use a wide-screen display if you want to keep the sidebar expanded and have some screen real estate left for mail and business applications. This is a major head ache for me when I’m in my home office as my primary display is a 4:3 (i.e. traditional) display and my wide-screen laptop is the secondary display. I found a solution that works for me though.

The way I solve this is by detaching the sidebar plugins I use the most (TwitNotes and Sametime) and have them open in a new window (see the part menu for that option) and then collapsing the sidebar. Now I have the screen real-esate I need on the primary display and my main sidebar plugins visible all the time on the secondary display.

That works like a charm for me.

A call to action for all non-US developers!

In my post titled “XPD – where do you live?” from the other day I discussed some problems with i18n (internationalisation) of applications developed in Java for the Notes 8+ platform using the built-in classes (java.util.Locale). Since that post I have been in dialog with IBM via the Domino NEXT Design Partner program.

It has been confirmed that this is indeed a problem and probably in the core Notes client. The problem probably stems from Lotus Expeditor.

Unfortunately not much light has been shed on the subject except IBM asking me to run a Danish Notes client which is among the worst thing I could imagine doing. I run software in English – period! I do however expect the software I run to be able to detect my computer locale as set in the operating system. As an aside it is actually quite common for non-English speaking Europeans to run English software despite the fact that a native-language edition is available.

As part of this process I have been thinking about the API’s that we need to have available for i18n. It is quite clear that we need

  • the possibility to obtain the language (as a java.util.Locale) of the client itself (that is the language of the menus etc.)
  • a way to obtain the java.util.Locale the OS is configured for
  • an official API for accessing the regional settings as configured in the Preferences for the calendar display in Mail

If we had these we should be able to create the kinds of localized products and plugins customers expect and demand.

What is your take? Can you see more API’s we need while we’re at it?

XPD – where do you live?

Disclaimer: I’m trying to get some info from IBM on this subject so please check back as I will update this post as more info becomes available…

Again this is one of those posts that will annoy the heck out of European developers…

Internationalisation – or i18n – is done using the java.util.Locale class in Java. When calling Locale.getDefault() the standard Locale for the JVM should be returned and should be da_DK for me (country: Denmark, language: Danish), en_US for you US guys (country: USA, language: English) and de_AT for people from Austria (Country: Austria, language: German). The Locale can be supplied to many localisation sensitive classes such as java.util.Calendar etc. to make sure it works as expected for the current user locale. Most times however you don’t supply the locale explicitly which will make the platform do a Locale.getDefault() for the current locale.

Meet Lotus Notes 8+…

Per default Lotus Notes 8+ runs with a Locale of en_US which is great if you’re based in the USA and speak English or simply only use the built-in functionality of Lotus Notes. If you’re a plugin developer and you do any i18n work you will be sadly disappointed since Calendar and ResouceBundle will be broken. Since Locale.getDefault() returns en_US you will get back a Calendar for the US (e.g. Sunday is first day of the week) and English strings from your resource bundles.

Maybe this is why the preference has a page for locale setup (see File/Preferences/Calendar and To Do/Regional Settings) which is used by Mail.

To makes matters worse I think it’s a core platform issue since you can actually change the language of your Notes client by supplying a command line argument (-nl) to the Notes client. Doing this (-nl da / -nl da_DK) changes the menu item text in my Notes client but any plugin that use Locale.getDefault() still return an incorrect result as shown on the image below.

To make it even weirder it works as expected when the Notes client is started from the Eclipse IDE using “-nl da_DK”. Go figure!



(click on the image for larger version)

This behavior has been verified with Notes 8.0.1, Notes 8.0.2 and Notes 8.5 beta 2.

A couple of reasons why the update site template in Notes 8 is cool!

Here’s a couple of reasons why the Eclipse Update Site template supplied with Notes 8 is a killer template and why it’s preferable to use from a Notes users perspective (get the pun?):

  1. Update Site accessible over NRCP (only by Notes clients) or HTTP.
  2. Easy to host on a Domino server even without running the HTTP task.
  3. Replication to other servers.
  4. Easy to control access with ACL.
  5. Easy overview of categories, plugins and features.
  6. Easy to update the update site URL for all/selected features without rebuilding.

If you’ve been doing plugin/feature packaging in Eclipse you’ll really appreciate item number 6.

SWT@Notes 8: Workbench startup and the Accounts API

So one of the things I have been wresteling with over the last couple of weeks is the Accounts API in Notes 8 / Expeditor. While very nice at the core it does leave something to be desired. Trying to interact with the Accounts API from a plugin running in Notes can and probably will result in an exception and the following messages being printed to the OSGi console if you happen to be looking there (which you really should). Look for an upcoming post for any easier approach… 🙂 

CLFMW0050E: Workbench is not ready to handle
   background thread request !
CLFMW0036E: Workbench is not ready for this
   operation

Suffice it to say that the lesson is that the Accounts API might be the same across Expeditor based clients but the implementation differs. For instance On Notes the accounts are stored in the local name and address book while it is stored in other formats in other Expeditor clients. This is all well and good but the fact that a Notes database is the backend store on Notes leaks through the API. The above messages are solved by running the code that access the Accounts API in a NotesJob. Really!? This is very poor design IMHO but something I think we have to live with.

Ahh the frustrations sometimes makes me want to scream…

Show ‘n Tell Thursday: Cross compiling sidebar plugins for Notes 8.0.x and Notes 8.5 (7 August 2008)


I haven’t done a SnTT in months (actually the last one was back on 24 May 2007) so I guess it’s about time. This week it’s about cross compiling sidebar plugins for Notes 8.5 and Notes 8.0.2. Enjoy…

Since installing Notes 8.5 I have had a lot of trouble developing in Eclipse 3.4 for Notes 8.5 and having the plugins work in Notes 8.0.x as well. The problem showed itself as a NullPointerException when trying to load the plugin Activator and a “Viewpart is null” message in the Notes UI. Looking at the log trace showed a class incompatibility message (“bad major version at offset=6”).

So far I have been screaming my lungs out, developing in Eclipse 3.4 and building the plugins in a virtual machine with Eclipse 3.2 as I couldn’t get plugins to work otherwise. Now I finally found a solution that lets me develop in Eclipse 3.4 and having the plugins work in Notes 8.0.x and Notes 8.5.

The issue is that Eclipse 3.4 configured with Notes 8.5 as a target platform is using Java 6 and that Notes 8.0.x is using Java 5 which causes class format problems. The solution is to set the required execution environment in Eclipse 3.4 which will cause Eclipse to build correctly. Setting the required execution environment (J2SE-1.5) is done in the “Overview”-tab of the MANIFEST.MF editor as shown below.

Using the GUI is of cause just a shorthand for editing the manifest manually. As an alternative you can edit your META-INF/MANIFEST.MF file directly and add the following line:

Bundle-RequiredExecutionEnvironment: J2SE-1.5

Please note that this is not the default value when creating new plugins in Eclipse 3.4 so you’ll have to pay attention and make sure it’s set correctly. This is of cause only necessary if your plugins need to work on Notes 8.0.x as well as Notes 8.5.

Thanks to Pierre Carlson from IBM for pointers on this.