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

List:       koffice-devel
Subject:    Re: Trying db-aware combo boxes in Kexi
From:       Adam Treat <treat () kde ! org>
Date:       2006-07-26 21:30:35
Message-ID: 200607261730.35892.treat () kde ! org
[Download RAW message or body]

On Wednesday 26 July 2006 5:13 pm, Jaroslaw Staniek wrote:
> Aaron J. Seigo said the following, On 2006-07-26 20:24:
> > On Wednesday 26 July 2006 3:08, Jarosław Staniek wrote:
> >>http://kexi-project.org/pics/1.1/combobox.png
> >
> > just fyi.. in kde3 there was KLanguageButton in kdeui
>
> It is a rather simple 200-line long code operating on QString/QPixmap data
> types...
>
> void KLanguageButton::insertItem( const QIconSet& icon, const QString
> &text, const QString & id, const QString &submenu, int index )
>
> ..designed for a specific purpose. Database-aware stuff is a whole library
> (koffice/kexi/widget/tableview/ and friends) supporting a dozen or so data
> types each with various display options, and so on. In 2003 the question
> was: whether building on top of KLanguageButton is beneficial. I wouldn't
> be so rude to propose dozens of virtual functions in KLanguageButton just
> to make it reusable :)
>
>  > and there's a similar
> >
> > class in datakiosk if i recall correctly. looks like we're duplicating
> > this functionality around a lot. would it make sense to make it generic
> > and push this down the stack a bit so that in future more people don't
> > reinvent this wheel? (and so we get it right once w/regards to RTL,
> > accessibility, theming, etc)
>
> I am aware of this issue. I've been talking to Adam Treat about this issue
> in 2004 or later. Th econclusion was that there would be a danger of
> overengineering. The apps are similar but DataKiosk is viewer or mostly
> read-only db schema while Kexi is highly read-write in this topic.
> Moreover, there was (and still is) no workforce for starting and
> maintaining this effort.

That might have been true at the time, but Datakiosk is very good at writing 
to the database now too.

OTOH, I don't think that Datakiosk's multi-column combo boxes would be very 
easy to port to Kexi nor would it make much sense.

The multi-column combo boxes in Datakiosk were based on KComboBox and a rather 
ugly hack around KCompletion* classes.  It works quite well, but for anything 
based on Qt4 or better, I feel this hack should be resolved and 
KComboBox/KCompletion should support multi-columns natively.  The KCompletion 
classes could stand a complete overhaul taking into account QCompletion and 
Qt4's model's.  I probably won't be the one taking on this task, however ;)  
Time is limited and I'm concentrating on KDevelop right now.

In my experience the multi-column combo boxes are often populated with 
hundreds of rows and absolutely require robust completion to be productive.

Cheers,
Adam
_______________________________________________
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]