Re: How to determine *actual* visible region of a window?
Gaurav Jain wrote: For the purpose of my application, I need to programmatically determine the actual 'exposed' region of a gdk window. The exposed region should not include any obscured regions of the window. For example, if there's some external window in front of my application's window, then the exposed region should not include the area obscured by that external window, but should include all other area that's visible. I tried using the API gdk_drawable_get_visible_region() but this doesn't exclude the obscured regions, so it's not of my use. Does somebody know of any suitable API that I can use to achieve what I want? Or is there a method that somebody could suggest that I could use to calculate this region? I'm pretty much a beginner with gtk but I do know a bit about X and you haven't had an answer, so here's what I understand: What is currently exposed is dynamic, of course, so it's event driven. I believe you need to get the GdkEventExpose structure from a GdkEvent of type GDK_EXPOSE and then look at the GdkRegion structure within it, which contains the information you're looking for. You'll need to enable such events on your window. You can also cause such an event any time you want by calling queue_redraw. HTH, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Flickering display (using RGB buffer to write on a DrawingArea)
Konstantin Evdokimenko wrote: Use this on your expose event callback. gdk_window_begin_paint_rect(widget-window, rect); /* Draw something */ gdk_window_end_paint(widget-window); And make sure that widget is double buffered (by default). Look at gtk_widget_set_double_buffered function. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list Thanks. I tried that, but that didn't work. By the way, aren't gdk_window_begin_paint_rect and gdk_window_end_paint automatically called before and after (respectively) the expose-event when double buffering is switched on for a GtkWidget ? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: drag-data-received signal not being emitted
Chris Morrison wrote: Hi all, I am trying to write a GTK/GNOME application. It has a main window with GtkTreeView control on to which you can drag and drop files from Nautilus. The code I have used to set up the widgets is: snip However, although the drag_drop signal is being received OK the drag_data_received signal is not being emitted at all. I have scoured the GTK documentation and Google but can find nothing on this. Any pointers would be appreciated. I'm also trying to make drag-and-drop work in a tree and not finding much in the docs. The best docs I've found so far are for the Python bindings. Try: http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html http://faq.pygtk.org/index.py?req=showfile=faq13.033.htp http://faq.pygtk.org/index.py?req=showfile=faq13.034.htp In particular, I believe you will also need to call gtk_tree_view_enable_model_drag_dest and/or gtk_tree_view_enable_model_drag_dest on the tree_view. That said, I haven't managed to make it all work yet, so I'd be very interested to see any working code - in my case for a tree rather than a list. Cheers, Dave Regards, 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: drag-data-received signal not being emitted
I wrote: In particular, I believe you will also need to call gtk_tree_view_enable_model_drag_dest and/or gtk_tree_view_enable_model_drag_dest on the tree_view. Oops. Second one should be gtk_tree_view_enable_model_drag_source of course. Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: drag-data-received signal not being emitted
I wrote: I'm also trying to make drag-and-drop work in a tree and not finding much in the docs. The best docs I've found so far are for the Python bindings. Murphy's alive and well. Just twenty minutes later and my words are wrong :) I've just found this site: http://www.codase.com/search/call?name=gtk_tree_view_enable_model_drag_sourceowner=lang=*project=search=Searchtype=parameters=nparams=-1obj=constant= I'm hopeful it might have some interesting links. Cheers, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+, building a display
I already searched and asked for this on the GTK+/GTK+Devel lists but I didn't get any answer, so I'll ask again: is there any way to set the font width or height size? I mean, not the font size in points but the font width or height in pixels. I'm doing a display in GTK+ for a POS emulator and I need to set the font width and font height to get some efects like double width or double height. At the moment I'm using some functions from the Pango lib, like pango_matrix_scale and pango_layout_get_pixel_size, to do this, but this is very annoying, since I have to start from a size in points like 0.5 and go to something like MAX_TEST_SIZE, testing all the values from pango_layout_get_pixel_size to see if any of them is in my desirable font width or height. I don't need to say that this consumes a lot of time and CPU usage. Another way to see my problem is answering this question: if I have a display with 168x136 pixels and 21x8 cols what font size, in points, should I use that best fits this display? The display size can change (the user can change the skins) at runtime, so I must recalculate this every time. Leonel Freire ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkTreeView total height.
Hi all!
I'd need to compute the total height of a treeview based on the
amount of rows its model has. I've tried with the following
code but I had to set some constants that obviously works in my
specific setting but I would like to know to what correspond
that unknowns.
Thanks in advance.
Here the code:
-
static guint
get_row_height (GtkTreeView *tree_view)
{
guint row_height = 0;
GList *columns = gtk_tree_view_get_columns (tree_view);
GList *current = columns;
while (current) {
GtkTreeViewColumn *renderers =
gtk_tree_view_column_get_cell_renderers
((GtkTreeViewColumn *) current-data);
guint cell_height = 0;
GList *current1 = renderers;
while (current1) {
GtkCellRenderer *renderer = (GtkCellRenderer *)
current1-data;
guint height;
gtk_cell_renderer_get_size (renderer,
GTK_TREE_VIEW(tree_view),
NULL, NULL, NULL, NULL,
height);
if (height cell_height)
cell_height = height;
current1 = g_list_next (current1);
}
g_list_free (renderers);
if (cell_height row_height)
row_height = cell_height;
current = g_list_next (current);
}
g_list_free (columns);
row_height += 4; /* horizontal-separator ? */
return row_height;
}
---
gint grid_height = n_rows * get_row_height (tree_view)
+ 35; /* header height ? */
---
-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to determine *actual* visible region of a window?
On 6/27/07, Dave Howorth [EMAIL PROTECTED] wrote: Gaurav Jain wrote: For the purpose of my application, I need to programmatically determine the actual 'exposed' region of a gdk window. The exposed region should not include any obscured regions of the window. For example, if there's some external window in front of my application's window, then the exposed region should not include the area obscured by that external window, but should include all other area that's visible. I tried using the API gdk_drawable_get_visible_region() but this doesn't exclude the obscured regions, so it's not of my use. Does somebody know of any suitable API that I can use to achieve what I want? Or is there a method that somebody could suggest that I could use to calculate this region? I'm pretty much a beginner with gtk but I do know a bit about X and you haven't had an answer, so here's what I understand: What is currently exposed is dynamic, of course, so it's event driven. I believe you need to get the GdkEventExpose structure from a GdkEvent of type GDK_EXPOSE and then look at the GdkRegion structure within it, which contains the information you're looking for. You'll need to enable such events on your window. You can also cause such an event any time you want by calling queue_redraw. HTH, Dave Thank you for your reply Dave. I have tried doing this programmatically (by invalidating the window's rect and then calling gdk_window_process_updates() ) but that results in expose events with the entire update region, including the areas that are actually obscured. However, if the window is shown as a result of user action (by say minimizing and then maximizing) with another smaller window in front of that window, then the expose events are emitted with the correct expose region (i.e., excluding the obscured windows). I wonder if there's a way to programmatically determine at any point of time what is the currently exposed/visible region of a given gdk window. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk with .po files
David Nečas (Yeti) wrote: Ignore the inti parts there, though. I'd rather point to http://www.gnu.org/software/gettext/manual/gettext.html and after groking the basic concepts, look at any internationalized Gtk+ application as working real world examples are better than tutorials. I suggest that too. In addition there are IDEs (e.g. Anjuta) that set up the whole directory structure and build enviroment for you. But you have still to understand the concepts. Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
motion-notify-event works only once
Hi, I've set up a motion-notify-event handler in a GtkDrawingArea, adding the POINTER_MOTION and POINTER_MOTION_HINT event masks to the widget. The event is triggered only when the pointer moves into the window. I'd like to receive an event for each movement of the pointer. Is there something I might have missed, or is it abnormal behaviour? Thanks in advance ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: motion-notify-event works only once
On Wed, Jun 27, 2007 at 05:46:57PM +0200, Jerome Blondel wrote:
I've set up a motion-notify-event handler in a GtkDrawingArea, adding
the POINTER_MOTION and POINTER_MOTION_HINT event masks to the widget.
The event is triggered only when the pointer moves into the window. I'd
like to receive an event for each movement of the pointer. Is there
something I might have missed,
Yes, the fact that no one knows what your code really does
if you don't post it.
Anyway, this works:
#include gtk/gtk.h
static gboolean
motion(GtkWidget *area,
GdkEventMotion *event)
{
if (event-is_hint) {
gint x, y;
gdk_window_get_pointer(area-window, x, y, NULL);
g_print(Motion (hint): %d %d\n, x, y);
}
else
g_print(Motion: %g %g\n, event-x, event-y);
return FALSE;
}
int
main(int argc, char *argv[])
{
GtkWidget *window, *area;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, destroy, G_CALLBACK(gtk_main_quit), NULL);
area = gtk_drawing_area_new();
gtk_widget_add_events(area,
GDK_POINTER_MOTION_MASK
| GDK_POINTER_MOTION_HINT_MASK);
gtk_container_add(GTK_CONTAINER(window), area);
g_signal_connect(area, motion-notify-event, G_CALLBACK(motion), NULL);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
The thing you *possibly* forgot is to call
gdk_window_get_pointer() which you have to as you explicitly
asked -- by using GDK_POINTER_MOTION_HINT_MASK -- not to get
any further events until you call gdk_window_get_pointer().
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: Newbie Question: How i can use glib-2.0 in my c-programm ?
On Tue, 2007-06-26 at 23:27 +0200, Kai Szymanski wrote: Sorry, german text. It say's: test.c:6: Error: »gstring« not declared This is because C is case sensitive. Try GString instead of gstring. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to determine *actual* visible region of a window?
Hi, I'm no expert, but AFAIK that information would have to be returned by the X server/whatever, and I expect the server will try and send the least possible events, eg. the smallest rectangle comprising all the surface to redraw. Plus, IIRC expose events won't tell you what has been covered, only uncovered, so if you obscure part of your window, you won't know it was until it gets unobscured again. Of course, I may be mistaken... Why do you need this information ? (if i may ask ;-) ) Regards, Jonathan On 6/27/07, Gaurav Jain [EMAIL PROTECTED] wrote: On 6/27/07, Dave Howorth [EMAIL PROTECTED] wrote: Gaurav Jain wrote: For the purpose of my application, I need to programmatically determine the actual 'exposed' region of a gdk window. The exposed region should not include any obscured regions of the window. For example, if there's some external window in front of my application's window, then the exposed region should not include the area obscured by that external window, but should include all other area that's visible. I tried using the API gdk_drawable_get_visible_region() but this doesn't exclude the obscured regions, so it's not of my use. Does somebody know of any suitable API that I can use to achieve what I want? Or is there a method that somebody could suggest that I could use to calculate this region? I'm pretty much a beginner with gtk but I do know a bit about X and you haven't had an answer, so here's what I understand: What is currently exposed is dynamic, of course, so it's event driven. I believe you need to get the GdkEventExpose structure from a GdkEvent of type GDK_EXPOSE and then look at the GdkRegion structure within it, which contains the information you're looking for. You'll need to enable such events on your window. You can also cause such an event any time you want by calling queue_redraw. HTH, Dave Thank you for your reply Dave. I have tried doing this programmatically (by invalidating the window's rect and then calling gdk_window_process_updates() ) but that results in expose events with the entire update region, including the areas that are actually obscured. However, if the window is shown as a result of user action (by say minimizing and then maximizing) with another smaller window in front of that window, then the expose events are emitted with the correct expose region (i.e., excluding the obscured windows). I wonder if there's a way to programmatically determine at any point of time what is the currently exposed/visible region of a given gdk window. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Morpheus linux, c'est une question de VI ou de MORE ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: motion-notify-event works only once
David Nečas (Yeti) :
On Wed, Jun 27, 2007 at 05:46:57PM +0200, Jerome Blondel wrote:
I've set up a motion-notify-event handler in a GtkDrawingArea, adding
the POINTER_MOTION and POINTER_MOTION_HINT event masks to the widget.
The event is triggered only when the pointer moves into the window. I'd
like to receive an event for each movement of the pointer. Is there
something I might have missed,
Yes, the fact that no one knows what your code really does
if you don't post it.
Sorry, I should have posted the code for the event handler. Indeed I
didn't handle the hint correctly.
Anyway, this works:
#include gtk/gtk.h
static gboolean
motion(GtkWidget *area,
GdkEventMotion *event)
{
if (event-is_hint) {
gint x, y;
gdk_window_get_pointer(area-window, x, y, NULL);
g_print(Motion (hint): %d %d\n, x, y);
}
else
g_print(Motion: %g %g\n, event-x, event-y);
return FALSE;
}
int
main(int argc, char *argv[])
{
GtkWidget *window, *area;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, destroy, G_CALLBACK(gtk_main_quit), NULL);
area = gtk_drawing_area_new();
gtk_widget_add_events(area,
GDK_POINTER_MOTION_MASK
| GDK_POINTER_MOTION_HINT_MASK);
gtk_container_add(GTK_CONTAINER(window), area);
g_signal_connect(area, motion-notify-event, G_CALLBACK(motion), NULL);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
The thing you *possibly* forgot is to call
gdk_window_get_pointer() which you have to as you explicitly
asked -- by using GDK_POINTER_MOTION_HINT_MASK -- not to get
any further events until you call gdk_window_get_pointer().
___
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son
interface r�volutionnaire.
http://fr.mail.yahoo.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-data-received signal not being emitted
On Wed, 2007-06-27 at 10:43 +0100, Dave Howorth wrote: I wrote: In particular, I believe you will also need to call gtk_tree_view_enable_model_drag_dest and/or gtk_tree_view_enable_model_drag_dest on the tree_view. Oops. Second one should be gtk_tree_view_enable_model_drag_source of course. I tried using gtk_tree_view_enable_model_drag_dest() on my tree view and it caused some really strange stuff to happen: I got a segmentation fault when ever I tried to access the GList of targets in drag_context-targets in my drag_drop handler. If I returned FALSE from my drag_drop handler (i.e. to indicate the drop was not over a valid area of the widget) the drag-data-received signal was emitted but then I got a GTK critical assertion failed error. I think I might give up on the GtkTreeView and use a GtkIconView widget instead. Regards, Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
geometry hints screwing up window sizes
I've poured over the GTK+ api docs and googled myself into the ground looking for a solution to the following issue. I have an app that creates a window. inside this window is an eventbox and inside that is a GtkFixed (no slapping me for using a GtkFixed, it works well for this purpose) I want to be a be able to scale the window to ANY size. (yes i know the fixed widget doesn't handle scaling, I plan on handling that once i can sort out the resizing problems) I've used gtk_window_set_geometry_hints to set the aspect ratio, and minimum size. The problem is the windows ALWAYS default displays at the minimum size. NOT at a size I specify using (gtk_window_resize) or similar. If I do NOT set the minimum geometry hint. I CAN set the size to be larger than the Fixed widget (with its children). All I want to be able to do is tell GTK/window manager that there's a window that can be no smaller than 100x100 and no larger than 1000x1000, and I want ot be able ot set the size to any point in between those extremes. (GTK ignores me, when using the hints) any ideas? GtkFixed is required as the objects placed into it are not really widgets in the normal sense, they are mainly display items arrange in a very specific (and customizable) way, so GtkFixed was the only way to arrange things without having to do lots of manual drawing with a GtkDrawingArea. -- David J. Andruczyk Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with gtk_label_set_text
Hello everyone I am using gtk_label_set_text in a dynamic gui and label keeps on changing around 1-2 times every second.My program crashes because of this. Is there any way to do the same. Thanks Divya ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkBuilder partial tree construction
By the way, if GtkBuilder can't be used for multiple top-level widgets, we should probably check that gtk_builder_add_from_*() are not called twice on the same instance. Or does merge mean something special in Parses a file containing a link linkend=BUILDER-UIGtkBuilder UI definition/link and merges it with the current contents of @builder. ? And this would make it even more useful to have *_new_from_file() and *_new_from_string(). -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder partial tree construction
Murray Cumming wrote: By the way, if GtkBuilder can't be used for multiple top-level widgets, we should probably check that gtk_builder_add_from_*() are not called twice on the same instance. Or does merge mean something special in Parses a file containing a link linkend=BUILDER-UIGtkBuilder UI definition/link and merges it with the current contents of @builder. ? Yes, you're able to create xml definitions which refers to object created by previous calls to gtk_builder_add_*. It's not yet supporting XUL-style overlays[1] (like GtkUIManager merges for widgets), but we might support it in the future. And this would make it even more useful to have *_new_from_file() and *_new_from_string(). See http://bugzilla.gnome.org/show_bug.cgi?id=447969 for a simplified API. [1]: http://developer.mozilla.org/en/docs/XUL_Overlays -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder partial tree construction
On Wed, 2007-06-27 at 11:12 -0300, Johan Dahlin wrote: Murray Cumming wrote: By the way, if GtkBuilder can't be used for multiple top-level widgets, we should probably check that gtk_builder_add_from_*() are not called twice on the same instance. Or does merge mean something special in Parses a file containing a link linkend=BUILDER-UIGtkBuilder UI definition/link and merges it with the current contents of @builder. ? Yes, you're able to create xml definitions which refers to object created by previous calls to gtk_builder_add_*. But I guess that's not implemented at all yet, right, or is it just XUL-style overlays that are not implemented? It's not yet supporting XUL-style overlays[1] (like GtkUIManager merges for widgets), but we might support it in the future. And this would make it even more useful to have *_new_from_file() and *_new_from_string(). See http://bugzilla.gnome.org/show_bug.cgi?id=447969 for a simplified API. [1]: http://developer.mozilla.org/en/docs/XUL_Overlays -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder partial tree construction
Murray Cumming wrote: On Wed, 2007-06-27 at 11:12 -0300, Johan Dahlin wrote: Murray Cumming wrote: By the way, if GtkBuilder can't be used for multiple top-level widgets, we should probably check that gtk_builder_add_from_*() are not called twice on the same instance. Or does merge mean something special in Parses a file containing a link linkend=BUILDER-UIGtkBuilder UI definition/link and merges it with the current contents of @builder. ? Yes, you're able to create xml definitions which refers to object created by previous calls to gtk_builder_add_*. But I guess that's not implemented at all yet, right, or is it just XUL-style overlays that are not implemented? The former, you can already do this; (in the not yet wrapped python API) builder = gtk.Builder() builder.add_from_string( interface object class=GtkListStore id=liststore1/ /interface) builder.add_from_string( interface object class=GtkWindow id=window1 child object class=GtkComboBox id=combobox1 property name=modelliststore1/property /object /child /object /interface) The first call will create the tree model. The second one will create an combobox in a window using the model. -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
openPrinting + the dialog...
Hi all, I am an interaction architect and active in the openUsability scene. Some of you know me from my work on GIMP, see: http://www.mmiworks.net/eng/publications/labels/GIMP.html Others I have met at the last linuxTag. Hello again. The reason I chime in here is the openPrinting project. The goal of this project is to bring printing that just works to every linux desktop. The project has wall–to–wall support of printing manufacturers, linux distros and dektop platforms. Some of you may know this project, Larry Ewing presented the gtk printing dialog spring last year to the openPrinting summit in Atlanta. OpenUsability is also involved with this project, that means that professional usability experts and interaction architects are giving user interaction in the printing workflow a fresh look in a structural way. I am leading the interaction architecture side. Currently we are concentrating on print dialogs, the printer installation side will be dealt with later on in the project. Here is in my blog the progress we have made up to now, in reverse chronological order: http://www.mmiworks.net/eng/publications/labels/openPrinting.html Now that we have mock-ups to show of the new concepts we are introducing in the printing dialog, it is the right time to start working with the UI toolkits like gtk on moving towards implementation. I would like to get in touch with those of you who work(ed) on the gtk print dialog, to ramp up a cooperation. look forward to working with you guys, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
scrolling big windows on win32, revisited
There was a thread on this topic -- the perils of trying to scroll through more than about 1000 gtktreeview rows on Windows -- a couple of years ago: http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00089.html If I'm making the right inference from googling subsequent developments, this is now fixed post GTK 2.6. However, app developers who want to support win98 are stuck with GTK 2.6. This may be asking too much, but is there any chance (Tor?) of getting a backport of the fix to 2.6? I for one would be very grateful. I'd do it myself except that I'm not set up to build gtk for win32. (BTW, I searched today, and couldn't find a GTK 2.6 win32 binary distribution anywhere. Tor has old stuff up to 2.4 archived, and gnome.org has 2.8 and above. Since 2.6 was the last version compatible with win98, it seems it would be a good thing to have the 2.6 runtime package available somewhere.) -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: scrolling big windows on win32, revisited
On Wed, 27 Jun 2007, Jernej Simon+AQ0-i+AQ0- wrote: On Wed, 27 Jun 2007 15:23:12 -0400 (EDT), Allin Cottrell wrote: (BTW, I searched today, and couldn't find a GTK 2.6 win32 binary distribution anywhere. Tor has old stuff up to 2.4 archived, and gnome.org has 2.8 and above. Since 2.6 was the last version compatible with win98, it seems it would be a good thing to have the 2.6 runtime package available somewhere.) It's available on my GIMP for Windows installers page: http://gimp-win.sourceforge.net/stable.html#gtkold Thanks, that's good to know. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Using the gtk print backend with CUPS and SSL
With the patches referenced in http://bugzilla.gnome.org/show_bug.cgi?id=451070 I've been able to get a list of printers from my local CUPS server which requires SSL. However, it takes a long time with a ~30 second wait for a response from the CUPS server while the whole gtk app blocks. I bet this is due to the app opening an initializing dozens of SSL sockets to the server - a new one for each request, without closing any of them. Eventually the server will respond to the last connection, and the printer list will fill. Does anybody have any tips for the best way to go about re-using one SSL socket for those requests, or at least closing the connection after each request? Thanks, Vince ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using the gtk print backend with CUPS and SSL
On 6/27/07, Vince Busam [EMAIL PROTECTED] wrote: With the patches referenced in http://bugzilla.gnome.org/show_bug.cgi?id=451070 I've been able to get a list of printers from my local CUPS server which requires SSL. However, it takes a long time with a ~30 second wait for a response from the CUPS server while the whole gtk app blocks. I bet this is due to the app opening an initializing dozens of SSL sockets to the server - a new one for each request, without closing any of them. Eventually the server will respond to the last connection, and the printer list will fill. Does anybody have any tips for the best way to go about re-using one SSL socket for those requests, or at least closing the connection after each request? The cups backend needs to be fixed to use a single connection anyway. The current method of using multiple connections was hitting cups max-connection limits at about 220 printers until I did some minimal fixes recently. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: openPrinting + the dialog...
Hi Peter, Nice to meet you again. Now that we have mock-ups to show of the new concepts we are introducing in the printing dialog, it is the right time to start working with the UI toolkits like gtk on moving towards implementation. I've seen those mockups at the LinuxTag and the idea to use tags instead of tabs for organizing looked very reasonable for me. Well choosen tags allow the user to quickly reach the options they need for their current printing task without endlessly searching complex notebook pages. The power of using tags to organize information instead of some artificial hierarchy has been demonstrated several times already in applications like Epiphany, F-Spot and on several Web 2.0 sites. So I highly recommand considering those mockups for a future versions of the printing dialog. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: openPrinting + the dialog...
On 6/27/07, Mathias Hasselmann [EMAIL PROTECTED] wrote: So I highly recommand considering those mockups for a future versions of the printing dialog. What future versions of the printing dialog ? We have one now, and I don't see hordes of volunteers who are eager to rewrite it... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
