Feedback needed with Impress 3D OpenGL transitions on Mac OS X
With the recent changes
Thorsten Behrens did (he fixed the bad color space with the cairo canvas helper),
the 3D OpenGL transitions are now working correctly with OpenOffice.org on Mac OS X. Of course, there is probably some additional work before to consider the implementation as "ok", but at least people can test them.
For the adventurous, there is an archive available(Mac Intel only, you use it at your own risks) there (search for INTEL -> DEV300_m42_ogltrans4mac -> en-US)
Please read
this mail for further information, and don't forget to provide feedback and/or file issues assigned to me if ever you find problems.
UPDATE : anybody interested to help me can have a look on the wiki page I created for the occasion.
=>
Mac OS X Porting & OpenGL transitions with ImpressLast but not least, a big thank you to
Mox Soini(cairo implementation),
Radek Dulik (most of the OpenGL thing'ry on OpenOffice.org for Linux) and
Thorsten Behrens(Impress Expert) for his help.
To be continued ... (I hope students working on new 3D transitions will be happy :) )
Libellés : aqua, High Tech, Impress, Mac OS X, OpenGL, OpenOffice
appleremote02 (part7)
Now, the remote works in Windowed mode. The solution was simply in front of my eyes since a while. I think the code simplification improved the design (Philipp has to confirm this is correct).
The new idea is, since we no longer use keycodes, we simply no longer need to check whether we are or not in fullscreen or in presentation mode. This job is a salframe (and salframeview) one, and works out of the box.
Bad news: was not able to build Andre's solution. I'll keep the one Philipp suggested: simple and efficient.
Triggered
issue 97925. Investigating. If ever I can fix it, I'll be done with appleremote02, and time to find a QA resp. and check the Ready for QA thing
Updated the
Apple Remote documentationon the wiki
Booked flight + hotel for
FOSDEM 2009. Sent the proposal to Jurgen.
If it is accepted, this will be my third (already !) participation to the FOSDEM. This year, I proposed a workshop about my contributions to the Mac port of OpenOffice.org.
Libellés : aqua, devel, High-Tech, Mac OS X, OpenOffice, Teaching OpenSource
appleremote02 (part6)
Time for code review, last step for the cws before to be ready for QA.
Philipp Lohmann agreed the changes in vcl ( and thus, the corresponding changes in apple_remote module)
Several problems had to be fixed :
*
Christian Lippka suggested the use of MEDIA_COMMAND_VOLUME (UP and DOWN ) had to be changed, for other OS than Mac OS S X [fixed]
* protect the popup menu case [fixed]
*
Andre Fischer asked about the eventlistener [partially fixed]: is not exactly at the right place, because I add the eventlistener at the end of GetState(SfxItemSet&) method, and this would result in multiple calls to Application::AddEventListener(const Link&). The Application class stores event listeners in a list, not in a set, and thus, more than one eventlistener may be registered for a single SdModule object. Fortunaly, when the (one) listener is removed in ~SdModule the Application::RemoveEventListener(const Link&) removes all listeners (that's what I verified using leaks on Mac)
The possible solutions :
Add the listener directly in the SdModule Ctor : Does not work (maybe my fault), because this leads to a sort of chicken-egg problem, and after some tests, it seems to be unbuildable ( I gve up with that).
Philipp proposed a solution I tested already, based on a singleton pattern [done, works already]
Investigating on another more complicated, but elegant solution Andre proposed. the idea is to create a static Create() method for SdModule, that creates and initializes an SdModule object.
This needs to make the constructor private (no side effects ?) and finally to have SdDLL::Init() calling this new Create() method. Work in progress ...
A big thank you for the code review, and for the time they spend helping me to
Andre Fischer,
Christian Lippka, Philipp Lohmann and
Thorsten Behrens ( kindly answering my questions on the #education.openoffice.org channel)
Libellés : Apple, development, High-Tech, Mac OS X, 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
[Mac OS X] experimental PowerPC and Intel builds need feedback
Please note :
not for production, backup your datas, save your prefs *before*... ...
For the adventurous, I do provide advanced, experimental builds for both
PowerPC and Intel, here : URL of Laurent site ( I can provide german on demand )
Those builds are based on DEV300_m35 + ogltrans4mac + macmenusquit + appleremote02 cws's
*
ogltrans4mac cws means, OpenGL transitions are inside, and work*
macmenusquit cws aims to removes useless "Quit" entries in all OpenOffice.org applications ( Calc, Writer .. and so on)
*
appleremote02 is a new apple remote implementation
And if you want to improve the chance to see such changes in the future 3.1, I really need feedback : thanks in advance for any ... !!Libellés : aqua, development, Mac OS X, OpenGL, OpenOffice
appleremote02 (part 2)
The second implementation works !! Thanks to the gold advices from
Philipp Lohmann, who saved me a lot of time.
I spend one hour to fix a stupid typo (if you see it, please drop me a mail ;-) ) :
SalData* pSalData = GetSalData();
AquaSalFrame* pFrame = pSalData->maFrames.front();
Window * pWindow = pFrame->GetWindow() ?
pSalData->maFrames.front()->getWindow()
: NULL;
if( pWindow )
{
...
Plus one other hour to see why start was not working, nor go to last slide ... **
But now, it simply works, and I'll try to add the contextual menu, and more if I can.
Anybody interested to QA the cws ?Total cumuled time to work on that: 10 hoursTo be continued ... **ha ha : the methods are simply missing in the slideshow, when you use events -> will do
Libellés : aqua, development, Mac OS X, OpenOffice, OSX
appleremote02 (part 1)
Since
Florian Heckl approved the appleremote01 cws (thanks to him !), we can say the Apple Remote has big chances to be integrated in the Mac OS X version of OpenOffice.org 3.1.
UPGRADE : appleremote01 is in the coming DEV300_m35 !! :-)
The code is ready since a while (in september is was ready), but as usual, the QA is a bottleneck : we simply losed month for this feature integration :-/
Well, without wait more, I started the appleremote02, who will improve the process, making the change more "portable". All details are given there
appleremote02 cws description (I'll add information progressively).
The plan is to use another type of events, for instance NSApplicationDefined , and pass the buttonIdentifier as parameter (data1 ).
More techincaly, I created a new events subtype ( AppleRemoteControlEvent), and this new event type will be detected by the NSApp in AquaSalInstance::handleAppDefinedEvent( NSEvent* pEvent ).
I didn't change anything to the butttons, but I'll probably add new effects, like contextual menus, once they will be properly handled.
First results :
* in Fullscreen
Received the following event from the Apple Remote : 16
Received the following event from the Apple Remote : 2
Received the following event from the Apple Remote : 32
Received the following event from the Apple Remote : 64
.. and so on
* In normal mode, we receive only menu + play buttons as expected
Looks ok so far :-)Status of the changes:
Done (but code not commited, because appleremote01 is not integrated ) :
* remove the event sending the keycode
* implement new method, sending new event type, including the buttonIdentifier value
* implement glu code for intercepting the event and receiving the value of the message
* new libAppleRemote builds without any glitch
Planned :
* turn the notification into the right constant ( COMMAND_MEDIA and co defined in vcl/inc/vcl/cmdevt.hxx )
* build
* test
* verify
To be continued ... Libellés : aqua, development, Mac OS X, OpenOffice, OSX
Creator type
Not sure this is what we should have, but I finally get the
"file creator " appear (using File Info application to verify it works as expected).
See the screenshot below:
APPL -> means an application to create the file
OOO3 -> means the file is of OpenOffice.org 3 type (yes, I know, I changed for 3 after discussing the point with
Oliver Braun (aka obr ), who provided me precious advices, like the extremely usefull
issue 60840 I was not able to find alone :-)
What was missing is a couple of parameters (who gave ???? when undefined ), the Finder needs, to be able to open OpenOffice.org files, even when the extensions are missing. Yet another Mac OS X feature :)
The fix is based on the patch
P. Luby donated some times ago, and who was not integrated (I sincerily believed it was). But this patch is now obsolete, and I had to adapt, and add a second modification to make it work. After some thought, other members like extFinderInfo need some investigations.
After tracing a bit, I finally found the missing information: in the patch (see
issue 55862 ), I had to create the second entry in the structure.
I hope someone will confirm the result is ok, and if I can find some time, I'll commit the change in some cws. Maybe we can expect other positive side effects since it works ?
Below, the trace, where all other parameters I've discovered during the debugging. the important is, in the aCatInfo structure, you have to set filetype and fileCreator, and things are ok :)
Update: it is important to explain nothing is so easy, and the estimated time of work to make that little feature work is approximatively
5 hours.
To be continued ...The (partial) trace :
Breakpoint 1, oslSetFileTypeFromPsz (pszStr=0xbfffdf6c "/Users/ericb/Library/Application Support/OpenOffice.org/3/user/registry/cache/org.openoffice.Office.Paths.dat") at /Users/ericb/Desktop/DEV300_m31/sal/osl/unx/file.cxx:2266
2266 if ( FSPathMakeRef( (const UInt8 *)pszStr, &aFSRef, 0 ) == noErr && FSGetCatalogInfo( &aFSRef, kFSCatInfoFinderInfo, &aCatInfo, NULL, NULL, NULL) == noErr )
(gdb) p aCatInfo
$1 = {
nodeFlags = 57305,
volume = -16385,
parentDirID = 0,
nodeID = 0,
sharingFlags = 237 '?',
userPrivileges = 245 '?',
reserved1 = 0 '\0',
reserved2 = 0 '\0',
createDate = {
highSeconds = 34290,
lowSeconds = 2247236563,
fraction = 7123
},
[...cut...]
Important information is below :
permissions = {466847000, 2415923616, 158532224, 1024},
finderInfo = "h\031\024\022$??? ?????!",
extFinderInfo = "??????!\000???\033???\033",
dataLogicalSize = 9574975677652728,
dataPhysicalSize = 9479542736618108,
rsrcLogicalSize = 13835339100762201912,
rsrcPhysicalSize = 386186189282738764,
valence = 0,
textEncodingHint = 467473592
}
Current language: auto; currently c++
Libellés : High-Tech, Mac OS X, OpenOffice, OSX
Call for donation for Education and Mac OS X porting projects
Several OpenOffice.org Projects have no or very limited resources. e.g.
Mac OS X Aqua port and
Education Project (still incubator project). But to continue the effort, like mentor students writing code for OpenOffice.org project, help developers attending conferences, or pay them expensive memberships for development (like Apple ADC, or iPhone SDK ), or even pay one skilled developer to write some new feature, they need a bit of money.
EducOO.org is a french association (non profit) who aims to help
OpenOffice.org Education Project, or other OpenOffice.org Project like the
Mac OS X port, but not only.
This association is there to receive legally money from donators, for a lot of reasons, like help the developers to write missing features, attend conferences, or buy machines and even more.
If you want to support both Mac OS X and Education Project,
you can simply donate.
Thank you very much !Further information :
EducOOo page for donations """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Education Project on the wiki EducOO.org blog (french) Many thanks to
Ben Bois , author of the Education Project Logo
Libellés : Education, EducOOo, High-Tech, Mac OS X, OSX
News from Education Project
Pierre Pasteau and
Rakesh Pandit have seen their rights granted (thanks to
Martin Holmichell, Louis Suarez Potts and Stefan Taxhet who have accepted the requests). This means Pierre and Rakesh can now create their own cws's, commit code using tunnel, and ask to a confirmed developer to validate their code. Like all other OpenOffice.org developers. If you join
#education.openoffice.org channel (IRC server is irc.freenode.net), their IRC nicknames are (respectively)
pierrep and
chacha_chaudhry.
This means too, the
Education Project now counts 2 new Domain developers ! Other tasks in progress :
This morning, I was invited to
Valentin Janiaut presentation. The topic was about his task : Image Capture Implementation on Mac OS X. Was a very interesting presentation, and Valentin did big progress, and presented several possibilities.
Valentin is yet another student involved in
Education Project Effort, and no doubt, he will soon propose code.
From my side, still playing with OpenGL, I tested FLipView, and I have some ideas for the future. If you don't understand what means FlipView, you can have a look at the video ( ugly, but we see what happens) I put there
OpenGL FlipView .(tested ok using VLC under Linux and Mac OS X)
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 : Education, High-Tech, Mac OS X, OpenOffice, OSX, School
OpenGL transitions ( 2)
Worked 5 hours on the thing last night (from 30th to 31st august).
Good some good news :
Fixed the colorspace issue: was the pDetectedFormat, means OpenGL transitions work and appear in the right colors now.
There is only one remaining important issue (flicker) Some details : GL_VERSION 1.2 or 1.3 detected means we enter in the "if .. .#endif" control structure
Adding debug info, we have :
rendering::ColorSpaceType:: 2 ( if RGB, returns 2 )
GL_VERSION 1.2 or 1.3 detected
nNumComponents = 4
nBitsPerPixel = 32
nComponentOrderIndex = 0
And in the #if .. #endif structure, this leads to lcl_ARGB32[] use, what is wrong. Indeed, correct OGLFormat is lcl_RGB24 on Mac OS X Intel ( lcl_RGB32 untested, might work )
Simple solution -> not use or fix the suspicious color space detection, and use (just fast workaround) :
#if defined(GL_VERSION_1_2) && defined(GLU_VERSION_1_3) && !defined( QUARTZ ) // buggy
instead of : #if defined(GL_VERSION_1_2) && defined(GLU_VERSION_1_3)
TODO :
- cleanup in void OGLTrans_TransitionerImpl::GLInitSlides() ,
- contact Radek, and Thorsten, and see. Maybe split the current OGLTransitionerImpl.cxx in three arch-dedicated files, should help to avoid the growing forest of #if ..
Last remaining issues : offset in window mode, caused by scrollbar not included in the slide position computation
(the frame dimensions are different)
=> Looks secondary, because everything works fine in a frame.
flickerVery noisy when happening. Must be fixed.
The problem is (using ssa words) : the slideshow displays the slide first
then an opengl view is painted on top of it and plays the slide transition
once it is removed the old background appears again still containing the first frame of the animation, and after a very short time the slideshow engine draws the final frame,
which is visible as a flicker
Update: the issues always occurs, means it does concern both windowed and fullscreen modes.
There is probably some needDisplay or whatever other event sent, we should not. Needs to ask pl, the master of vcl.
Optimization / compatibility ?
Will be Fun ( cleanup in OGLTransitionerImpl::GLInitSlides() is mandatory to be sure the detection works on every machine.
To be continuedLibellés : development, fun, High-Tech, Mac OS X, OpenGL, OpenOffice, OSX
OpenGL transitions in Impress for Aqua (1)
Started the effort, to make work the
OpenGL transitions, Shane M. Mathews developed under the Google Summer of Code 2007.
The goal is to use these transitions in Impress with the Aqua version. Obviously, the feature does concern Mac OS X only. As reminder, the great work Shane did, was mentored by
Thorsten Behrens.
The work is progressing fastly, and I created the cws is
ogltrans4mac. We'll probably do commit everything soon ( build completed with the current patches)
Everything will be documented on
the OpenGL transitions for Aqua wiki page. I'll document the code changes (incuding the one about another idea) asap.
Currently, the transitions can be tested, but some important issues have to be solved, and any help for the implementation is welcome.
Last, I'd like to thank
Stephan Schaefer for the important piece of code he provided (making the NSOpenGLView working).
Any volunteer is warmly invited to join us in the adventure :-)
Some screenshots are available
hereIMPORTANT: we need volunteers to (I hope this will not slow down the work in progress) write a spec document... and the Macport needs new devs, with objective C / C /C++ skills. Feel free to contact us :)Libellés : aqua, development, fun, High-Tech, Mac OS X, OSX
apple remote (4)
Recent changes :
- commited all the code
- the bounce with previous slide is fixed
- some new keyCodes are under test ( NSEvent.h is really helpfull ! )
- Did some cleanup, and code factorization.
- F5 can open the navigator in Calc/Draw and writer. Other keys are not active
I'll upload a new (unofficial and hacked) Intel build today on
Laurent site today
The idea in the code factorization was to add a (private) method for sending the events, and simplify. No idea whether other parameters can or not be usefull, but I'll do some investigations.
e.g. use the isARepeat parameter could be interesting, because more "Front Row like"
Todo : open contextual menus, and make the up / down buttons work, and select items in the contextual menu (if ever it is possible).
Last : I found information about the concerned API for the Media Browser :-)
To be continued ... Libellés : aqua, devel, High-Tech, Mac OS X, OSX
apple remote (3) and other recent things
The apple_remote alias is ok (thanks to
Martin Hollmichel), thus I created appleremote01 cws ( should be buildable with m29 now).
Thanks to
Eike Rathke who explained me how commit the new build.lst and d.lst
The great and fast feedback from
Yves Roggeman, who helped me to fix the fullscreen issue ( I just forgot to implement it ).
I made a point with
Pierre Pasteau about his first task ( see
replace mozilla 1.7.5 )
Hope to find some time for the other cws I'd like to create ( macmenusquit)
Last but not least, new builds are available on
oooaqua site ( ja locale is available for Intel, and I'll start PowerPC build this afternoon)
IMPORTANT : please do not forget they are
unofficial and hacked builds, who just aim to receive feedback about the apple remote, nothing else. Do not use them if you don't know what you are doing, and make a backup of your datas
Libellés : aqua, development, fun, High-Tech, Mac OS X, OSX
Apple Remote in Impress : first try before more serious implementation
Just back from holidays, I found some times to hack the Apple Remote (the controller shipped with Apple machines).
After a week of learning the great
Pierre Chatelier documentation (Objective C for C++ developers ), and
Aaron Hillegass book " Cocoa Programming for Mac OS X", I finally found how to adapt
Martin Kahr's code, to make the Apple remote work with OpenOffice.org.
Today, reading Apple documentation, I finally found a simple way to implement the basics of the thing. and it works :-)
What you currently can do is:
- start a presentation
- goto next / previous slide
- goto to last/first slide
- quit the presentation
The Impress window must be in front (the active window). Else, Front row menus works as usual.
Some other features are missing, and I hope to make them work asap.
For the curious, I do provide unofficial builds Intel only ( PowerPC on tuesday), for en-US , fr and de (upload in progress). Don't forget to do a backup of your files.
The URL for the download is
Laurent Buisson site . Many thanks to him, for providing the ressources.
Last but not least, I found a way to modify the menus on the fly, and at build time, e.g; removing the not Aqua HIG compliant extra "Quit" in all the menus. I think this change could be an open door to better Mac OpenOffice.org menus customization.
Of course, this is work in progress, and I'm thinking to a more deep and professionnal implementation, but we need feedback from our users, to implement proprely the thing.
To be continued ...Libellés : Apple, aqua, development, High-Tech, Mac OS X
Import pdf for Aqua works
I wrote a
french Howto for the installation of the pdfimport extension with the Aqua version of OpenOffice.org.
See
Import PDF avec OpenOffice.org sous Mac OS X (French only)
Jus wondering:
why isn't this extremely interesting feature integrated in the Bundle ?An extension for that is not good, because
a lot of users will simply ignore this is possible. :-/Libellés : aqua, Education, EducOOo, High-Tech, Mac OS X, OpenOffice
