[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:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2006-07-26 21:13:52
Message-ID: 44C7DB10.9020405 () iidea ! pl
[Download RAW message or body]

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.

What could be done is to pull some of the abstract and visual classes (like 
the combo box) up in the KDE hierarchy. For KOffice 2.0 these are going to be 
shipped in kofficelibs, for reusing in KWOrd, KSpread, etc. Sure, we can talk 
about this in Dublin. There are many more KDE4 apps that can benefit from 
rich, well-defined data types.

I recall we have similar choice to do regading to the Forms Designer framework 
(with KFormDesigner app as a test app built on top of it, in times when 
QtDesigner (v3) was poorly extendable). We choose to design and maintain 
Kexi-independent layer and only build a factories and a more 
"intelligent/functional" view on top of this. After a while the stuff was even 
embeddable in KDevelop quite well. Today... me and Cedric Paster know it was a 
huge task that wasn't profitable. Overengineering in this case. Sometimes this 
is a real danger.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en/) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org/

_______________________________________________
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]