|
Discussions: Dublin aKademy 2006
J.Staniek, S.Sauer, etc.
Macros
First, read introduction for Macros.
There are discussions planned on the topic. We hope to bring some prototypes and API as well as list our requirements, analyze what's developed by the competition. As our formats are not based on ODF (as ODF has no idea about macros), portability issues and backward compatibility has to be maintained locally too.
The target for macros is kofficelibs or kdelibs, so some discussion can be held at KOffice level. We want to allow other apps to benefit from this simplified way of programming. Macros in Kexi is a test bed for KOffice macros in general.
^ toc
Kross
During the hacking marathon, Sebastian has developed scripts dealing with ODF support using Python, generating documents. Rob Weir was impressed :)
^ toc
Kexi Main Window
The main window based on KMDI will be replaced by something better. Identify what's new in KDevelop development and Qt4. Meet Alexander Dymo, Adam Treat and others. Quanta is also in the game.
^ toc
Reporting
Kugar can be replaced sooner or later; there are engine issues already identified in Malaga.
There is also other type of reporting: based on KWord display and print engine. KWord folks can have something to tell about this. The goal is to embed relatively lightweight KWord frame with some features switched off within the Kexi forms and reports.
^ toc
KOffice-wide database support
- Database support at ODF level. How to be interoperable without introducing inconveniences for the user?
- KexiDB is coming to kofficelibs, kdelibs or kdenonbeta (needed for proper packaging and reusability)
- share database connectivity (connection information, metadata)
- share data processing facilities (e.g. queries)
- share data importing/exporting facilities (e.g. CSV, Fixed-Width Text, MDB formats)
- There are planned wrapper interfaces for typical use of KexiDB, so other apps can use them instead of flexible but complex interface. See also Facade pattern
 .
- What about Kexi Forms in KOffice documents? It's problematic. Kexi Forms have some richer features than standard ODF Controls. XForms are used in ODF. However, we can identify common areas for ODF and Kexi Forms. One of them are data sources for the forms.
- Idea (jstaniek): database storage for very efficient and random access to large KOffice documents. Probably split large content into sections (physically, one section per record) or reuse "main document" facitlities of the existing format. Locking parts of sections could be easier. Thus, make KOffice more network- and multiuser-enabled product. Versioning/backups can be also a benefit. Think about broker that maintains the multiuse access in a network. ODF is still the internal format for pieces of the document and final document can be stored back in a file.
- KexiDB could make it easier to handle the storage layer transparently. Other advantage is that the document can refer to a data sources located in the same place as the document itself.
^ toc
ODBC Support in Kexi and KDE
- Fizz (Ian Ventura-Whiting, fizz at titania.co.uk) offered to meet and talk about ODBC. He developed Qt3-based configuration tool and plans to port it to Qt4.
- Upadate (16 oct 2006, jstaniek): he meet me and we had a nice talk. His code ("Data Sources" and "ODBC statistics") is now uploaded to trunk/playground/utils/datasources/ and trunk/playground/utils/odbcstats/. He also responded: "I am currently developing the SQL query tool which I would rather upload when it is a little further along."
- Upadate (21 oct 2006, jstaniek): trunk/playground/office/sqlquery has been uploaded to the KDE SVN by Fizz. He describes it: "It is still quite basic at the moment, but is quite capable of connecting to a variety of databases using both ODBC data sources and Qt configurations. The connection window is split into three at the mo with a database browser tree on the left, a sql query edit box at the top right and the query results at the bottom right."
^ toc
Update
^ toc
See also
|
OpenDocument Developers Kit