Hi, sorry to wake up this thread from the dead - but I'm curious how this went on.
Our model always was to have a platform layer and implement our framework on top of that. On several occasions I've got the impression that since we got a avery demanding new platform ;-) we get more and more requests for some platform dependent features that can't be implemented in VCL because the necessary information is not available there and the code that has this information is platform agnostic. So maybe it's time to decide how we want to proceed: (1) Do we want to have code inside VCL (or even its sal part) that uses our API to retrieve the needed information? (2) Or do we have to accept that platform dependent code enters the framework module? (3) Or can we continue in our old model by finding and defining new abstraction layers (interfaces) in VCL? Regards, Mathias eric b wrote: > Hi Andreas, > > > Le 10 sept. 08 à 10:07, Andreas Schlüns a écrit : >> The question should be the other way around. Our UX Team wrotes >> some specifications regarding the title shown in the title bar. > > > Yes, in meantime, one explained me that it was a recent UX change (I > don't remind where exactly). > > >> And OOo is a crossover product (means it runs on windows, linux, >> solrais and now on Mac). > > > Since the time I'm contributing for the Mac port, I know that :-) > > >> But all those platforms show the same title. Its up to our UX team >> to decide if we change that for Mac - no problem so far. But then >> it should be done inside the framework module and not inside VCL .-) > > > Ok, agreed: let's investigate what could be done in framework. > > My intention, is to follow your recommandations, and implement > something clean. The good thing is I don't know at all framework (say > just a little), and I think that's interesting to discover this part > of OpenOffice.org. Mathias Bauer did a nice presentation for > Education Project, and looks like it's time to go further :) > > > >>>> And then it must be implemented in framework also (might be >>>> conditional with #ifdef MAC ... #endif) but not in VCL ! >>> Sorry, you mean vcl of VCL (API ) ? About the #ifdef QUARTZ, if >>> we could avoid such #ifdef , I'b be happy :) >> >> Seams we cant not :-( >> As I've already said. The title implementation is a generic one >> used for all platforms. If MAC wish to have it's own >> implementation ... we must think about #ifdef QUARTZ ... >> > > Ok. Anyway, we can use .mm files for objective C++ ( probably needed > there ): these files are built on Mac OS X only. > > > >>>> A VCL Window has to provide the possibility to set a title on a >>>> window only .... not to create such title by itself .-) >>> The point is not to create the title itself, but to retrieve the >>> information internally. >> >> Because the title is "not the file name" ... it's a title - it's >> never a good idea to extract any informations from it. It's an UI >> feature (might be localized) only. So please NEVER USE IT TO >> RETRIEVE ANYTHING FROM IT! > > > I won't :-) > > >> >>> I'll try to explain more: >>> To implement a proxy icon, we basically need 4 things : >> >> (??? What do you mean with "proxy icon" ? The icon shown inside the >> Dock?) >> > > I presented the (little) feature on the wiki. Please have a look > (there are screenshots too, and Florian Heckl and Graham Perrin > helped with nice links and comments) > > The link, after a little upgrade with your comments -> http:// > wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_- > _Proxy_Icon_implementation > > (take care to remove extra spaces my mailer randomly adds if the URL > seems to not exist :/ ) > > > >> For me it looks like it MUST be a feature of the framework module. >> > > OK > >> There you will find the code where all documents (and it's related >> windows) will be opened ... where its content will be changed ... >> where >> you will be informed in case a document change its state from >> readonly to modified or back ... etcpp. >> >> There exists two possible solutions: >> a) You implement it as an internal feature of OOo available all the >> time ... >> > > Since this is a default feature on Mac OS x, already asked by the > users, my choice is : internal feature > > >> All informations you will need are provided by events triggered by >> the framework/sfx project. > > > > Do you have some places in mind ? I'm discovering framework and > sfx2, and have classnames, or places to start, or a short description > would save me a lot of time. Thanks in advance. > > > >> Path and File name can be retrieved from the model only >> ... and such model isnt known in the context of VCL. Because VCL >> knows to handle windows only ... > > > + sometimes, very deep system information ( sort of "graphical sal" > from some side ) > > >> independent if such windows are used to show documents or not. >> > > > I remember the case can be determined in vcl : we can discriminate > several types of windows. But that's not the point. > > Thanks again for your help. > > > Regards, > Eric Bachard > > -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
