On 21 April 2011 15:23, Shantanu Tushar Jha <jhahon...@gmail.com> wrote: > Hi Jaroslaw, > > On Thu, Apr 21, 2011 at 3:24 PM, Jaroslaw Staniek <stan...@kde.org> wrote: >> >> On 21 April 2011 09:35, Cyrille Berger Skott <cber...@cberger.net> wrote: >> > On Thursday 21 April 2011, Shantanu Tushar Jha wrote: >> >> Right now my code is not that modular, and I plan to do that once I >> >> understand how to properly use Calligra libs. >> >> Once that is done, we can have different UIs for different form >> >> factors. >> >> But anyway, even if we have a mobile version for now, >> >> for Active, its better than nothing. >> > Not being strictly modular now is fine :) Especially since your project >> > is >> > exploratory, and after all, the "calligra/active/lib" can start by being >> > empty >> > (or contains only koabstraction library), and then when there is more >> > common >> > code it get moves from the mobile subdirectory to the relevant library. >> >> Some notes: >> If I undestand correctly, neither 'Mobile' code for calligra is >> conceptually subset of Active nor the other way round. >> >> Where's KoAbstraction in this? >> KoAbstraction (or however it will be named) shall contain parts that >> are dependencies of some Calligra apps; apps that are willing to >> interact with other Calligra apps, e.g. Words<->Tables bridge. This is >> second purpose of KoAbstraction, I discussed with Inge in Berlin >> (let's not go too off-topic though). The first is a tool for creating >> custom office apps 'in minutes'. So KoAbstraction is part of desktop >> too. > > So to be clear, can the QML UI be built using KoAbstraction? The reason is > that I am already copying a lot of code from it, given that KoAbstraction > only helps to create QWidget based UIs (correct me if I am wrong).
Shantanu, One thing KoAbstraction does is abstracting (hmm..) typical features/actions of applications (actually document based main apps: Words, Tables, Stage). This is the 'controller' part, actually known as KoAbstractApplicationController. Example actions that you use when implementing core workflow is: concept of the current document, it's opening process (should be asynchronous), standard action like formatting (in progress now), querying support for document types, information about document (page count, current page), navigation (go to slide/page...). All this is GU Itoolkit-independent (with exceptions that we can actively fix). Another abstracted area is the GUI abstraction. This is GUI toolkit-dependent as in the case of WebKit. For now the only complete implementation of Calligra is for QWidget world so KoAbstraction is for QWidget too. I am confident that while QML GUI is developed, the abstraction can be further extended to address specific needs. In fact KoAbstraction grows out of real effort of application development, namely FreOffice, and thanks to support of FreOffice developers (and their patience!). It could be similar case with the current effort, QML GUI. So jsut don't be afraid to first have your concepts in your private code, don't be afraid of copy/pasting and templorary code _as long_ as you mark dirty areas with //! @todo marks so we can refactor dynamically. It all looks like iterative process. "Premature refactorization is a source of frustration ;)" -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
