GTK pipe
hello every1,
i'm trying to capture stdout.stderr of a child prosses while using gtk. i'v
found the following codes and i changed it a little and it works perfect:
void run_program( char *cmd)
{
gintstdin_pipe[2];
gintstdout_pipe[2];
gintstderr_pipe[2];
/* Define buffs to copy your reads from the pipes to */
gchar buffer[BUFSIZ+1];
gchar buffer_err[BUFSIZ+1];
/* Def some vars to hold your results */
gint fork_result;
gint data_processed;
gint data_processed_err;
gint nchars;
nchars=0;
/* Clear Your Buffers */
memset(buffer, '\0', sizeof(buffer));
memset(buffer_err, '\0', sizeof(buffer_err));
/* Do the fork and pipe - watch closely here */
/* Create pipes to read from and write too */
if( (pipe(stdin_pipe) == 0)
(pipe(stdout_pipe) == 0)
(pipe(stderr_pipe) == 0)
)
{
/* Perform the fork */
fork_result = fork();
/* fork attempt was not successful */
if(fork_result == -1)
{
fprintf(stderr, Fork Failure\n);
exit(EXIT_FAILURE);
}
/* We're in the child process! */
else if(fork_result == 0)
{
/* Close the Child process' STDIN */
close(0);
/* Duplicate the Child's STDIN to the stdin_pipe file descriptor
*/
dup(stdin_pipe[0]);
/* Close the read and write to for the pipe for the child. The
child will now only be able to read from it's STDIN (which is our pipe). */
close(stdin_pipe[0]);
close(stdin_pipe[1]);
/* Close the Child process' STDOUT */
close(1);
dup(stdout_pipe[1]);
close(stdout_pipe[0]);
close(stdout_pipe[1]);
/* Close the Child process' STDERR */
close(2);
dup(stderr_pipe[1]);
close(stderr_pipe[0]);
close(stderr_pipe[1]);
/* Make the system call to run the program. */
system(cmd);
/* If javac didn't take over the exec call failed. */
exit(EXIT_FAILURE);
}
/* We're in the parent process. */
else
{
/* Close STDIN for read write and close STDERR for write */
close(stdin_pipe[0]);
close(stdin_pipe[1]);
close(stderr_pipe[1]);
while(1)
{
data_processed_err=read(stderr_pipe[0],buffer_err,BUFSIZ);
if(data_processed_err == 0) break;
//addMsgInfo( buffer_err );
Msg_dialog(Error,buffer_err);
}
/* Close the read end of STDERR */
close(stderr_pipe[0]);
/* Close the write end of STDOUT */
close(stdout_pipe[1]);
while(1)
{
/* Read BUFSIZ of STDOUT data */
data_processed=read(stdout_pipe[0],buffer,BUFSIZ);
/* Break this loop when we're read all of the STDOUT data */
if(data_processed == 0) break;
/* Insert it into our gtktextbox */
addMsgInfo( buffer );
}
/* Close STDOUT for reading */
close(stdout_pipe[0]);
}
}
}
but if i call the following function (clicking that button):
void on_button1_clicked(GtkButton *button, gpointer user_data){
GtkWidget *dialog;
GtkFileFilter *filter = gtk_file_filter_new ();
GtkFileFilter *filter2 = gtk_file_filter_new ();
GtkWidget *parent = lookup_widget(GTK_WIDGET(button), win);
GtkWidget *entry = lookup_widget(GTK_WIDGET(button), entry1);
dialog = gtk_file_chooser_dialog_new (Open Image File,
parent,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_filter_set_name(filter,Iso Files);
gtk_file_filter_set_name(filter2,All Files);
gtk_file_filter_add_pattern (filter, *.iso);
gtk_file_filter_add_pattern (filter2, *.*);
gtk_file_chooser_add_filter (GTK_FILE_CHOOSER (dialog), filter);
gtk_file_chooser_add_filter (GTK_FILE_CHOOSER (dialog), filter2);
if (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT)
{
char *filename;
filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER (dialog));
gtk_entry_set_text(GTK_ENTRY(entry),filename);
g_free (filename);
}
gtk_widget_destroy (dialog);
}
befor using the first one my program chrashes. has anyone any idea? i can't
actually find any relationship bitween these two functions. but with a
little experiment i realized it crashesh if i make any dialog (filechooser
or not) in my programm.
thankx
Ammsa
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Events and derived objects
I'm using in my application a subclassed object (a subclass of HBox) that contains a TextView widget (and some other things not relevant here). What I'd like to do, with regard to key presses, is the following: 1. Almost all basic keys (letters, cursor movement, etc) should still be handled by the TextView so that it behaves normally. 2. A couple of keys would be captured by the derived object itself (notably, ENTER will have a special action), and do some internal action. 3. Everything else should be propagated so that the user of this derived widget can connect a handler to key-press-event and add special actions for even more keys. I've achieved capturing some specials keys, but letting everything else work as normally in the TextView by connecting a handler to a key-press-event of the TextView inside the derived widget's implementation, but I have'nt discovered how to propagate keys unhandled by the TextView itself or by my special handler to the user. -- Eduardo M Kalinowski [EMAIL PROTECTED] http://move.to/hpkb ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
re: SPAM LOW Re: Top Window Background
Yeah, when I use the gtk_widget_modify_bg(GTK_WIDGET(window), GTK_STATE_NORMAL, color), the background color does not change, even if I use it with all GTK_STATE_...s. Andy From: Andreas Stricker [EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 3:01 AM To: gtk-app-devel-list@gnome.org Subject: SPAM LOW Re: Top Window Background Andy Grebe wrote: I've got a callback function where I want to change the background of the entire window. I can set the color on startup using: style = gtk_widget_get_style(topWindow); style-bg[0] = c; style-bg[1] = c; style-bg[2] = c; style-bg[3] = c; style-bg[4] = c; gtk_widget_set_style(topWindow, style); but when I attempt to change the color of the background in a callback function, it doesn't work. I've also tried the modify_bg function with the same results. The right approch is indeed gtk_widget_modify_bg(): GdkColor color; gdk_color_parse(red, color); gtk_widget_modify_bg(GTK_WIDGET(window), GTK_STATE_NORMAL, color); Note that the widget must be in the right state. Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
re: Reference to a C++ object in GTK+ callbacks
Paul,
As it has been said, your function needs to have the correct format, i.e.
gboolean play_cb (GtkWidget *widget, gpointer ptr) {}
Andy
From: Paul Santa Maria [EMAIL PROTECTED]
Sent: Tuesday, December 13, 2005 7:01 PM
To: gtk-app-devel-list@gnome.org
Subject: Reference to a C++ object in GTK+ callbacks
Hi -
I'm using the GTK+ 2.6.4 that came with Suse 9.3. I'm coding in C++, but using
the raw GTK+ C
libraries.
I'm trying to pass a pointer to one of my C++ classes into a callback, so that
I can call a method
on that class. The code looks like this:
1. less hbaview.h =
--
class HbaviewApp
{
...
private:
AnimationFile *m_animation;
...
class Hbafile : public AnimationFile
{
public:
Hbafile (GtkWidget *da);
virtual ~Hbafile ();
virtual void open (const char *fname);
virtual void close ();
virtual void start ();
...
2. less HbaviewApp.cpp =
---
void init ()
...
GtkWidget *play =
gtk_image_menu_item_new_from_stock (
gtk-media-play, accel_group);
gtk_widget_show (play);
gtk_container_add (GTK_CONTAINER (menu3), play);
gtk_signal_connect (GTK_OBJECT (play), activate,
G_CALLBACK (play_cb), m_animation);
...
3. less callbacks.cpp =
--
gboolean
play_cb (gpointer data)
{
// Deference the object pointer to do the actual work
AnimationFile *ani = (AnimationFile *)data;
ani-start ();
}
ani-start() works fine outside of the callback. I know my Animation object
has been
successfully created and that m_animation points to it before I call
gtk_signal_connect().
But it crashes with a signal SIGSEGV, Segmentation fault when the play_cb
callback tries to call
ani-start().
Any idea what I might be doing wrong?
Or tips for debugging the problem?
Thanx in advance!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Events and derived objects
Eduardo M Kalinowski wrote: [...] I've achieved capturing some specials keys, but letting everything else work as normally in the TextView by connecting a handler to a key-press-event of the TextView inside the derived widget's implementation, but I have'nt discovered how to propagate keys unhandled by the TextView itself or by my special handler to the user. If the user wants to treat events that are not handled by the widget's event handler, they'll have to use g_signal_connect_after (or the appropriate flag), otherwise the handler will be called before the default widget's handler. So the normal chain would be: my_ojbect_key_press (connected to textview delagate's key-press-event) key_press_cb(connected by the user using g_signal_connect) textview_key_press (base class handler) after_key_press_cb (connected by the user using g_signal_connect_after) And ofcourse, the first handler to return TRUE effectively stops the emission. Another approach would be to derive an object from GtkTextView, override the base class handler for class-key_press_event and from your key_press_event; decide if you want to: return GTK_WIDGET_CLASS (parent_class)-key_press_event (widget, event); Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2005 11:19 AM, Stephen Pollei wrote:
On 12/13/05, Daryl Lee [EMAIL PROTECTED] wrote:
Are you sure that is the right style for that callback?
static void
rocket_cb(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
class city_node *city=static_castclass city_node *(data);
global_game.rocket_up(*city);
city-update_targets();
each_tick(NULL);
}
C++ functions do, indeed, have to be static to be used as GTK+
callbacks.
Untrue I just removed the static keyword from 8 of my callbacks and
then recompiled, worked just fine. As Andy Grebe of apogeelabs said
... function needs to have the correct format.
That I bet was the problem. That I label a lot of my callbacks with
static, I just consider good style.
diff -u1 gtk_main.cc-save gtk_main.cc static-out.diff
The only c++ problem I can see is if you had overloaded functions; I
can't think of how you'd select which one you meant.
IIRC, I believe the functions only have to be static in this case if
they're actually C++ class methods. Plain old C global functions don't
need to be static, though if they're only used in that one module,
there's no reason *not* to make them static, and it's good practice to
do so.
-brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDoHJ16XyW6VEeAnsRAiaqAJ0fCFNpf1k/+OSTqtxHUpDdKuD6QACfSkJT
3iqrkpsHfNp4+XzAnyLq+so=
=BnXm
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
Well, thanks for the correction. I will have to go back through my projects to understand why I thought that. On Wed, 2005-12-14 at 11:19 -0800, Stephen Pollei wrote: On 12/13/05, Daryl Lee [EMAIL PROTECTED] wrote: ... C++ functions do, indeed, have to be static to be used as GTK+ callbacks. Untrue I just removed the static keyword from 8 of my callbacks and then recompiled, worked just fine. ... -- Daryl Lee Open the Present--It's a Gift. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
On 12/14/05, Gnaural [EMAIL PROTECTED] wrote: Does anyone here know why the GTK+ windows apps would give-up before even getting to either my main() (or WinMain())? If a library (dll) that your executable is linked against is not found, the executable cannot be run. You're trying to specify the library path after it has already tried to load the library. The way that gaim's loader works is that the initial executable is a small application that is linked only with System Libraries - it then sets up the appropriate path and dynamically loads a (gtk+ dependent) dll containing the bulk of the application. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
On Wed, 2005-12-14 at 11:28 -0800, Brian J. Tarricone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... IIRC, I believe the functions only have to be static in this case if they're actually C++ class methods. Plain old C global functions don't need to be static, though if they're only used in that one module, there's no reason *not* to make them static, and it's good practice to do so. True. the static keyword is 'overloaded' with a different meaning - it doesn't change scope, but indicates that the function is one that doesn't have an associated object. // Wally ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
On Wednesday 14 December 2005 20:38, Wallace Owen wrote:
[snip]
Warning!
It may work for you. It's not portable. C++ implementations are free
to use a calling convention different from the C calling convention: In
C, parameters are pushed in reverse order to support varargs. C++
functions are specified in the standard as not supporting varargs so
that compiler vendors are free to use certain optimizations. For
example, in C, it's the caller's responsibility to clean up the stack
after a call because the called function can't know at compile time how
many parms were passed. C++ compilers are free to optimize this such
that the called function does the stack cleanup, so that a function
that's called from many different places only has one stack cleanup
chunk generated.
It's for this reason that a static function should be used to catch
callbacks, so it can cast the parameter to a pointer to the object, then
invoke the member function. Static member functions don't have an
implied first parm that's it's object. See below:
class Foo
{
public:
static redrawCB(Event *event, void *parm)
{
Foo *obj = reinterpret_castFoo*(parm);
obj-redraw(event);
}
redraw(Event *event)
{
...
}
};
Your version isn't portable either. GTK+ callbacks required C linkage, so to
be portable your code should provide C linkage, and static member functions
cannot have C linkage. This means that to be portable the callback has to be
declared extern C in file scope (and if it needs access to the class's
internals, needs to be declared a friend in the class definition).
Paragraph 7.5.1 of the standard says this:
All function types, function names, and variable names have a language
linkage. The default language linkage of all function types, function names,
and variable names is C++ language linkage. Two function types with
different language linkages are distinct types even if they are otherwise
identical.
Static member functions happen to work with g++. They may not work with other
compilers.
Chris
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
activeX embedding
Does anyone know if it is possible to embed an activeX control in a GTK+ app? In particular the mozilla control or if I get desperate enough the IE one? For win32 so gtkmozembed is out although I'll probably use that when I port to linux. Thanks guys. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ for Windows: issues with apps locating the dll's
Gnaural writes: One glitch, though. I'm finding that my GTK+ apps don't automaticaly find the installed GTK+ dll's in Windows. The lazy solution was just to set the system PATH variable to point to the GTK+ bin directory. But I've been informed that this is bad practice, because of (among other things) something called dll hell. Umm, dunno. I would say that setting PATH to include the bin folder of the GTK+ installation you want to use is quite straightforward. It's when users start copying DLLs here and there and then forgetting where they are, and messing with PATH so that they don't know what copies of the DLLs they really are using that you get DLL hell. You could always write a minimal (a dozen of lines) helper exe that sets the PATH environment variable and then invokes you real application. Does anyone here know why the GTK+ windows apps would give-up before even getting to either my main() (or WinMain())? Well, if the exe requires on DLLs that aren't found, it will never get to main() (or WinMain()). The DLLs that an exe links to are loaded by the system before the program starts executing user code. And is there another, more straightforward way people are accomplishing this (besides either setting the system PATH or using some very fudgy-looking platform-dependent registry code to find the dll's)? You could keep your application's exe in the same bin folder where the GTK+ (Pango, atk, GLib etc) DLLs are. Then they will be found without any PATH manipulation. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reference to a C++ object in GTK+ callbacks
Thank you on all counts!
The main problem was my callback (duh! I forgot the GtkWidget *w argument!);
I also changed all
my gtk_signal_connect() calls to g_signal_connect(), and all my
gtk_signal_connect_object()
to g_signal_connect_swapped().
It works fine now - thanx again!
--- Stephen Pollei [EMAIL PROTECTED] wrote:
On 12/13/05, Paul Santa Maria [EMAIL PROTECTED] wrote:
I'm coding in C++, but using the raw GTK+ C
libraries.
I'm doing similiar for a game I'm making.
--
gboolean
play_cb (gpointer data)
{
// Deference the object pointer to do the actual work
AnimationFile *ani = (AnimationFile *)data;
ani-start ();
}
Are you sure that is the right style for that callback?
static void
rocket_cb(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
class city_node *city=static_castclass city_node *(data);
global_game.rocket_up(*city);
city-update_targets();
each_tick(NULL);
}
is what I have for one of my callbacks.
Maybe do a printf(%p,ani); and a printf(%p,m_animation);
to really make sure they point to the same thing.
ani-start() works fine outside of the callback. I know my Animation
object has been
successfully created and that m_animation points to it before I call
gtk_signal_connect().
Good does ani point to the same thing once inside the callback as
m_animation points to outside the callback?
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
Gnaural wrote: First of all, big thanks to Tor Lillqvist and everyone else involved in the GTK+ for Windows port. Because of the GTK+, Glib, the MinGW cross-compiler, and WINE, I never have to leave Linux (or even own a Windows box) to make some Windows users happy! I love that -- in fact, it is the main feature that's made me commit to GTK+. [snip] I've found out that if the user install a GTK+ Runtime (such as the one found at http://gimp-win.sourceforge.net/), GTk+ apps find the necessary dlls just fine. Another option is Application Paths - they are registry keys for you application that set a path were it can find DLL's. It's better than setting the global PATH environment variable. If your program uses a installer, you'd set this registry key during installation. Google for more details since I don't know exactly where the keys should be and how that works. -- He's dead, Jim. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ for Windows: issues with apps locating the dll's
Eduardo M KALINOWSKI [EMAIL PROTECTED] wrote: ... Another option is Application Paths - they are registry keys for you application that set a path were it can find DLL's. It's better than setting the global PATH environment variable. If your program uses a installer, you'd set this registry key during installation. ... Great tip - you got me to look in to the freeware installer Inno Setup, which will handle all the registry stuff I'd like to keep out of my core code, and (with the help of a simple script I found in this list) checks to see if GTK+ 2.0 is installed and gives me the path to it. Which I can then put in a string named Path under my app's key here: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe And thanks also to the other two replies. I hadn't realized that all the libs an exe was linked-with needed to be available at the exe's launch, and also hadn't yet figured out that Gaim was running itself as a dll once a it's launcher established that GTK+ was available. Creative solution! Now win_gaim.c makes a lot more sense for me. BTW, with all that solved, I am still a bit mystified by one thing I mentioned in my last email (and don't want to start another thread unless someone else thinks this is important): Why are Gimp's GTK+ runtime 2.6.9 unuseable under WINE (even a standard GTK+ Hello World is all black on all Debian/Ubuntu boxes I tried), while Gaim's GTK+ runtime 2.6.9-rev-a work great? Tonight, as an experiment, I tried Gimp's GTK+ 2.8.7 runtime -- which ALMOST works in WINE, but still has big black splotches over it. What is the relationship between the two packages? Do the Gaim developers just modify current stable packages offered at Gimp site, or are they developing their own line independently? Both seem to work fine enough in Windows; it only matters for me because WINE is a crucial part of my development process, since all preliminary debugging happens through it. Thanks again, people. You've helped a lot. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
