Frameworks/Epics/Reduce class duplication: Difference between revisions

From KDE Community Wiki
(started)
(more)
Line 3: Line 3:
Some of the splitting for kdelibs are easily blocked by classes mentionned here. The goal of this epic, is to determine for each class what it will become. Possible solutions are:
Some of the splitting for kdelibs are easily blocked by classes mentionned here. The goal of this epic, is to determine for each class what it will become. Possible solutions are:
* go straight in hel^Wkde4support if it is obsoleted completely by a class in Qt;
* go straight in hel^Wkde4support if it is obsoleted completely by a class in Qt;
* have it's features ported to the corresponding class in Qt 5, then moved to kde4support (in which case a corresponding task has to be opened in one of the Qt 5 epics;
* have its features ported to the corresponding class in Qt 5, then moved to kde4support (in which case a corresponding task has to be opened in one of the Qt 5 epics;
* if it provides a valid feature on its own on top of Qt (real novelty, not just some addon cramed into a subclass), decide on which framework it goes to;
* if it provides a valid feature on its own on top of Qt (real novelty, not just some addon cramed into a subclass), decide on which framework it goes to;
* if it's purely about integration among KDE applications, go straight to the upcoming kde "consistency" framework (Tier 4).
* if it's purely about integration among KDE applications, go straight to the upcoming kde "consistency" framework (Tier 4).
Line 14: Line 14:
!  width=250 | Comment
!  width=250 | Comment
|-
|-
{{FeatureTodo|KApplication : public QApplication|kde4support}}
{{FeatureInProgress|KApplication : public QApplication|kde4support is the plan, but we should check for specifics}}


{{FeatureTodo|KComboBox : public QComboBox, public KCompletionBase|major features on top of Qt (completion), plus lots of small API things that should go into QComboBox (contains, ...)}}
{{FeatureInProgress|KComboBox : public QComboBox, public KCompletionBase|major features on top of Qt (completion), plus lots of small API things that should go into QComboBox (contains, ...). Final destination = a framework with the completion stuff?}}


{{FeatureTodo|KLineEdit : public QLineEdit, public KCompletionBase|major features on top of Qt (completion), plus lots of small API or behaviors that should go into QLineEdit (dropping URLs). TODO: deprecate clickMessage, by applying https://git.reviewboard.kde.org/r/101360/diff/#index_header and porting kdelibs}}
{{FeatureInProgress|KLineEdit : public QLineEdit, public KCompletionBase|major features on top of Qt (completion), plus lots of small API or behaviors that should go into QLineEdit (see Qt 5.1 merging). Final destination = a framework with the completion stuff?}}


{{FeatureTodo|KDialog : public QDialog|??}}
{{FeatureDone|KDialog : public QDialog|Mostly convenience and consistency -> tier4, after porting the rest of kdelibs away from it (except tier4 and kde4support/kde3support)}}


{{FeatureTodo|KDialogButtonBox : public QDialogButtonBox|??}}
{{FeatureDone|KDialogButtonBox : public QDialogButtonBox|Deprecate, move to kde4support, using QDialogButtonBox directly takes 2 or 3 lines of code (when using KGuiItem).}}


{{FeatureTodo|KDialogButtonBox : public QDialogButtonBox|??}}
{{FeatureDone|KDoubleValidator : public QDoubleValidator|Deprecate, move to kde4support, the merging of the locale stuff makes it obsolete.}}


{{FeatureTodo|KDoubleValidator : public QDoubleValidator|??}}
{{FeatureDone|KIcon : public QIcon|Discussed on kde-frameworks-devel, replace with one method.}}


{{FeatureTodo|KIcon : public QIcon|??}}
{{FeatureTodo|KLibrary : public QLibrary|(probably kde4support, but let's wait for final plugin framework in Qt)}}
 
{{FeatureTodo|KPluginLoader : public QPluginLoader|(probably kde4support, but let's wait for final plugin framework in Qt)}}
{{FeatureTodo|KLibrary : public QLibrary|??}}


{{FeatureTodo|KListWidget : public QListWidget|??}}
{{FeatureTodo|KListWidget : public QListWidget|??}}
Line 41: Line 40:


{{FeatureTodo|KMenuBar : public QMenuBar|??}}
{{FeatureTodo|KMenuBar : public QMenuBar|??}}
{{FeatureTodo|KPluginLoader : public QPluginLoader|??}}


{{FeatureTodo|KProcess : public QProcess|??}}
{{FeatureTodo|KProcess : public QProcess|??}}
Line 66: Line 63:
{{FeatureTodo|KUndoStack : public QUndoStack|??}}
{{FeatureTodo|KUndoStack : public QUndoStack|??}}


{{FeatureTodo|KUrl : public QUrl|??}}
{{FeatureDone|KUrl : public QUrl|Finish porting to QUrl, then move to kde4support}}


{{FeatureTodo|KAction : public QWidgetAction|??}}
{{FeatureTodo|KAction : public QWidgetAction|??}}
Line 72: Line 69:
{{FeatureTodo|KDateTime|??}}
{{FeatureTodo|KDateTime|??}}


{{FeatureTodo|KLocale|??}}
{{FeatureDone|KLocale|Already part of jlayt's plans}}


{{FeatureTodo|KColorDialog|??}}
{{FeatureTodo|KColorDialog|??}}

Revision as of 09:40, 28 April 2012

Reducing class duplication with Qt

Some of the splitting for kdelibs are easily blocked by classes mentionned here. The goal of this epic, is to determine for each class what it will become. Possible solutions are:

  • go straight in hel^Wkde4support if it is obsoleted completely by a class in Qt;
  • have its features ported to the corresponding class in Qt 5, then moved to kde4support (in which case a corresponding task has to be opened in one of the Qt 5 epics;
  • if it provides a valid feature on its own on top of Qt (real novelty, not just some addon cramed into a subclass), decide on which framework it goes to;
  • if it's purely about integration among KDE applications, go straight to the upcoming kde "consistency" framework (Tier 4).


Status Description Comment
IN PROGRESS KApplication : public QApplication kde4support is the plan, but we should check for specifics


IN PROGRESS KComboBox : public QComboBox, public KCompletionBase {{{2}}}


IN PROGRESS KLineEdit : public QLineEdit, public KCompletionBase {{{2}}}


DONE KDialog : public QDialog Mostly convenience and consistency -> tier4, after porting the rest of kdelibs away from it (except tier4 and kde4support/kde3support)


DONE KDialogButtonBox : public QDialogButtonBox Deprecate, move to kde4support, using QDialogButtonBox directly takes 2 or 3 lines of code (when using KGuiItem).


DONE KDoubleValidator : public QDoubleValidator Deprecate, move to kde4support, the merging of the locale stuff makes it obsolete.


DONE KIcon : public QIcon Discussed on kde-frameworks-devel, replace with one method.


TO DO KLibrary : public QLibrary (probably kde4support, but let's wait for final plugin framework in Qt) <{{{3}}}>
TO DO KPluginLoader : public QPluginLoader (probably kde4support, but let's wait for final plugin framework in Qt) <{{{3}}}>


TO DO KListWidget : public QListWidget ?? <{{{3}}}>


TO DO KMainWindow : public QMainWindow ?? <{{{3}}}>


TO DO KMenu : public QMenu ?? <{{{3}}}>


TO DO KMenuBar : public QMenuBar ?? <{{{3}}}>


TO DO KMenuBar : public QMenuBar ?? <{{{3}}}>


TO DO KProcess : public QProcess ?? <{{{3}}}>


TO DO KPushButton : public QPushButton ?? <{{{3}}}>


TO DO KSplashScreen : public QSplashScreen ?? <{{{3}}}>


TO DO KStatusBar : public QStatusBar ?? <{{{3}}}>


TO DO KSystemTrayIcon : public QSystemTrayIcon ?? <{{{3}}}>


TO DO KTabBar: public QTabBar ?? <{{{3}}}>


TO DO KTabWidget : public QTabWidget ?? <{{{3}}}>


TO DO KTextBrowser : public QTextBrowser ?? <{{{3}}}>


TO DO KTextEdit : public QTextEdit ?? <{{{3}}}>


TO DO KToolBar : public QToolBar ?? <{{{3}}}>


TO DO KUndoStack : public QUndoStack ?? <{{{3}}}>


DONE KUrl : public QUrl Finish porting to QUrl, then move to kde4support


TO DO KAction : public QWidgetAction ?? <{{{3}}}>


TO DO KDateTime ?? <{{{3}}}>


DONE KLocale Already part of jlayt's plans


TO DO KColorDialog ?? <{{{3}}}>


TO DO KMessageBox ?? <{{{3}}}>


TO DO KInputDialog ?? <{{{3}}}>


TO DO KFileDialog ?? <{{{3}}}>


TO DO KProgressDialog ?? <{{{3}}}>


Retrieved from "https://community.kde.org/index.php?title=Frameworks/Epics/Reduce_class_duplication&oldid=20512"