Data aware KDE widgets in dataKiosk

Hey, ruurd, I was going to post this as a comment, but blogger's login crap was giving me problems. Anyway, I have several data aware KDE widgets in DataKiosk I hope to introduce into KDElibs with KDE4. They include some widgets that DataKiosk shares with KDEPIM and some that are entirely new to KDE including one that mimics the MS Access Relation Combo. They are written to be generic enough to use for any QSql driver.

If you want to have a go at them before the KDE4 timeline ( or if you want to start the port early ) feel free. The widget I'd most like to see in KDELibs is the multi-column KComboBox derivative I created as a foreign key relation editor. It comes with completion courtesy of KCompletionBox, but it employs a couple of hacks to overcome deficiencies in the API that should be solved for KDE4. You could also look into making the entire DataTable class ( which is derived from QTabWidget and features custom QDataTable, QDataBrowser tabs that work with eachother ) into a standalone KDE widget if there is interest.

Here is the pic of the multi-column KComboBox derivative embedded in the DataTable widget.


Looks very interesting indeed.
Does it support column titles as well?

By John Tapsell at Sat, 05/14/2005 - 02:44

I thought column titles would look ugly and make it harder to use, but I think they could be added without too much fuss.

By Adam Treat at Sat, 05/14/2005 - 03:56

Where would you want to put your db widgets? To kdeui? Don't forget kdeui isn't dependent on QtSQL, which is separated since Qt4. My idea is to keep such things outside kdelibs, unless quite a few apps make use of your widgets.

You could also look into making the entire DataTable class .. into a standalone KDE widget if there is interest.

Somebody could call it reinventing. But the issue is not as simple.

There's advanced TableView, widget which doesn't mimic MSA -- being developed since late 2003, actually it's better than in MSA. Since february it shares data model with FormView. The same here: together with Designer, it was continouosly developed since mid 2004.

OTOH, I don't believe everyone here will be comfrotable with dropping QtSQL use in favour of more advanced framework. Basically, sometime QDataTable is better bacause it's simple. So, my proposal could be to keep both approaches (the one with using rich meta data and the one - QtSQL's handcrafting). But then: let's keep them outside of kdelibs.

Let's do not forget that in KDE there are two apporaches, certain "K*" widgets are just extensions to "Q*" widgets (most notable: QDialog), but quite often, developers, sometimes asked by users, believed in a better way of doing things, hence we have KMessageBoxes, KFontChooser, keyboard and actions handling framework and many others. I can see we have similar "two" approaches here, regarding to data-aware widgets.

BTW: This is a multicolumn combo box made (one year ago) just as a full TableView widget displayed as a popup (hence you have all sugar coming with it, like displaying pictures, and so on). (sorry, this shot only presents a single column).

By Jarosław Staniek at Sat, 05/14/2005 - 13:05

Uhm, answering your 'where' question: add kdedblibs and kdedbui? And since I'm probably the reason for this discussion, I wanted to have simple data-aware widgets like line edits that I can use in KDevelop Designer. And those simply are non-existent it seems...

By Ruurd Pels at Sat, 05/14/2005 - 15:04

I get tired of your dick arguments. I haven't reinvented a damn thing. If I were to take from something it would be Knoda, anyway. Your TableView and FormView widgets do not meet the needs of my application. Hell, Kexi and dataKiosk are not even the same type of application.

Kexi was meant to be a reinvention of MS Access, Knoda, ReKall and OpenOffice's new Base application. dataKiosk is not meant as a reinvention of MS Access or the other applications in the least. It doesn't operate anything like yours.

Besides, most of the widgets that I'm thinking of including in KDELibs would not be bound to QSql and they are already used in other applications.

BTW: I had need for a multi-column combo box with _COMPLETION_ ... before you go presenting your little asides why don't you make sure you are comparing apples to apples.

By Adam Treat at Sat, 05/14/2005 - 15:16

I wouldn't care but: how could you call my post as `dick arguments`? I've wrote "Somebody could call it reinventing. But the issue is not as simple." what means I _can_ see we have two different purposes and it's good there're are two approaches to frameworks (not _apps_!). Competition is good. The only thing I am not sure about is how and where put the (reusable) stuff for KDE devs. No doubt merging both implementations is not easy/reasonable, neither creating common 'bag' library (kdedblibs and kdedbui as ruurd propsed) with two incompatible sets of classes.

You're mentioning 'being MS Access ripoff or not' again and again, but I thought this discussion is all about data-aware wigets, where to put them, etc., not about applications and their ideas. And BTW, we may need to better sync our dictionaries: you said "these are not tied to QtSQL" -- so how could we call them "data aware"? If we can, then QLineEdit is "data aware" too...

Again, it is not attack, neither an attempt to convince you to rewrite you app :) Anyway, such clarification is always good, it forced me to update these pages (who knows, perhaps it can help somebody):

By Jarosław Staniek at Sat, 05/14/2005 - 15:54

The widgets I was proposing were mostly K widgets that are already used in other parts of KDE and the addition of the multi-column combo box with completion. The code that makes them data aware in dataKiosk is minimal as it ties very simply to QtSQL. Stuff like KDEPIM's timeedit and dateedit classes.

As it stands QtSQL is the Troll's data framework and it works very simply. I can see a need for a kde library with data aware ( for QtSQL ) KDEified widgets that take into account our completion classes and localization. If any data aware widgets are going into kdelibs they should be using the Troll's framework as it provides the most natural path from Qt's framework to KDE.

The guts of the widgets that are non data aware can and should go into kdeui IMO.

By Adam Treat at Sat, 05/14/2005 - 16:18

If any data aware widgets are going into kdelibs they should be using the Troll’s framework as it provides the most natural path from Qt’s framework to KDE.

I wish it was true... but look for example at QSA... it was the 'natural' path to reuse that in KDE but we have PyQt/PyKDE, KJSEmbed... By looking at these examples, I guess Qt-only solutions are not always adapted by KDE. OTOH, i know, as Qt improves, thinks like Qt4's rich text renderer is going to be used in KDE...

The guts of the widgets that are non data aware can and should go into kdeui IMO.


By Jarosław Staniek at Sat, 05/14/2005 - 16:38

... that we need to get support for generic data backends. using only sql is very primitive still, and not much more useful that plain QtSQL. even though it is a pain in the ass to use CDO on win32 is a very powerful concept. ideally we can implement such a thing in a more coherent manner. until we have a generic data layer than can handle SQL, LDAP, XML, or dbm, then i think we would not gain much more by adding more "data aware" widgets.

as for data kiosk, i think the concept is spot on. unlike trying to be a bad MS Access ripoff with absolutely no real thought towards the user, you have gone from a user's need and backed into an application. maybe we can expand data kiosk beyond sql, then truly it would be a killer app.

By Ian Reinhart Geiser at Sat, 05/14/2005 - 13:57

Wow. Generic backend! Let's get practical and tackle one backend that would be a nice addition to KDE to support programs that do basic data manipulation but are not intended to be more or less 'everything-including-the-kitchensink' like Kexi, Rekall or Datakiosk. No offense meant here, mind you! This whole thing started of at my astonishment that there are no standard data-aware widgets in KDE other than those inherited from Qt, all three of them. From the viewpoint of KDE - or Qt for that matter - as an application framework, that is very odd.

Anyway, I myself wanted to create an application that would benefit from such widgets very much. I have benefitted from them in other development environments very much. And after deciding to scratch my own itch, manyoso pointed me to Datakiosk as a possible springboard to create them for myself...

By Ruurd Pels at Sat, 05/14/2005 - 14:58