SSR plugin: improvements

Due to great number of panels in SSR plugin (first drawings took 5 pages of paper on notebook), I've decided to put each panel in separate class (extension of JPanel). Also, I've re-used code from GMTIGenerator to get the table to enter lat/lon coordinates. Right now I have implemented all Requester ID and all GeoArea* panels.

It's all getting more and more in shape. Yikes! :-)

fixes Ctrl-Backspace behaviour, working on SSR

I had to fix annoying 'Ctrl-Backspace' typo in new release (Ctrl-BS in chat window should erase a word).

Also, I recovered (again) beginnings of SSR plugin and tried to do something with it.

I've been helping out Reiner Beck today with his installation. He pointed out to the old 'bug' that I thouhg I've eliminated: when user changes look and feel in Preferences | Appearance | Theme (Look and Feel), SALT menu dissapears from right-click menu in the roster. I remember talking about that with Adam Olsen once and he said that this is the way Look & Feel works (or something like that). I need to see if I can do anything about that.

JBother using local mirror for plugins

This feature is maybe not too needed, but it would probably make our users happy: JBother can now use other plugin mirrors than standard one (on www.jbother.org). That means that people running JBother on "closed" networks (like us) can set-up their own plugin mirrors and the users can be up-to-date much easier. I've sent the patch to JBother developers, I hope they will include it into official release.

UPDATE (26.07) : the changes has been included in official JBother release.

Also, I was testing task with Apache ant (separate target makes it even easier to put freshly built SALTPlugin onto our local plugin mirror!). Interestingly, it doesn't work with it 'out-of-the-box': you have to download additional package from Jakarta Commons. After that it is very handy.

GeoLocationDialog bug fixed

Well, it took me some time but it looks that bug in GeoLocationDialog is gone. I was using too large precission factor in Point class; 1000 is enough (I hate when such things happen!). I also managed to fix some minor bugs in ant build files and - voila! - new version of SALTPlugin (0.9) was released. Files were uploaded to the portal.

I also continued looking into possible implementation of SSR plugin - and as the usage of XMLBeans was dubious with SALT plugin, it is totally justified with this one. SSR XML is too complicated to think about implementing the parser from scratch. I still need to figure out the whole idea how this plugin will be operated.

GeoLocationDialog bug; JCalendar; SSR started

I've found a bug in GeoLocationDialog, coordinates are not displayed correctly (probably, due to rounding, users cannot enter certain values, for example 1 deg 2 mins 0 secs renders into 1 deg 1 min 59.9999 secs). This needs to be fixed!

After looking for nice widget for calendars that will come handy with SALT and SSR plugins, I've found JCalendar that is not too big and looks quite nice.

I've also started working on SSR (Sensor Service Request) plugin. I hope with lessons learned from SALT, I'll go more swiftly.

plugin loading restrictions resolved; SALT plugin (almost) finished

Got reply from Adam on plugin loading restrictions (see yesterday's post) stating that they can be removed as all 'all-purpose' plugins are being checked by the developers anyway. This is good news, that means that we can use XMLBeans with JBother :-).

Also, got some progress with using XMLBeans within the plugin. Getting used to the way you create object when using XMLBeans may take some time but it comes down to fact, that you need to initialize everything before you can use it (there is no automatic 'constructor', filling those values for you).

This certainly is looking good. I think I'm going to finish re-writing SALT plugin pretty soon and, having learned XMLBeans on the way, I'll be ready to go for SSR.

Latest news: I think I finished SALT plugin. I did the basic testing and it looks ok. I'll try to do the final polishing on Monday, and will release it as version 0.9.

problems with loading in JBother plugin & lack of cooperation between XmlPullParser and XMLBeans

I've managed to resolve problem from yesterday, when JBother was not loading whole classes of the plugin: as it turned out, the code doesn't load classes that belong packages 'java' and 'javax' (there are some classes in XMLBeans like that). I've mailed Adam (JBother's author) asking what options do we have.

Also, there are more problems: Smack is using XmlPullParser for parsing its XML and it seems to be really hard to get the original XML string from it. I need it to pass it to XMLBeans factory methods to create objects... it seems that I will have to parse it without actual parsing, to some String, that I can use later on with XMLBeans. This looks like very dirty solution :-(.

This all makes me feel uneasy. Using XMLBeans with JBother is not that easy... and I'm slightly worried by big size of plugins (example: SALTPlugin, without XMLBeans: ~40k, with XMLBeans: ~4Mb). The overhead of all those classes can be a burden, especially on some memory-restricted machines. If there would be an a way to automatically generate all parsing routines for XmlPullParser. With such a big schemas like SSR, it is a real pain to have to do it all by hand (it's more like "it's out of question").

learning XMLBeans & rewriting SALTPlugin

Today I've spent most of the day learning how to use XMLBeans. Very interesting package, you pass an XML schema through it and it creates classes for accessing, parsing and verifying XML files.

I want to re-write SALTPlugin for JBother I'm working on right now to use XMLBeans (in case that schema changes, we only need to recompile - how convenient is that?). I managed to compile it but when the plugin loads, it complains that 'javax/xml/namespace/QName' class can't be found, even though it's in the jar archive. I need to check it tomorrow.

Right after SALT plugin will be rewritten and I will (hopefully) know how to use XMLBeans, I can start working on SSR plugin, which would come down to programming the GUI part.

Last note: in assumption, using XMLBeans is nice & easy, but the code generated is pretty big. I wonder if this can be reduced somehow.

Welcome to CoqDevel

In this blog, I'll try to post my attempts on the field of software development. This would be mainly work-related, but I also try to get something done in my spare time for open source community.