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

List:       kde-devel
Subject:    Re: kdenonbeta/khexedit2
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2003-09-15 18:45:56
[Download RAW message or body]

On Monday 15 September 2003 19:22, Friedrich W. H. Kossebau wrote:
> CVS commit by kossebau:
>
> CCMAIL: reinhold@kainhofer.com, kde-devel@kde.org
>
> * enrolling dynamic binding by KParts::ComponentFactory and interfaces

Hi,

is this not a little bit overkill to create interfaces for a pure widget?
I would say this will unnessesary complicate the use of the widget in
an application, makes it slower (loading of a shared library on demand needed, 
calls are routed via the interface). And suppose we have e.g. 50 widgets 
which do it the same, we enlarge kdelibs by >100 interfaces.
Besides, interfaces are used to allow multiple, user choosable 
implementations, and I doubt it a little bit in the case of your widget.

Perhaps it's better to use another strategy for somewhat complex widget 
additions. The real reason for not having the widgets in kdelibs/kdeui is the
enlargement of the shared library to be loaded by every app. Thus, including
a widget into kdeui needs it to be used in many apps of everybodys desktop.

If at first, only 1 app uses a widget, it's simple: put that widget to the 
apps sources. If a custom widget is used by >1 app, but doesn't qualify for 
kdeui, we have 2 options:
1) Duplicate sources
2) Have a static library for the widget, and link the app with it.

For sure, (1) is not desirable for consistency problems. I want to note here 
that for my TreeMap widget, I use this approach, and have the widget 
duplicated in kdeaddons/konq-plugins/fsview and kdesdk/kcachegrind. And it's
not very nice to copy changes back and forth...

I think, (2) is the way to go. If the apps using the class are in the same KDE 
package, make a package wide static library to link against (like in 
kdepim?). But if the usage is spread over KDE packages?

Proposal: Add a static library/libraries to kdelibs for classes used >1 times 
in KDE CVS, but seldomly enough to not qualify for a shared lib to be loaded 
by every KDE app. Like a "kdecomplexwidgets.a".
(Putting all complex widgets in a extra shared lib is no solution, as all apps 
needing one class would have to load the full lib).

Policy for "shared" classes:
*) 1 user in KDE CVS: put class directly to user
*) 2 users in KDE CVS: static lib if in same module, source duplication 
otherwise (as with my TreeMap widget)
*) >2 users from kdelibs/kdebase: put in shared lib in kdelibs
*) >2 users in KDE CVS otherwise: static lib in kdelibs

Static libs are only needed for compiling apps, so for distributions it would 
go with -devel. Thus, it doesn't need disc space for the regular user.
And enlarging kdelibs source distribution doesn't matter in my opinion.

Opinions?

Josef

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]