On Sunday 28 August 2005 11:50, Christoph Cullmann wrote:
> Hi,
> guess what we really want is this scheme I describe in the .png file.
> We want the current KDE framework for KDE apps and a interface allowing
> ISV's to integrate their apps slightly.

I guess I need to add some thoughts to make the picture move obvious ;) (had 
to left for Dirk's talk, therefor the quick short mail ;)

a) What we should aim for kdelibs for KDE 4
  - clean up the API (slightly)
  - reshape that we have some core/ui seperation like QT has now
  - improve kio,kconfig,... whatever
  - make it eaiser to port over kdelibs to other platforms while not loosing 
our functionality

b) What we should provide for ISV's:
  We should create some linking independent interface lib which allows ISV's 
to use the KDE specific features on unix and have fallbacks for windows/mac 
and the gtk+ unix case. This interface floats on top of the 
kdelibs/gtk+/win/mac API and provides some long term stable interfaces for 
example you would need to use some "mailto" dialog in any ISV app without 
linking to any specific toolkit.

c) KDE Desktop reshaping:
  - We should provide some set of apps which define the KDE Desktop, likely:

        - KWin
        - Kicker/KDesktop/Plasma (whatever it is called)
        - Filemanager + Browser (aka Konqui)
        - Konsole
        - Universal Viewer (okular or whatever)
        - Simple Editor (KWrite)

  - All other apps should be moved to some extragear like repository, where 
the authors have the choice to:

   a) release on their own schedule
   b) release with the KDE release cycles automagically

What we win?

a) With such cleaned up kdelibs we may get full ports of the KDE platform to 
Windows/Mac, be it for real usage or more for PR to have users try the KDE 
apps on this platform to make any feeling up why to switch to a OpenSource 
system.

b) Make ISV happy, they could integrate their apps well into KDE while still 
have good integration with Windows/Mac & GTK+ if needed and no linking and 
compiling dependencies on KDE which means that this even works without 
kdelibs really be ported to any other platform than Unix as the interface lib 
would only use the kde stuff on Unix as only there it makes sense to use e.g. 
the filedialog of KDE, on Windows you want the Windows dialogs.

c) We would gain some shaped thing we can actually call "THE KDE DESKTOP", 
which we atm lacks.

cu
Christoph