Re: How to create a simple multilingual GUI
Michelle Konzack wrote: Am 2007-05-14 20:43:42, schrieb David Ne?as (Yeti): On Mon, May 14, 2007 at 08:04:09PM +0200, Michelle Konzack wrote: Does setlocale(LC_ALL, de_DE); not work? It works. Future locale-dependent calls will use the new locale. So if you do this while your application is already running, you can watch it trasmuting slowly to German, with some parts probably never getting there. AFAIK it is enough, if you reload all the Widgets... It works only for the widget itself. Usually there is also localized code in the program control flow like this: if (condition) status_text = _(Condition is true); If a branch like this is not executed again on reload or branch into another part of the code, the language of the text stays in the former language. Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ and multithreating
Am 2007-05-14 20:56:05, schrieb Cédric Lucantis: Michael is probably right, but to answer your question there's a good documentation about that in the GLib manual. See the sections 'Threads', 'Thread Pools' and 'Asynchronous Queues' under 'Glib Core Application Support'. If you want to know more, there's a tutorial here (about pthread but with a general introduction) : http://www.llnl.gov/computing/tutorials/pthreads Thursday evening downloaded with some other pthread-Tutorials and 3 hours later tried... I have put my function into pthread_create() like in the example of those tutorials and it was just working... (generaly) But now I must find out, how to put the received data (from the thread) back into the GtkTreeView widget (updating).. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Bypassing Force Quit
Greetings, I am running on FedoraCore5 and I have an application that when the user clicks the X in the upper right wants to query for saving any changed data. I have currently coded this as a signal handler for the delete event which puts up a modal dialog box with the questions and waits for the user's response. However, after some internal timeout, I get another dialog box warning me that the window titled ... is not responding and do I want to force it to quit, losing all of my data. I would like to disable this if possible, but I've not yet found a way. Is this caused by GTK? Has anyone encountered this and have you found a way around it? Dan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Bypassing Force Quit
On Wed, 16 May 2007 14:19:19 -0400 Dan Gruhn wrote: Greetings, I am running on FedoraCore5 and I have an application that when the user clicks the X in the upper right wants to query for saving any changed data. I have currently coded this as a signal handler for the delete event which puts up a modal dialog box with the questions and waits for the user's response. However, after some internal timeout, I get another dialog box warning me that the window titled ... is not responding and do I want to force it to quit, losing all of my data. I would like to disable this if possible, but I've not yet found a way. Is this caused by GTK? Has anyone encountered this and have you found a way around it? This is caused by the window manager, not gtk. It thinks the application isn't responding because it takes too long to return from the delete-event handler. You should probably return from the handler and open a dialog box via an idle function or something like that. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Bypassing Force Quit
On Wed, May 16, 2007 at 11:28:55AM -0700, Brian J. Tarricone wrote: I am running on FedoraCore5 and I have an application that when the user clicks the X in the upper right wants to query for saving any changed data. I have currently coded this as a signal handler for the delete event which puts up a modal dialog box with the questions and waits for the user's response. However, after some internal timeout, I get another dialog box warning me that the window titled ... is not responding and do I want to force it to quit, losing all of my data. ... This is caused by the window manager, not gtk. It thinks the application isn't responding because it takes too long to return from the delete-event handler. This is interesting, do you know what exactly the window manager is waiting for? Because it has of course no idea what your code does inside (namely whether it is in some handler or not) -- and you let Gtk+ main loop run, so it responds to events normally. Therefore the window manager expects some specific reaction from the client on delete. However, it cannot be destruction of the window as that would break all applications that allow one to cancel the closing of the window. Returning TRUE also prevents the default Gtk+ handler from running, so anything else Gtk+ could do there cannot be the thing. So what is it? Yeti -- http://gwyddion.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: hide window when minimized
On Tue, 2007-05-15 at 12:55 +0100, Emmanuele Bassi wrote: On Tue, 2007-05-15 at 13:51 +0200, bronson wrote: could anyone tell me how can I hide window, when user minimizes it? I tried to handle signal 'window-state-event', but when in that method i hide window, strange things happen - window hides, and then shows up again and it never ends. why would you want to hide a minimised window, which should already be hidden by your window manager? and, most of all, you should really ask on gtk-app-devel-list - this list is for developing gtk+, non *with* gtk+. Sounds like he wants a minimize-to-tray behaviour, which is common on Windows. -- Hans Petter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ and multithreating
On Wed, 2007-05-16 at 21:32 +0100, Chris Vine wrote: On Wed, 2007-05-16 at 16:44 +0200, Michelle Konzack wrote: Am 2007-05-14 22:22:34, schrieb Chris Vine: Pass the callbacks representing the events concerned to the main program loop using g_idle_add(). Make sure the callbacks return FALSE. g_idle_add() is thread safe, provided that you have initialised glib with g_thread_init(). Chris - END OF REPLIED MESSAGE - Forgive me if I do not understand this... Do you have a short exanple? For the phtreads I have only copied an example-sniplet and modified a bit and it was just working... :-) The documentation is here: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-idle-add The idea is that you call g_idle_add() in your worker thread with a callback (function pointer and data) which you want to execute in the main program (GUI) loop. http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html A simple example would be to call: g_idle_add((GSourceFunc)g_print, Hello\n); Actually it occurs to me that this may not work without a wrapper function which returns FALSE. I am not sure what the effect of casting a function with a void return type to a GSourceFunc type (which returns a gboolean/int type) is. Anyway, just put it in a wrapper function to try out the example. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ and multithreating
On Wed, 2007-05-16 at 21:38 +0100, Chris Vine wrote: On Wed, 2007-05-16 at 21:32 +0100, Chris Vine wrote: On Wed, 2007-05-16 at 16:44 +0200, Michelle Konzack wrote: Am 2007-05-14 22:22:34, schrieb Chris Vine: Pass the callbacks representing the events concerned to the main program loop using g_idle_add(). Make sure the callbacks return FALSE. g_idle_add() is thread safe, provided that you have initialised glib with g_thread_init(). Chris - END OF REPLIED MESSAGE - Forgive me if I do not understand this... Do you have a short exanple? For the phtreads I have only copied an example-sniplet and modified a bit and it was just working... :-) The documentation is here: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-idle-add The idea is that you call g_idle_add() in your worker thread with a callback (function pointer and data) which you want to execute in the main program (GUI) loop. http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html A simple example would be to call: g_idle_add((GSourceFunc)g_print, Hello\n); Actually it occurs to me that this may not work without a wrapper function which returns FALSE. I am not sure what the effect of casting a function with a void return type to a GSourceFunc type (which returns a gboolean/int type) is. Anyway, just put it in a wrapper function to try out the example. And you would need to put the Hello argument on the heap, and free it in the wrapper function, because otherwise it will go out of scope before the idle handler is called. (Sigh). Use g_strdup() to create the string on the heap. Simple examples are never that simple. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Question about suspending g_io_add_watch
Hi folks, i'm using g_io_add_watch like this: /* SNIP */ guint result; result = g_io_add_watch(io_chan, G_IO_IN, (GIOFunc) refresh, NULL); g_source_set_can_recurse(g_main_context_find_source_by_id(NULL, result), FALSE); /* SNAP */ I'm using g_source_set_can_recurse because I don't want that refresh() is called while this function is executed...but this doesn't seem to work. Is there any other way to suspend the call of refresh() or what am I doing wrong here? Regards, rw ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ and multithreating
On Wed, 2007-05-16 at 23:22 +0100, Chris Vine wrote: And you would need to put the Hello argument on the heap, and free it in the wrapper function, because otherwise it will go out of scope before the idle handler is called. (Sigh). Use g_strdup() to create the string on the heap. Simple examples are never that simple. On this case, Hello is a statically allocated string. It's always available and never is destroyed (it is always on the heap, as it were). Not something that's typically useful, though. In general, yes, data must be allocated on the heap, not the stack, in order to be passed to a callback handler like this. Unless it's a global static object (such as a string literal). Chris ___ 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: GTK+ maintenance
On Wed, 2007-05-16 at 09:06 +0100, Martyn Russell wrote: So, right now, the Board is not considering the option of hiring people to hack/do technical things. I'm not saying we'll never do this, but doing this has a lot of implications (managing the employees wouldn't be easy, people could start thinking that there's no need to contribute to GTK+ since the GNOME Foundation has developers for this, etc.), and we'd prefer to explore other ways to fix the issue first. I doubt that. Imendio (among other companies) have slowly been putting more resources into GTK+, is there any evidence that shows people are contributing any less? I think that's what he says: hiring GTK+ hackers by the board = bad, but hiring GTK+ hackers by companies = good. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Tuesday 15 May 2007 10:37, Kristian Rietveld wrote:
It depends what you mean with remove the row from the model. If that
means unlinking the row from the model's data structures, then there's
not a nice way anymore to retrieve an iterator to access that row. And
if _get_iter() is still supposed to be working, all other model methods
should also work: you are much better off not removing the row in that
case :)
Yes, I meant unlink it from the model. Think about something like this:
gboolean
gtk_list_store_remove (GtkListStore *list_store,
GtkTreeIter *iter)
{
GtkTreePath *path;
GtkSequencePtr ptr, next;
g_return_val_if_fail (GTK_IS_LIST_STORE (list_store), FALSE);
g_return_val_if_fail (VALID_ITER (iter, list_store), FALSE);
path = gtk_list_store_get_path (GTK_TREE_MODEL (list_store), iter);
ptr = iter-user_data;
next = _gtk_sequence_ptr_next (ptr);
- _gtk_tree_data_list_free (_gtk_sequence_ptr_get_data (ptr),
list_store-column_headers);
+ list_store-removed_data = (GtkTreeDataList *) _gtk_sequence_ptr_get_data
(ptr);
_gtk_sequence_remove (iter-user_data);
list_store-length--;
gtk_tree_model_row_deleted (GTK_TREE_MODEL (list_store), path);
+ _gtk_tree_data_list_free (list_store-removed_data,
list_store-column_headers);
+ list_store-removed_data = NULL;
gtk_tree_path_free (path);
if (_gtk_sequence_ptr_is_end (next))
{
iter-stamp = 0;
return FALSE;
}
else
{
iter-stamp = list_store-stamp;
iter-user_data = next;
return TRUE;
}
}
/* This new API method gets values from the very last deleted row: no needs
for an iter arg */
void
gtk_list_store_get_removed_value (GtkListStore *list_store,
gint column,
GValue *value)
{
GtkTreeDataList *list;
g_return_if_fail (GTK_IS_LIST_STORE (list_store));
g_return_if_fail (column list_store-n_columns);
g_return_if_fail (list_store-removed_data != NULL);
list = list_store-removed_data;
while (tmp_column-- 0 list)
list = list-next;
if (list == NULL)
g_value_init (value, list_store-column_headers[column]);
else
_gtk_tree_data_list_node_to_value (list,
list_store-column_headers[column],
value);
}
Of course, this solution needs a private field in the _GtkTreeStore struct and
a new API function, but it does not break anything and provides what needed.
Anyway, I think moving gtk_tree_model_row_deleted() at the top is a better
solution, but if you want backward compatibility, well, what can you do?
I think row-deleted does specifiy you the subject, one of its arguments
is the path ...
Yes, but if I need some data from the model I must duplicate it.
I don't want to bother, I only want to highlight that the row-deleted signal
(from an application developer's point of view) is, at this moment, quite
useless. But maybe I'm short in fantasy ...
-- Nicola
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkCalendar and day_selected event
Hi, I'm trying to use an instance of a GtkCalendar to allow the user to navigate through days. Other widgets respond to the selected day and present relevant information. However, using the day_selected event, the widget only accepts one click, after that, the day_selected event is apparently not fired on clicking other days. Ideally, I'd like the user to be able to navigate to as many days as they like. Is this achievable? Djihed ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk: hide window when minimized
On Tue, 2007-05-15 at 12:55 +0100, Emmanuele Bassi wrote: On Tue, 2007-05-15 at 13:51 +0200, bronson wrote: could anyone tell me how can I hide window, when user minimizes it? I tried to handle signal 'window-state-event', but when in that method i hide window, strange things happen - window hides, and then shows up again and it never ends. why would you want to hide a minimised window, which should already be hidden by your window manager? and, most of all, you should really ask on gtk-app-devel-list - this list is for developing gtk+, non *with* gtk+. Sounds like he wants a minimize-to-tray behaviour, which is common on Windows. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
