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

List:       koffice-devel
Subject:    Personal look at koffice.org pages and integration (was: Grouping
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-12-14 13:07:00
Message-ID: 43A018F4.8070007 () iidea ! pl
[Download RAW message or body]

Thomas Zander said the following, On 2005-12-14 11:16:

>>IIRC The current groups on koffice.org were chosen after long in-depth
>>thinking and discussion, looking at how users describe programs. Also
>>"Helper" is more developer's description compared to "Supporting". I
>>was asumming this work is closed now.
>>
>>Having that said, I am against further changes like above. So far
>>people I know are accustomed with Creativity/Productivity pair.
> 
> 
> Still, Kexi does not belong in the first category for reasons I posted in 
> my previous mails.
> Not to mention the lack of integration that makes it hard to explain why 
> its posted side by side with the others.

Re integration

Do you refer to that amateur who has wrote a LinuxMagazine article on KOffice 1.4?
BTW I thought it's clear: the integration is data-based. Messing KoPart-based 
kexi parts inside _any_ KOffice app is against the policy of switching to 
OASIS document formats. Do you remember, I mentioned this in Malaga. I believe 
you're not thinking about integration in "Microsoft" way. Again, I prefer UNIX 
way based on standards.
IIRC you've raised the "you can do this in using KoParts way" topic few moths 
ago and proposed no alternative to integration methods we've defined on the 
Kexi Wiki Pages.

Note that some people expect "Koffice is just one package" sort of integration 
what will never be acheived on Linux without sane packaging standards, e.g. 
Linux-wide support for subpackages. SO far only Klik is the only but temporary 
solution.

There is data import/export (CSV) as available integration. The question: why 
it's not put back in kolibs? The answer is easy: KSpread is the only 
spreadsheet I tested which does not recognize clipboard data good enough (I've 
already mentioned this on koffice-devel). My policy is not to expose unstable 
features to users by default in stable version, not mentioning pushing these 
features to kofficelibs for reuse. Do you want menu entries like "export to 
Kexi" in KWord/KSpread? Add it. Kexi API docs (and me) tell you that only ~40 
lines of (mostly copy/paste) code is required to achieve this.
I understand integration as a _weak_ integration.


Re groupping

Two other well known office suites currently have database app on its main 
list. Look at openoffice.org: "OpenOffice.org 2.0 Components" is clear.

After closer look I wonder, maybe we're defining artificial categories?
Maybe we could define grouppings that overlap in the way that a single app is 
kept in more than one group?

Maybe let's base the groupping on tasks (by using verbs)? So far on the page 
only Karbon14 and Kexi has task-based friendly description (the latter has: 
"create databases and database applications"). Other items have used terms 
like "spreadsheet" or "word processor". That would be "Write documents and 
letters", "Perform calculations" and so on.

In any way, the groupping is not mirrored in KMenu. Not mentioning that distro 
makers usually tweak the menu themselves. Maybe with KDE4 menu they will have 
no chance to change things, but for now

Web page

Our page can still look like a developers area because of such overengineering 
(is this because "generic" php functions seem to be more important than 
improving usability of the web page?).
Examples: for each app there are two links on the main page. "KDE Family" adds 
a bloat even more (with 3-rd level links like "KDE on Solaris" ).

BTW: What's a bit weird, "download" link is a _minor_ link on the page, not 
visible in my big browser window (I need to _know_ I should scroll down). 
kde.org has it better.
There's still rainbow in koshell.
I wonder where's the discussion on the design of the web page kept except 
ephemeral posts on the list? I proposed wiki pages, to keep some formal 
decissions.
Why are we pushing TaskJuggler or KPlato while we're not using the tools? 
Mature projects usually eat their own dog food.

> I doubt there was a long discussion about that, was there?

Long enough to get OK from most interested people on #koffice; due to lack of 
official document for the topic (wiki?), you may have missed or forgot about 
details or lost the plot. At least sometimes I've got this problem looking at 
long threads.

-- 
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]