Hi, Am Freitag, 30. November 2007 14:14 schrieb Wolfram Gloger: > Hi, > > > Guess, someone has to open/learn QTdesigner now... ;) > > So it's impossible to change dvbcut GUI elements without Qtdesinger? No,... small changes can be done by editing the ui files... as we did in the past (of course it has to be done in such a way so that QTdesigner is able to read them back!).
But I'm not sure is this is possible for a new dialog-box with various different/new widget which can't be cut&pasted from the present one. > > > And normally for a given pipe command not all muxers make sense, so > > it is dangerous to let the user choose among all with a combo box (at > > least for the preset pipe commands). For instance dvdauthor only will > > work with DVD NAV-Pakets (muxer 0 and 2)... > > That is true but any sort of postprocessing should be possible > with the pipe.. Of, course ... if you supply the command with the input field method resp. the script. But I wanted to have the comands in the settings... without the need for a script. With the patch both pipe method work in parallel... > > > That would be the best solution... a file menu entry "Export to pipe" > > (like "Export video"), which opens a dialog with a file/directory > > selection field, > > You mean for the dvdauthor output (-o option)? Or for any other output file/directory needed for the pipe command... > The chosen file/directory could be embedded in the command > string using $1 (or similar), but it should be kept as general > as possible. (sorry, haven't looked at your patch in detail, > maybe that's already the case) Yes, that's the case...the %OUTPUT% placeholder. of course, that's not working for the pipe script... or any pipe command given as output file (but at least for the latter you can use %CHAPTERS%). > > No idea how to do this... does execl return the child return code? > > No. You would have to check the result from the waitpid() call. > If it's 127, then there was a fatal error (probable cause: > executable not found or not really executable). Thats why I included originally that checks before calling execl... > > > I use now system() (what exactly is the difference to exec()?) > > system() always uses the shell with all its features and baggage. > > > to check for > > the pipe command with 'which' and only proceed if the commmand is found! > > I really don't think this is necessary, but that is a question > of taste. "which" AFAIK isn't universally available. Hmmm,... then maybe it's better to just check the waitpid-return code.... > Besides, it doesn't really guarantee that execution will succeed. > The only way top find out is to try. Hmmmm,... I tried it several times. One time it didn't work, but I couldn't reproduce the error... > > > Therefore one can now again give a pipe comand without specifying the > > full path (if it's in the systems $PATH). > > That was already possible (because the execl() call used the shell, > and that in turn uses PATH). Yes, I know,... but DVBcut crashed/terminated without any message, when the script or any directly given pipe command was not found... for instance just because of a typo. But, as I already said,... if we check the return code of the pipe, we don't need the checks with 'which' or QFileinfo (that I tried to implement)... ciao ralph PS: BTW,... just gave it a quick try to compile under windows without that #ifndef switches.... seems that sys/wait.h was not found... Anyhow,... somewhere I read that pipes under windows are only implemented using temporary input/ouput files (!)... so there would be not much benefit! ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
