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

List:       koffice-devel
Subject:    Re: Some thoughts
From:       Jaroslaw S <kexipl () gmail ! com>
Date:       2010-01-28 23:01:17
Message-ID: 56a746381001281501y2dbbb17bxc53e1f1fbdbba441 () mail ! gmail ! com
[Download RAW message or body]

On 28 January 2010 23:44, Thomas Zander <zander@kde.org> wrote:
> On Thursday 28. January 2010 21.59.44 Boudewijn Rempt wrote:
>> > I think it would be a huge mistake to try to factor that out from the
>> > rest of KOffice.
>>
>> You're entitled to your opinion, of course,
>
> Thanks, this is indeed all just *my* opinion, nothing more. Thanks for
> clarifying.
>
>> but I think that, especially
>>  given  the way qwidget replacements are breeding like bunnies in and
>>  around Qt, komain seems to be something that has been shown to be a
>>  liability, and that having an even more rigorous separation between ui and
>>  core could be very advantageous.
>
> I agree on the excited idea of qwidget replacements, QGraphicsview concepts
> are all quite interesting to try to apply to KOffice applications.
> The one reason KoMain is in my mind not going to be BC any time soon is
> because we want to keep innovating in that space.
>
> This is the journey we stated when we started working on KOffice2.0, new UI
> concepts that seem to work out quite well so far and apply it to all KOffice
> apps. I.e keep stuff consistent.
>
> This is my point; we should focus on one consistent approach that we apply
> koffice-wide if we want to keep the advantage of our office suite. This is why I
> say its the future.
> I'm the last that will claim I know what it will look like in 2 years, and I
> have already been playing with the idea to redo various widgets in QML or just
> GraphicsView.  This doesn't invalidate our designs, it builds on top of them.
> Evolves our designs as we drew them on paper 3 ½ years ago to fit new ideas and
> concepts. Evolving is a key word here; we can't afford to start over at this
> time.
>
> The suggestion to separate UI and core goes the other way; it makes
> applications again be different and incoherent by separating something that is
> one thing.

It is hard to say for me that generation of ODF elements and the code
for the UI/interaction is one thing.
These are rather orthogonal, existence of GUI-less libodf and friends
allow to use common code in filters and various document generators.
For now in filters, a number of elements are generated redundantly by
creating XML elements from scratch e.g. at the xml reader's/writer's
level.
The code for reuse already exists (especially in pligins and/or
libflake) but the API is bound to QPainter, which is not related to
odf processing. One could call this approach a bit monolithic.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Software Development Platform on MS Windows (http://windows.kde.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]