Bug#27684: KRun crash libkde QT redesign
peter.buckenleib at debitel.net
peter.buckenleib at debitel.net
Mon Jun 25 11:03:09 UTC 2001
Version: 1.4.1 (using KDE 2.1.2 )
Installed from: SuSE
Compiler: gcc version 2.95.2 19991024 (release)
OS/Compiler notes: kernel 2.4.2
As described in the documentation :
> You need to create an instance of KFileOpenWithHandler before, so that in case the mime-type of
> the file is unknown, or if there is no application associated, KRun will bring
> up the "open with" dialog. Example: KFileOpenWithHandler fowh; new KRun( url );
i´ve tried the following statements :
> // transfers all necessary information for KRun to this module
> // and ENABLES/DISABLES the GO-Kaction
> void Mailjoiner2App::slotOpenResult(KURL::List * K, KURL *O )
> if ( (KUL != 0) && (OutFileURL != 0) )
> // even declaring owh global and static does not prevent this app from crashing
> // before the selection viewer starts
> static KFileOpenWithHandler owh;
> // start the GO-KAction, using the values we´ve got
> // this should __O_N_L_Y_ callable, when both KUL and OutFileURL are valid
> // @see slotOpenResult
> void Mailjoiner2App::slotExec()
> //KFileOpenWithHandler owh;
> owh.displayOpenWithDialog ( *KUL);// when commented app= CRASH no output shown
> Runner = new KRun(*OutFileURL ,0,true, false );// app= CRASH output shown
after CRASH > }
The result is almost the same at everything i´ve tried.
1: The dialog to select the app which should be used to display the contents of OutFileURL appears.
2: i select the application to use (noatun in my case) .
3: then my own app crashes, and while i´m reading the crash-info
4: noatun comes up and works like expected.
KCrash says :
> 0x40c6e5a9 in __wait4 () from /lib/libc.so.6
> #0 0x40c6e5a9 in __wait4 () from /lib/libc.so.6
> #1 0x40cd6ad8 in __DTOR_END__ () from /lib/libc.so.6
> #2 0x404a4120 in KCrash::defaultCrashHandler ()
> from /opt/kde2/lib/libkdecore.so.3
> #3 <signal handler called>
> #4 0x4068b58b in QString::operator= () from /usr/lib/qt2//lib/libqt.so.2
> #5 0x404a8475 in KURL::operator= () from /opt/kde2/lib/libkdecore.so.3
> #6 0x400f7a89 in KRun::KRun () from /opt/kde2/lib/libksycoca.so.3
> #7 0x8053653 in Mailjoiner2App::slotExec (this=0x80b80d0)
> at mailjoiner2.cpp:467
Besides the reasons for the app-crash, there are some more things i really don´t
Why do i have to create KFileOpenWithHandler in my app, so KRun can
use it internally ?? That´s how M$ designed ODBC and that is a severe
design-bug from my point of view!!! Please please please fix this. Whatever
helper-function KRun might need, it should handle it internally !
Another topic that i consider to be a design-bug :
KRun is described like this:
>KRun ( const KURL& url, mode_t mode = 0, bool isLocalFile = false, bool showProgressInfo = true )
> Create a KRun object to run the preferred application for a file/URL. KRun will first determine
the type of the file, and will then run the associated application.
Why does the constructor of KRun start the execution of any "associated application" it considers
to be usefull??? shouldn´t this be the job of the run-commands? If execution is already started by
the constructor what can the they do to an application that´s already fired?
Should they play some kind of "catch and kill"?
Now that`s how i would preferr KRun to look like:
KRun(); // just initiallizes the internal data-structures
// but does nothing else
void set...(...); // a bunch of set...()- methods)
// to tell KRun what we already know about the app
// these knowledge could be used to do some
// preselections to KOpenWithHandler
// this starts KFileOpenWithHandler internally
// uses the values given by set...(...)- methods
// and records the users intentions on
// what application to use
// ( there are dozens of sound-players f.e.)
// what shell (sh,bash,ksh,chs,.......)
// with/without terminal
// all that can be selected or entered using the
pid_t run (.....)
// fire the selected application using all the information
// that was set, selected or entered
this would be incompatible to the existing versions, so it must get a new name.
Let`s call it KAppRunner ( if this name is not in use yet ).
(Submitted via bugs.kde.org)
(Called from KBugReport dialog. Fields OS manually changed)
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel