First step into making a tde app, remove the original "admin" folder. #1

There is no content yet.

Guys, at this point, Francois's patch becomes relevant for evaluation.
https://bugattach.pearsoncomputing.net/attachment.cgi?id=2243

here is the error I get:

kpacman.cpp: In member function ‘void KpacmanApp::slotKeyBindings()’:
kpacman.cpp:448:9: error: ‘keys’ was not declared in this scope; did you mean ‘Keys’?
  448 |   Keys *keys = new Keys();
      |         ^~~~
      |         Keys
kpacman.cpp:448:20: error: expected type-specifier before ‘Keys’
  448 |   Keys *keys = new Keys();
      |                    ^~~~
kpacman.cpp:453:10: error: type ‘<type error>’ argument given to ‘delete’, expected pointer
  453 |   delete keys;
      |          ^~~~
make[2]: *** [Makefile:673: kpacman.o] Error 1

how to give this a build test:

first, add the TDE's admin folder
then

cp -Rp <path to your system's libtool.m4 file> admin/libtool.m4.in
cp -Rp <path to your system's ltmain.sh file> admin/ltmain.sh
make -f admin/Makefile.common
./configure && make

The patch from François is well simple, but I object to the part:

--- kpacman-0.3.2/kpacman/kpacman.cpp.orig	2014-09-15 23:28:49.835250363 +0200
+++ kpacman-0.3.2/kpacman/kpacman.cpp	2014-09-15 23:30:24.411651990 +0200
@@ -445,12 +445,11 @@
   slotStatusMsg(i18n("Configure key bindings..."));
   ///////////////////////////////////////////////////////////////////
   // configure key bindings
-  Keys *keys = new Keys();
+  PKeys *keys;
   if (keys->exec() == TQDialog::Accepted) {
     view->referee->initKeys();
     view->score->initKeys();
   }
-  delete keys;
 
   slotStatusMsg(i18n("Ready."));
 }

This will solve the fact that the build does not end on FTBFS, but it will cause the application to crash. After modification by François, the variable keys is defined as a pointer to the type PKeys, but it is not initialized. And immediately on the next line it is dereferenced – keys->exec() => it will cause a crash due to dereferencing the null pointer.

Therefore, I believe that there should be:

--- kpacman-0.3.2/kpacman/kpacman.cpp.orig	2014-09-15 23:28:49.835250363 +0200
+++ kpacman-0.3.2/kpacman/kpacman.cpp	2014-09-15 23:30:24.411651990 +0200
@@ -445,12 +445,12 @@
   slotStatusMsg(i18n("Configure key bindings..."));
   ///////////////////////////////////////////////////////////////////
   // configure key bindings
-  Keys *keys = new Keys();
+  PKeys *keys = new PKeys();
   if (keys->exec() == TQDialog::Accepted) {
     view->referee->initKeys();
     view->score->initKeys();
   }
   delete keys;
 
   slotStatusMsg(i18n("Ready."));
 }

Note: The obsolete name of include ntqbitarry.h is used in the referee.h file. You can replace it with tqbitarray.h during includes cleanup.

This will solve the fact that the build does not end on FTBFS, but it will cause the application to crash. After modification by François, the variable keys is defined as a pointer to the type PKeys, but it is not initialized. And immediately on the next line it is dereferenced – keys->exec() => it will cause a crash due to dereferencing the null pointer.

Exactly, that is a problem as I had pointed out to Greg through email too.

Will try to have a look tonight at why using Keys gives FTBFS. I would prefer not to rename it unless strictly necessary.

...After modification by François, the variable keys is defined as a pointer to the type PKeys, but it is not initialized...

yes, a new PKeys object should be fully constructed then attached to a pointer, It makes sense. Thanks for the clear explanation. 👍

Once tested, I'll push Francois's patch with your tweak.

Note: The obsolete name of include ntqbitarry.h is used in the referee.h file. You can replace it with tqbitarray.h during includes cleanup.

Good to know, I'll take that into account. 👍

...I would prefer not to rename it unless strictly necessary.

That's even a better outcome. 😋
To be continued...

KpacmanApp extends TDEMainWindow, which as part of its definition already defines a Keys enum value. Therefore using Keys in "KpacmanApp::slotKeyBindings()" will refer to that enum definition.
It is likely that at the time KPacman was written (Qt2), such enum was not present in TDEMainWindow.

One possible solution would be to use something like this:

::Keys *keys = new ::Keys();

but it would be easy to miss out why this is required and other people would wonder why we need such syntax.

So in the end it is preferrable to rename the Keys class to PKeys.

One possible solution would be to use something like this:
::Keys *keys = new ::Keys();
but it would be easy to miss out why this is required and other people would wonder why we need such syntax.

So in the end it is preferrable to rename the Keys class to PKeys.

Yes, I agree, renaming from too general Keys to PKeys seems like a good idea.

rem:

cleanup CMakeLists.txt
check help page (vs auto tqt/tdelibs conv scripts)
missing icons "Quit" and an other one...

cheating is part of human nature: https://mirror.git.trinitydesktop.org/gitea/TDE/kpacman/src/branch/master/kpacman/referee.cpp#L722

Hi Greg,

in commit 5debd26d you removed the ntqlist.h header file. You should have replaced it with ntqptrlist.h (and later clean up into tqptrlist.h)

Btw it builds and works great!! 😄

...you removed the ntqlist.h header file...and later clean up into tqptrlist.h

Nice, I'll add them back.

...you removed the ntqlist.h header file...and later clean up into tqptrlist.h

Nice, I'll add them back.

The main point is that those Qt2 classes that have been removed are now replaced by the equivalent "ptr" class. So instead of removing the headers, you need to convert them

@SlavekB This is It for me I believe.
I'll be leaving kpacman into your care from now on (ascii conv - translations). 👍

@SlavekB This is It for me I believe.
I'll be leaving kpacman into your care from now on (ascii conv - translations). 👍

Great work Greg!!

I finished my part of the work. There, some char* conversions seemed unnecessary. To work with map content and font, it seemed appropriate to use latin1(). Please test if the game still works and it is possible to play it.

Note: According to the warnings displayed during the build, it looks like there is still some code corresponding to KDE 2.x (deprecated).

Works like a charm!

warning: ‘static int TDEAccel::stringToKey(const TQString&)’ is deprecated

Would be good to fix this too, as well as remaning the repo and the program to tdepacman

warning: ‘static int TDEAccel::stringToKey(const TQString&)’ is deprecated

Had a quick look into this yesterday, I believe TDEShortcut(() should be used, but I have to make some testing...

...as well as remaning the repo and the program to tdepacman

ok, i''ll see about that too.

Last commit looks good in terms of functionality (show/hide toolbar) but there is a small bit to fix. The status of the toolbar is not preserved when exiting and launching the game, while before it was, so this would be a regression. I think at startup we need to read the current status and use "setStandardToolBarMenuEnabled()" with such value.

Last commit looks good in terms of functionality (show/hide toolbar) but there is a small bit to fix. The status of the toolbar is not preserved when exiting and launching the game, while before it was, so this would be a regression. I think at startup we need to read the current status and use "setStandardToolBarMenuEnabled()" with such value.

Ok, I was saying something wrong. Looks lie "setStandardToolBarMenuEnabled(false)" would not enable the menu button.

Probably need to use saveMainWindowSettings() to save the status of the toolbar and applyMainWindowSettings() to read them. Will have a look at it later if I can.

I leave kpacman "as-is", some kde2 deprecated remain but they're just warnings.

I won't rename the application into tdepacman because they is a lot of occurences (kpacman) spread everywhere (code, doc, html, config files, etc). I don't want to spend hours and hours to check everything.

I'm removing the WIP status.
Please check kpacman, once everything is fine with you, please include kpacman into the main tree.

We can do the renaming after we merge, as a separate topic. I can take care of that.