vendredi, octobre 31, 2008

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 hours

To be continued ...


**ha ha : the methods are simply missing in the slideshow, when you use events -> will do

Libellés : , , , ,

jeudi, octobre 30, 2008

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 : , , , ,

jeudi, septembre 18, 2008

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:

creator type

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 : , , ,

mardi, septembre 16, 2008

Call for donation for Education and Mac OS X porting projects

Education Project Logo

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 : , , , ,

vendredi, septembre 12, 2008

News from Education Project

Education Project Logo

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 : , , , , ,

dimanche, août 31, 2008

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.

flicker

Very 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 continued

Libellés : , , , , , ,

jeudi, août 28, 2008

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 here


IMPORTANT: 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 : , , , , ,

jeudi, août 21, 2008

apple remote (5)

Last changes:

- Seems to work well with the the Presenter Screen, a great and promising feature. Many thanks to the authors btw !

The issue was, the events were not sent to the right screen, and thus, no clics ... After searching complicated things, it was just a bad parameter. For one time I didn't had to read Apple doc for hours. Just a 20 minutes of search ... et hop :-)

- Updated the wiki page

I'll continue to test

To be continued...

Libellés : , , , ,

mercredi, août 20, 2008

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 : , , , ,

mardi, août 19, 2008

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 : , , , , ,