Search results
Search results 1-16 of 16.
There is (a method with long long), but only in recent Qt versions. So I think the problem here is that the Qt headers being used don't match the Qt lib being used. Check the output of configure (where it looks for Qt), compare the -I paths with the -L paths to find the difference, or append -Q -v -Wl,-t to the link line to see exactly which libs it's using.
The best way is to create a KMainWindow yourself in the code, and set the QtDesigner-generated widget as the central widget of the mainwindow (see QMainWindow::setCentralWidget).
KIO::get() uses new to create the job, no problem there. It's async, so it's normal that it returns immediately, and that your get() returns early. But when the data comes it should appear there..... I'm not sure what else you do in get(), but I don't see what the problem is right now.
You need to define the slots as slots. In the .h file, put the Q_OBJECT macro at the right place, like class MyProtocol : public QObject { Q_OBJECT public: ... and later on define slots: public slots: void slotData( ... ); void slotResult( ... ); Then ensure that "moc" runs over that file (get kdevelop to regenerate the Makefiles or type "make force-reedit"), and include the .moc from the .cpp This is standard QObject/moc stuff, and is necessary in order to define slots.
I guess the problem is the rest of your get() implementation... or a setup problem (kioslave not launched at all).... You do need to debug it, e.g. adding debug output to it... To see its output, simply type "kdeinit" in a terminal, further kioslaves will be forked from there so their output will be in that terminal. If you want to use gdb, see http://webcvs.kde.org/cgi-bin/cvsweb.cgi…kup&sortby=date
I guess the application is not one you're writing yourself, but e.g. Konqueror, right? So this code is all inside the slave? In that case you have to 1) make sure you create a KApplication, not just a KInstance, in the slave (this is necessary for using other slaves, like kio_audiocd does) 2) create a QObject (I guess the code doesn't compile because "this" isn't a QObject). The simplest is probably to multiply inherit with "public QObject, public SlaveBase". 3) forward the data indeed, but don'...
I think you need kdelibs CVS HEAD.
I don't know the kdevelop GUI, but from the command line, try make -f Makefile.cvs ./configure make make install When adding/removing the Q_OBJECT macro from a .h file, type make force-reedit in that directory, to force the Makefile magic (am_edit) to re-run and notice the new files needing a .moc
kapp is a global macro defined in <kapplication.h>
proc.setUseShell(true) and use the all-in-one-string variant IIRC.
Instead of writing a whole new kioslave, how about setting the referrer metadata and using http:// ? The metadata key is simply "referrer" (see kdelibs/kio/DESIGN.metadata) It's quite difficult to reuse an existing slave's code from another one...
i18n("&Datei") surely looks ascii to me (although it doesn't really look like an English word, but that's another problem!). Are you sure about the guilty line? Isn't there one with a special character, like an umlaut or something like that? i18n() takes a UTF8 string, so if you want to put a special character (e.g. in someone's name, you have to use "recode l1..u8" to convert it to utf.
Well, which way did you try? If you modified configure.in.in, did you (or kdevelop) run Makefile.cvs again? I'm quite sure about UIC_NOT_NEEDED. It should skip the uic test (but then of course you might have trouble compiling .ui files in your project, since $(UIC) won't be set....
Set the environment variable UIC_NOT_NEEDED=1 to skip the uic check. You can also put UIC_NOT_NEEDED=1 at the top of your configure.in.in file.
uic crashes? Strange. Either it's a problem within uic itself (linked to the wrong Qt? check with "ldd $QTDIR/bin/uic") or it's the kdewidgets.so that makes it crash. Check if you have a /usr/lib/kde3/plugins/designer/kdewidgets.so or something like that. You didn't change your gcc version since you installed the distribution, right? gcc versions are incompatible; when upgrading gcc, one needs to recompile all the C++ libraries (i.e. qt and kdelibs). If you still don't see why it crashes, you mi...
Do you have kdelibs-devel installed? Did you upgrade Qt without recompiling kdelibs? (this creates a problem with the version number in libkdewidgets, so you need to recompile kdelibs after upgrading Qt). If the above doesn't help, what's the exact error message you get, and what's the relevant part of config.log?