Re: GIO input/output streams for stdout, stderr and stdin
Here is a suggested addition to GIO, GWin32InputStream and
GWin32OutputStream. You can use these in your code until they appear
in GLib (in 2.26 hopefully). Pick out the files gwin32inputstream.[ch]
and gwin32outputstream.[ch] from the git diff below, change the names
to avoid using the GLib namespace, and use in your code.
--tml
commit ff7c3baa94723040d3ef6808209716baf4e176ee
Author: Tor Lillqvist
Date: Mon Apr 12 18:14:23 2010 +0300
Add GWin32InputStream and GWin32OutputStream classes
Correspond to GUnixInputStream and GUnixOutputStream. No true async
support though. But that is how the Win32 API is, for files not
explicitly opened for so-called overlapped IO.
The API to create streams takes Win32 HANDLEs. Not file descriptors,
because file descriptors are specific to the C library used. The user
code and GLib might be using different C libraries.
Also add a test program for the new classes, and a gio-windows-2.0.pc
file.
diff --git a/Makefile.am b/Makefile.am
index 708b16b..ace9c9a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -53,6 +53,7 @@ EXTRA_DIST += \
gthread-2.0.pc.in \
gio-2.0.pc.in \
gio-unix-2.0.pc.in \
+ gio-windows-2.0.pc.in \
glib-2.0-uninstalled.pc.in \
gobject-2.0-uninstalled.pc.in \
gmodule-2.0-uninstalled.pc.in \
@@ -108,6 +109,10 @@ if OS_UNIX
pkgconfig_DATA += gio-unix-2.0.pc
endif
+if OS_WIN32
+pkgconfig_DATA += gio-windows-2.0.pc
+endif
+
$(pkgconfig_DATA): config.status
# install mkinstalldirs for glib-gettextize's benefit
diff --git a/configure.in b/configure.in
index f6d80fb..a8697a4 100644
--- a/configure.in
+++ b/configure.in
@@ -3510,6 +3510,7 @@ gobject-2.0.pc
gobject-2.0-uninstalled.pc
gio-2.0.pc
gio-unix-2.0.pc
+gio-windows-2.0.pc
gio-2.0-uninstalled.pc
gio-unix-2.0-uninstalled.pc
glib-zip
diff --git a/gio-windows-2.0.pc.in b/gio-windows-2.0.pc.in
new file mode 100644
index 000..77eecdf
--- /dev/null
+++ b/gio-windows-2.0.pc.in
@@ -0,0 +1,11 @@
+pref...@prefix@
+exec_pref...@exec_prefix@
+libd...@libdir@
+included...@includedir@
+
+Name: GIO Windows specific APIs
+Description: Windows specific headers for glib I/O library
+Version: @VERSION@
+Requires: gobject-2.0,gmodule-no-export-2.0,gio-2.0
+Libs: -L${libdir} -lgio-2.0
+Cflags: -I${includedir}/gio-win32-2.0/
diff --git a/gio/Makefile.am b/gio/Makefile.am
index fd42438..ee47461 100644
--- a/gio/Makefile.am
+++ b/gio/Makefile.am
@@ -178,6 +178,15 @@ win32_sources = \
gwin32resolver.h \
gwin32volumemonitor.c \
gwin32volumemonitor.h \
+ gwin32inputstream.c \
+ gwin32outputstream.c \
+ gwin32outputstream.h \
+ $(NULL)
+
+giowin32includedir=$(includedir)/gio-win32-2.0/gio
+giowin32include_HEADERS = \
+ gwin32inputstream.h \
+ gwin32outputstream.h \
$(NULL)
endif
diff --git a/gio/gio.symbols b/gio/gio.symbols
index 62a99d7..4c670fd 100644
--- a/gio/gio.symbols
+++ b/gio/gio.symbols
@@ -827,6 +827,30 @@ g_unix_output_stream_get_fd
#endif
#endif
+#if IN_HEADER(__G_WIN32_INPUT_STREAM_H__)
+#if IN_FILE(__G_WIN32_INPUT_STREAM_C__)
+#ifdef G_OS_WIN32
+g_win32_input_stream_get_type G_GNUC_CONST
+g_win32_input_stream_new
+g_win32_input_stream_set_close_handle
+g_win32_input_stream_get_close_handle
+g_win32_input_stream_get_handle
+#endif /* G_OS_WIN32 */
+#endif
+#endif
+
+#if IN_HEADER(__G_WIN32_OUTPUT_STREAM_H__)
+#if IN_FILE(__G_WIN32_OUTPUT_STREAM_C__)
+#ifdef G_OS_WIN32
+g_win32_output_stream_get_type G_GNUC_CONST
+g_win32_output_stream_new
+g_win32_output_stream_set_close_handle
+g_win32_output_stream_get_close_handle
+g_win32_output_stream_get_handle
+#endif /* G_OS_WIN32 */
+#endif
+#endif
+
#if IN_HEADER(__G_MOUNT_H__)
#if IN_FILE(__G_MOUNT_C__)
g_mount_get_type G_GNUC_CONST
@@ -1340,3 +1364,4 @@ g_file_descriptor_based_get_type G_GNUC_CONST
g_file_descriptor_based_get_fd
#endif
#endif
+
diff --git a/gio/gioerror.c b/gio/gioerror.c
index 287cb2b..8a1ee4f 100644
--- a/gio/gioerror.c
+++ b/gio/gioerror.c
@@ -206,5 +206,32 @@ g_io_error_from_errno (gint err_no)
}
}
+#ifdef G_OS_WIN32
+
+/**
+ * g_io_error_from_win32_error:
+ * @error_code: Windows error number.
+ *
+ * Converts some common error codes into GIO error codes. The
+ * fallback value G_IO_ERROR_FAILED is returned for error codes not
+ * handled.
+ *
+ * Returns: #GIOErrorEnum value for the given error number.
+ *
+ * Since: 2.26
+ **/
+GIOErrorEnum
+g_io_error_from_win32_error (gint error_code)
+{
+ switch (error_code)
+{
+default:
+ return G_IO_ERROR_FAILED;
+ break;
+}
+}
+
+#endif
+
#define __G_IO_ERROR_C__
#include "gioaliasdef.c"
diff --git a/gio/gioerror.h b/gio/gioerror.h
index c1dc377..12c2b06 100644
--- a/gio/gioerror.h
+++ b/gio/gioerror.h
@@ -43,6 +43,10 @@ G_BEGIN_DECLS
GQuark g_io_error_quark (void);
GIOErrorEnum g_io_error_from_errno (gint err_no);
+#ifdef G_O
Re: gthreads and file operations
> By the way, I had never programmed using glib threads before. Is the threads > part of the code I had sent earlier correct? If you want people to actually test your code, you do need to show a *complete* compilable and *minimal* test case. In general, it's best to avoid threads. For some reasons, many people think they need threads even if they don't. And threading brings in all kinds of interesting problems. Have you programmed using other thread APIs then? Based on the incomplete program you submitted, I really don't see why you think you need threads in *that* program. Is the gnomeProxy() function really supposed to take a significant amount of time to run (like tens of seconds) so that you really need it to run concurrently with the UI? And it is a bit odd to call gdk_threads_enter() at the beginning of the function and then gdk_threads_leave() at the end, that is almost certainly not what you want. > also have to add GUI(a gnome panel applet) to my application. Would that > require a new thread? No. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GCancellable Error Code
Hey, I'm wondering if anyone knows what/where I can find the error code name
for an asynchronous operation being canceled? I've looked through the
docs/headers but was unable to find the information. This would just be used
for something like the following, where the user is only notified of an error
if it was not themselves who triggered it through a disconnect button:
if ((connection =
g_socket_client_connect_to_host_finish(G_SOCKET_CLIENT(client), res, &err)) ==
NULL)
{
if (err->code != G_ERROR_CANCELED)
//Tell user
}
--
Nader Morshed
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
On Tue, 13 Apr 2010 01:01:15 +0530, Nischal Rao wrote: >> Is the >> threads part of the code I had sent earlier correct? I haven't seen the code yet. It could be me, but the mailing list software probably scrubs attachments. Most folks just post as inline text. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
Not sure if it's just me, but I can't see the attachment. For things like fseek and fclose, you might want to look at the gio library (http://library.gnome.org/devel/gio/stable/) which is included along with glib. On Tue, 13 Apr 2010 00:21:44 +0530 Nischal Rao wrote: > I just noticed... the code sometimes works and sometimes doesn't work(the > code doesn't go to completion which kind of confirms that there is thread > lock problem). > > There doesn't seem to be an error in other parts of the code because the > code works fine when i comment the file writing part(i.e., prepareGrammar() > ). > > I have attached part of my code. > > PS: I have used standard functions (fopen, fprintf etc) because i couldn't > find glib equivalent(for fseek() and fclose() ). > > On Mon, Apr 12, 2010 at 10:52 PM, Tor Lillqvist wrote: > > > It would be *much* easier to help you if you could show us some actual > > code that works strangely for you. A minimal but complete sample > > program, thanks. Now it is very hard to understand what you mean. > > > > --tml > > > > > > -- > regards, > Nischal E Rao > blogs.sun.com/nischal > > Join RVCE OSUM at http://osum.sun.com/group/rvceosum -- Nader Morshed ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
the problem still persists. :( my assumption was wrong On Tue, Apr 13, 2010 at 12:43 AM, Nischal Rao wrote: > I got the problem! > > The thing is, before calling the prepareGrammar() function i am calling a > function, SPI_generateMouseEvent() which modifies the at-spi tree which is > accessed by prepareGrammar, i.e., i was accessing the tree while it was > being modified by another external program. All i need to do is, delay > calling the prepareGrammar() function by 1 sec(or is there any other way??). > > By the way, I had never programmed using glib threads before. Is the > threads part of the code I had sent earlier correct? or does it need any > changes? I also have to add GUI(a gnome panel applet) to my application. > Would that require a new thread? > > Thanks for all the help so far. Sorry if I wasted your time. > > > On Tue, Apr 13, 2010 at 12:21 AM, Nischal Rao wrote: > >> I just noticed... the code sometimes works and sometimes doesn't work(the >> code doesn't go to completion which kind of confirms that there is thread >> lock problem). >> >> There doesn't seem to be an error in other parts of the code because the >> code works fine when i comment the file writing part(i.e., prepareGrammar() >> ). >> >> I have attached part of my code. >> >> PS: I have used standard functions (fopen, fprintf etc) because i couldn't >> find glib equivalent(for fseek() and fclose() ). >> >> >> On Mon, Apr 12, 2010 at 10:52 PM, Tor Lillqvist wrote: >> >>> It would be *much* easier to help you if you could show us some actual >>> code that works strangely for you. A minimal but complete sample >>> program, thanks. Now it is very hard to understand what you mean. >>> >>> --tml >>> >> >> >> >> -- >> regards, >> Nischal E Rao >> blogs.sun.com/nischal >> >> Join RVCE OSUM at http://osum.sun.com/group/rvceosum >> >> > > > -- > regards, > Nischal E Rao > blogs.sun.com/nischal > > Join RVCE OSUM at http://osum.sun.com/group/rvceosum > > -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
I got the problem! The thing is, before calling the prepareGrammar() function i am calling a function, SPI_generateMouseEvent() which modifies the at-spi tree which is accessed by prepareGrammar, i.e., i was accessing the tree while it was being modified by another external program. All i need to do is, delay calling the prepareGrammar() function by 1 sec(or is there any other way??). By the way, I had never programmed using glib threads before. Is the threads part of the code I had sent earlier correct? or does it need any changes? I also have to add GUI(a gnome panel applet) to my application. Would that require a new thread? Thanks for all the help so far. Sorry if I wasted your time. On Tue, Apr 13, 2010 at 12:21 AM, Nischal Rao wrote: > I just noticed... the code sometimes works and sometimes doesn't work(the > code doesn't go to completion which kind of confirms that there is thread > lock problem). > > There doesn't seem to be an error in other parts of the code because the > code works fine when i comment the file writing part(i.e., prepareGrammar() > ). > > I have attached part of my code. > > PS: I have used standard functions (fopen, fprintf etc) because i couldn't > find glib equivalent(for fseek() and fclose() ). > > > On Mon, Apr 12, 2010 at 10:52 PM, Tor Lillqvist wrote: > >> It would be *much* easier to help you if you could show us some actual >> code that works strangely for you. A minimal but complete sample >> program, thanks. Now it is very hard to understand what you mean. >> >> --tml >> > > > > -- > regards, > Nischal E Rao > blogs.sun.com/nischal > > Join RVCE OSUM at http://osum.sun.com/group/rvceosum > > -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
I just noticed... the code sometimes works and sometimes doesn't work(the code doesn't go to completion which kind of confirms that there is thread lock problem). There doesn't seem to be an error in other parts of the code because the code works fine when i comment the file writing part(i.e., prepareGrammar() ). I have attached part of my code. PS: I have used standard functions (fopen, fprintf etc) because i couldn't find glib equivalent(for fseek() and fclose() ). On Mon, Apr 12, 2010 at 10:52 PM, Tor Lillqvist wrote: > It would be *much* easier to help you if you could show us some actual > code that works strangely for you. A minimal but complete sample > program, thanks. Now it is very hard to understand what you mean. > > --tml > -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
It would be *much* easier to help you if you could show us some actual code that works strangely for you. A minimal but complete sample program, thanks. Now it is very hard to understand what you mean. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
On Mon, 12 Apr 2010 21:25:44 +0530, Nischal Rao wrote: > the files are coming empty. I suspect this is happening because of thread > lock problems... > > Have you tried a "flush" operation. ie fflush() or g_io_channel_flush()? Beyond that we would need to see some sort of code example. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.20 for Windows
2010/4/10 Nader Morshed : > > I'm wondering what the status is for 2.18/2.20 compatibility with Windows and > if I should bundle it with my project, through modifying the gtk-win > project's NSIS file, or if there are issues that still need to be worked out. I think the most imporant bugs are the client-side-window (csw) related bugs: [1] (csw was introdued in 2.18 cycle) More info here and links to bugzilla database here: [2] Also take a look here: [3] Regards, [1] https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=csw;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=win32;product=gtk%2B [2] http://live.gnome.org/GTK%2B/Win32 [3] http://www.gtk.org/download-windows.html Javier Jardón Cabezas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
On Mon, Apr 12, 2010 at 8:33 PM, Thomas Stover wrote: > 1) you mean glib threads right? (maybe there is a gnome thread?) > yes... i mean glib threads. > 2) you're going to want to use glib based functions like io channels > instead of stdio (for regular files at least) > 3) "don't seem to work" is not enough information for anyone to help you > the files are coming empty. I suspect this is happening because of thread lock problems... > 4) you also need a real reason to be using threads in the first place > since that sort of thing should be discourage unless it truly is > appropriate. (not that you don't have a real reason, just that many people > assume they do when it actually is just making the problems worse) > I have to use threads because i need to listen for signals and at the same do some processing(which is not related to the signals I am listening to...) > 5) start with reading up on the glib interfaces > http://library.gnome.org/devel/glib/stable/ I read the glib threads part which is working well except for the file part. I really have no time to read the entire documentation. I'd rather wait for somebody who is experienced enough to help me out. > > > -- > www.thomasstover.com > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
2010/4/12 Nischal Rao : > Hi, > > Within a gnome thread i need to read as well as write to a file. I tried > using the regular fprintf() etc but they don't seem to work. > Can somebody please help me out since I am new to gnome threads. see if you can use the GIO _async() calls, they use threads in the background while keeping the diffucult things away for you. regards, Olivier ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gthreads and file operations
1) you mean glib threads right? (maybe there is a gnome thread?) 2) you're going to want to use glib based functions like io channels instead of stdio (for regular files at least) 3) "don't seem to work" is not enough information for anyone to help you 4) you also need a real reason to be using threads in the first place since that sort of thing should be discourage unless it truly is appropriate. (not that you don't have a real reason, just that many people assume they do when it actually is just making the problems worse) 5) start with reading up on the glib interfaces http://library.gnome.org/devel/glib/stable/ -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag And Drop - "drag-motion" cursor lockup? [FIXED]
Since gtk-app-devel-list was useless, I am going to post a working full DnD
example here that others can use in case they search for the same problem
and locate this thread.
This example is going to be in GOB format. But since that generates C you
can use that if you care. This example will accept file-system drops but
only if a URI contains .jpg
/*http://www.jirka.org/gob2.1.html*/
%h{
#include
%}
%{
// Identifiers for DnD target types.
enum
{
TARGET_TEXT_URI_LIST,
};
// Target types for dropping into the tree view.
static const GtkTargetEntry drop_targets[] = {
{ "text/uri-list", 0, TARGET_TEXT_URI_LIST },
};
%}
class Test:App from G:Object
{
private GtkBuilder* builder = {gtk_builder_new()} unrefwith g_object_unref;
private GtkWindow* window = NULL;
private GtkButton* button = NULL;
init(self)
{
gtk_builder_add_from_file(selfp->builder,"MainWindow.glade", NULL);
selfp->window =
GTK_WINDOW(gtk_builder_get_object(selfp->builder,"window1"));
selfp->button =
GTK_BUTTON(gtk_builder_get_object(selfp->builder,"button1"));
gtk_builder_connect_signals (selfp->builder, NULL);
g_signal_connect (selfp->window, "destroy", G_CALLBACK (gtk_main_quit),
NULL);
gtk_drag_dest_set (GTK_WIDGET (selfp->button), 0, drop_targets,
G_N_ELEMENTS (drop_targets),
GDK_ACTION_COPY | GDK_ACTION_LINK | GDK_ACTION_MOVE);
// Connect to drag and drop signals.
g_signal_connect (GTK_OBJECT(selfp->button), "drag-data-received",
G_CALLBACK(self_do_drag_data_received), self);
g_signal_connect (GTK_OBJECT(selfp->button), "drag-drop",
G_CALLBACK(self_do_drag_drop), self);
g_signal_connect (GTK_OBJECT(selfp->button), "drag-motion",
G_CALLBACK(self_do_drag_motion), self);
g_signal_connect (GTK_OBJECT(selfp->button), "drag-leave",
G_CALLBACK(self_do_drag_leave), self);
// Show the window.
gtk_widget_show_all(GTK_WIDGET(selfp->window));
}
//
http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#GtkWidget-drag-drop
private gboolean drop_data_ready = FALSE;
private gboolean drop_occurred = FALSE;
private gboolean drop_highlight = FALSE;
private gchar* drop_data = NULL destroywith g_free;
private void do_drag_data_received(GtkWidget* widget,
GdkDragContext* context,
gint x,
gint y,
GtkSelectionData* data,
guint info,
guint time,
gpointer user_data)
{
Self* self = SELF(user_data);
// Check to see if we have the drop data yet.
if (FALSE == selfp->drop_data_ready)
{
// If this is data we expected or can handle, then process it.
if (TARGET_TEXT_URI_LIST == info &&
gtk_selection_data_get_format(data) == 8 &&
gtk_selection_data_get_length(data) > 0)
{
selfp->drop_data = g_strdup((gchar*)gtk_selection_data_get_data(data));
selfp->drop_data_ready = TRUE;
}
}
// Actual drop handling code.
if (TRUE == selfp->drop_occurred)
{
// Reset state.
selfp->drop_occurred = FALSE;
g_print("RECEIVED DROP `%s`\n",selfp->drop_data);
// Notify whether we handled the drop or not.
gtk_drag_finish(context,TRUE /* success or not */,FALSE,time);
// Clean up.
self_do_drag_leave(widget, context, time, user_data);
}
}
private gboolean do_drag_drop(GtkWidget* widget, GdkDragContext* context,
gint x, gint y, guint time, gpointer user_data)
{
Self* self = SELF(user_data);
// Get drop target datatype.
GdkAtom target = gtk_drag_dest_find_target (widget, context, NULL);
// Is it something we can handle?
if (target == gdk_atom_intern("text/uri-list", FALSE))
{
// Tell data recieved handler (do_drag_data_received) we can actually handle
the drop.
selfp->drop_occurred = TRUE;
gtk_drag_get_data(widget,context,target,time);
// We can handle this data type.
return TRUE;
}
else
{
// We cannot handle the drop.
return FALSE;
}
}
private gboolean do_drag_motion(GtkWidget *widget,
GdkDragContext *context,
gint x,
gint y,
guint time,
gpointer user_data)
{
Self* self = SELF(user_data);
// Get drop target datatype.
GdkAtom target = gtk_drag_dest_find_target (widget, context, NULL);
if (target != gdk_atom_intern ("text/uri-list", FALSE))
{
// not something we can handle
return FALSE;
}
// If we don't have the drop data yet, request it (so we can validate it).
if (FALSE == selfp->drop_data_ready)
{
// Request drag data from the source.
gtk_drag_get_data (widget, context, target, time);
// Tell Gdk we are unsure whether we can handle this drop.
gdk_drag_status (context, 0, time);
return TRUE;
}
else
{
// Make sure the drop data has `.jpg` inside of it.
if (NULL == g_strstr_len(selfp->drop_data,-1,".jpg")) {
return FALSE;
}
else
{
// Tell Gdk we can handle this.
gdk_drag_status(context, GDK_ACTION_COPY, time);
// Draw drop highlight (but only once).
if (FALSE == selfp->drop_highlight) {
gtk_drag_highlight(widget);
selfp->drop_highlight = TRUE;
}
return TRUE;
}
}
}
private void do_drag_leave(GtkWidget* widget, GdkDragContext* context,
guint time, gpointer user_data)
{
Self* self = SELF(user_data);
// Cleanup drag data.
if (TRUE == selfp->drop_data_ready)
{
g_free(selfp->drop_data);
selfp->drop_data =
Re: GTK 2.20 for Windows
On Sun, 2010-04-11 at 09:51 +0300, Tor Lillqvist wrote:
> > Would filing tickets of the issues that arise generate a response?
>
> Filing tickets (bug reports in bugzilla.gnome.org) for individual
> clearly separate issues (that don't have bug reports already) is
> always good,
This is essential. We can't have a discussion about the problems, or
attract anyone to deal with them, if we don't know what they are.
> especially if accompanied by minimal but complete test
> programs. But don't expect any immediate "response" for bugs that are
> hard to fix. (And avoid setting the "priority" or "severity" fields,
> that only makes the bug reporter seem obnoxious ("my bugs are the most
> important ones"), those fields are cheerfully ignored by most
> maintainers I think, or at least by me.)
>
> > Or is the project needing an active developer to sort out the issues
> that have already arisen?
>
> That is it, yes. Either some existing "maintainer" (like me) that
> already knows the code to some extent needs inspiration to start
> working on the issues, or some new person needs to appear, full of
> energy and inspiration.
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gthreads and file operations
Hi, Within a gnome thread i need to read as well as write to a file. I tried using the regular fprintf() etc but they don't seem to work. Can somebody please help me out since I am new to gnome threads. Thanks in advance. -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
