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

List:       koffice-devel
Subject:    Minutes of the akademy koffice meeting
From:       David Faure <faure () kde ! org>
Date:       2004-08-24 19:09:42
Message-ID: 200408242109.43085.faure () kde ! org
[Download RAW message or body]

Minutes of the KOffice meeting which happened during the akademy meeting
Ludwigsburg, 23/08/2004.

The question that was asked early during the meeting but constantly postponed and
actually discussed last was: when should be the next KOffice release :)

Before that, we discussed:
* The need for good API documentation to make KOffice easy to understand for new developers
* The work that remains to be done for complete support of the OASIS file format. In particular
  we need to keep unknown elements and attributes for saving. Keeping QDomElements would be too
  expensive, so better convert to string ready for use in koxmlwriter when saving. We discussed
  two solutions for where to store the data: in each relevant object, or more globally.
  For things which are stored in named QObjects (like KWord's framesets), we could use
  a global map, with key=classname+name and value=list_of_properties. But for the rest, we
  need to store data in the actual objects - e.g. in text paragraphs.
* The drawing of shadow in kotext needs to be redone to paint the shadow, then 
  rotate, then offset it. Otherwise the shadow direction doesn't match the one
  requested by the user. At the kpresenter level, Thorsten will look into applying
  the same principle to other kpresenter objects.
* Similarly, we could implement mirroring (horizontal and vertical mirroring). We checked
  and the OASIS file format supports it already.
* The famous WYSIWYG problem: how to make text painting fit a pre-determined width.
  Do we need outlines to solve the WYSIWYG problem? We need to talk to Lars about this.
* KPresenter should move to a master-page concept instead of "sticky objects" which
  always appear on all pages. Master pages were decided against in KWord, but in 
  page-based documents like kpresenter documents, they actually make sense. To make
  it easy to use for users, it should mostly be done the powerpoint way: editing an 
  object that is from the master page offers to go to edit the master page. The application
  then switches to displaying all master pages (in the sidebar), to edit them, and
  must offer a convenient way to go back to normal editing (e.g. with a floating toolbar).
* Thorsten asked for input on other KPresenter issues. For instance we decided on
  adding all per-object settings dialogs to the "Properties" dialog, while keeping the
  current RMB menu entries which will then simply open that dialog and activate the
  corresponding tab.
* Image filters (as provided by KImageEffect in kdelibs) should be moved to a new
  class in libkofficecore and used by KoPicture which will store the final image
  for fast painting. Moving the image-filter code will allow KWord to use it as well.
* The dialogs handling Custom Variables in KWord need to be improved. Thomas Zander
  will add jobs to the JJ page.
* "Lower object" in kpresenter needs to be improved (to immediately go under the first
  overlapping object). Not sure if KWord has the same problem (the implementation is
  very different there).
* Split views: one has to click once to make the other view active, and then click again
  to act on objects. In Konqueror this isn't necessary for some reason, which 
  is surprising since they use the same KParts PartManager event filter for this...
* Having several views on the same document is supported currently, but kotext requires
  to have the same zoom level for all views since it stores pixel information in the
  data classes (characters and paragraphs). We should ask Lars and Simon for different 
  zoom levels in different views. They said that the layout is kept only for 
  the objects currently visible on screen, which seems to imply that it's in separate
  classes, so hopefully this is possible...

And finally: what about the next release? Given that Qt4 is far from being ready,
we would like to make a koffice-1.4 release before qt4/kde4 port, which probably
means first quarter of 2005. The main goal of that release is full OASIS support
(and switching to it as the native format). In order to have something stable by
that time, big redesigns should happen in separate branches. Several people have
been talking on the list about redesigning parts of kspread, so the idea would be
that if they're not ready for release we could still release koffice-1.4 (without
the redesigned kspread).

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]