"Cornelius's grand plan" - Merging KDElibs into Qt
Aaron J. Seigo
aseigo at kde.org
Tue Nov 2 18:44:44 GMT 2010
On Tuesday, November 2, 2010, Cornelius Schumacher wrote:
> On Monday 01 November 2010 Aaron J. Seigo wrote:
> The idea is about maintaining the KDE libraries in a different way, merged
> with Qt.
"merged with" needs further definition, imo. does it mean:
* lives in the same git hosting system (or even repository)
* ships alongside Qt releases (meaning we sync our release schedules)
* renaming classes
* rebranding libraries (not the same as renames in code)
* other properties?
there are so many things "merged with" can mean, and each have implications
positive as well as negative to one degree or another. defining what is meant
by "merged with" will be key so that we can:
* have a discussion amongst ourselves where we are actually discussing the
same things (and not accidentally discussing different things but using the
same words for them :)
* share the idea acurately with Qt Development Frameworks to work out buy-in
(or not) from them
> So it wouldn't mean less work (well, maybe there could be some
> redundancies removed and free up some resources),
> but doing the work in a
> different way, more consistent with how it's done in Qt, more consistent
> for developers who would like to use the libraries.
similar with the term "merge with", this needs fine grain definition. what
aspects of "how it's done in Qt" would we want to adopt or adapt to?
> For example the idea to create something like QtDesktop similar to
> QtMobility is neat.
implications of this are changing the granualization of our libraries. this is
something some people (e.g. Kevin Ottens) are already working on, of course.
figuring out what would belong in a QtDesktop module would be an interesting
much of kdelibs is not desktop specific, perhaps even most of it is not. off
the top of my head things like the user interface bits in KIO, the widgets in
libkdeui and the file dialogs are probably the best candidates for "desktop"
categorization. we still have a lot of bulk left that doesn't fit that at all
well, at least not without saying, "Well, our libraries are only useful for
the desktop." this isn't true in fact, but we could still make such a
statement. personally, i hope we wouldn't.
we'd also need to define what "Desktop" means clearly, covering things such as
"where does it start and end on a spectrum of devices going from phones to
tablets to netbooks to laptops to desktops to workstations to industrial
control systems to..?" that definition will avoid us sucking things into
Desktop that are actually applicable elsewhere.
i can see the utility of having a separation of some things that only makes
sense for "mouse and pointer driven interfaces on larger screens", but in
general looking at things from a device spectrum perspective makes a lot more
sense to me. in a great world, i'd be able to use KComboBox and get something
appropriate on a phone and a desktop when it is used. i may need a different
layout for the UI it is in, but that specific widget need not be form factor
specific. for non-UI items, it is often even more clear cut that they are form
factor neutral (every platform regardless of form factor needs/wants
configuration data storage, for instance) while others are more gray (async IO
is important, does it need to be out of process?)
lots of details to fill in :)
> That would go into this direction. It of course needs
> a lot more investigation and concrete details to tell, if it makes sense.
> > imho Qt open governance is mature enough yet to realistically support
> > free
> I suppose you meant "is *not* mature enough yet".
erp, yes. it is _not_ mature enough yet.
> > handed 3rd party involvement in development. when we (KDE) would need
> > something, it would result in a lot of asking Qt Dev Frameworks for
> > permission and convincing of others. right now, that's unlikely ime, and
> > when things are improved (and i do think they will) it will be less
> > efficient than what we have now due to the increased number of entities
> > involved.
> That's a challenge for the Qt community and the people steering it. It
by joining the Qt community more directly, we would shift some of that
challenge to ourselves. iow, it becomes our problem, at least in part.
> won't be easy, but things are improving,
> participate and contribute. To what degree we in KDE want to be part of
> that, is up to us.
it is also partly up to the Qt community. if they don't want us or can't
incorporate our involvement, then that will negatively impact our desire to be
a part of it. if we wish to try this, we need to do so with not only our own
priorities well defined, but to collaborate with Qt prior to making our
decision and laying out shared goals, commitments and requirements.
> > so what exactly do people mean when talking about "merging with Qt"? not
> > broad brush strokes, but specific detailed goals.
> Yes, and I'm happy to see how many good ideas and details already have been
> produced in this thread.
> > you really can't plan the future of core assets like that.
> I don't think we can talk about a plan yet. This started as brainstorming
i agree that we don't need a concrete, detailed plan. but what we do need are
specific goals. without such goals being aggregated together, it'll be very
hard to know which way to turn. maybe you have a selection of such goals
already in your mind. :)
the kinds of goals i'm thinking of would answer questions like:
* what do we want the impact on our end users to be?
* what kind of improvements do we wish to bring our application developers?
* what kind of inconveniences are we willing and not willing to put on our
* what do we want to achieve socially?
* what do we want to achieve in terms of market share from this?
* what kind of control do we wish to retain over our source code?
* what areas of collaboration with Qt do we want to see strengthened or emerge
as a result?
* what parts of our workflow around kdelibs do we see as "required that we
maintain", "are negotiable", "don't matter one way or the other" and "are
currently negative and should be replaced"? which of those would we wish to
address in a "merge with Qt" initiative?
* how much effort and (calendar) time are we willing and able to put into
* how much and what kinds of change in kdelibs are we willing to entertain?
i'm slightly concerned that if it becomes an open ended brainstorm for too
long, we'll end up caught up in detail issues (like class naming and
namespacing discussions) without a proper framework of expectations and goals
to direct those conversations. i'm also concerned that without a survey of
where we are and what we are wanting to change from that in slightly more
concrete terms that some will not be in favor of it simply because it is full
of unknowns (which is fair) and others will be in favor of the idea without
basing that on any actual idea of what would actually be achieved, let alone
what the benefits and risks are.
i'm glad to see this conversation started and think that it could be an
excellent idea. it's also something that will be easy to get horribly,
horribly wrong without serious planning. it's also something that could be a
complete waste of time to do, though we will only know that once a more
thorough assessment is done.
there have been mumblings about doing an "Appeal 2" type meeting. it's also
been ~4 years since we got all the kdelibs people together specifically to
talk about kdelibs. given the difficulty of the above, perhaps it makes sense
to host such a meeting to come up with a clear set of goals, requirements,
etc. for this initiative. "worst case" scenario is that we would come out of
it knowing why we can't/won't do it and we'll have spent time and energy
discussing something that won't happen; even then we'll emerge with a better
understanding of what kdelibs is all about. "best case" is that we emerge with
a crystal clear plan of how to proceed in the future, perhaps targeting a Qt
i don't see this happening on a mailing list, though. it's not a great medium
for the kind of exercises that really help with these sorts of deliberations,
and not everyone that ought to be invovled is here (e.g. it might make sense
to invite Lars Knoll to join such a meeting on the last day or two so we can
pitch to him directly) ...
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel