Difference between revisions of "Porting to TDE"

From Trinity Desktop Project Wiki
Jump to navigation Jump to search
m (→‎Widget styles: moved warning box)
(→‎Build system: added porting notes)
Line 5: Line 5:
 
== Build system ==
 
== Build system ==
   
  +
Trinity software uses CMake with [https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake custom macros]. Since R14.0.11 these macros are automatically installed as part of Trinity, so you don't need to worry about including them as a submodule anymore.
  +
  +
The best way to get a hang of how it all works is to take a look at how CMake is used in an existing project. For simplicity take a standalone app package as an example (e.g. [https://mirror.git.trinitydesktop.org/gitea/TDE/mathemagics/ Mathemagics]). Note the files named <tt>CMakeLists.txt</tt>, <tt>CMakeL10n.txt</tt>, <tt>ConfigureChecks.cmake</tt> and <tt>config.h.cmake</tt> and how they configure, build and link the software.
  +
  +
More specific notes can be found in other Wiki articles, depending on what you are trying to port.
   
 
== Software ==
 
== Software ==

Revision as of 17:27, 16 February 2022

Konqi.png
To-do
This section has not been written/completed yet. You can contribute to Trinity by writing or finalizing this section.

This page is intended to provide generic instructions for porting old KDE3 software to the Trinity libraries.

Build system

Trinity software uses CMake with custom macros. Since R14.0.11 these macros are automatically installed as part of Trinity, so you don't need to worry about including them as a submodule anymore.

The best way to get a hang of how it all works is to take a look at how CMake is used in an existing project. For simplicity take a standalone app package as an example (e.g. Mathemagics). Note the files named CMakeLists.txt, CMakeL10n.txt, ConfigureChecks.cmake and config.h.cmake and how they configure, build and link the software.

More specific notes can be found in other Wiki articles, depending on what you are trying to port.

Software

Porting Qt3 and KDE3 software to Trinity has mostly been automated with scripts. Before porting your first application/style/... do obtain these scripts from TGW:

$ git clone https://mirror.git.trinitydesktop.org/gitea/TDE/scripts/

Then, to port a KDE3 application you would follow the following steps:

1. Switch into the directory containing the source code.

2. Run the Qt3→TQt conversion script.

$ scripts/conversions/qt3-tqt3/convert_existing_qt3_app_to_tqt3

3. Replace all <ntq*.h> headers with <tq*.h> ones in order to use the TQt-TDE interface (simply remove the t letter). This can be done with a small script:

#!/bin/bash
for f in $(grep -Rl "<ntq[[:alnum:]]*.h>" * --include=\*.{h,c,cpp,ui});
do
    sed -Ei 's!<n(tq[[:alnum:]]*.h)>!<\1>!g' $f
done

4. Run the KDE3→TDE conversion script.

$ scripts/conversions/kde-tde/convert_existing_kde3_app_to_tde

5. Try to build. If this fails take note of the errors and fix them.

For Qt3-only apps follow steps 1 to 3.

Widget styles

Messagebox warning.png
Warning!
The TQt API docs do not currently seem to reflect the API changes described here.

The TQt Style API has undergone some important changes, so porting a widget style to TDE will entail a little more than just running scripts.

Keep the following changes in mind:

  • Most functions' definitions have changed;
  • The usage of the widget argument is deprecated in favor of specifying widget parameters via ceData and elementFlags;
  • SH_UnderlineAccelerator has been extended with a new style hint, SH_HideUnderlineAcceleratorWhenAltUp.

Porting an existing style to the new API is relatively straightforward; simply update the function definitions in the existing style with the new definition prototypes and cast the passed pointer to TQWidget or TQObject where appropriate.

Window decorations