* update the ooo-build to dev300-m36. I started to build dev300-m36 last night. When I came back this morning, found that some package were missing. For I just updated my system to SLED11 beta5, it seems these packages are removed when the system is updated. I had to install the missing packages again. It took me about 1hours to make the new build continue.

* Great to hear that Redflag 2000 guy Wanglibing wanted to start port new vba api. Answer his mail. Hope he can warm up quickly.

* Accept Noel's suggestion to start a new build based on dev300-m35 in another system for it is verified to use well.

* Overview the commandbar stuff. I am annoyed by the codes, ( seems not much better to port it from helperapi directly. had better to re-invent the wheel :-). Anyway, after some modification, some common issuees are fixed. and more common apis are added too.

Current existing problems:

1) Regarding commandbar stuff, the main difference between MS Office and OOo is that MS Office treats commandbar as toolbar ( main menu is a toolbar named "Worksheet Menu Bar" in Excell ), while OOo treats commandbar as menu and toolbar. The url of menu is "private:resource/menubar/menubar" for build-in menus or "vnd.openoffice.org:CustomMenu" for customize menus. The url of toolbar is "private:resource/toolbar/" for build-in toolbars or is "private:resource/toolbar/custom_toolbar_***" for customize toolbars. In MSO, you can create customize toolbars in "tools->customize". In OOo, you can create customize menu/toolbar in "Tools->Customize". The related codes of the customize dialog is located in svx/source/dialog/cfg.cxx.

2) Confused with CommandBars("File") & CommandBars(1).Controls("File")
* CommandBars("File") returns a CommandBar object which type is msoBarTypePopup.
* CommandBars(1).Controls("File") returns a CommandBarControl object which type is msoControlPopup.

It seems they are referenced to the menu "File"

Note they are not supported in OOo VBA yet.

3) Currently OOo VBA only supports CommandBarControl, and doesn't support CommandBarPopup and CommandBarButton. In MSO both CommandBarPopup and CommandBarButton are common used. It is better to support them in OOo VBA. Both CommandBarPopup and CommandBarButton are based on CommandBarControl, So the following macro is OK in MSO

dim cbc1 as CommandBarControl
dim cbc2 as CommandBarControl
dim cbb as CommandBarButton
dim cbp as CommandBarPopup

set cbp = CommandBars(1).Controls.Add( Type:= msoControlPopup )
cbp.Caption = "Popup Menu 1"

set cbc1 = CommandBars(1).Controls.Add( Type:= msoControlPopup )
cbc1.Caption = "Popup Menu 2"

set cbb = cbp.Controls.Add( Type:= msoControlButton )

set cbc2 = cbp.Controls.Add( Type:= msoControlButton )


4) I think CommandBarControl.OnAction is an important api which is to set the name of a vb procedure that will run when the user clicks the menu/toolbar. Most of the reasons you create a customize menu/toolbar is to let user to run a vb procedure by clicking the menu/toolbar.
when OnAction is set, it needs to map the name os a vb procedure to a working command url of OOo. e.g.

myControl.OnAction = "Macro1"

The name "Macro1" needs to convert to a working command url like: vnd.sun.star.script:Standard.Module1.Macro1?language=Basic&location=document

* Meet a couple of breaks when building dev300-m36. To saving time, abandon to build it. and focus to build dev300-m35.

* Start to have a look at the patch of vba for word.

* Team meeting

After this blog has been dead for about two years, I will start with some technical stuff – at least when computers don’t work as expected, most times I know how to fix it.

Ok, lets move on to the topic of this post. Short time ago I was forced to do some stuff on windows again (EEKK — the word registration number still sends me cold shivers …). As I needed really working USB support (unfortunately Nokia thinks Linux is good enough for their hardware, but not for their customers computers), and I was unable to make it work neither in Xen (not at all) nor with KVM (unusably slow), I ended up with VMWare.

So, USB worked really nice, no problems at all. While I was there, I thought „let’s have a look at the 3D acceleration“. At a first glance, it looked quite easy – „upgraded“ the VMs version to 6.5, and ticked the option for „3D acceleration“ – TADA – „Failed to construct 3-D rendering backend. The 3-D features of the display card will be disabled.“

Ok, what’s wrong? After some digging in the log, I found these two suspicious lines:
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_texture_compression_s3tc
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_framebuffer_object
Unfortunately, the Intel driver does not support these two OpenGL extensions – more or less.

Let’s have a deeper look into this. First, S3 texture compression. S3TC is a lossy texture compression used in many games, and it is mandatory for DirectX. Unfortunately, S3TC is covered by some patents, and although the decompression is handled by the hardware, a conformant OpenGL driver has to handle decompression and compression. As in many cases (most games ship with precompressed textures) only decompression is needed, which is handled by the hardware, there is a switch to force Mesa to report support of S3TC although it actually only handles one half – if you want to know more, force_s3tc_enable drirc are the keywords.

If you want to know more, or even want to enable compression as well, have a look at Roland Scheideggers‘ page.
As said, S3TC is covered by patents, so enabling compression is legally problematic. But there may be some hope, as S3TC is „owned“ by VIA, and they recently open sourced their Linux graphics driver, maybe we will even get S3TC out of that – at least, they could put compression under a liberal license, and still sell licenses to ATI/Nvidia/Intel (I still may have some dreams, don’t I?)

The other part is GL_EXT_framebuffer_object, shortly referred to as FBOs. These are really not supported by the Intel driver at the moment, but there the new memory managers come to the rescue, see this post.

Summarized, as soon as GEM has landed in the kernel tree (and/or in the downstream distributions), it should be possible to make it work. GEM should be available soon, and S3TC can be worked around today.

Mouse speaking. Christina came for a visit and I thought finally I'll get some attention. Then she unpacked her luggage and there were so many presents. Do you think I got at least one of them? No, she gave Antje one present after the other and left me with nothing. They always carried me with them when they went on their trips. They ate chocolate wherever they went. On the train, on the streets, in the shops. I heard them munching while I got thinner and thinner. Now I almost look like a skeleton. And the trains they chose! We spent hours on them. There was this ghost train that stopped everywhere. Even in Oberheckenhofen. Horrible places. I got so scared. And then Antje got stuck in the underground while Christina was left behind in the station. Only because they wanted to help this disoriented elderly drunk man that tried to get out at the wrong door. Maybe he thought he can go through walls. Actually, maybe he could. He looked just like it. It was this automatic underground without driver. We went into a tunnel and stopped there. It gave me the creeps. But after a while it went back to the station. Christina was standing there laughing like mad. I really don't know what was funny about that. And this tourist place. Rothenburg. With all those horrible huge bears. And then they went to Munich. On Saturday. There were millions of people on the streets and even more in the shops. And we had to enter all of them. I'm claustrophobic ever since. I'll ask Antje to send me to Canada. Did I tell you about Lanzarote at all? She took me there with her in October. She never let me outside. And there was so much sun and warmth. but I stayed pale. And then she met those Irish people and went for dinner so many times without introducing me. And it's even worse as she wants to travel to Ireland soon and she said she'll take me with her. I'm having such a miserable life.

Here are some of the Lanzarote views I missed from inside the dark bag:

Today i received the confirmation that openSUSE will have a devroom @ FOSDEM 2009!

Yay! Because it’s a little bit earlier next year (2008-02-07/08), we should
start right now with the the planing.

Please head over to the opensuse-project list and read/comment this posting.

After several requests to get GNOME 2.24 built and made available the GNOME Team (well Magnus Boman really), took on the challenge of making it so.  Unfortunately we were a bit focused on the 11.1 release and didn’t actually think about doing any backports.  This has kind of bitten us squarely on the behind, yes we must bow to the KDE Team‘s backporting powers – make the most of it chaps

Unfortunately there are too many dependencies for the backport, and will involve a heck of a lot of maintenece – more so than normal.  After several attempts to coax things to work we must bow our heads in admission to being beaten This doesn’t mean that we won’t be doing any backports in the future, the championship isn’t over just this match.  It does mean that there wont be a GNOME 2.24 for openSUSE 11.0 however, sorry to disappoint.

We have learnt our lesson and with the aim of not disapointing you again we have already instigated measures to ensure that your backporting needs are met.  We are already starting to build GNOME 2.25 against the current Factory and will continue to ensure that each release has the latest and greatest from the Enchanted Wood.  There may well be occaisons where things just won’t work, but we will do our utmost to minimise them and give you plenty of notice.

One thing we do need is your help.  Funny I always seem to be asking for help, but this time there is a really good reason (actually more than one ).  We need more people to run Factory to test things and ensure that bugs and issues/comments are reported back.  This doesn’t just apply to GNOME but openSUSE in general, please please test our latest releases and give us your feedback.  There are several ways you can do this – Bugzilla, IRC and Mailing Lists, oh and at events like the upcoming FOSDEM.

Yesterday, Brad announced the first release of the Mono Accessibility team's work, which started a little less than a year ago. It's pretty exciting for us to put out this developer preview release; I'm interested to see what people make of it.

The goal of the first phase of our project, which will culminate in a 1.0 release early next year, is to make Winforms applications accessible in Linux with traditional at-spi tools like Orca and Accerciser. In 0.9, we offer support for most Winforms controls (Button, Label, ComboBox, ToolStrip, WebBrowser, etc). In 1.0, we will be rounding out this support to include the remaining controls (DataGridView, TreeView, custom controls, etc), in addition to fixing bugs and improving stability.

It may not sound that exciting to enable accessibility for Winforms apps. After all, you probably aren't using very many on your GNOME desktop today. However, there certainly are some cool open source apps out there (Paint.NET, NClass, etc). And the main benefit will be for overall Linux adoption. There are many businesses, large and small, schools, governments, non-profits, etc...that are stuck on Windows because they have custom applications written using APIs like Winforms. One goal of the Mono project is to provide a migration path for these potential Linux users. Accessibility support is often a requirement, so by making these custom Winforms applications fully accessible in Linux, we are enabling Linux adoption scenarios that would have been too expensive before (rewriting your internal tools is not cheap or easy).

If you are not familiar with our project, let me briefly explain what it is we are doing:

We are implementing Microsoft's "User Interface Automation" (UIA) specification on Linux. During the first phase of our project, we are focusing on the "provider side" of this specification, which offers interfaces that are implemented by the accessibility/automation "provider" for a given control. This is similar to implementing ATK interfaces for a GTK+ widget, if you are familiar with that. We have been writing UIA providers for all of the Winforms controls.

The other half of our work this phase has been creating a bridge from UIA to ATK. This bridge translates between UIA interfaces and ATK roles/states/etc. This is the piece that makes a Winforms application look like a GTK+ app (or any other app written in a toolkit that exposes a11y info over at-spi) in a tool like Orca.



It's pretty cool the way this fits together. Next year, after 1.0 is released, we'll begin the second phase of our project. It includes two major efforts:

First, we will be making Moonlight accessible in the same way we have made Winforms applications accessible. We will create UIA providers for Moonlight controls, and they will automatically gain accessibility via the exiting UIA<->ATK bridge.

Second, we will implement the "client side" of the UIA specification. This is a set of interfaces designed to allow an accessibility tool (think Orca) to interact with accessible applications. It is similar to the at-spi interfaces, and we will in fact be implementing it as another bridge, this time translating "client" UIA calls into equivalent at-spi calls. The benefit here is that as Windows developers create accessibility and automation tools using the UIA interfaces, they will be portable to Linux (and vice versa).

Accessibility is a great feature for users and potential customers. Automation support is invaluable to testers, software QA, and even users who just want to streamline common tasks. With the release of Mono Accessibility 0.9, we are growing the landscape of accessible applications. We look forward to your feedback (and bug reports)!

I have been toying around with this idea of gathering disk access patterns and using device mapper to fool the filesystem to improve I/O performance. And did try this idea out in a limited fashion. I did a workout session to improve upon this work in foss.in. Despite a cricket match being scheduled on that day, people did turn up. We discussed, hacked together and made friends, which was fun. It was cool to see some well-known kernel hackers turn up for the session and were actively involved. And I also should thank some of colleagues who also participated and helped me through out the session.

We improved the performance, found bugs... it was cool. Now really looking forward for the upcoming much more interesting sessions especially the Linux Kernel Hackers Gathering and the Linux Kernel Workout. You can see the plan and results in the links. Thanks for whoever attended the session and the organizers.

Last Friday we released MonoDevelop 2.0 alpha 2. This is an exciting release because for the first time it includes debugger integration. This integration is not yet perfect, the debugger is not yet 100% stable and not all features are available, but we finally have some debugging support. This has been the #1 feature request for long time. You can take a look at my previous post about the debugger to get an idea of what it looks like.

In addition to the Mono Debugger (MDB), I also have spent some time improving the GDB integration. We now have support for expression evaluation, which can be used in conditional breakpoints and tracepoints. The debugging service in MonoDevelop is extensible, so we can plug support for different debuggers into it. I hope we can add support for debugging other non-.net based languages in the future.

Anyway, here is a screenshot of a debug tooltip in a GDB debug session:



The other big improvement in alpha 2 is the new code completion engine, on which Mike Krueger has been working. The new engine supports "aggresive" code completion, which means that the completion window will be shown in any context by just typing the first char of an identifier. It also has some nice features such as automatic insertion of event handlers or anonymous methods when completing an event subscription. In addition, the C# parser has been upgraded to support C# 3, and we already support some of the new C# features, such as completion of extension methods. The new engine still needs polishing and performance improvements, but it is looking great.



Michael Hutchinson has done a great job improving the editing experience for ASP.NET, HTML and XML files. There is better support for code completion and CodeBehind files. Compatibility with Visual Studio 2008 has improved, and we now have preliminary support for creating Moonlight projects. Many hackers will also be interested in the new vi mode that has been implemented for the text editor.

The GTK# designer has also some improvements. Mike Kestner became the maintainer of the designer some months ago, and he's been learning about the inner workings, and doing some fixes and improvements. One of the main changes is the simplification of the GTK# settings panel. It is not necessary to explicitly enable GTK# support on projects in order to use the designer. Now it can be done by just adding a reference to GTK#. Also, exporting a widget so it can be used in another project is as simple as applying a [ToolboxItem] attribute to the widget class.

Ankit Jain did a great job with the new Override/Implement dialog, which allows to easily implement members defined in a base class or interface. Here is a screenhot:



Ankit is now working behind the scenes to complete xbuild, our MSBuild implementation. The mid term plan is to replace MD's build system by xbuild, but this won't happen before MD 2.0.

There are many other improvements in version control support, project management and others, but you'll have to take a look at the release notes to know more.

In the following weeks we are going to focus on bug fixing, and we plan to release a 2.0 Beta 1 soon (the plan was to release before Christmas, but holidays may not permit it). In the meanwhile I hope you find alpha 2 useful and file any bug you can find so we can fix it to make MD 2.0 an awesome release.

I found an interesting video. If you have about a hour to spend and if you work in scientific computing, maybe these talks would be useful for you:

Development is more active after our move to new svn ! Julien (of openchange.org) has patched evolution-mapi to be compatible with libmapi 0.8 .Patches are welcome !

Some of the cool things with libmapi 0.8 is the possibility of having multiple exchange accounts (multiple sessions) in Evolution (Yep. you read that right! ). But they will hit the trunk little later .

Now more focus is on real world testing on servers other than few test servers we are running. What doesn’t work in different setups is something we would like to know and fix them all ! Thanks to those who have been reporting issues and TIA

NEWS :

+ evolution-mapi is proposed for GNOME 2.26. Yay !

+ we have a new product ‘evolution-mapi’ in GNOME bugzilla.

+ Wiki page is updated with information on building evolution-mapi .