Hi Mox,
as you correctly outlined, XUL is the only _realistic_ approach, to get
a (nearly) native OOo on Mac OS X.
Main point probably is, that such an adoption introduces a new, high
sensitive dependency into OOo. I am 100% sure, that we would find bugs,
miss features, face incompatibilities and so on, if we go this way. We
probably would need _active_ help from the Mozilla community, to succeed
with this.
On the other hand, currently _no_ ISV etc. really has a chance of doing
inter application open source desktop programming, because of the
diversity of technologies to learn, e.g. GTK+, QT, XPCom, UNO, XUL, VCL,
OOo BASIC, JavaScript, C, C++, Bonobo, ..., not even mentioning the
thousands of interfaces.
And, there could be even more, just take a look at the overall
architecture of OOo and Mozilla ... :-)
Kay
Mox wrote:
Hi again...
A bit of a disclaimer first. I do not have any first hand knowledge on
OOo with Cocoa or any other combination. I have been just reading
NeoOffice forums and blogs about OOo, Cocoa, GTK, KDE etc etc.
However, I think that what I try to say is not without merits. On the
other hand, if there are mistakes, please correct them!
I can very well understand that for Mac, the idea of combining OOo and
Cocoa is intuitively the "right thing to do". And for many programs it
is. Cocoa is very nice way to port for apps like Abiword or for apps
that can be created more or less from the beginning.
But OOo is a HUGE program. It also has an architecture that is very much
oriented towards Windows and X11. It does NOT work well with Cocoa
programming concepts. See, for example, NeoOffice people's comments:
http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=3585#3585
<http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=3585#3585>
I think the more or less only people, who have actually tried to make
Cocoa and OOo work together were Patrick and Ed from NeoOffice. They
worked on that for 1+ years and in the end, got a very fragile and very
unstable build called "flaming yeti". After working so much on it, they
decided (in 2003) that it was NOT a good way and then started using Java
for the UI.
....
The following numbers and percentages can be very wrong. I hope somebody
could correct them. But I'll try anyway....
For KDE(QT) and GTK, the theming in OOo 2.0 uses NWF, a.k.a. Native
Widget Framework, which does not actually use native widgets. It only
uses the same native theme resources (button pictures, configurations
etc) as the toolkit (QT/GTK) would use and then places those pictures on
top of the widgets of OOo.
For Mac, this does not work, because Apple does not allow look-a-likes.
Apple wants implementations to use the real native widgets. I don't know
exactly how NeoOffice does this currently, but there might be some
shortcuts when using Java.
So, to get Cocoa widgets working in OOo, a complete Cocoa toolkit must
be implemented in VCL module of OOo. This means replacing about 70-80%
of VCL! And as written previously it will be exceptionally difficult
work. This would be a Mac-only project.
What about alternatives?
Mac could use also QT 3 or QT 4. The QT toolkit already has a Mac native
implementation (using Carbon, QuickDraw and CoreGraphics). This would
mean replacing also about 70% of VCL, a little less, because NWF already
has some bits of code that woould help. This would also be a lot of
work, because it would have to fit into the existing VCL architecture.
However, QT is more compatible with that architecture and there also
could be linux developers that could help in the process (Like Jan
Solevsky). This would be a Mac&Linux joint project.
A more far-sighted plan, would be to use XUL (+Gecko) as the alternative
architecture for VCL. This would mean replacing about 90% of VCL. But it
would give a LOT more flexible architecture for all the platforms. See:
http://ooocon-arnes.kiberpipa.org/media/XUL_Gecko_Stephan_Schaefer/video.ogg
XUL already has platform support for Windows, Linux (GTK/KDE) and Mac.
It's been used in Mozilla Firefox and is actively developed all the
time. For Mac, the XUL used to use Carbon, but the current betas use
Cocoa with Quartz (via Cairo). XUL would have to be extended to support
all the widgets of OOo, but the basic ones are already in place.
Using XUL would be a joint project with many SUN people, linux people
(GTK/KDE), localisation people etc etc. It would affect many areas, but
also it would also make OOo easier to develop for very many people.
...
So with XUL, the question is not about: "Do we use Cocoa?". It is about
1) "Do we use the existing difficult VCL architecture and try implement
it directly with Cocoa?" (not using XUL)
or
2) "Do we improve the VCL architecture by integrating XUL and then get
the benefit of existing Cocoa stuff that comes with it? The rest of the
missing pieces can be coded with Cocoa (and XUL)" (using XUL)
...
If you have read this far, thanks a lot for your patience :)
Now, some comments...
On 10/3/05, *Eric Hoch* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Mox,
Am Mon, 3 Oct 2005 22:42:13 +0300, schrieb Mox:
> On 10/3/05, eric.bachard <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> To see how well XUL w/ Gecko integrates with Mac, just download
Firefox or
> Camino to your computer from mozilla.org....
^^^^^^
Sorry here you are wrong. Camino is a Cocoa based browser using the
Gecko Engine. It's not written in XUL. From www.caminobrowser.org
<http://www.caminobrowser.org>
Sorry, my mistake. Camino and Firefox are using more and more the same
infrastructure, but as you said, Camino uses Cocoa directly. Firefox, on
the other hand, uses Cocoa via XUL.
> Plus it would make localization and menu editing a matter of
changing a
> plain text file. And you can make the change and see the results
while
> running OOo!
Right, but same for real Cocoa/Objective C. Almost everything is in
a .plist file for your language and once this file is translated a
lot of work is done.
However, with XUL, there would be no need for platform specific
translations. All the platforms could use the same plain-text
localisation files (XML files?).
There could be some platform-specific custom menu-localisations though....
> The OOo XUL might have interested parties also outside Mac
community, so it
> wouldn't be just 3 person effort. At least Stefan Schäfer and
Michael Meeks
> (Novell) have shown interest.
There will always be some interest for any kinf of developing and
porting OOo to any GUI plattform out there, that is only natural.
The point here is that even when QT and other kits are available
for OS X and are OS X native the "real native feeling" only is
Coccoa/Objective-C. We advanced users and developers can life with
QT and other GUI kits but what about the long time Mac user? He
switched to OS X and now he has an OOo that uses XUL and the
feeling of native but not really native.
Firstly, Apple has officially said, that both Carbon and Cocoa equally
good alternatives. Which one of those two you use, should be a decision
based on what you need.
Secondly, QT is quite native; it uses Carbon and Quickdraw to do it's
stuff. The newer versions also make quite much effort to align with
Apple HIG ( i.e. UI guidelines).
XUL on the other hand uses Cocoa and Quartz. So the real Cocoa Widgets
are in use. Also XUL has seen many efforts to make the Mac port align
more to Apple HIG.
It is of course harder to get a QT or XUL app to be 100% same as a pure
Cocoa app. But it is not impossible. And I think for the most people,
getting a XUL application that is 98% similar to Cocoa available at the
same as windows and linux versions would be very nice thing in deed. The
rest 2% would then be fine tuning for OOo 3.0.x versions.
When you speak about toolkits such as QT and then think that just using
Cocoa will be the solution, you forget that OOo already has a toolkit
within itself: the VCL. For Mac people, that toolkit is probably worse
than what QT would be. And if you do not use VCL at all ( i.e. replace
everything), then every new change by non-Mac developers to VCL would
have to be re-implemented by Mac developers. So basically, you would
have to re-implement big parts of VCL for Mac in every major OOo
release. And it would be a lot of work to track & fix all the changes
that go into VCL.
With XUL, the changes that non-Mac developers make into menus,
localisation and many widget changes also, would automatically work in Mac.
> Getting OOo for Mac in shape with only X11 is already a huge
task. Adding
> Cocoa or something else on top of it makes the work 10 times
harder and time
> consuming. Where are the people who have time for it?
I hope that once the real Cocoa/Objective-C port is started we get
more developers involved and more interested users wanting a native
OOo even if there is a competer out there in Neo/J.
That is a nice hope. But at least in 2003 that did not happen (the
NeoOffice/C project). I would put my hopes in a larger cooperation with
the rest of the OOo developers (i.e. XUL).
> I think it's better to stick with X11, unless there is some
solution that
> gets us more people to work with it. I think Apple will provide
X11 in the
> future as well. And at least we will have X11 through fink or
opendarwin.
Where did Eric B write that he will dismiss the X11 port any time
soon. At least the 2.0.x series will we maintain for X11 and yes
there will always be a X11 via Darwinports, fink, XDarwin.org or
whererever you get it from.
Well, Tim Bray said so, when referring to the Eric B. presentation:
http://www.tbray.org/ongoing/When/200x/2005/10/01/Open-Office-Conference#p-1
<http://www.tbray.org/ongoing/When/200x/2005/10/01/Open-Office-Conference#p-1>
I'm glad to hear that X11 is not abandoned. I think Fink et al. would
not be able to provide OOo 2.0 if the [EMAIL PROTECTED] would not have made
such a nice big effort. So relying only on fink & darwinports may not
guarantee that OOo will have a X11 version.
Anyways, anything more native than X11 will anyways be more than 2 years
effort. Although, I guess NeoOffice/J 2.0 might be (optimistically)
available by the end of spring 2006...
Thanks,
Mox
--
Mox on G
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
