RE: Switching theme
Hi... Probably u can even use existing applications on net to change themes on the fly http://www.muhri.net/nav.php3?node=gts download gtk-theme-switch Hope this helps. Rgds, Madhusudan E This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Paolo Franzetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 1:41 PM To: Madhusudan E Subject: Re: Switching theme Madhusudan E wrote: Hi, On selecting the theme, Use, say gtk_rc_parse(/home/Madhu/gtk/Themes/AquaX/gtk-2.0/gtkrc); Then reset the window rc styles using gtk_widget_reset_rc_styles(window); Then reparse all... gtk_rc_reparse_all(); I hope this helps Rgds, Madhusudan Thanks for the suggestion. It almost works ... The first time I switch theme it works (a part for the menu from which I launch the command); then it works no more, or it works partially (some widgets updated, some not). I am using libglade to build my application; it could be a problem? Thanks again, Paolo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_entry_set_text
Hi! I've got the following problem: I want to set the text of a gtk_entry from an event-handler. Normally one can use the function gtk_entry_set_text, but in this case this is not possible, because I risk that the application crashes, when I use this function due to conflicts between gtk_main() and the GTK call invoked in the event handler. Does anybody have an idea, how to set the text of a gtk_entry from an event-handler? I use gtk 2.8.x under windows. Thanx, spocky -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_entry_set_text
[EMAIL PROTECTED] wrote: I've got the following problem: I want to set the text of a gtk_entry from an event-handler. Normally one can use the function gtk_entry_set_text, but in this case this is not possible, because I risk that the application crashes, when I use this function due to conflicts between gtk_main() and the GTK call invoked in the event handler. Um, are you sure it is not possible? Does GTK+ complain or even crash if you try? Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
moving a window off screen
Hi all,
I want to move a window off screen and then move it gradually onto the screen.
When using the gtk_window_move() function with values greater than the
current screen size the window will not move off-screen but remain
with the full window visible.
Could someone please tell me why this is?
Am i using the correct function or is the window manager stopping it or what?
using libgtk version 2.10.6-0ubuntu3 (edgy-updates)
Thanks,
Niall
Example code
#include gtk/gtk.h
int main( int argc, char *argv[] )
{
GtkWidget *window;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_window_move(GTK_WINDOW(window), 1200, 800);
gtk_main ();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_entry_set_text
2006/12/19, [EMAIL PROTECTED] [EMAIL PROTECTED]: Normally one can use the function gtk_entry_set_text, but in this case this is not possible, because I risk that the application crashes, when I use this function due to conflicts between gtk_main() and the GTK call invoked in the event handler. If it is so you found the biggest bug of 2006... what do you mean by conflicts? Can you please post a minimal test case? cheers -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Weird problem with GTK+ 2.10.6
Hi there!
Maybe problem, which affect isn't a bug in GTK+, maybe it's occurred by
something else, I don't know. Here's short description. I write small multi
thread application in C language. Whole code is based on GTK+/GLib and
GObject. I have problem with dealing with GtkProgressBar. Window, which
contains GtkProgressBar widget is created in separated thread. Firstly i
make this progress bar pulsing for a while using g_timeout_add () and after
few seconds I remove this source and try to set progress bar's fraction to
0.0. after executing gtk_progress_bar_set_fraction () GUI starts behaving
very funny. Whole program still works, it creates new windows but it doesn't
show widget inside those windows and doesn't update already existing widgets
(when I move mouse pointer on already existing button etc.), it looks like
this:
http://img509.imageshack.us/img509/5880/zrzutekranury1.png
This is normal behavior (when gtk_progress_bar_set_fraction () is removed
from code):
http://img217.imageshack.us/img217/4130/zrzutekranu6vj6.png
when in situation on first screenshot I click in place, where normally is
OK button, program behaves normally ?!
Here's some code:
*this function creates window: **
GtkWidget *goofy_gui_get_progress_dlg (GoofyFile *file) {
GladeXML*xml;
GtkWidget *dialog;
GtkWidget *tmp_widget;
gchar *size_string = goofy_file_size_to_string (file-file_size);
xml = glade_xml_new (GUI_FILE_PATH, progress_dlg, NULL);
dialog = glade_xml_get_widget (xml, progress_dlg);
/* Set labels etc. in window */
tmp_widget = goofy_gui_get_widget (dialog, file_name_lb);
gtk_label_set_text (GTK_LABEL (tmp_widget), file-file_name);
tmp_widget = goofy_gui_get_widget (dialog, file_size_lb);
gtk_label_set_text (GTK_LABEL (tmp_widget), size_string);
tmp_widget = glade_xml_get_widget (xml, progress_bar);
gtk_progress_bar_set_pulse_step (GTK_PROGRESS_BAR (tmp_widget), 0.05);
/* Connect signals */
g_signal_connect (dialog, delete-event, G_CALLBACK
(on_send_progress_dlg_delete_event), file);
tmp_widget = goofy_gui_get_widget (dialog, cancel_but);
g_signal_connect (tmp_widget, clicked, G_CALLBACK
(on_send_progress_cancel_but_clicked), file);
tmp_widget = goofy_gui_get_widget (dialog, close_but);
g_signal_connect (tmp_widget, clicked, G_CALLBACK
(on_send_progress_close_but_clicked), file);
/* allocated memory */
g_free (size_string);
/* Show window */
goofy_gui_show_widget (dialog);
return dialog;
}
* this make progress bar pulsing *
voidgoofy_gui_set_progress_bar_pulsing (GtkProgressBar*pbar,
gboolean status)
{
guintsource_id;
if (status == TRUE) {
source_id = g_timeout_add (100, (GSourceFunc)
_goofy_gui_progress_bar_pulsing, pbar);
g_object_set_data (G_OBJECT (pbar), pulse-source-id,
GINT_TO_POINTER (source_id));
}
else {
source_id = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (pbar),
pulse-source-id));
g_source_remove (source_id);
/* Clear progress bar */
gtk_progress_bar_set_fraction (pbar, 0.0);
}
}
** This code deal with window in separated thread
/
gdk_threads_enter ();
dialog = goofy_gui_get_progress_dlg (GOOFY_FILE (file_send));
tmp_widget = goofy_gui_get_widget (dialog, main_lb);
gtk_label_set_markup (GTK_LABEL (tmp_widget), _(span
size=\x-large\bSending file/b/span));
tmp_widget = goofy_gui_get_widget (dialog, name_host_ip_lb);
gtk_label_set_text (GTK_LABEL (tmp_widget), _(Destination host's IP:));
tmp_widget = goofy_gui_get_widget (dialog, host_ip_lb);
gtk_label_set_text (GTK_LABEL (tmp_widget), GOOFY_SOCKET
(file_send)-ip_address);
gdk_threads_leave ();
/* some code here */
gdk_threads_enter ();
tmp_widget = goofy_gui_get_widget (dialog, progress_bar);
goofy_gui_set_progress_bar_pulsing (GTK_PROGRESS_BAR (tmp_widget), TRUE);
gtk_progress_bar_set_text (GTK_PROGRESS_BAR (tmp_widget),
_(Connecting...));
gdk_threads_leave ();
/* ... other code... */
gdk_threads_enter ();
tmp_widget = goofy_gui_get_widget (dialog, progress_bar);
goofy_gui_set_progress_bar_pulsing (GTK_PROGRESS_BAR (tmp_widget), FALSE);
gtk_progress_bar_set_text (GTK_PROGRESS_BAR (tmp_widget), _(Connected));
gdk_threads_leave ();
**this sis 'goofy_gui_show_widget ' function, which is workaround
for problem with dealing with GTK under win32 **
voidgoofy_gui_show_widget (GtkWidget *widget){
g_timeout_add (5, _goofy_show_widget, widget);
}
static gboolean_goofy_show_widget (gpointer data){
gtk_widget_show (GTK_WIDGET (data));
gdk_flush ();
return FALSE;
}
The most suprising thing is that this problem occurs only on my Ubuntu
6.10(GTK+
v2.10.6). On Ubuntu 5.10 on Windows XP (both with GTK+v2.10.6) it works
normally. When I remove gtk_progress_bar_set_fraction () from code it
Re: Weird problem with GTK+ 2.10.6
Update: I was wrong - the same situation occurs on all platforms ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: moving a window off screen
2006/12/19, Niall Murphy [EMAIL PROTECTED]: Could someone please tell me why this is? Am i using the correct function or is the window manager stopping it or what? Most likely is the WM that takes care of always show your window. btw why you want to move the window offscreen? It is not sufficent to hide it? cheers -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkComboBox question
I am trying to work on an application which has a combo box. I want to restrict the user to values that are included in the drop down list only. My thought was to prevent the user from editing the value in the entry box, but I can't seem to find a way to do this. I am running Fedora Core 6, and developed the application using glade-2. I am not using the lib, but working with the generated C code. Thanks for any assistance. Russell Markus Sr. Software Engineer IPMobileNet, Inc. (949)417-4590 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBox question
Russell Markus wrote: I am trying to work on an application which has a combo box. I want to restrict the user to values that are included in the drop down list only. My thought was to prevent the user from editing the value in the entry box, but I can't seem to find a way to do this. I am running Fedora Core 6, and developed the application using glade-2. I am not using the lib, but working with the generated C code. Um, that's exactly what GtkComboBox does, no? To allow editing, you need a GtkComboBoxEntry. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBox question
On Wed, 2006-12-20 at 02:31 +0200, Paul Pogonyshev wrote: Russell Markus wrote: I am trying to work on an application which has a combo box. I want to restrict the user to values that are included in the drop down list only. My thought was to prevent the user from editing the value in the entry box, but I can't seem to find a way to do this. I am running Fedora Core 6, and developed the application using glade-2. I am not using the lib, but working with the generated C code. Um, that's exactly what GtkComboBox does, no? To allow editing, you need a GtkComboBoxEntry. He says he's using a combo box, but you suspect he's accidentally chosen a GtkComboBoxEntry in glade? // Wally -- Constructing a program is like painting a room. A beginner at either will start in one corner and end in another, left there to discover just how important approach and technique are in obtaining a good result. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Dialog-like window?
Dudes, Is there a way of creating a window which, when shown, will cause the caller function to sit and wait until it gives a result? I mean, something like the GtkDialogs and gtk_dialog_run. However, as far as I understood, a normal GtkDialog only returns integer values. I ask this because I would like to have a certain dialog working itself like a function, building a structure according to whatever is shown or input in its widgets, and then returning this structure (or any other type) when the user clicks on OK. Then the program would continue from the point where the open_dialog function was called, using the data structure (or any other value type) which has been created with the dialog. I have seen this behaviour in other programming languages/toolkits, but still haven´t got a clue of how to emulate this in GTK. What do you suggest? Thank you! Fabricio Rocha Brasilia, Brasil The RADiola Project http://radiola.sourceforge.net ___ Yahoo! Mail - Sempre a melhor opção para você! Experimente já e veja as novidades. http://br.yahoo.com/mailbeta/tudonovo/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Dialog-like window?
On Tue, 19 Dec 2006, Fabricio Rocha wrote: Is there a way of creating a window which, when shown, will cause the caller function to sit and wait until it gives a result? Blocking? If I'm understanding you right, you can do that by making a secondary call to gtk_main() -- then call gtk_main_quit() when you're good and ready. The function that calls gtk_main() will not return till gtk_main_quit() is called. If you want to prevent user interation in the meantime you'll also have to make the dialog-like window modal, though that is a separate issue. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Scrolled Window With TreeView in it
Hi i recently post to this list about the subject below. I didn't realize that I disabled the mail delivery a few days ago. I'm really sorry for the for the inconvinients taken and i don't expect anybody to resend me any responses (if any) but I would appreciate it. El lun, 18-12-2006 a las 13:27 -0300, Matías Alejandro Torres escribió: Hello everyone, I have a GtkTreeView packed inside a GtkScrolledWindow. The GtkScrolledWindow is packed inside a GtkVBox and I want that whenever the windows' size changes the GtkScrolledWindow fills the unused space. I've have two dialogs created in the same way, one works, the other doesn't. Here is the code: /* GtkTreeModel GtkTreeView */ contactbox-treeview = do_contact_treeview (); /* TreeView's Scrolled Window */ contactbox-sw = gtk_scrolled_window_new (NULL, NULL); gtk_scrolled_window_set_shadow_type (GTK_SCROLLED_WINDOW (contactbox-sw), GTK_SHADOW_ETCHED_IN); gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (contactbox-sw), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); gtk_container_add (GTK_CONTAINER (contactbox-sw), contactbox-treeview); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-sw, TRUE, TRUE, 6); This is how i pack the other widgets of the dialog: Initialization of the class: /* Initialize contact box init */ gtk_box_set_homogeneous (GTK_BOX (contactbox), FALSE); gtk_box_set_spacing (GTK_BOX (contactbox), 6); /* Packing of its widgets */ gtk_box_pack_start (GTK_BOX (contactbox), hbox, FALSE, FALSE, 0); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-search_button, FALSE, FALSE, 0); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-sw, TRUE, TRUE, 6); gtk_box_pack_start (GTK_BOX (contactbox), buttonbox, FALSE, FALSE, 6); gtk_box_pack_start (GTK_BOX (contactbox), label, FALSE, FALSE, 6); gtk_box_pack_start (GTK_BOX (contactbox), table, FALSE, FALSE, 6 ); As you can see the only widget which should expand is the scrolled window but for some reason, it doesn't. Thanks in advance, Matias. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
eel - save/restore window geometry
Hi, i'd like to implement window geometry save/restore in system-monitor. I'm surprised that gtk+ has no trivial support for this. I understand that nautilus uses eel and its two functions : eel_gtk_window_get_geometry_string eel_gtk_window_set_initial_geometry_from_string and that many desktop applications use custom code. Is there any plan to merge soon this feature into gtk+ ? Thanks. -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: eel - save/restore window geometry
On Mon, 2006-12-18 at 22:19 +0100, Benoît Dejean wrote: Hi, i'd like to implement window geometry save/restore in system-monitor. I'm surprised that gtk+ has no trivial support for this. I understand that nautilus uses eel and its two functions : eel_gtk_window_get_geometry_string eel_gtk_window_set_initial_geometry_from_string and that many desktop applications use custom code. Is there any plan to merge soon this feature into gtk+ ? Thanks. As a side note, Sound Juicer implements this via libgconf-bridge[1], which stores those (and eventually other properties) in gconf. Ciao, Luca [1] - http://cvs.gnome.org/viewcvs/libgconf-bridge/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Publically exposing GtkFileChooserIface
El mié, 13-12-2006 a las 11:28 +0100, Kristian Rietveld escribió: The easiest way to solve this is probably to: * Move GtkFileChooserIface into it's own, new, header file. gtkfilechooserprivate.h also contains some data structures internal to the implementation of the default file chooser which don't make sense to install. * Add GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED defines like in gtkfilesystem.h. * Get GTK+ to install it. I would really like to get this into 2.12. Objections? Suggestions? The bug for this is http://bugzilla.gnome.org/show_bug.cgi?id=382528 It's a good idea, and something that we wanted to do for 2.10, but it just fell through the cracks. However, the file chooser at this point is really buggy. I don't want to do any API work on it until the bugs are fixed. Making the Iface public is more or less orthogonal to fixing the bugs, but making it public would require documenting it, polishing the bits of the interface that are really too specific to the current implementation, etc. All that would take resources away from fixing the bugs in the default implementation. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widgets II
On Ter, 2006-12-19 at 14:18 +0100, Tim Janik wrote: hey All. here's a refined proposal for pluggable widgets, incorporating the recent comments from Damon Chaplin and Paul Pogonyshev. the motivation for pluggable widgets is supplied in the original proposal: http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00125.html and the corresponding bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864 unless any serious objections come up, the new plan is to introduce this new libgobject API: gpointer g_factory_create (GTypetype, const gchar *first_property_name, ...); Think of the poor language bindings! Please add this API to the list: gpointer g_factory_createv (GType object_type, guint n_parameters, GParameter *parameters); Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widgets II
Tim Janik wrote: here's a refined proposal for pluggable widgets [...] Looks fine to me, except that I support the requested addition of va_list version of g_factory_create(). Otherwise everything seems good. Paul ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widgets II
2006/12/19, Tim Janik [EMAIL PROTECTED]: - g_object_factory_ was suggested as namespace for this factory. that'd be technically correct because the API is supposed to only create GObject derived types, however g_object_factory_ is significantly longer and i think we can be pretty certain to not need other fundamental object types in libgobject any time soon, so picking g_factory_ isn't too risky. What about other factories? It's always sucky to have The foo after you come up with the idea that this other foo which does baz instead of bar would be handy too. Then you really wish[1] you had named The foo as foo_bar so now the API would have more clarity (foo_baz is for baz? What's for bar then? Just foo? Why on earth..?)[2]. Besides, breaking so far uniform API (I think?) to manipulate GObjects just to save characters sounds like a bad policy to me. At least the proposed API calls are not gigantic by any standard. - g_factory_new (type, ...) was suggested to create objects instead of g_factory_create (type, ...). i think that naming is too similar to naming a factory constructor and suggested that a factory is created. to avoid that impression, i personally prefer g_factory_create(). This I agree with strongly. [1] I speak from experience with the issue. I named ScwView simply view and now that I want to add another viewing widget, it's silly to have a view and then the other view... [2] Example API is fictive. Any resemblance to actual API calls is purely coincidal. P.S. This all sounds very much like GStreamer, which opens up some interesting paths to walk for the little grey cells :) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widgets II
On Tue, 2006-12-19 at 21:51 +0200, Paul Pogonyshev wrote: Tim Janik wrote: here's a refined proposal for pluggable widgets [...] This isnt really a concern, just curious... g_factory_appoint (TYPE_BAR, TYPE_BAZ); g_factory_appoint (TYPE_FOO, TYPE_BAR); g_factory_get_appointed (TYPE_FOO) == TYPE_BAZ ? On first thought, I would probably favour this behavior (i.e. above statement evaluates TRUE), but more importantly I was just raising that because I didnt see mention of it before in the mails and I just think it should be clear in docs etc :) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widgets II
On Tue, 19 Dec 2006, Tristan Van Berkom wrote: On Tue, 2006-12-19 at 21:51 +0200, Paul Pogonyshev wrote: Tim Janik wrote: here's a refined proposal for pluggable widgets [...] This isnt really a concern, just curious... g_factory_appoint (TYPE_BAR, TYPE_BAZ); g_factory_appoint (TYPE_FOO, TYPE_BAR); g_factory_get_appointed (TYPE_FOO) == TYPE_BAZ ? On first thought, I would probably favour this behavior (i.e. above statement evaluates TRUE), but more importantly I was just raising that because I didnt see mention of it before in the mails and I just think it should be clear in docs etc :) right, i'd not expect this to be a too common use case, but maybe i'll be proven wrong on this one. in any case, i think it makes sense to support repeated lookups for re-appointed types, provided some measurements are taken to prevent endless recursion ;) Cheers, -Tristan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
