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

List:       koffice-devel
Subject:    Re: Some thoughts
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2010-01-28 21:07:17
Message-ID: 201001282207.18221.boud () valdyas ! org
[Download RAW message or body]

On Thursday 28 January 2010, lassi.ta.nieminen@nokia.com wrote:
> Hi,
> 
> As some of you may have noticed, KOffice version,
> which contains kword, kpresenter and kspread
> was released some time ago on N900. While the process for improving
> it is still on going, I'd like to share some thoughts about the process.
> 
> KOffice offers flexible and effective framework, which made
> the task perhaps much easier than we dreamed of. This was good
> and is bound to bring more users for KOffice in time.
> 
> However, the process also had few bumps and I like to hear
> your comments to them.
> 
> - It wouldn't hurt to have more documentation and even examples
> in the main classes:)
> 
> - In the beginning the N900 UI was built separately of the KOffice source
> tree. This was quite limited approach since it seems that in order to do
> some features, such as search words inside a document, some functionality
> is occasionally needed  from headers and/or libraries which are not
> published at all for those building their UI outside the KOffice source
> tree.

I think we should start thinking of ways of exposing higher-level 
functionality, like search, moving between pages, for different top-level user 
interfaces in a more generic way. Using headers from kword or kpresenter to be 
able to do that feels bad.

> Now I'm wondering that if there will be more UIs in the future, for example
> to iPad or who knows what, they will face exactly the same issues.

There might be, though for the iPad, I doubt we could compete with a $9.99 
Pages.

> In order to ease this, would it be a terrible idea at some point to
> separate the build of all of the UIs of applications somehow from the main
> build? This could also improve the architecture of KOffice in time.

I wouldn't mind -- but that's something that, if it happens, will be far into 
the future. Right now the practical impediment is that development of apps and 
libraries goes hand in hand. That's to say, adding a feature to an app will 
often entail development in the libraries. The other way around is the same: 
churn in the libraries (whether in the form of refactoring or of 
reorganization) will cause work in the applications.
-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
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]