[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KRun kills my app
From:       Peter Buckenleib <pbu397 () compuserve ! de>
Date:       2001-06-28 15:19:49
[Download RAW message or body]

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 )
> {
> 	KUL=K;
> 	OutFileURL=O;
> 	if ( (KUL != 0) && (OutFileURL != 0) )
> 		Go->setEnabled(true);
> 	else
> 		Go->setEnabled(false);
> }

> // 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 
understand.
 
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:

class KRun
	{
	KRun();	// just initiallizes the internal data-structures 
		// but does nothing else 
	~KRun();
	
	public:
	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
	void	init();
		// 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 
		// KOpenWithHandler

	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 ).


regards,


Peter


 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]