Backend for a Glade-app

@ngelot · 05-31-2007, 07:52 AM

I've just started with Glade, and I've buildt a simple frontend.

I would like the app to make a local folder based on user input.

I've got a simple entry-box and a button.

If the user enter ex. /home/myname/newdir in the entry-box and then click the button the mkdir command are supposed to be executed.

I belive I need some c-code, but I have never done any programming (except php and shell).

Can anyone help me getting startet? Know of any tutorial for executing shell-commands with a glade app (if possible)....

I've found a lot of tutorials for making the GUI (frontend) with glade, but I haven't found any regarding my problem....

Thanks!

@ngelot

theNbomr · 05-31-2007, 10:49 AM

Glade is both a GUI designer, and to a lesser extent, a code generator. The code generated is a basic template that you finish off by completing the functionality of the event handlers for each widget. Depending on the version of Glade, the code generated is either C or C++. It is possible, in C/C++, to invoke shell commands using the system() function. For something as simple as creating a directory, it is easier to simply use library/system functions, such as mkdir().
I realize that none of this will make much sense unless you have some knowledge of C/C++. The C/C++ code generated by Glade won't make too much sense to a C/C++ programmer either, without having learned a bit about GTK and its underpinnings, which is quite well documented on the GTK website.
--- rod.

@ngelot · 05-31-2007, 07:52 PM

I've done som work, and now I can execute a command.

This is a cutout of callbacks.c:

Code:

GtkWidget *path_entry = lookup_widget(GTK_WIDGET(button), "path_entry");
gchar *path = gtk_editable_get_chars(GTK_EDITABLE(path_entry), 0, -1);

const gchar *ProgramName="/usr/bin/gmplayer";

gchar *argv[4];

argv[0]=(gchar *) ProgramName;
argv[1]="audio.mp3";
argv[2]=0;

execv(ProgramName, argv);

I run in to two problems with this:

1. I would like gmplayer to open audio.mp3 in the path from userinput path_entry.

I've tried with:

Code:

argv[1]=((gchar *) path, "audio.mp3");

But that won't work :-)
How can I write this?

2. After execution my app is killed and only gmplayer is left...
How can I make my app to stay open? fork? clone?

@angelot

theNbomr · 05-31-2007, 10:55 PM

The filename argument to mplayer must be a full filespec, with path:

Code:

char filespec[512];  /* Naive, but for demonstation... */

strcpy( filespec, path );
strcat( filespec, "audio.mp3" );
argv[1] = filespec;

Use fork() + exec() to keep your parent process:

Code:

if( fork() ){

}
else{
    execv( Progname, argv );
}

--- rod.

EDIT:
PS. Nice work for a non C programmer.

@ngelot · 06-01-2007, 07:27 AM

Quote:

Originally Posted by theNbomr

PS. Nice work for a non C programmer.

Thanks :-) Google is fantastic....

That did the trick, and I've got this code:

Code:

void
on_start_button_clicked (GtkButton *button, gpointer user_data)
{

GtkWidget *path_entry = lookup_widget(GTK_WIDGET(button), "path_entry");
gchar *path = gtk_editable_get_chars(GTK_EDITABLE(path_entry), 0, -1);

GtkWidget *audiofile_entry = lookup_widget(GTK_WIDGET(button), "audiofile_entry");
gchar *audiofile = gtk_editable_get_chars(GTK_EDITABLE(audiofile_entry), 0, -1);

const gchar *ProgramName="/usr/bin/gmplayer";

gchar filespec[512]; 

gchar *argv[4];

strcpy( filespec, path );
strcat( filespec, "audio.mp3" );
argv[1] = filespec;

if ( vfork() )

{

}

else

{
    execv( ProgramName, argv );
}

}

1. When I launch my app from a terminal, enter path_entry and click the start_button mplayer (not gmplayer btw!) open in the same terminal window I executed my app. Then when I kill mplayer with Ctrl-C this also kills my app. I've tried both fork and vfork but it doesn't seem to matter...

2. Why can't I do this

Code:

strcat( filespec, audiofile );

instead of

Code:

strcat( filespec, "audio.mp3" );

3. Is

Code:

gchar filespec[512];

supposed to be

Code:

gchar *filespec[512];

Thanks a lot for helping me understand how tis works!

@ngelot

theNbomr · 06-01-2007, 11:02 AM

On the question of Ctrl-C killing your mplayer & its GUI parent, I think that the Ctrl-C signal gets sent to all processes whose controlling terminal (or maybe whose stdin) is that TTY. If that is correct, there are two approaches that I think should work (and I am spitballing, here). The easiest, probably, is to trap, using the signal() system call, the Ctrl-C signal, and handle it in some graceful way (probably ignoring it) in your GUI. I think an alternative, and probably a more graceful arrangement, would be to pipe() mplayer's stdin & stdout to your GUI. Then, create a button that issues a signal to the mplayer child process to kill it. You could also use this to grab mplayer's stdout, and display it in a GUI window, winning favor from your application's users, accolades from your colleagues, fame and glory (sorry, no cash; this is open source).
The exact mechanics of the first method can be mostly gleaned from the man pages for signal & kill(2). The second arrangement is a bit more complex, but for a decent description of how to use pipe()'s, I like Beej's Guide to IPC.

Code:

strcat( filespec, audiofile );

Should be perfectly valid, as long as the arguments are correctly initialized.

Code:

gchar filespec[512];

is an array of characters. Essentially, storage for a string.

Code:

gchar *filespec[512];

is an array of pointers to characters. Essentially, a bunch of pointers to one of those which is declared above. Until initialized, each of said pointers is a pointer to somewhere completely random, and dereferencing it would be likely to cause a Bad Thing.
Before calling string functions, don't forget to

Code:

#include <string.h>

GTK may have some wrapper library function that would possibly be better to use as an alternative.

--- rod.

@ngelot · 06-04-2007, 03:30 AM

Thanks for the tip - I'll look into it....

I still can't execute the file. I've switched to gedit now, and trying to open a text-file.

EDIT: I found the error:

I redused gchar *argv[4]; to gchar *argv[2]; and then nothing worked....

When pushing it up to four again - everything worked. What is it with the [] ?

My headers:

Code:

#ifdef HAVE_CONFIG_H
#  include <config.h>
#endif

#include <gnome.h>

#include "callbacks.h"
#include "interface.h"
#include "support.h"
#include "stdio.h"
#include "sys/types.h"
#include "sys/stat.h"
#include "errno.h"
#include "string.h"

Is there someone missing - do I need everyone? I've just added them on the fly beliving more is better :-)
And - is the syntax correct? I've seen both <name.h> and "name.h" in tutorials....

@ngelot · 06-04-2007, 04:23 AM

Well - I fond another error....

When running the app after make I got it working, but after exiting (with the button I made) and rerun the app it wouldn't open the file.

If I use the menu File/Quit it works everytime....

This code kills the app correctly:

Code:

gboolean on_gims_app_delete_event (GtkWidget *widget, GdkEvent *event, gpointer user_data)
{
gtk_main_quit();
return FALSE;
}

void
on_quit1_activate (GtkMenuItem *menuitem, gpointer user_data)
{
gtk_main_quit();

}

But this won't:

Code:

void
on_quit_button_clicked (GtkToolButton *toolbutton, gpointer user_data)
{
gtk_main_quit();

}

I've tried with return FALSE; in her too, but I get an error when compiling...

Do I need another gboolean for my toolbutton?

theNbomr · 06-04-2007, 10:29 AM

It looks like you need to understand what the argv[] argument is for. This is the list of arguments passed to the program. Each of the arguments, pointers to strings, should be initialized to point to strings that make some sense in the context of the program being launched. In the case of execv(), the argument list is terminated by a NULL pointer, '(char *)0'. The first element of argv[] should be a duplicate of the 'path' argument. Failing to correctly initialize the elements of your argv[] argument list will result in a Bad Thing.
To put the explanation in a different context, the argv[] array corresponds to '$1', '$2', '$3'.... in a bash script. To confirm that your arguments are being correctly configured, you could make a testbed launcher that launches a bash script, and that bash script could simply echo its commandline arguments. If the output from that looks good, then use that format for your real program launcher.
I think your last question is a symptom of the same problem.

--- rod.