Pavel's diary

Warning: not everything in this blog entry is strictly true :-)

The image you see here has an interesting history... Yesterday, I extended my patch set I use for testing svdem sample application with a simple processing of key events. With simple, I really mean simple - in case of key event, it just prints all event parameters and does nothing else. Today I thought it could be interesting to actually do something ;-)

As I was not aware of any other piece of code than font dialog (svtools's svdem) that works now and should also work a bit better with keyboard, I wanted to implement cursor key down to be able to use keyboard to see all nice fonts we can display now even without X11 installed! Thus I first sent one SalEventKey with KEY_DOWN key on every key event (any key down, any key up or key repeat). I was happy to see cursor jumping down six times after pushing keys N, e and ? (I somehow forgot the last key, sorry for that) in sequence ;-)

OK, but this was still not quite enough - I decided that only real cursor down key should move the cursor down. So I "sniffed" the key code number for cursor down key (it is 125) and sent the event only in case of key down Carbon event. It worked. Adding cursor up was an immediate idea I have implemented (still being watched by Fridrich who was always a bit before me - because I actually had to type down all of our ideas ;-).

Then we realized, that the keyboard I have connected to my Mac mini has more than 100 keys and after one-second-long-dream of the "switch" command in the source we realized we need a table mapping key codes to actual keys ;-) Fridrich started to draw his own keyboard layout on the paper wanting to be better than this chap. After few lines and few letters, we both agreed he can't do that ;-) So he started the desktop with huge K and cog-wheel on its screen and finally found some keyboard layout image. Few minutes after it, Kendy admits that he actually is using the layout shown on that image (closer investigation revealed it was Dvorak's keyboard layout instead of QWERTY - no problem for me though).

"Interesting" work writing down key code of every key on my keyboard took me approximately half an hour - really productive work :-( You can click on the thumbnail of the image to get the full size image of the keyboard layout with all key codes written down (modulo Expose keys handled by window manager, and modifier keys and some other special keys probably forgotten by Apple on the drawing board when they designed their first keyboard).

Now seriously: my current svdem is able to scroll down using cursor keys and Page Up and Page Down keys. Good beginning. More later this week (read as: quick hack done, works, rewrite it from scratch with complete understanding of the problem area).

I thought a bit about possible methods or models of cooperation between OpenOffice.org (GNU LGPL licensed software) and its fork NeoOffice (GNU GPL licensed; because of its focus, it is available only on the proprietary operating system, Mac OS X). In the past, there were some issues between both projects that I still do not understand completely; maybe because I didn't care about Mac OS X port until recently and I was not involved in these issues (I concentrate mainly on technical issues that I think both projects benefit from!).

I'm working on the OpenOffice.org project, thus please read everything here with that in mind. I never even thought about working on NeoOffice because its code is forked and there still is no upstreaming process implemented in their development. (Compare with ooo-build - a "friendly fork". At the beginning I was very anti- ooo-build oriented because of the very slow upstreaming process there but we communicated fixes very well and the cooperation with distributors' oriented ooo-build is now almost perfect and both sides clearly benefit from it). But with NeoOffice, the situation is different. If I want to fix something in NeoOffice, it also has to be fixed also in OpenOffice.org as well. As a consequence it is much easier for me to fix things in OpenOffice.org directly. Fixing it in both projects is inefficient.

And what about fixing issues in NeoOffice only without contributing back to the originating project, OpenOffice.org? I have to say that I haven't even thought about it. But people doing so probably have their motives. But as I said above, I only care about technical issues, so I can think of following reasons to do so:

• the code is NeoOffice only, it does not affect or it does not exist in OpenOffice.org at all. This is legitimate reason - OpenOffice.org for Mac OS X is not yet as advanced as on other platforms and it is not possible to integrate all the functionality NeoOffice contains
• the quality of the code is not up to the quality of OpenOffice.org standards
• the architecture of the code doesn't follow the architecture of the rest of the code

But there probably are also other reasons (I'd be glad to hear them from you so I can see the whole picture from both sides). I'm mainly interested in the motivation to not share the generic patches that affect both projects. Have a look at ooo-build: at the beginning, the project was several development milestones behind the mainstream OpenOffice.org because of the boring process connected with re-diffing changes not yet integrated into mainstream OpenOffice.org, checking the build, and then again concentrating on their own changes.

After several (I can imagine how Michael Meeks hated me ;-) rounds of discussions and bringing existing problems to the discussion table, we realized that there are almost no problems and both parties can benefit from working together closely - OpenOffice.org working for distributors' ooo-build and ooo-build working for OpenOffice.org.

I see the same problem on NeoOffice side. I understand that developers probably concentrate more on the user friendliness side of the product and thus they are a bit behind OpenOffice.org. This is understandable - it is no easy job to follow all the changes happening in OpenOffice.org CVS tree if you have to implement your changes in many source files of the project and even add your new code. I see the same problem when working on aquavc01 child workspace. Because of the fact it is a development cws, there is no schedule for its integration, so we have to resync it very often to bring latest changes in OpenOffice.org milestones, and it is time consuming work. And boring work to say the truth. But we have to do so, because we are not that fast with development to integrate it yet. This clearly is a point where we can cooperate to make both OpenOffice.org project and NeoOffice project even better and to save the managerial burden connected with the different code we have - having the code in OpenOffice.org means it also gets tested also on other platforms thus it gets tested by more people.

So the above is a clear (at least from my technical point of view) win for both sides! Where else could we cooperate? I again have to look at ooo-build. There is close cooperation - we share our Wiki (provided by OpenOffice.org), Bonsai, LXR and tinderbox (provided by ooo-build) and other infrastructure as well. It helps both projects - shared administration, shared costs. I think infrastructure is a place where both OpenOffice.org and NeoOffice can cooperate too. Ah, I almost forgot about OOoPlanet - also run by ooo-build project!

Before I even started to think about this issue, I thought if both sides would like to cooperate at all. Of course I do not know about NeoOffice (as I do not follow it), but for OpenOffice.org it clearly would be interesting to integrate applicable fixes and thus make it even better. Do you know? From what I read on Neo forums, the attitude to OpenOffice.org project and developers is not very good - e.g. after Eric's presentation at OOoCon 2005 at Koper, Neo people's financial income from donations was lower than they have expected and they feel it was a dirty trick to them. But even if it looks so, it was not meant to be.

The OpenOffice.org team is listening to its users on Mac OS X platform and they want OpenOffice.org without the X11 subsystem - so working on native port is a logical step forward for us! NeoOffice already is running without X11, but some people still prefer running OpenOffice.org instead. We want to make their experience smoother, and without X11. The port is not progressing as fast as Eric expected - mainly because of lack of knowledge and experiences with Mac OS X on the OpenOffice.org's developers side, but we are getting there, but slowly. Unfortunately we can't use the work done on NeoOffice's side. Not only because it is GNU GPL licensed (OpenOffice.org is GNU LGPL licensed) but also because of technical reasons (UI of NeoOffice is implemented using Java instead of C or C++, thus potentially slower than the native code). But this is no reason for not sharing the common code as pointed above.

I'm still mixed. I'm probably missing some (either technical or political) reason not to share the code or I simply haven't yet read some clear statement from NeoOffice developers with their reasoning to not share the code. So if you know where to read it, please point me to it. Thank you.

Now back to real work ;-)

Apple now finally acknowledged that some MacBook units (serial numbers matching regular expression 4H6[12]7.*) could be discolored very soon after regular use. They also acknowledged or at least mention whining sound problem of some MacBook Pro units (although I have never seen so short article from their side ;-). Although it may look like negative to Apple, I like this policy - now Apple's customers are not in hazard when buying new notebook and do not have to ask the question: will it be good?

So now I only expect them to announce using new Intel Core 2 Duo chip in the next revision of MacBook Pro on WWDC in August.

I have fixed almost all of my bugs targeted to 2.0.4 today, and I'll start my typical work before every release - I'll ask issue owners if they are able to meet the deadline or if they need help.

We still have 189 issues, so still a lot of work. Please help to reduce the number of issues for 2.0.4!

Notice for translators: the deadline for providing GSI files is August, 3rd. The same deadline applies to code-freeze. Other deadlines are on Wiki.

I had to restart all builds because of bug in Bulgarian GSI not spotted by gsicheck (#i67767#).

Current status:

• GNU/Linux on x86: builds uploaded
• GNU/Linux on x86_64: builds uploaded
• Solaris/SPARC: buils finished
• Windows: builds uploaded
• Mac OS X: building module dbaccess

I'll update this blog entry later.

The milestone SRC680_m177 contains child workspace pdfencryption. This child workspace contains implementation of new PDF export options - security of the produced document.

I have tried it on sample document and it works intuitively. If you need to know more information about it, you can read its specification.

Good work! Not only very useful, but also done properly. Thanks!

As I promised yesterday, I implemented menus. Click on the image to get full view of my current svdem from svtools.

Of course there are issues :-) Menus probably do not work for more windows properly, no separators, no checkboxes, no shortcuts, no events. I certainly forgot something. But it looks nice now ;-)

I hope I'll find some more time next days to continue.

I have started builds of SRC680_m177.

Current status:

• GNU/Linux on x86: finished, uploaded
• GNU/Linux on x86_64: finished, uploaded
• Solaris/SPARC: restarted, many patches needed included in cws pj55
• Windows: build finished; cws native56 decided that building download instsets is not to be done, so no download sets now. I asked on dev@installation "why".
• Mac OS X: building helpcontent2

I'll update this blog entry later.

OpenOffice.org 2.0.4 is getting closer and closer. Right now, we have 254 issues opened with target 2.0.4. Please help to reduce the number of them!

The deadline for providing GSI files is August, 3rd. The same deadline applies to code-freeze. Other deadlines are on Wiki.

As before every OOoCon, I announce "Pavel's beer motivation". I'd like to motivate someone to reach the goal of some small project. If you reach the goal, you receive all Czech beers I can pack into my luggage ;-) Delivery at OOoCon 2006, Lyon.

This time, I'd like to see working invader without the need of X11 libs, runtime etc. on some version of Mac OS X (preferably Tiger), with texts, menus, bitmaps etc. As part of this goal, I'd like to finish one level myself ;-)

This is the second blog entry in mini-serie about native menus for OpenOffice.org.

Today, I'll describe how menus are created and displayed in my sample Carbon application. I rewrote the example so it matches better the OpenOffice.org native menus API.



I'll now describe, how the above image can be generated using Carbon instead of Gimp ;-) Let's start with the small description of the terms menubar and menu. Please read the article The Menu Bar and Its Menus in the Apple Human Interface Guidelines which describes them very well.

As you can see on the image above, we have defined two menus inside application menu - menu File and menu Edit. They are contained in the invisible "RootMenu" which is a container for them. In OpenOffice.org, we will use one RootMenu for every OpenOffice.org window.

So how can we create the RootMenu?

MenuRef rootMenu;
CreateNewMenu(0, 0, &rootMenu);

It is very simple - we will call CreateNewMenu function and the new menu will be returned in the variable rootMenu. We already know OpenOffice.org native menus API, so we can see RootMenu as an equivalent to SalMenu created with bMenuBar = TRUE. This means that our class AquaSalMenu will add new member to reference the RootMenu's MenuRef and the function AquaSalInstance::CreateMenu will set it when called with bMenuBar = TRUE to create the menu bar (and will set its bMenuBar member to TRUE to reflect it is a menubar).

So we have a menu bar now. The menu bar is not shown yet, we will actually display it later. Now we can create the actual menus to be attached to the menu bar (RootMenu):

MenuRef myMenu;
CreateNewMenu(1, 0, &myMenu);

Actual menus are created using the same function as the menu bar (RootMenu) itself. Yes, it's true - we will see later what is the difference (hint: calling the function SetRootMenu). Every top-level menu is represented using its MenuRef reference. As the same applies to MenuBar itself (it is AquaSalMenu too), we can share the same member for MenuRef of the menu bar and menu and use bMenuBar member to distinguish between menus and menu bars.

Now, I'll describe the first main difference between both APIs. In OpenOffice.org native menu API, the string "File" is associated to the empty member item in the MenuBar. In Carbon, "File" is the title of the menu and is associated with it, not with the menu bar itself:

SetMenuTitleWithCFString( myMenu, CFSTR("File") );

So now, the menu created above is named as "File", it is still empty and still not shown. So we can fill it with items:

MenuItemIndex item;
AppendMenuItemTextWithCFString( myMenu, CFSTR("Open"),  0, 0, &item );
AppendMenuItemTextWithCFString( myMenu, CFSTR("Close"), 0, 0, &item );
AppendMenuItemTextWithCFString( myMenu, CFSTR("Exit"),  0, 0, &item );

We have just added three menu items (they will be mapped directly to AquaSalMenuItems created using AquaSalInstance::CreateMenuItem) to the menu. The returned value in the variable item together with the MenuRef myMenu will be stored for future reference (have you already noticed that our menu items are not functional, they are only items in menus? ;-).

Now that we have menu "completely" defined, we can add it into the menu bar (link it with the menu bar). We will first insert unnamed empty item into the menu bar and then will set its hierarchical menu to the just defined "File" menu. This is different in OpenOffice.org native menus API, because in OpenOffice.org, you insert menu item "File" into menu bar and then you SetPopupMenu of it to the File menu which is untitled (it only contains menu-items "Open", "Close", ...):

MenuItemIndex myMenuIndex;
AppendMenuItemTextWithCFString( rootMenu, NULL, 0, 0, &myMenuIndex );
SetMenuItemHierarchicalMenu(rootMenu, myMenuIndex, myMenu);

The function AppendMenuItemTextWithCFString will create empty menu item in the menu bar and the function SetMenuItemHierarchicalMenu will set its hierarchical menu to our "File" menu defined above.

Now we can do the same with the "Edit" menu:

CreateNewMenu(1, 0, &myMenu);
SetMenuTitleWithCFString( myMenu, CFSTR("Edit") );
AppendMenuItemTextWithCFString( myMenu, CFSTR("Search"), 0, 0, &item );
AppendMenuItemTextWithCFString( myMenu, CFSTR("Replace"), 0, 0, &item );
AppendMenuItemTextWithCFString( rootMenu, NULL, 0, 0, &myMenuIndex );
SetMenuItemHierarchicalMenu(rootMenu, myMenuIndex, myMenu);

So now we have the menu bar defined, two menus connected to it, but it still is not displayed. This way, we can define more menu bars, but we still have to set one of them to be displayed. This is what SetRootMenu is doing:

SetRootMenu(rootMenu);

This function sets the RootMenu's part of the application menu to the menu referenced by its MenuRef. We will have to call this function when changing windows (frames) because of different menus in different windows. This also means that we have to extend AquaSalFrame class to contain also its RootMenu's MenuRef.

This entry was written to make it clear how menus in OpenOffice.org and menus in Carbon differ. I have not yet investigated how to pass menu selection for processing, how separators work, how menu shortcuts work etc. This is not the goal of this blog entry. My first goal is to have the menus actually displayed first. I hope you found it interesting to read it. If so, please drop me a line. I hope I (or Pierre) will find the time this week to make this into the actual code for you to test! Please bear with us. I'm no Carbon hacker. I'm learning on the go. BTW, can you help us?

How menus work in practice in OpenOffice.org?

In this blog entry, I'll describe how native menus should work. For the description, I'll comment the source code of current aquavcl01 child workspace patched with my patch for menus. I do this because I need to clean up my notes and help also other people to understand what I have now and how to continue.

VCL is a deep magic :-) Too many classes, deep inheritance. I'll try to cast some light into our part and will describe the current status clearly (at least I hope so).

In the vcl's svdem (the file vcl/workben/svdem.cxx), we extend class WorkWindow (which itself extends SystemWindow which itself extends class Window ... OutputDevice ... Resource - now you know what I meant with "deep magic"):

class MyWin : public WorkWindow
{
public:
   MyWin( Window* pParent, WinBits nWinStyle );
   ...
   MenuBar   aMenuBar;
   PopupMenu aFileMenu;
   PopupMenu aEditMenu;
};

This means that our window will have one MenuBar (see declaration) and we will add two PopupMenus into it (see the declaration of PopupMenu).



In main, we instantiate the MyWin class in aMainWin window:

MyWin aMainWin( NULL, WB_APP | WB_STDWORK );

At this time, MenuBar and two PopupMenus are created. The method SalInstance::CreateMenu (AquaSalInstance::CreateMenu, see FIXME: link to ssa's document about native menus) is called with bMenuBar = TRUE for the MenuBar and twice with bMenuBar = FALSE for PopupMenus.

This means that both menu bar and top-level menus are SalMenu (in our case, AquaSalMenu) items and are created using the same method!

Now we have menu bar and two PopupMenu items created and can work with them.

aMainWin.aMenuBar.InsertItem( 1, XubString( RTL_CONSTASCII_USTRINGPARAM( "File" ) ) );
aMainWin.aMenuBar.InsertItem( 2, XubString( RTL_CONSTASCII_USTRINGPARAM( "Edit" ) ) );

We will insert two items into the menu bar aMenuBar - "File" (it will be item number 1) and "Edit" (item number 2). These are actually menu items - SalMenuItem (AquaSalMenuItems in our case; see the declaration of SalMenuItem). Notice, that "File" is not a menu, it is a menu item in the menu bar! This is important.

aMainWin.aMenuBar.SetPopupMenu( 1, &aMainWin.aFileMenu );
aMainWin.aMenuBar.SetPopupMenu( 2, &aMainWin.aEditMenu );

These two calls of SetPopupMenu method "connect" the menu items "File" and "Edit" of the menu bar with the actual sub-menus. Item number 1 in the menu bar aMenuBar is connected with the PopupMenu aFileMenu.

The first function call will call the method SetSubMenu with three arguments - the first one is the SalMenuItem representing "File", the second is the actual SalMenu which should be expanded when menu item "File" is clicked on. The third argument is the position in the native menu.

FIXME: I do not understand why we have to specify nPos here too, because the SalMenuItem already is inserted at some position in the menu bar. Isn't it thus redundant?

aMainWin.aFileMenu.InsertItem( 1, XubString( RTL_CONSTASCII_USTRINGPARAM( "Open" ) ));
aMainWin.aFileMenu.InsertItem( 2, XubString( RTL_CONSTASCII_USTRINGPARAM( "Close" ) ));
aMainWin.aFileMenu.InsertItem( 3, XubString( RTL_CONSTASCII_USTRINGPARAM( "Exit" ) ));
...
aMainWin.aEditMenu.InsertItem( 1, XubString( RTL_CONSTASCII_USTRINGPARAM( "Search" ) ));
aMainWin.aEditMenu.InsertItem( 2, XubString( RTL_CONSTASCII_USTRINGPARAM( "Replace" ) ));

We also have to fill actual sub-menus. Menu "File" will contain three entries "Open", "Close" and "Exit". Menu "Edit" will have two entries.

The method InsertItem is already described above. We will create three menu items - SalMenuItem (AquaSalMenuItems in our case) - and will insert them into the menu "File", and two into menu "Edit".

aMainWin.SetMenuBar( &aMainWin.aMenuBar );

At the end, we have to associate the menu bar with the window. This method will call SetMenu of the respective SalFrame object and do other stuff.

So this is the OpenOffice.org side of menus. I'll try to describe the Carbon side of the same soon so we see how to map it into the OpenOffice.org side :-)

I have started builds of SRC680_m176.

Current status:

• GNU/Linux on x86: build is uploaded.
• GNU/Linux on x86_64: build is uploaded (Build-2)
• Solaris/SPARC is still not finished because of warnings are errors issues (I use newer compiler than Hamburg RE).
• Windows is uploaded.
• Mac OS X finished, I won't upload it.

I'll update this blog entry later.

We are getting closer to OpenOffice.org 2.0.4 - for information about (current) deadlines, see Wiki.

Right now, we have 301 issues opened with target 2.0.4. Please help to reduce the number of them!

I hope you all read Vladimir's announce about localization deadline for 2.0.4. If not, here are the key facts:

• The deadline for providing GSI/SDF files is August 3rd, 2006.
• Issues should be filed with: Assign to "vg@openoffice.org", Target milestone to "2.0.4" , Component "l10n" , Subcomponent "code" , Issue type "ENHANCEMENT"
• your GSI file should contain both en-US and your language strings
• add the URL to the GSI file in the issue, not the GSI file itself!
• check your file with gsicheck (if you use GNU/Linux, you can use statically linked gsicheck I provide with every build)

If you want your language to be included in my build system, please send me: the link via mail too.

I'm now back from two weeks on Mallorca, Balearic Islands. Wonderful place on the earth. We spent most of the time playing with my son in the water. He really loves the sea :-) We enjoyed all beauties of Mallorca. I especially like Sa Calobra and Torrent de Pareis. And of course the sunrise above the sea was impressive (modulo early hour ;-)).

And now I'm slowly reading all mails collected during my vacation. I'd like to thank Yenya and Dan who saved me some stress by restoring ftp.linux.cz and notifying me that my procmail decided that 50 MB of mails is enough :-)

On the OpenOffice.org side, I started to build SRC680_m175 and after filing about 10 issues for all platforms, I decided I'll skip it and wait for m176.

I'll also start with building all instsets with updated GSI files - please check the URL you gave me - there are problems for at least en_GB, fa, ne and other languages!