KOffice Database Application


Too many tasks before the deadline

This time I am using the blog to ask for some help.

I need someone who is able to convert HTML documentation about form desinger (one really important chapter from user's POV, about 35KB) to docbook for Kexi. Not much time left before the documentation freeze (friday evening, 8th sept).


Visual Alter Table!

What has implementation of database table schema (design) altering to do with Undo/Redo implementation for Table Designer?

In case of Kexi, everything!

Read on to learn why.


Easter Egg

There's hidden easter egg in recent Kexi SVN version.

Just create a new table design and name it "sudoku" and you'll get a nice game for free...

Thanks to ksudoku author for the code ;)


KDE to sue MS over Ribbon GUI?

Sometimes I like such challenging questions (who cares? journalists are sometimes more extreme). Let's look a bit closer at "new" MS's Riboon GUI. If you just want to know who can be sued, and by who, simply jump to the last section of this entry and save some your time.


Scripts, Macros, Bindings and 0xbaadf00d

OK, I guess I should go back from my area where I've recently worked on data/project migration improvements (more about this at bottom of this page) and spend some more hours on scripting stuff.

I think mainly about helping with moving it up to kofficelibs. Contribute with scripting design and implementation and macro bindings, making it easier adaptable for other KOffice apps, most notable Krita.

Sebastian is a chief in our scripting department, his awesome work deserves support. We all need to make KROSS fit well for relatively different apps like Kexi and Krita.

I'll tell this for myself: a main difference you need to know is that we're not fans using automatic bindings for this. User-level scripting won't work this way. Look at how SUN's UNO exposed in StarBasic - it's relatively more ugly to instantiate dozens interfaces impleemntation to get an access to, say, a spreadsheet cell or to get data loaded from a datas source.

It's not how user's world looks like. Users want one, or at most: two API layers - that's all.

They won't love APIs created by casting C/C++ APIs to Python/Javascript/Basic/whateverlanguageyoulike, 1-to-1. Audience for app level scripting is not the same as audience for PyQt/PyKDE. The task of providing must be perfomed by human being, so the effect will be more flat, not so powerfull, but easier to understand and remember API.

The resulting API that use familiar metaphores, like spreadsheet cell or data table row, and lacks many abstract classes and layers virtually nobody will want to study except me and you.

On the other hand, if your power user, "one in a million", complains she/he cannot "override a method class X", feel free to propose her/him just to use C++ (or full PyQt/PyKDE?) so she/he can implement extension in a form of plugin. Or she/he can just contribute her/his code to your app directly. The power user will be able to do so, if it's works of additional work.
In the same time, the rest (or majority) of users will be quite happy not to see bloated scripting APIs.

And finally, for the rest of users, who are not able to do scripting but want automation, we have macros
- even more simplified version of the original API, most often allowing only linear step-by-step processing (i.e. no looping and algorithms) - simple and easy to understand.


How many ways for bug hunting?

I couldn't complain about excessive number of bug reports for Kexi. Yes, writing 43252352nd text editor, drawing app or a frontend for media player can be more cool, especially if somebody's coding session is just for fun after boring day at {work|school}.


CSV, eventually

Last month I've "stolen" code from KSpread's CSV import dialog, and now it's tweaked quite much:


Nice effects

At first, as this is my first posting to kdedevelopers.org, I'd like to introduce myself.
To avoid writing the whole stuff again, please take a look at this page.