kdelibs splitting: April iteration

[Stephen Kelly]

David Faure wrote:

> On Tuesday 03 April 2012 16:16:16 Stephen Kelly wrote:
>> It's a lot of moving files around, and it seems that after some files
>> were moved around, some other files were noticed as dependencies, so they
>> were then moved too. There doesn't seem to have been any questioning of
>> 'should this class even still exist anymore', with the exception of
>> porting KColorDialog away from KHBox (which I have just cherry-picked
>> into frameworks).
>> 
>> For example, KDialog was pulled in because the color dialogs use KDialog
>> presumably. I don't know if KDialog should still exist, but in a later
>> patch  KPushButton was pulled in too, presumably because KDialog uses
>> KPushButton.
>> If there is concensus on that, the code which is to be moved should
>> instead first be ported away from KPushButton before being moved to a
>> framework.
> 
> Yes, we are discovering some things as we go. I agree that it could be
> done differently, but at this point I would really like to take the
> shortest path to merging the two branches.

I decided to lead by example here and do the rebase that I talked about 
before. It's important that our history is buildable, so merging that branch 
is a bad idea. It never builds. We need to cherry-pick the working parts of 
it into the frameworks branch, which is what I've started doing.

I cherry-picked some of your cleanup commits into frameworks and then 
started cherry-picking Giorgos' commits.

Some notes:
* kdeguiaddons has the wrong name. It should be 'k' not 'kde', and the 
addons part is a 'forbidden suffix' according to the wiki (we have other 
examples of this with kcoreaddons and kdbusaddons currently though).
* When creating kdeguiaddons, I didn't move the tests (Unlike Giorgos), 
because they depend on kdeui/kwidgets and didn't build - circular 
dependency. 
* I also didn't create the kcolorwidgets framework because it doesn't 
build/depends on kdeui.
* I don't really understand why we have a kcolorwidgets framework instead of 
just kwidgets/colors. Having them split introduces several awkward 
dependencies on private headers etc (see eg kcolorspaces.h, which I had to 
export to fix the build, and the copying of kcolorhelpers).
* kdeui/colors/kcolorhelpers_p.h is copied to staging/kdeguiaddons, like 
Giorgos did.
* I'm not certain kdeguiaddons/colors is useful on it's own without also 
using the corresponding color widgets, which would indicate that those 
classes should live with the widgets. Can anyone clarify?
* Part of kwidgets is initialized by KApplication (KGlobalSettings), which 
might make anything that uses KGlobalSettings not useful without 
KApplication (lots of things depend on it, eg KIconLoader).
* I moved KPushButton to kwidgets even though I understood from the 
discussions that it should be repurposed as KAuthPushButton instead. Note 
that this brings in a dependency on kauth to kwidgets. So if you want to 
load an xdg themed icon now, you need kauth and X11 (because of 
KWindowSystem, which kdialog brings in). This is exactly counter to some of 
the goals of the frameworks effort such as avoiding having dependencies-by-
association. I presume Giorgos was simply unaware of that goal. Maybe it is 
not well enough communicated. Do we have a small page listing our goals for 
this effort (a page which does not also have a lot of other stuff on it). 
This is also why I think the cleanups are more important (and useful) than 
doing a few git mv's.
* I didn't cherry-pick the most recent moves by Giorgos because they don't 
build. Giorgos confirmed that for me. He doesn't have buildable commits as 
one of his goals, he said, because he always finds new interdpendencies when 
moving classes (after moving them and committing and pushing).
* The way things are going, we'll end up with almost everything from kdeui 
being moved to kwidgets, including all the dependencies-by-association. I 
don't think this is a useful direction.

I've put some new entries on the wiki for the todo items there.

http://community.kde.org/Frameworks/Epics/kdelibs_cleanups

> I.e. finishing kwidgets, even

What do you mean finishing? Moving all widgets from kdeui into it? It's 
probably easiest for me to just do all of it at once instead of two classes 
at a time (with commits that don't build). If that's your short term goal, 
we can just get it out of the way and work on more interesting things and 
enable further more useful work, like isolation of the dependencies-by-
association and porting away from things that should be deprecated. 

Looking at what's in kdeui still, it looks like most of it would go into 
kwidgets. kdeui contains widgets utils and dialogs, all of which have been 
moved in part to kwidgets already. 

There's also actions stuff, but if the point of kwidgets is to contain 
everything in kdelibs which depends on QtWidgets, then that belongs in 
kwidgets too. All this seems to be doing is 'move washing' (a term I made up 
modelled on the terms white washing/green washing) classes without affecting 
dependencies or modularity to a great extent. If you want to get moves like 
that done before doing the more interesting/challenging stuff, then tell me 
what should be moved and I'll get it done and out of the way.

> with "too much stuff in it", to be able to merge the kcolors branch, 

I've cherry-picked most of the useful stuff from it. I can cherry-pick the 
creation of the kcolorwidgets framework once it actually builds if it 
doesn't make more sense to just move that stuff to kwidgets/colors. I think 
things like that need to be continually evaluated.

> and
> then we can look into whether some stuff needs to be moved out of kwidgets
> again, and probably into kde4support instead, once everything else in
> kdelibs is ported away from it.

I've put some of that stuff on the wiki. Now that it's in the frameworks 
branch, we can think about what should be moved to 'tier4' (I'm thinking 
KDialog perhaps), and what should be deprecated (KHBox, maybe?).

I'd really like to get to the point where we can run ls in kwidgets and see 
if anything needs to be moved out of there now that we've got it in.

> 
> Nothing is set in stone, it's all about moving forward in the right
> direction, and at this point I think merging the efforts is more important
> than 'doing it right' and thus prolonging the separate branches.

I've at least merged most of the efforts by now, by doing it right. 
Hopefully that can continue. I don't think the separate branches will need 
to remain too much longer, but I would say that each commit that goes into 
the frameworks branch should build, and that means a change of approach 
compared to what is currently being done on the branch, which is move files 
and update CMakeLists and export in separate commits.

So, I agree, the sooner we don't have the separate branches the better.

Thanks,

Steve.