Difference between revisions of "Log Mac Meeting 4 May 2007"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 271: Line 271:
  
 
[22:34]  <ericb2> sorry
 
[22:34]  <ericb2> sorry
 +
 +
[22:35]  <PhilippL> The first point seems to be getPixel ?
 +
 +
[22:35]  <ericb2> PhilippL: if I'm not wrong, yes
 +
 +
[22:35]  paveljanik PhilippL plipli
 +
 +
[22:35]  <ericb2> PhilippL: currently we return nSalColor =0
 +
 +
[22:36]  <ericb2> PhilippL: and I wonder ..
 +
 +
[22:36]  <PhilippL> The question is whether it is needed, the answer is: seldom, but in some places, yes. It should be possible to implement since you have getBitmap, so
 +
the hard way would be getBitmap and then get the pixel out of the bitmap.
 +
 +
[22:37]  <paveljanik> or getBitmap with 1x1 rectangle...
 +
 +
[22:37]  <ericb2> PhilippL: what is the main purpose of this method ?
 +
 +
[22:37]  <ericb2> paveljanik: yes, this is what I had in mind
 +
 +
[22:37]  paveljanik PhilippL plipli
 +
 +
[22:37]  <plipli> PhilippL: for a general purpose, I think what we need and that you can teach us is : what is the goal of each mandatory function/method
 +
 +
[22:37]  <ericb2> paveljanik: some CGRect
 +
 +
[22:37]  <PhilippL> The most common example i found is getting the background color to blend with.
 +
 +
[22:37]  <PhilippL> Arguably that is just bad implementation.
 +
 +
[22:38]  <thorsten> yeah - Impress edit engine samples five points from the bg to calc its background color ;-P
 +
 +
[22:38]  <PhilippL> One valid example: the eyedropper
 +
 +
[22:39]  <PhilippL> There you pick a color out of the document to work with.
 +
 +
[22:39]  <PhilippL> This cannot be implemented differently I think.
 +
 +
[22:39]  <plipli> PhilippL: +1
 +
 +
[22:40]  <thorsten> well - mid-term, all apps will  have switched to aw's overlay buffer
 +
 +
[22:40]  <thorsten> so, there's always  a VDev with the currently visible content
 +
 +
[22:41]  <PhilippL> Which will need getPixel :-) Also I'm not sure whether this will squat the eyedropper case.
 +
 +
[22:42]  <thorsten> PhilippL: sure - but getPixel in a VDev  should be fairly easy ;-)
 +
 +
[22:42]  <PhilippL> Since with that you pick a color out of the document and save it e.g. for use in a color scheme.
 +
 +
[22:42]  <PhilippL> thorsten: point taken.
 +
 +
[22:43]  <PhilippL> However when the overlay will come to pass is unknown, so we better implement getPixel using getBitmap just now.
 +
 +
[22:43]  <PhilippL> If we don't need it anymore, it can go.
 +
 +
[22:43]  <thorsten> yep
 +
 +
[22:45]  <ericb2> maybe this is enough infos ?
 +
 +
[22:45]  <PhilippL> please tell me if I'm too noisy :-)
 +
 +
[22:45]  * Nesshof_ (n=chatzill@p5B05C866.dip.t-dialin.net) has joined #ooo_macport
 +
 +
[22:45]  <ericb2> PhilippL: no, at all
 +
 +
[22:46]  <ericb2> PhilippL: we are glad to learn more about vcl 
 +
 +
[22:46]  * mreimer_ can tell it's going to be very helpful having sun devs helping
 +
 +
[22:47]  <PhilippL> Next point on the list is Beziers ? That's optional. I would suggest leaving this empty for now.
 +
 +
[22:47]  <ericb2> ok, agreed
 +
 +
[22:47]  <ericb2> next is drawBitmap
 +
 +
[22:49]  <ericb2> in AquaSalGraphics, they are 3 drawBitmap() , and one is not implemented
 +
 +
[22:50]  * _Nesshof_ has quit (Remote closed the connection)
 +
 +
 +
  
 
Return to Previous meetings page : [[Previous_Mac_Meeting_logs]]
 
Return to Previous meetings page : [[Previous_Mac_Meeting_logs]]
  
 
Return to April Meetings [[Mac_meetings_May_2007]]
 
Return to April Meetings [[Mac_meetings_May_2007]]

Revision as of 20:51, 4 May 2007

Return to Previous meetings page : Previous_Mac_Meeting_logs

Return to April Meetings Mac_meetings_May_2007


[22:00] <ericb2> Can we start ?

[22:00] <shaunmcdonald> ericb2: yes

[22:00] <ericb2> 1. Welcome new devs and devs from Sun joining Mac OS X port

[22:00] <ericb2> :)

[22:00] <shaunmcdonald> the agenda is at http://wiki.services.openoffice.org/wiki/MacOSXPortMeetings

[22:01] <ericb2> shaunmcdonald: thanks

[22:01] * cloph_away is now known as cloph

[22:01] <ericb2> as usual , the first point is dedicated to welcome the new devs

[22:01] <ericb2> today is not usual, becasue we have to welcome Sun devs

[22:02] <paveljanik> we want to :-)

[22:02] <PhilippL> Oh, I'm here :-)

[22:02] paveljanik PhilippL plipli

[22:02] <PhilippL> Hello everybody.

[22:03] <paveljanik> Looks like _Nesshof_ finally trashed Windows as well? ;-)

[22:03] <ericb2> PhilippL: can you please shortly present you ?

[22:03] paveljanik PhilippL plipli

[22:03] * cloph wonders whether anybody commented to my nas question/rant since I have been disconnected...

[22:03] <_Nesshof_> paveljanik: not really, I'm using all the platforms where OOo runs

[22:04] * PhilippL works for Sun/StarOffics/StarDivision for nearly ten years. basically always on the platform GUI stuff, and here mostly for the Unix platforms.

[22:04] * _Nesshof_ admits that he runs now Vista

[22:05] * Cremlae (n=Cremlae@dialup-85-141.colorado.edu) has joined #OOo_macport

[22:05] <PhilippL> Apart from vcl I work on printing clipboard, PDF export, scanning and have left fingerprints at a dozen other places.

[22:05] <plipli> hi Cremlae

[22:05] <paveljanik> PhilippL: glad to have you on board!

[22:05] <Cremlae> plipli: Hi!

[22:06] <PhilippL> I have basically no mac experience, but I think I can help with integration into general vcl.

[22:06] <plipli> PhilippL: great to have a vcl expert with us

[22:06] <PhilippL> HDU on the other hand is THE font expert inside OOo I would say.

[22:06] <ericb2> PhilippL: sure you will : your vcl knowledge is IMHO impressive

[22:06] <plipli> we need vcl knowledge, we ll bring mac osx experience

[22:07] <PhilippL> The aqua ATSUI code is already contributed (at least partly ?) by him and he will certainly continue to work on that.

[22:07] <plipli> hdu has helped eric and me for atsui

[22:07] <PhilippL> I guess that's about it about us ?

[22:07] <ericb2> FYI , Herbert advertised me he cannot attend the meeting

[22:07] paveljanik PhilippL plipli

[22:07] paveljanik PhilippL plipli

[22:08] * fheckl (n=florianh@p57B55D99.dip.t-dialin.net) has joined #ooo_macport

[22:08] <plipli> With hdu tips, I was able to inplement beginning parts of salatslayout

[22:08] <ericb2> PhilippL: thank you very much

[22:08] <shaunmcdonald> fheckl: hello, PhilippL has just introduced himself

[22:09] <plipli> hi fheckl

[22:09] <fheckl> ok, I read his intro mail, hi everyone

[22:10] <paveljanik> other new devs?

[22:10] <ericb2> paveljanik: I think so

[22:12] <impad> yes, I am a standalone programer with some experience with OSX dev

[22:12] <impad> but a newcomer on the project :)

[22:12] <ericb2> impad: great ! be welcome :)

[22:13] * Fridrich (n=fridrich@26-34.1-85.cust.bluewin.ch) has joined #ooo_macport

[22:13] * ChanServ gives channel operator status to Fridrich

[22:13] <impad> ericb2 : thank you

[22:13] <ericb2> impad: do you have Carbon API experience ?

[22:14] * damiend (n=damiend@fau42-2-82-239-192-212.fbx.proxad.net) has joined #ooo_macport

[22:14] <ismael_> hi damiend

[22:14] <damiend> ismael_: ih

[22:14] <impad> ericb2 : unfortunately, I'm much more experienced in Cocoa

[22:14] <damiend> ismael_: i'm reading the log

[22:15] <ericb2> impad: if you have Mac experience, you can help us

[22:15] impad ismael_ IZBot

[22:15] <PhilippL> Question: Is the Cocoa implementation based on Carbon ?

[22:15] <impad> ericb2 : at least, I'll try ;)

[22:16] <fheckl> PhilippL; given Cocoa's past, I doubt it

[22:16] <ericb2> PhilippL: no, this is another API ( objective C, simple inheritance, dynamic typing ..etc) . Most of the time Carbon "compatible" , but not always

[22:16] <paveljanik> PhilippL: some APIs are, some are not.

[22:17] <PhilippL> So is there any real danger of Apple end-of-lifing Carbon ?

[22:17] * doctype (n=martin@p57a23df8.dip0.t-ipconnect.de) has joined #ooo_macport

[22:18] <fheckl> PhilippL: not in the next few years

[22:18] <plipli> ericb2: i don t agree

[22:18] <tinor_> PhilippL: In principal yes, but I think its almost the same as with win32 on Windows, they can really afford to end-of-lifing it

[22:18] <tinor_> PhilippL: Without loosing lots of old apps

[22:18] <thorsten> which other apps are based on Carbon?

[22:19] <PhilippL> Ok, i just asked, because that was of the concerns in the Blog-Comments

[22:19] <thorsten> mozilla, I guess?

[22:19] <tinor_> #can#can't

[22:19] <damiend> thorsten: old CS2 Adobe and Office 2004

[22:19] <damiend> but often into PowerPPC arch

[22:19] <paveljanik> next point? ;-)

[22:19] <plipli> cocoa and carbon are mixed in macosx apis

[22:19] <tinor_> thorsten: AFAIK many of the Adobe apps

[22:20] <ericb2> Other devs ?

[22:20] <plipli> we have to focus on

[22:20] <plipli> paveljanik: no

[22:20] <plipli> a sec

[22:20] <tinor_> thorsten: Even MS Office is based on Carbon, though I've heard they are trying to switch to Cocoe

[22:20] <plipli> cocoa can use carbon and carbon can call cocoa

[22:20] <plipli> we don t need to switch truly

[22:21] <paveljanik> good example will be spell checker integration for us ;-)

[22:21] <plipli> apple release api for both cocoa and carbon

[22:21] <plipli> becaus cocoa is too high level

[22:21] <plipli> for specific dev every mac coder use part of carbon apis

[22:21] <ericb2> plipli: and this is expensive .. maintain only one would simplify apple life

[22:22] <plipli> all this will be much clearer zith core grpahics, core text

[22:22] <ericb2> Next point ?

[22:22] <shaunmcdonald> one quick thing

[22:22] <plipli> ericb2: the transition has alreqdy begun

[22:22] <shaunmcdonald> the news of the sun devs is reaching far

[22:22] <shaunmcdonald> there have been around 2 dozen blog posts or more so far

[22:22] <plipli> we have to focus on being Core * co;patible

[22:23] <shaunmcdonald> this is a *lot* compared to an ooo release or any other mac related ooo news

[22:23] <obr> paveljanik: is somebody actively working on spellchecker integration ?

[22:23] <paveljanik> obr: no.

[22:23] <obr> paveljanik: o.k., thanks.

[22:23] <damiend> plipli: what do you mean by "Core compatible ? "

[22:24] <shaunmcdonald> this have been received mostly positively :-) though there have been a few comments on "Just use NeoOffice"

[22:24] <plipli> if we continue to use recent apple code, sample and core grpahics, core text etc

[22:24] <plipli> we ll be safe

[22:24] <ericb2> plipli: +1

[22:24] <ericb2> plipli: this is my opinion too

[22:24] <plipli> I ll get info more precise from apple engineers

[22:24] <plipli> that s one of the main reason to go to wwdc

[22:25] <plipli> and fetch info at the source

[22:25] <fheckl> plipli: yes, just think of QuickDraw deprecation in favor of CoreGraphics/Quartz

[22:26] * Fridrich (n=fridrich@26-34.1-85.cust.bluewin.ch) has left #ooo_macport

[22:26] <ericb2> Next point is :

[22:26] <plipli> fheckl: cocoa is only a framework historically from nextstep

[22:26] <ericb2> 2. A point on Aqua port

[22:26] <plipli> fheckl: now Tiger and leopard are Core* based

[22:27] <plipli> damiend: we have to continue following apple s guide to Core oriented progrmming : using API of Core frameworks

[22:27] <plipli> ericb2: +1

[22:28] <ericb2> The Aqua port now

[22:28] <ericb2> our first objective is to provide a real Mac application

[22:29] <ericb2> since some times ,we did big progress, enough to define a timeline and a Top 10 of issues before to provide an "alpha"

[22:30] <ericb2> The timeline : http://porting.openoffice.org/mac/timeline.html

[22:30] <ericb2> as you can see, we are a bit in late

[22:30] <ericb2> Top 10 of issues: http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html

[22:30] <ericb2> 5 are ( please correct me) fixed

[22:31] <ericb2> 3 over 5 have a workaround ( we know the " what", not the exact "why")

[22:32] <ericb2> During 2nd Hamburg porters meeting (dec2006)

[22:32] <shaunmcdonald> ericb2: very good point about the timeline

[22:32] <ericb2> Stephan Shaefer wrote a document describing the most important points to solve

[22:32] <ericb2> http://eric.bachard.free.fr/mac/MacPortersMeeting_Ham_07/may04/aquaport-roadmap.pdf

[22:33] <ericb2> I just updated the document ( the old one is : http://eric.bachard.free.fr/mac/MacPortersMeeting_Ham_07/ )

[22:34] <ericb2> I proose to discuss the content, point by point, and define objectives

[22:34] <ericb2> s/proose/propose/

[22:34] <ericb2> sorry

[22:35] <PhilippL> The first point seems to be getPixel ?

[22:35] <ericb2> PhilippL: if I'm not wrong, yes

[22:35] paveljanik PhilippL plipli

[22:35] <ericb2> PhilippL: currently we return nSalColor =0

[22:36] <ericb2> PhilippL: and I wonder ..

[22:36] <PhilippL> The question is whether it is needed, the answer is: seldom, but in some places, yes. It should be possible to implement since you have getBitmap, so the hard way would be getBitmap and then get the pixel out of the bitmap.

[22:37] <paveljanik> or getBitmap with 1x1 rectangle...

[22:37] <ericb2> PhilippL: what is the main purpose of this method ?

[22:37] <ericb2> paveljanik: yes, this is what I had in mind

[22:37] paveljanik PhilippL plipli

[22:37] <plipli> PhilippL: for a general purpose, I think what we need and that you can teach us is : what is the goal of each mandatory function/method

[22:37] <ericb2> paveljanik: some CGRect

[22:37] <PhilippL> The most common example i found is getting the background color to blend with.

[22:37] <PhilippL> Arguably that is just bad implementation.

[22:38] <thorsten> yeah - Impress edit engine samples five points from the bg to calc its background color ;-P

[22:38] <PhilippL> One valid example: the eyedropper

[22:39] <PhilippL> There you pick a color out of the document to work with.

[22:39] <PhilippL> This cannot be implemented differently I think.

[22:39] <plipli> PhilippL: +1

[22:40] <thorsten> well - mid-term, all apps will have switched to aw's overlay buffer

[22:40] <thorsten> so, there's always a VDev with the currently visible content

[22:41] <PhilippL> Which will need getPixel :-) Also I'm not sure whether this will squat the eyedropper case.

[22:42] <thorsten> PhilippL: sure - but getPixel in a VDev should be fairly easy ;-)

[22:42] <PhilippL> Since with that you pick a color out of the document and save it e.g. for use in a color scheme.

[22:42] <PhilippL> thorsten: point taken.

[22:43] <PhilippL> However when the overlay will come to pass is unknown, so we better implement getPixel using getBitmap just now.

[22:43] <PhilippL> If we don't need it anymore, it can go.

[22:43] <thorsten> yep

[22:45] <ericb2> maybe this is enough infos ?

[22:45] <PhilippL> please tell me if I'm too noisy :-)

[22:45] * Nesshof_ (n=chatzill@p5B05C866.dip.t-dialin.net) has joined #ooo_macport

[22:45] <ericb2> PhilippL: no, at all

[22:46] <ericb2> PhilippL: we are glad to learn more about vcl

[22:46] * mreimer_ can tell it's going to be very helpful having sun devs helping

[22:47] <PhilippL> Next point on the list is Beziers ? That's optional. I would suggest leaving this empty for now.

[22:47] <ericb2> ok, agreed

[22:47] <ericb2> next is drawBitmap

[22:49] <ericb2> in AquaSalGraphics, they are 3 drawBitmap() , and one is not implemented

[22:50] * _Nesshof_ has quit (Remote closed the connection)



Return to Previous meetings page : Previous_Mac_Meeting_logs

Return to April Meetings Mac_meetings_May_2007

Personal tools