lundi, décembre 29, 2008

About the (real) number of developers contributing to OpenOffice.org source code

Since we switched to svn this is really easy to obtain the number of regular OOo contributors. Means for source code, not for anything else.

Before, the best resource we had was Bonsai. e.g. you can easely retrieve all the contributions of someone, or the exact content of a cws. Just fill in correctly the right fields and all the information concerning the commit before svn appear. Sort of "memory of OOo" :-)

Now, just look at : CIA vc and you're done.

.. and the result is: the current number of nicks is 77 known people (at least one commit ... ) who wrote code for OpenOffice.org the last two months ... and not 200 like I read on some blog :-/

As example, the Education Project attracted 4 new developers*** (able to create their own cws's and commit). Of course, they still need to learn a lot, and the next steps are : how to integrate code.

***Not that bad ;-) (I'll wrote more about that very soon)


Last, there is a remaining issue : I still don't know how to make appear all the changes people commited in a given cws, and more annoying, how to read just every diffs, like Bonsai allows us to do (please contact me if I missed something about that :) ). Of course, I can extract all the changes in a given cws, and navigate in te cws tree ( using this link, but that's not the most efficient (imho).

I'm confident, there is probably a tool in preparation. Crossing the Fingers ;-)



Update:

About the coming month, we expect to see 6 new students from Ecole Centrale Nantes ( look at Improve the OOo Impress), and 3 students from UTBM, working on the OpenGL transitions. No information from Seneca College, and students from this school, joining the project.

To be continued :)



---------------------------------------

Donate to Education Project

---------------------------------------

Libellés : , , ,

mardi, décembre 23, 2008

appleremote03 (part1)

Since everything work with appleremote02, I think the last remaining changes for this cws will be about :
- remove the eventlistener (e.g. when closing the document)
- avoid leaks (to be confirmed)
- test on other ports (Windows)

Started working on appleremote03 : implement the contextual menus with the remote.

Done :

* catch all the remote event, and turn them into the right MEDIA_COMMAND
* found where in the code, is treated the contextual menu entries with mouse events or the keyboard

Work in progress : design the new implementation

Todo :

* create the new case, means when in fullscreen, and one popup menu is open, specificly for the remote events
* create one callback for any catched remote events
* write separated tests for every part
* write the code
* test

Libellés : , , , ,

samedi, décembre 20, 2008

appleremote02 (part 5)

"Play" works :-)

After searching the entire week (in my free time, mostly late in the evening), I finally found a way to fix the issue I mentionned in the previous entry ( appleremote02 part 4), ... and I finally get it working :-)

Of course, the changes I commited today are maybe not the best one, and I'm waiting for opinion(s), one people who accepts to QA my code, and maybe tell me whether something is wrong.

How does it work ?

When opening a presentation (in static mode) in Impress, it means we use Draw with another GUI. Our issue was, no event listener was running, and thus, the events sent through vcl ( kRemote* turned into MEDIA_COMMAND_something ) get lost. Just because the eventlistener only exists when Impress is in presentation mode. The idea was: implement a new event listener in sd, but more early, means in static mode, to be able to catch the "Play" event, the last one who was not working.

But what do exactly, and where ?

The only way I found to understand was to ask on IRC, and read the code (if you know better, please tell me). I firstly tried in sd/source/ui/unoidl, but it was not correct, and following the advice from Thorsten, I tried in sd/source/ui/app. Probably not perfect, but at least it works.

Everything is based on the use of macros (at preprocessor step). Following the existing example previously studied in slideshowimpl.cxx, I had to :

1) add a DECL_LINK() in the header, to declare a member function in a class that acts as a handler

2) set a handler using the LINK macro : after searching a while. I have choosen to use the sd/source/ui/app/sdmod1.cxx, in getState(), where a lot of things are initialized. The first choice was to set it in sd/source/ui/unoidl/unomodel.cxx, but the choice was probably wrong (at least too complicated), because I had no easy way to retrieve the frame and the shellview.

The LINK() adds the event listener.

3) Set an LINK_IMPL() acting as - sort of - "Callback", with the parameters passed in arguments by LINK().

The IMPL_LINK is the place where I put what do of the event. For instance, check, first whether we have sd running in Impress mode (the other mode is Draw mode), second whether there is a frame containing the presentation, and is focused .. and so on.

4) the most simple was to remove the previous hack to switch at runtime (using environment variables) between use F5 or not. Now, only the right way is used, of course.

Note: in sdmod1.cxx, I firstly believed I could factorize more the code, and this bad idea caused me a lot of pretty crashes before I understood I had two steps at some places, instead of only one. Until now, with the current status of appleremote02, no crash occured.

Other fixed items :

- did some modifications in the wiki page about Apple Remote Implementation
- commited the changes in the appleremote02 cws

Conclusions: I spent a lot of times on that, but I think I understood an important information in OpenOffice.org source code with the DECL() , LINK, LINK_IMPL() mechanism (that's why I try to describe it). Indeed, the scanner does use a similar mechanism, and I know have 90% of the information for the Image Capture implementation, that Valentin Janiaut started some times ago. Another good thing, is the entire changes, if accepted, are really portable : the first side effect will indeed be, it will work on Windows too !!

Last but not least: who helped me there ?
As usual Philipp Lohmann (for important theorical points**), Thorsten Behrens (for his great Impress knowledge) and Jonathan Winandy (from the Centrale Nantes Team) who agreed to build appleremote02 on Leopard on monday (and do some little tests), to confirm there is no obvious problem.

**e.g. Philipp confirmed me, that two event listeners can run together without clash, what I was not sure at all.


To do :

- code cleanup (remove some debug extra stuff e.g.)
- improve : add a removeEventListener somewhere ?
- track leaks ?
- build a clean set, based on appleremote02
- upload it and ask people for tests
- ask for other tests in Windows and Linux ?

Libellés : , , , , ,

samedi, décembre 13, 2008

appleremote02 (part 4)

Removing the F5 key

In appleremote01 cws, the plan was to send keycodes, and the sd had to interpret as commands for the slideshow. It works perfectly, but has the drawback to not respect the portability criteria.

As replacement, I modified the way events are sent to the application

Before, we had :

[NSApp postEvent:

[NSEvent keyEventWithType:NSKeyDown
location: NSZeroPoint
modifierFlags : modifierFlags
timestamp: 0
windowNumber: [[NSApp keyWindow] windowNumber]
context: nil
characters: characters
charactersIgnoringModifiers: characters
isARepeat: toBeRepeated
keyCode: theKeyCode]
atStart: NO];

Means, for every case, I sent the right keycode, for the right slideshow command ( I passed the theKeycode variable to the postEvent method, using an keyEventWithType:NSKeyDown type) (for further information, see RemoteMainController.m appleremote01 )

The new implementation is different :

1) I created a different event type (otherEventWithType:NSApplicationDefined ) sent to the NSApp


- (void) postTheEvent: (short int)buttonIdentifier modifierFlags:(int)modifierFlags
{
[NSApp postEvent:
[NSEvent otherEventWithType:NSApplicationDefined
location:NSZeroPoint
modifierFlags:modifierFlags
timestamp: 0
windowNumber:[[NSApp keyWindow] windowNumber]
context:nil
subtype:AppleRemoteControlEvent
data1: buttonIdentifier
data2: 0]
atStart: NO];
}


(for further information, see RemoteMainController.m appleremote02)

2) in AquaSalInstance::handleAppDefinedEvent(), the NSApp detects the event (in vcl/aqua/app/salinst.cxx ), and turns it into a MEDIA_COMMAND_(some_name) event through the data1 parameter. Then, the sd received the event throught the eventlistener, and does the dispatching to the ::Command and ::Notify implemented methods.

The problem was, it works nicely for all events sent, but only when the slideshow is running.

Means: no way to start the slideshow using the same method as the one used for e.g. gotoNextSlide(), gotoFirstSlide() and so on. My first hack was to continue to create, in salinst.cxx, the NSKeyDown event. The problem is ... it is just a hack.

So I decided to figure out what was happening. And for that, I implemented new methods (uggly buggy hacks, but very usefull to trace everything at runtime), in sd/source/ui/view/viewshel.cxx (see the diff for further information)

What I discovered, is, the events coming from the remote are never seen, when the slideshow is not started !

My first tries where: maybe I do no send the event to the right frame ? So I implemented another hack, when sending the "PLAY" command. The idea was to check for every frame, and see what happens ... More precisely, doing :

switch ([pEvent data1])
{
case kRemoteButtonPlay:
{
nCommand = MEDIA_COMMAND_PLAY;
std::list::iterator it = pSalData->maFrames.begin();
while( (*it) && (it != pSalData->maFrames.end()) )
{
AquaSalFrame* pFrame = (*it);
Window * pWindow = pFrame->GetWindow();
if( pWindow )
{
const Point aPoint;
CommandEvent aCEvt( aPoint, COMMAND_MEDIA, FALSE, &nCommand );
NotifyEvent aNCmdEvt( EVENT_COMMAND, pWindow, &aCEvt );
fprintf( stdout, "EVENT_COMMAND Notified from
AquaSalInstance::handleAppDefinedEvent \n");

if ( !ImplCallPreNotify( aNCmdEvt ) )
pWindow->Command( aCEvt );
}
it++;
}
}


But nothing ... After tracing a lot, and using the backtraces for working and not working events, Philipp Lohmann suggested me to check the focused window.

So did I, using Window* pWindow = Application::GetFocusWindow(); instead of the list of frames.
And one more time, it was not working :-/

So what is the problem ? After yet another discussion on IRC, Philipp finaly found the reason, following ( if I'm not wrong) Christian Lippka explanations : the draw event listener for the slideshow is not active.

More precisely, the "play" does not work on Windows too. The reason is, as soon as the slideshow exists, it registers as event listener of the application. But that is AFTER the slideshow is started. Said differently, the slideshow doesn't exist at all, before the F5 key is pressed :)

=> So the events go nowhere (what I verified since several days ;) )

The solution (see issue 97195 ) in the air is the sd to register as event handler before. Andre Fischer is the specialist, and will work on that.

So far, once it will work, I'll just fix that in 2 minute, and this is the last change I see before to declare the cws as Ready for QA (and find someone for the QA ...) : everything else works, including a new little feature: play/pause when slideshow started.

Crossing the fingers to see the change occur before the deadline of 3.1 (waiting, I'll have a look at how eventlistener work ... cannot be bad to understand how things work ... ;-) )

.. to be continued ...

Libellés : , , , , , ,

mercredi, décembre 10, 2008

Centrale Nantes and Education Project : first result with Tablet PC and Impress

Education Project Logo

More information on the original link (french ) : Tablet PC

After hours of compilation, the first try gives interesting results :
Tablet PC, multi colors

The students working on that, are Olivier Girardot (aka ssaboum) and Frederic Gelot (aka fredus on IRC). Wow :-)

To be continued ...


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Education Project on the wiki

EducOO.org blog (french)

Many thanks to Ben Bois , author of the Education Project Logo

Libellés : , , , , ,

jeudi, décembre 04, 2008

Ecole Centrale Nantes joined Education Project

Education Project Logo

How did this happen ? Firstly, some students ( Olivier Girardot and some other) joined the IRC channel, explained their idea (I'll tell more another time). They asked questions about Impress, and Thorsten Behrens and me tried to help them.

Looks like they appreciated, because I officialy received a mail from Morgan Magnin ( Lecturer, Ecole Centrale Nantes), explaining me that Mr Guillaume Moreau, Director Information System, of the school, authorized us to add it in the list of the schools working with us :-)

It means we will have to organize us better now, e.g. , we'll have to create a dedicated page on the website, think how they can contribute positively for the project and so on ...

Nevertheless, this is always an honnor for us to welcome students and their professors / lecturers. I expect other will join (some people I recently met in Paris during Open World Forum let me think we can expect other ... )

Let's continue the effort !!



""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Education Project on the wiki

EducOO.org blog (french)

Many thanks to Ben Bois , author of the Education Project Logo

Libellés : , , , , ,