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

List:       koffice-devel
Subject:    Re: About 2.0
From:       Alfredo Beaumont <alfredo.beaumont () gmail ! com>
Date:       2006-03-26 11:13:26
Message-ID: 200603261313.26600.alfredo.beaumont () gmail ! com
[Download RAW message or body]

Ostirala 24 Martxoa 2006 11:06(e)an, Boudewijn Rempt(e)k idatzi zuen:
> I've tried to come up with checklist & roadmap for the 2.0 development. I
> think we need to coordinate this a little more closely than before, so we
> can integrate our applications even closer. I would, for one thing, really
> like to be able to use flake objects as a kind of building blocks to build
> various types of documents. Anyway, here's my first draft. It's unfinished
> wip.
>
> KOffice 2.0
>
> Features -- Design -- Roadmap -- TODO's -- Milestones -- Discussion
>
> * Introduction
>
> I think it's necessary to do some coordinating work for KOffice 2.0,
> some mild design and even establish some tentative milestones. What I
> personally want with KOffice 2.0 is to leave the embedded OLE nineties
> and arrive at some real integration. We really need to look at all
> applications when working on our own babies.
>
> I propose putting the separate chapers of this document in separate
> pages in a wiki (frex, wiki.kde.org), so we can keep them up to date
> without having to checkout KDE's www module or messing with php.
>
> * Features
>
> Divided into Must Have, Should Have, Nice to Have, Probably Won't Have
> and Don't Care
>
> ** Must Have
>
> *** Qt4 port
>
> No idea how much time this will take, but I guess David and Laurent Montel
> can provide an estimation based on their experience with kdelibs and
> kdebase.
>
> *** Improved font handling
>
> The replacement, finally, of KoText with Scribe++. Plusplus, because we
> need hyphenation and possibly other things. Maybe we should experiment
> here, to see whether Scribe is good enough. Otherwise we could, perhaps,
> mooch Scribus' text layout engine, or Xara's.
>
> *** Common graphics object library (aka flake)
>
> Flake is designed to handle the user-handling of objects on the page. That
> means at the lowest level that flake objects correspond to frames, but
> flake objects are not bound to a rectangular frame. Flake objects can
> be subclassed to provide grouped objects, svg objects, kotext objects
> (here we need to integrate Thomas' work on non-rect. kotext frames),
> movie clips etc.
>
> Note: we need to make it possible for flake object to coordinate their
> contents with each other, so flake objects containting text can align
> their baselines, for instance.
>
> *** Canvas
>
> Flake is not a canvas; but do we need a canvas? Around the 1.3 times we
> thought we did. Is QPainter enough? We need to decide.
>
> *** Integration at object level, instead of document level
>
> Currently, embedded objects are complete documents. This means that there
> is no generic way to get a kotext frame, a couple of connected graphical
> objects or an editable bitmap into a document. For instance, for Krita,
> we'd like to mix & match Karbon and Krita layers in one document. Kivio
> needs access to KWord text frames, potentially with text flow between
> several frames. We need to design this using the flake ideas generated
> in the koffice hack weekend.
>
> *** Documents loaded in separate processes
>
> I brought this up recently. I think that the performance hit of creating
> a new process for every document, even on Windows, is not that bad,
> compared to the problem of a single crash killing all windows (and no,
> it's not realistic to assume that we'll be able to iron out every last
> crash, we've never been able to before), or the advantage of natural and
> easy separating the event loop per loaded document. I love threads as
> much as the next Java hacker, but I think they are the wrong tool for
> this problem.
>
> We would also need a small server to keep track of open and recent
> documents -- that can be something very simple using dcop or dbus and
> written in Python or Ruby -- for added stability :-).
>
> *** Integration of data and file format
>
> There is already some data exchange possible (using kspread for kword
> mailmerge), but we should make this more generic and pervasive. KSpread
> as provider for karbon object shapes or Krita pixels, for instance. Kexi
> tables as columns in KSpread.  Kivio objects that when clicked open
> KWord chapters (and KWord needs an outline view). Krita and and Karbon
> should be able to read each others file format. If KWord reads a KSpread
> file it should convert the contents to a KWord table.
>
> *** Pervasive scripting using Kross
>
> Already Isaac has started on a Kross plugin for KSpread. We really should
> push this along and integrate into KWord, KPresenter and all our other
> applications. Note: look for ways to call two applications from one
> Kross scripts. Or maybe that's already possible.
>
> *** Perfect OpenDocument support
>
> Again, this is a given. But we're on the right track: lots of work is
> already being done.  For 2.0, should we consider moving the old file
> format into separate filters?
>
> *** A common interface design
>
> We need to decide on palettes/inspectors, toolbars or toolboxes, menu
> standards and custom widgets. Peter Simonssen has a good idea for a
> usable inspector/palette type widget. We should maybe decide to use that
> in all our applications.
>
> Similar, our current template dialog is nice, but could be
> better. Templates should offer more than just a template for a complete
> document; they could have snippets and sections that the user could apply
> to a section of his document, like Apple's Pages, but with bits that
> are useful for many different kinds of content in one template. Making
> templates should also be made really easy. Documents should remember
> their template, and our recent files dialog should categorize documents
> according to their original template (and for Krita and Karbon according
> to their colorspace?).
>
> ** Should Have
>
> *** IPC interpreter plugin for Kross
>
> That way we have to define the scripting interface only once and have
> a common api for scripting and ipc. And we can get rid of the individual
> IPC definitions that are littering the individual applications and are
> never complete or coordinated.
>
> *** Macro recorder
>
> KoMacro is already in playground, but I don't know about its status.
>
> *** OpenDocument file format spec for Krita
>
> This discussion has been initiated by Cyrille in a wider setting, namely
> the Create mailing list.
>
> *** Create support KOffice-wide
>
> Any application that can do something with a gradient or a patter should
> follow the Create standard. It's an easy win and may mean much improved
> interoperability with other applications, like Scribus.
>
> *** The standard file format for KPlato I have forgotten the name of
>
> Raphael and Dag know about this: something like OpenDocument but for
> planning software.
>
>
> ** Nice to Have
>
> *** Extend KOShell to form a pasteboard as designed by Martin Pfeiffer
>
> If we manage to make really small objects that can be integrated into
> almost any KOffice document, then the pasteboard-like design by Martin
> Pfeiffer becomes a possibility. Currently, KOShell is a little anemic
> and not very compelling. We can improve on that.
>
> *** Collaborative editing
>
> This is already in Abiword and it's a feature I personally miss a lot. We
> could look at MateEdit and see how to do it in a lib so all KOffice apps
> can use it. That may mean -- I don't know -- that we need a similar command
> structure (that goes beyond kaction, typing a character in KWord or
> painting a line in Krita isn't an action) in all our applications, and that
> can only be a Good Thing.
>
> *** Versioning
>
> Version history and change management. This is again something we can start
> to share in koffice libs, and may well be related to the previous point.
>
> ** Probably Won't Have
>
> *** Server mode for all apps
>
> It's very nice and handy to be able to create documents -- whichever kind
> -- in an automated way without the gui popping up. I've seen OO being used
> for this, and WordPerfect. It may also improve our code if we can separate
> the gui and the core in such a way that the core can be run separately.
>
> ** Don't Care
>
> *** MSO file format compatibility
>
> It's controversial, but I think we shouldn't spend any effort on MSO file
> format compatibility, whether the old, binary file format, or the new
> patent encumbered xml-ish file format. If someone is panting to work on
> it, fine, but it's not something that should consume major effort. It's
> too much work, and if Apple can get away with really inferior .doc
> compatibility (worse than ours), we can, too. OpenDocument is going to
> win anyway, and as a last resort, we can script OO to do the MSO->ODF
> conversion for us without the user noticing anything.
>
> *** VBA for Kross
>
> VBA would be great, but given the resources Novell is putting into
> it it is one of those tasks we simply don't have the time to even
> contemplate. Just keying in the code needs a roomful of codemonkeys,
> and then I haven't even thought of actual design.
>
> * Design
>
> We should take the best ideas of the design competition and try to arrive
> at a uniform interface for all KOffice applications.
>
> * Application TODO's
>
> I only note the items which are not general issues for all of KOffice. We
> should make a fairly full list of todo's for our applications and then
> determine which todo's make sense in a wider setting. The current list
> has been taken from the document I circulated last year, when the funding
> thing was still on the table.
>
> ** KWord
>
> - tables - spreads
>
> ** KPresenter
>
> - multipages
>
> ** Kexi
>
> - MS Access compatibility - Reporting - KOffice integration
>
> ** Kivio
>
> - Rewrite of file format - Internal data structures need rewritten -
> OpenDocument - Style support
>
> ** Karbon
>
> - Full svg support - new canvas
> - Full set of tools to create all of svg
>
> ** Krita
>
> - paths
> - masks
>

** KFormula

- Proper font handling. The way it works now is far from optimal. IMHO we 
should look for the free font with best support for mathematical symbols and 
package it. 1.5 will include BaKoMa but AFAIK is not complete enough.
- Full ODF/MathML native support.
- Full TeX import/export support.
- Docks with organized symbols for direct inserting 'a la' kile. Something 
similar to how kivio shows its stencil sets.
- Direct formula edition, posibly through various languages: OOo, TeX, 
possibly others.
- Accesibility compliance. Fulfil Gary's report issues.

This would also known wishlist, apart from BUG #53563, which I consider out of 
scope for kformula. So if you have any other idea for kformula, I'd like to 
hear it :)

>
> * Roadmap
>
> ** Design decisions
>
> ** Priority decisions
>
> ** Qt4/KDE4 port
>
> ** Flake implementation
>
> ** Feature implementation
>
> * Milestones
>
> ** Decide on canvas/graphics backend
>
> Possibilities: libart, kcanvas, Arthur, Cairo, Xara. Of these, Arthur
> and Xara are real contenders. Xara is fast, but doesn't fit in with Qt4
> as well, and the draw library itself is not yet open source (although
> the intention is clearly there). Target date: April 1st, 2006.
>
> ** Running current trunk on Qt4/KDE4
>
> Estimation:
> Target:
>
> ** Implementation of flake
>
> Estimation:
> Target:
>
> ** Implementation of scribe-based kotext
>
> Estimation:
> Target:
>
> ** technology preview release
>
> Estimation:
> Target:
>
> Target: September
>
> Estimation:
> Target:
_______________________________________________
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]