kdelibs splitting: April iteration

[Stephen Kelly]

Kevin Ottens wrote:
>> > If anyone sees a problem with those goals for April (apart from the
>> > points I address later on in this email), please speak now!
>> 
>> I'm not sure you're progress tracking is using the right metrics and
>> working towords the right goals. You're TODO lists are aiming at finished
>> frameworks,
> 
> Well, the list of the kdelibs splitting page aims at *splitted*
> frameworks. They don't need to be completely finished (kwindowsystem is
> not for instance, there's a port to xcb going on). The checklist was
> originally focusing on splitting only (roughly buildsystem adjustement,
> source compatibility warning and enforcing policies)

I think the 'kdelibs cleanups' are the enablers for the splits, especially 
for newbies, but ok.

> , now I admit a couple
> of extra things (like Q_WS* cleanups) crept up which maybe shouldn't be
> there.
> 
>> but I rather think we should focus on the intermediate goals
>> which enable those final goals. We should focus on the horizontal struts
>> that tie otherwise unrelated code in kdelibs together (and
>> interdependencies).
> 
> That's what "kdelibs cleanups" (I don't like the name though) is intended
> for. http://community.kde.org/Frameworks/Epics/kdelibs_cleanups
> 
> That's an extra dimension, so tracked separately although of course
> there's ties between both the splits and the cleanups (just like with the
> Qt 5.x tasks, the cmake ones, etc. it's never perfectly orthogonal).

Ok.

>> I'm thinking of intermediate goals like:
> Pretty please add those tasks to the page mentionned above.

Done.

> 
>> * Look into K-classes where Q classes exist, find out why the K-class
>> exists, find out if the K-features are actually used, decide if it should
>> remain, or be renamed to something more appropriate, document that in the
>> wiki, and what changes in Qt are required, and/or make the changes. That
>> is, investigate, decide, document and do. The result of such a TODO would
>> either be documenting what should happen with a class, or doing it.
> 
> For this one, I'm pondering between either having it in the Qt 5.x pages
> or start a new epic page just for it. Early on, we had those cases in the
> Qt 5.x pages (KSaveFile was tracked there for instance). I'd say we'd need
> to produce the list of relevant K-classes first. Depending on how long it
> is, it probably makes sense to have a specific page for it. Any taker for
> producing said list?

Here's a list of K-classes which inherit a similarly named Q-class:

KApplication : public QApplication
KComboBox : public QComboBox, public KCompletionBase
KCursor : public QCursor
KDialog : public QDialog
KDialogButtonBox : public QDialogButtonBox
KDialogButtonBox : public QDialogButtonBox
KDoubleValidator : public QDoubleValidator
KIcon : public QIcon
KLibrary : public QLibrary
KLineEdit : public QLineEdit, public KCompletionBase
KListWidget : public QListWidget
KMainWindow : public QMainWindow
KMenu : public QMenu 
KMenuBar : public QMenuBar
KMenuBar : public QMenuBar
KPluginLoader : public QPluginLoader
KProcess : public QProcess
KPushButton : public QPushButton
KSplashScreen : public QSplashScreen 
KStatusBar : public QStatusBar
KSystemTrayIcon : public QSystemTrayIcon 
KTabBar: public QTabBar 
KTabWidget : public QTabWidget
KTextBrowser : public QTextBrowser
KTextEdit : public QTextEdit
KToolBar : public QToolBar
KUndoStack : public QUndoStack
KUrl : public QUrl

Here's a supplemental list of things not found by my script, but which I 
know exist:

KAction : public QWidgetAction
KDateTime
KLocale
KColorDialog
KMessageBox
KInputDialog
KFileDialog
KProgressDialog

I think it should be in an epic of its own.

>> 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).
> 
> Yes, that's exactly what happened. And that's perfectly understandable
> why, we got two nice motivated persons with no prior kdelibs experience so
> they hack and slash. That helps a lot to make progress, but that also mean
> they need help and guidance, which they didn't really get so far.
> 
> IMHO the crux of the issue here is that we lack involvement on helping new
> people getting up to speed.

Yes, the efforts are of course appreciated. I'm not sure how to be better 
about helping new people get up to speed with splits (which require 
knowledge of CMake)

> 
>> We shouldn't put items of 'splitting frameworks out' onto our TODO list,
>> but rather things I have listed in this email IMO. The problem with
>> splitting frameworks out is that it's harder than the things I have
>> listed here. People don't know how to do it, as evidenced by the commits
>> in the branches, which is of course understandable. It requires knowledge
>> of CMake, what include directories are, what exports and export macros
>> are, what linking is, etc. I think splitting (a vertical orientated task)
>> is more difficult than decoupling (a horizontal task), and so we
>> shouldn't ask newbies to do splitting. It's more frustrating and
>> mysterious than it needs to be I think.
> 
> => kdelibs cleanup page, then let's advertise it more
> 
> And I still don't think we should postpone the splitting to ensure all the
> cleanups are done. But someone working on a split should definitely look
> at what's blocking for the split dependency why, and if that matches a
> cleanup proceed with it. 

Yes. I do think cleanup tasks are easier though and more suited to newbies 
than splitting tasks though. I agree they should be advertised more. 
cleanups for newbies, and splits for people who know how to create libraries 
and dependencies in CMake etc.

> I get an overall uneasy feeling with some of the points you're making in
> this email BTW. You took the time to look into kcolorwidgets and spot the
> depencendy to kwindowsystem. Then to send an email pointing out it's
> wrong. This dependency is here for a single call. If we cumulate the time
> you took and the one I'm taking to reply it'd be fixed already.

Actually I saw commit e340a0dccf3f16641d35f7000ef33cf811a3f34d. I had no 
idea why it was needed. 

I have since looked into it and I think it's for the screen color picker. 
Someone should probably look into whether that can be done through QPA. 
Should that be a cleanup-task? I've added a generic kwindowsystem task.

> 
> Of course that doesn't rule out that you're making very good points here,
> but I'd rather see us be proactive in fixing this kind of problems when we
> see them arise than engaging in meta-discussions.

I didn't think it was very meta-discussion-like, but ok.

> 
> To summarize my point:
>  * You think we miss tracking for the K-classes? Very good point, put them
>  in
> the wiki and notify people it's there;

We have a start on the list. Now we just need to know which page it belongs 
on.

> I don't think we need a new TODO list. I think we need to improve on how
> we use the ones we currently have and make them live more actively.

Sounds good.

Thanks for driving this forward,

Steve.