Optionally build as a full KDE4 app at compile-time

[Former user]

Originally reported on Google Code with ID 126

Change the application in such a way that two targets can be built: simple
Qt4 and KDE4.

Adapting to KDE includes (probably among others) supporting two different: 

    translation systems
    settings storages
    about dialogs

Reported by helder.pereira.correia on 2007-12-11 23:43:16

[Former user]

``` What about another way to modularize the source code? We could create libspeedcrunch which will be shared among the front-ends, then we have speedcrunch-qt and speedcrunch-kde. For the sake of coolness, we might even have speedcrunch-plasmoid.

I'm not sure whether libspeedcrunch should be Qt-dependent or not. I guess the best would be "no", but that means a lot of code duplication between Qt and KDE front-ends. However, that opens the possibility of e.g. speedcrunch-gtk.

```

Reported by `ariya.hidayat` on 2007-12-12 08:51:58

[Former user]

``` I'd thought about separating the application logic from the GUI in order to allow GTK+/GNOME/name-your-fav-tk. But the dependency on Qt is indeed very high (not a bad thing at all, by the opposite), which turns the task very hard to accomplish and will certainly introduce bugs. Only HMath can be reused with no changes. Yet, I'm still not sure if we should #ifdef it or create separate files. ```

Reported by `helder.pereira.correia` on 2007-12-12 09:45:24

[Former user]

``` I did the port using #ifdef's as much of the interface uses the same widgets for Qt and KDE frontends, to avoid code duplication. I think that a GTK or Plasma port fits other use cases: the plasmoid won't have the same interface as the Qt frontend (even if it reuses some elements, the keypad for example, but these are actually widgets), and a GTK frontend won't use any Qt widget. On the dependency on Qt: I thought Qt4 brought the possibility to use Qt-based libraries in GTK programs by implementing e.g. the GTK event loop. Not sure about that though, I'm not very comfortable with such stuff... Anyvody know GTK experts? ```

Reported by `loic.corbasson` on 2007-12-12 10:43:09

[Former user]

``` I started a branch called 0.9-kde as I began the port using the 0.9 release. I plan finishing it before the KDE 4.0 release and then working on 0.10 (it seems that only i18n still has to be ported/shared between Qt and KDE versions, as well as some testing and documentation work). I initially changed the name as I thought that the interface may be a little different and to avoid having two programs with the same name in /usr/bin and the application menu. This is open for comment though :)

I'll start committing my changes (as atomically as possible) this afternoon, it only depends on the quality of my wireless connection. ```

Reported by `loic.corbasson` on 2007-12-12 10:54:20

[Johan Thelin]

``` I think that a split into lib and app is very natural. However, the apps could be separated using ifdefs (for KDE and Qt) - i.e. one app that can build two apps.

Regarding a GTK port - the CleanLooks theme is supposed to make that possible - even

if we don't end up with a "proper" GTK application.

As for the name change - I'm really opposed to it. Having the name SpeedCrunch for

all incarnations is really a Good Thing marketing wise. This can be resolved by the

packagers - naming the binary speedcruch-qt, speedcruch-kde, etc. to tell them apart. ```

Reported by `e8johan` on 2007-12-12 12:22:36

[Former user]

``` Yes, let's keep building one binary, one name, "speedcrunch". ```

Reported by `helder.pereira.correia` on 2007-12-12 12:54:08

[Former user]

``` Ok, I imported my code to the repository and changed the name back to speedcrunch. Comments are now welcome :)

I'll do some documentation work and play with i18n when I have time. ```

Reported by `loic.corbasson` on 2007-12-12 13:09:07

[Former user]

``` I disagree with #ifdef. I have done this in past for a pet project of mine (Qt3 vs KDE3) and things will soon become a mess. In addition, if we want to have a faithful KDE version, we should prefer KDE classes for KMenu, KDialog, etc. This is much easier to realize using two different (albeit similar) code base. ```

Reported by `ariya.hidayat` on 2007-12-12 13:38:27

[Former user]

``` This problem can never be easy. With one source, code can become a mess to read. With two, code becomes duplicate often and you must sync changes all the time... ```

Reported by `helder.pereira.correia` on 2007-12-12 13:43:39

[Former user]

``` True, but once KDE (important libraries only) becomes "ubiquitous" in both Win32 and Mac OS X, the Qt-only front-end can be deprecated and thus giving us a single code base. ```

Reported by `ariya.hidayat` on 2007-12-12 14:12:13

[Former user]

``` Do you really think we should dump the plain Qt interface when kdelibs are able to run on Windows? I'm not sure about that. It will *probably* bloat the size of the Windows binary with no need. ```

Reported by `helder.pereira.correia` on 2007-12-12 14:17:39

[Former user]

``` And even if the KDE4 interface is very fast to start, it is a little slower to start than the plain Qt one (as it loads KDE libraries in addition to Qt ones). But

that may be negligible (I'm using debug builds for KDE4 so I can't compare reliably). ```

Reported by `loic.corbasson` on 2007-12-12 14:25:27

[Former user]

``` No, I wrote only when it becomes "ubiquitous", i.e. if KDE for Win32 and Mac OS X has enough users that likely a majority of the people installs it (e.g. like Java/JRE).

And even in that case, there is no need to ship kdelibs. It is a requirement. Just like Eclipse installer doesn't ship any JRE. ```

Reported by `ariya.hidayat` on 2007-12-12 14:46:23

[Former user]

``` To build branches/0.9-kde with the KDE interface, you'll need a fresh kdelibs build

(≥ r747344). Then, do the following:

mkdir build cd build cmake -D BUILD_FOR_KDE:BOOL=true -D QT_DBUSXML2CPP_EXECUTABLE:PATH=/home/kde-devel/qt4/bin/qdbusxml2cpp ../src /usr/bin/make

The QT_DBUSXML2CPP_EXECUTABLE is because CMake, for a yet unknown reason (it's in the PATH) didn't find it on my system. This might not be required on yours.

Mail me if you need help :) ```

Reported by `loic.corbasson` on 2007-12-12 14:56:25

[Johan Thelin]

``` Ok, lets trust Ariya on the point that the Qt/KDE versions are hard to keep apart using #ifdefs. An alternate suggestions would be to use a "shared private" class to

keep the functionalities, for example "class PrivateMyDialog : public QObject" implements all slots and such. Then "class MyDialog" exists in two versions, one inheriting QDialog and one inheriting KDialog. Both contain a private "ui" member from Designer and a private "impl" member that contains all functionality and slots.

This means that the Qt/KDE parts are wrapped around a raw functionality class.

Also, if we avoid using signals and slots in the PrivateMyDialog class (and don't inherit QObject) we can probably use it with gtkmm to build a GTK version as well. ```

Reported by `e8johan` on 2007-12-13 07:47:34

[Former user]

``` Again, I'm not sure a GTK version makes sense, as Qt4 seems to make a good job on integrating in a GNOME environment (Cleanlooks theme etc). And adding a GTK frontend means maintining two frontends, syncing features between both, having bugs

in one but not another, etc. I think that if somebody really wants to work on a GTK

frontend, the most reasonable step for him would be to turn the core functions of Speedcrunch into a library, which the GTK frontend could then use. Using complicated workarounds like shared private classes is of course impressive code-wise, but I think it would have too much an impact on code readability for newcomers to the project (e.g. me a few weeks ago :)) and therefore code maintanability (because we want to be able to read what we write in a few years' time, don't we?).

On the KDE/Qt separation using #ifdefs: I think that as of today it is well maintainable and doesn't add too much bloat or complications in the way of readability. An evident benefit of #ifdefs is that we can keep the Qt and KDE versions very close to each other without too much effort, as very much code is shared between the two and the small differences are close and easily modifiable (in part thanks to a few #defines which use Qt or KDE versions of e.g. {K| Q}LineEdit depending on the build target; KDE4 being closer API-wise to Qt than KDE3 was, this is mostly easily doable). Nevertheless, I am not an expert on KDE/Qt development and I may be wrong or not seeing the flaws of my position. But then, please do prove me wrong :) ```

Reported by `loic.corbasson` on 2007-12-19 16:52:31

[Former user]

``` Unfortunately impossible for 0.10. 0.11's main focus will be this issue. ```

Reported by `helder.pereira.correia` on 2008-02-19 01:26:19 - Labels added: Priority-High, Milestone-0.11, OpSys-All - Labels removed: Priority-Medium, Milestone-0.10

[Former user]

Reported by `helder.pereira.correia` on 2008-07-17 22:52:52 - Labels removed: Priority-High, Milestone-0.11, OpSys-All

[Former user]

``` IMHO, a KDE version would bring the following advantages when used with KDE: 1) apps consistency (GUI, menus, settings storage, dialogs) 2) component reuse (translation, embedded KPart component into other apps)

It seems most work to achieve 1) is to implement standard KDE menus and functions and can benefit everybody: - icons in menus - Shortcuts config - Help menu with Handbook, What is?, Bug report, Language, translate.

The second point would benefit every KDE apps but not SpeedCrunch itself nor other non-KDE apps. Yet how great would it be to type e.g. "calc: sin(pi/3)" in Konqueror address bar and see the result history scrolling in the main Konqueror frame! As a KPart, SpeedCrunch could be easily reuse in other KDE Science and Education apps. ```

Reported by `adrien.cordonnier` on 2009-04-27 16:40:41

[Former user]

Reported by helder.pereira.correia on 2013-01-27 07:49:27 - Status changed: Rejected