> I thought the kate sort plugin made it into the code. It isn't
>in kate in R14.
When all is said and done, more often than not more is said than
done. What you see is as far as the request developed.
Would be a nice addition.
Darrell
Slavek,
kaffeine is partially fixed to deal with the new paranoia/cdda.h and
paranoia/paranoia.h header locations. The fix to kaffeine/configure.in.in seems
OK. However, without a patch to 'kaffeine/kaffeine/configure.in.in' ./configure
fails to find the new headers and fails with:
checking cdio/cdda.h usability... no
checking cdio/cdda.h presence... no
checking for cdio/cdda.h... no
-----------------------------------------
ERROR: Could not find cdparanoia headers.
-----------------------------------------
configure: error: could not find cdparanoia headers
This check in 'kaffeine/kaffeine/configure.in.in is causing the failure:
dnl --------------------
dnl check for cdparanoia
dnl --------------------
KDE_CHECK_HEADER([cdio/cdda.h], [with_cdparanoia=yes], [with_cdparanoia=no])
if test "$with_cdparanoia" != "yes" ; then
echo ""
echo "-----------------------------------------"
echo "ERROR: Could not find cdparanoia headers."
echo "-----------------------------------------"
echo ""
AC_MSG_ERROR([could not find cdparanoia headers])
fi
This must be consitnt with the new 'kaffeine/configure.in.in' check of:
KDE_CHECK_HEADER(cdio/paranoia/cdda.h, [have_libcdio_090="yes"],
[have_libcdio_090="no"])
if test "x$have_libcdio_090" = "xyes"; then
AC_DEFINE(HAVE_LIBCDIO_090, 1, [have libcdio >= 0.90])
fi
Since that check fails I have to patch configure.in.in. Next, you (or
somebody) added preprocessor checks to
kaffeine/kaffeine/src/input/disc/paranoia.h at line 35 - line 36 is MISSING a
'/' after paranoia:
extern "C"
{
#ifdef HAVE_LIBCDIO_090
#include <cdio/paranoiacdda.h>
#include <cdio/paranoia/paranoia.h>
#else // HAVE_LIBCDIO_090
#include <cdio/cdda.h>
#include <cdio/paranoia.h>
#endif // HAVE_LIBCDIO_090
}
Should be:
extern "C"
{
#ifdef HAVE_LIBCDIO_090
#include <cdio/paranoia/cdda.h>
^^^^
Further, since configure.in.in is not fixed, the preprocessor checks do not
work after I patch configure.in.in... I still get build failures:
In file included from disc.h:39:0,
from disc.cpp:42,
from libkaffeinedisc_la.all_cpp.cpp:2:
paranoia.h:39:23: fatal error: cdio/cdda.h: No such file or directory
#include <cdio/cdda.h>
I've tried fixing each of the autofoo checks and defines, but I still get:
l_cpp.Tpo -c libkaffeinedisc_la.all_cpp.cpp -fPIC -DPIC -o
.libs/libkaffeinedisc_la.all_cpp.o
In file included from disc.h:39:0,
from disc.cpp:42,
from libkaffeinedisc_la.all_cpp.cpp:2:
paranoia.h:39:23: fatal error: cdio/cdda.h: No such file or directory
#include <cdio/cdda.h>
^
compilation terminated.
I've attached the latest patch I tried. I need help fixing it :(
--
David C. Rankin, J.D.,P.E.
Darrell, Calvin, Slavek,
I thought the kate sort plugin made it into the code. It isn't in kate in R14.
I thought Calvin made a plugin for TDE for it? Anybody recall anything about it?
--
David C. Rankin, J.D.,P.E.
>Although I foresee the counterarguments that will be provided in
>this regard, I want to make the following comment.
>
>The general response of any non-English-speaking low/medium level
>user, but usually unwelcome in English-speaking dev lists, is that
>translations should be in the main package or be a one of its
>dependences or at least a "recommend" (in the Debian package
>system jargon), because non-English-speaking novices find very
>frustrating to want to install a software (p. eg. k3b or
>kaffeine), find and install the package, and find it only in
>English - however much we may seem very normal to have to look for
>a additional package xxx-i18n or xxx-l10n or xxx-i18n-es or xxx-
>l10n-es (as Spanish example).
>
>As I comment and report as many bugs, should be given much more
>importance to translations in TDE. The 1232 bug is an example of
>how the lack of translation can make a desktop environment as
>unusable for non-English-speaking users.
>
>Cheer and thanks for all
I think i18n will receive attention after R14.0.0. At that time,
please be vocal to help ensure that happens. :)
Darrell
Slavek, Darrell,
tdeutils fails when built with cmake:
[ 96%] Building CXX object
superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o
cd /build/tde-tdeutils/src/build/superkaramba/src && /usr/bin/c++
-DHAVE_CONFIG_H -march=i686 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include
tqt.h -I/opt/tqt3/include -I/usr/include/tqt -DQT_NO_ASCII_CAST
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/tde-tdeutils/src/build
-I/build/tde-tdeutils/src/build/superkaramba/src
-I/build/tde-tdeutils/src/tdeutils/superkaramba/src -I/usr/include/python3.3m
-I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -o
CMakeFiles/superkaramba.dir/meter_python.cpp.o -c
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp
In file included from
/build/tde-tdeutils/src/tdeutils/superkaramba/src/karamba.h:73:0,
from
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:17:
/build/tde-tdeutils/src/tdeutils/superkaramba/src/imagelabel.h:41:14: warning:
declaration 'class TDEIO::CopyJob' does not declare anything [enabled by default]
class TDEIO::CopyJob;
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function
'TQString PyString2TQString(PyObject*)':
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:96:33: error:
'PyString_CheckExact' was not declared in this scope
if (PyString_CheckExact(text))
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:98:41: error:
'PyString_AsString' was not declared in this scope
char* t = PyString_AsString(text);
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function
'PyObject* TQString2PyString(TQString)':
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:151:38:
error: 'PyString_FromString' was not declared in this scope
pyString = PyString_FromString("");
^
superkaramba/src/CMakeFiles/superkaramba.dir/build.make:973: recipe for target
'superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o' failed
What scope should it be declared in? When building with autotools, I do not
experience this failure.
--
David C. Rankin, J.D.,P.E.
>On my system i can use the right window key to do that.
>The very first time it seems to take a while. Can you confirm
>that? Perhaps a bug similar to the Alt+F1 one. New bug report?
I had to re-enable the keys on my laptop but the response is
immediate.
Now to find a way to replace that function without those keys. :(
Darrell
>This is a bit of a problem. Designed script uses the ability CGIT
>that can
>provide patches from GIT. If references should be local, you'd
>either have
>installed CGIT (or other web interface for git), which will
>provide patches
>from GIT, or would have to be when generating page the patches
>extracted from
>git and stored in local files => this is the problem of the
>current script,
>as mentioned by Tim.
I understand. I looked at this yesterday and realized I have no
local way to generate stand-alone captures of each patch.
Thank you for what you provided. :)
Darrell
>As I mentioned, a side effect of the processing git log in the
>proposed script
>is that each commit is on output in a single line. This would be
>possible to
>simply add the pagination.
>
>For example - adding one simple "sed" to a previously sent crazy
>command for
>listing on the console... see attached script.
Slavek,
Is there a way to change the commit links to the local repo?
The local html page looks fine but the commit links are to the
remote server rather than local.
Yes, I can cd to the affected module and look at the commit, but
having the html page link locally would be nicer.
Darrell
>I could try dusting off my very rusty Java skills one of these
>days and see if I can create a "Hello TQT World", but not tonight.
I seem to recall a collection of files in tdebindings. Perhaps they
are still there. They did not work for me, but just as likely I do
not know how to make them work. If the files do work then we need a
README for dim-lit light bulbs like me.
Primarily all we need are proof-of-concept scripts and compiled
binaries. Use c, python, perl, java, etc. to open some Trinity
dialogs or perhaps open a Trinity app and perform a basic non-
destructive task.
Darrell
>And now it builds. 3 hours wasted just to find out python wants
>flags at the end
>of the call. (You wonder why it is frustrating when things move
>around in TDE..... ;-)
I share your frustration. Been there dome that many times.
And we don't have a collection of demo scripts and C/Java programs
for packagers and developers to test the bindings related apps. We
build this bindings related stuff and have no idea whether anything
actually works.
Darrell