About the number of developers contributing to OpenOffice.org (again)
Back from FOSDEM (I'll write a word asap about it), I tried to see what happened in meantime, mainly what was committed in OOo tree.
If you remember my previous blog entry ( see
this link ), I wrote it was very easy to retrieve the most recent information, and have the number of people who commited code in some cws, for OpenOffice.org Project.
The magic link was:
CIA.vc server Now it is no longer possible, because
the stack of the recent commiters, including the sum,
disappeared.
I ignore what happened, and who did that, but that's clearly a
big regression for me, and yet another hidden information, who should be publicaly available.
Indeed, we now are in the situation where we:
- just see the (20 ?) most recent commits, nothing else
- have no idea on the number of contributors since we use svn
- cannot extract the exact content of a commit, and who did what in a cws (at least this is not as easy as it was using Bonsai, where we could even watch everything online).
I have contacted the owner of CIA.vc. Maybe he will explain me some tip, or how to proceed, to retrieve the values, and maybe more.
Libellés : Code, development, High-Tech, number of OOo devs OpenOffice
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 : Code, development, High-Tech, OpenOffice
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 : aqua, Code, development, High-Tech, OpenOffice
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 handler2)
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 : aqua, Code, development, High-Tech, OpenOffice, Teaching OpenSource
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 : aqua, Code, development, fun, High-Tech, Mac OS X, OpenOffice
