[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: About 2.0
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-03-24 10:53:14
Message-ID: 200603241153.17732.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 24 March 2006 11:43, Cyrille Berger wrote:

> I don't know if there are similar work for Office application, but the
> Tango project have some specifications for sharing the same icon in
> creative applications : http://tango-project.org/ArtLibreSet and I think
> Krita/Karbon14 should follow that specs.

Consistency withing KOffice is more important, I think -- and if the Oxygen 
project comes up with icons for KOffice 2, we should use those. I don't see 
the value in having the same icons as other art applications. It just papers 
over the differences and makes users expect the tools behind those icons to 
behave exactly the same.

> I have a desing problem with that one. But I don't know much enought about
> dbus/dcop, so maybe some IPC expert can help me to understand.
> My understanding of dbus/dcop is that the application export a few objects,
> and then you can make a call to a function related to that object. Whereas
> in kross we have one or two entry points object, and when calling some
> functions you can get new objects. So the question is, can you do something
> like that with dbus/dcop :
>
> image = Dcop/Dbus::call("Krita Kross Document getImage");
> and then manipulate the image object ?

Don't know about dbus, but if it doesn't support something that basic 
(transparent manipulation objects to proxies), then it isn't good enough. I 
mean, even Java's RMI makes that possible.

> I agree and disagree at the same time.
> Disagree: VBA for Kross is just about to have a Basic interpreter in Kross,
> and there are a lot of them on the web (for instance ariya's one :
> http://bscript.sourceforge.net/ ;) ). And then when we add a
> function/object/etc to our API, we should check how it's is called and how
> it works in VBA.
> Agree: we shouldn't target to have a 100% compatibility API

I wouldn't mind a basic interpreter. But a basic interpreter that can be 
called VBA needs all Microsoft's wierd basic extensions, and, most 
importantly, a very similar object model. VB is very different from your 
average basic :-(. (And for how long will MS support VBA? I mean, they don't 
support plain VB anymore.)

> but Xara is really fast. Isn't it possible to have an abstraction layer for
> the canvas called KoCanvas, and then you could have any backend you want ?
> I think that's what scribus is doing, and then you don't have to choose
> canvas/graphics backend.

That's possible of course. But abstraction layers are a lot of work, and the 
world is full of them. Abstraction layers generally make things slower and, 
then, doing an abstraction layer to make it possible to switch cairo and xara 
is silly, since xara intends to make their library a possible cairo backend. 
I don't know well enough how Arthur works, but since it supports so many 
backends, perhaps doing a xara backend for Arthur would be a good thing. I'll 
leave these decisions to the guru's, primarily Rob :-).

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]