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

List:       koffice-devel
Subject:    Re: kivio+karbon? [Grouping of applications in Koffice]
From:       Jarosław_Staniek <js () iidea ! pl>
Date:       2005-12-14 22:38:48
Message-ID: 43A09EF8.6010809 () iidea ! pl
[Download RAW message or body]

Casper Boemann said the following, On 2005-12-14 19:01:

> On Wednesday 14 December 2005 17:49, Jaroslaw Staniek wrote:
> 
>>It is not the UNIX way only if you've assumed 'drawing diagrams with
>>connector lines/putting floating text boxes/using stencil libraries'
>>feature set is _different_ from just drawing app. I believe it is not.
>>Things like UML Modelling features would bring a difference here, but we're
>>not talking about Kivio/Umbrello merge.
> 
> Not but we are talking about features like that coming into Kivio.

To clear that up: I am voiting for merging the project as development process.

>>>I think that you may not understand what kivio is about. So here is a
>>>link Peter gave on #koffice explaining what he would like kivio to be.
>>>
>>>http://www.omnigroup.com/applications/omnigraffle/
>>
>>Oh. I've already seen this.
>>To me, this is in no way UNIX paradigm in the sense you are put here. Look:
>>
>>http://www.omnigroup.com/images/newimagestemp/omnigraffle/4/screenshots/bez
>>ier.jpg
>>
>>Bezier curves in diagramming app? LOL. This is a bit like Mac Shareware
>>style (or even commercial app style) like "pack it with any features that
>>force customers to upgrade".
> 
> What kind of an argument is that: "All concrete is gray. This bird is gray. So 
> this bird must be made out of concrete"
> 
> Come on - KPresenter has bezier curves. Do you want to merge that too?

It's not clear, so I'll explain.

1. I've asked about possibility of merging most of the kivio/karbon libs to
one project so we can benefit from (probably) faster development and reusing
things not only at KOffice Parts API level. To show this possibility I
mentioned there are many graphical operations that are available in both apps 
(even if hidden behind more complex features), like connecting objects. Naming 
objects, aligning, properties, all this is also quite common, and already 
defined by ODF.

2. You've replied "you may not understand what kivio is about" and pasted the
link to Omnigraffle app.

3***). I (ironically) answered that the Omnigraffle app is exactly against 
your point because it has feature like bezier curves editing, that's pretty 
advanced one, present in both diagramming and vector drawing apps.

4. You have understood 3. as a proposal for merging all apps that support one
particular feature. This is not true. But the feature can be placed in a
separated library with a public API (not just KoParts!).
In case of kivio/karbon duet, in my imagination is that there are so many such 
common interfaces and needs, that merging the projects (in terms of 
developemnt process, releases and mainteinance) could be positive thing.

***) marked for Martin

>>Let's look at this from developer P.O.V.: develop a single set of libraries
>>and then release two apps (if you think this is really such a difference to
>>a Joe) by just hidding features in one or other app (about 5% of the
>>code?). But I really think complete merge could save a few hours. The apps
>>will no doubt still be strongly based on libraries...
> 
> I foresee more like 60% difference - not 5%.
> 
> Take a task like changing a treegraph into a list of sorts. Or diagramming 
> your computernetwork automatically. Or any number of similar tasks. Is that 
> truly something you think Karbon should do?

If we;r etalking about plans: one day Karbon's scripts maybe could do that. 
Such apps can and should be plugin-based. The rest, special cases in core code 
that differentiate Kivio from Karbon could be still ~5%.

> You are very biased in thinking that kivio is just objects with connectors. 
> Kivio will (in time) be so much more. At least that is the impression Peter 
> gave on irc, and from seeing what Vision does.

This is all nice but one word, again: plugins. Sharing the core functionality.
On my side I'd like then use, eg. polygon editor in my app, not just embedding
KoPart box.

> Just because some drawing programs have the abillity to connect objects, does 
> not mean they are flowcharting/visualizing/diagramming apps. It is just the 
> OOo and MS shitty ways of putting everything into one instead of embedding 
> the KOffice way.

It's nobody fault, but these 'shitty' apps are loaded with features that are 
not even in our TODOs. Thus we have a smaller chance to be compatible with 
OASIS specs except reading files. You may need to decide whether you want to:
a) copy these apps (to comply with OASIS for read/write to achieve loseless
write support) or
b) stay with only support for reading and then 'innovate' at your will; thus
end up with own file formats (because OASIS treats diagrams as drawing).

This is nothing new and all office apps are in such situation. Just pick the
way. I have more comfort as we've picked b) for Kexi for obvious reasons
(there's no "full" database format specs in the wild so far).

If you do not like putting everything into one bag, do you really think Kivio
will do a lot more than these apps that do so?

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

  Kexi Developer:      http://www.kexi-project.org | http://koffice.org/kexi
  Kexi Support:        http://www.kexi-project.org/support.html
  Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
  KDE3, KDE4 Libraries For Developing MS Windows Applications:
                       http://www.kdelibs.com/wiki
_______________________________________________
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]