Cairo clearing problem.
Hi all!
Well, I'm having a problem with clearing a line.
---
cairo_t *cr;
cr = gdk_cairo_create (widget-window);
cairo_set_source_rgba (cr, 0, 0, 0, 1);
static const double dashed[] = { 3.0 };
cairo_set_line_width (cr, 1.5);
cairo_set_dash (cr, dashed, 1, 0);
cairo_move_to (cr, RECTANGLE_GAP, RECTANGLE_GAP);
cairo_rel_line_to (cr, width - (RECTANGLE_GAP * 2), 0);
cairo_rel_line_to (cr, 0, height - (RECTANGLE_GAP * 2));
cairo_rel_line_to (cr, -(width - (RECTANGLE_GAP * 2)), 0);
cairo_close_path (cr);
cairo_stroke (cr);
cairo_destroy (cr);
---
It intends to set a dotted rectangle around the
border of a GtkVBox. Then, it must be erased
without affecting the inner widgets.
I thought that having the current path
it could be used after to clear just that drawn
in this path. Is there a way to do it?
I've used gdk_window_clear (), but child widgets
in the box are cleared also, which is undesired
of course.
Any suggestion ?
Thanks in advance...
Carlos Savoretti.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Issue with GIO monitoring
Hi, I have a bit of an odd issue - my GFileMonitor setup wasn't working (callback not changed). So to isolate the program and maybe show why the code wasn't working, I isolated it into it's own program... and it worked. Looked back into how I did it in the main program, it's still exactly the same, sans the callback getting called. What steps should I take to debug this? I did have an issue before with gio complaining heavily of g_type_init() not being called, but it's happy now that its called. Maybe it's related? Thank you. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Cairo clearing problem.
Hi, Carlos
Where do you use your drawing operation? As GTK suggested (like
GtkDrawingArea), you have to do it in expose_event:
* The expose_event signal to handle redrawing the contents of the widget.
Here you can have several if's:
if (something)
draw_lines();
else
draw_other_lines();
something can be a simple enum, or gboolean, which is assigned
elsewhere. By the way, after changing it, you can send signals by
yourself, to redraw your widget.
Good luck,
Vlad Volodin
2009/5/8 Developer csavore...@clubsanjorge.com.ar:
Hi all!
Well, I'm having a problem with clearing a line.
---
cairo_t *cr;
cr = gdk_cairo_create (widget-window);
cairo_set_source_rgba (cr, 0, 0, 0, 1);
static const double dashed[] = { 3.0 };
cairo_set_line_width (cr, 1.5);
cairo_set_dash (cr, dashed, 1, 0);
cairo_move_to (cr, RECTANGLE_GAP, RECTANGLE_GAP);
cairo_rel_line_to (cr, width - (RECTANGLE_GAP * 2), 0);
cairo_rel_line_to (cr, 0, height - (RECTANGLE_GAP * 2));
cairo_rel_line_to (cr, -(width - (RECTANGLE_GAP * 2)), 0);
cairo_close_path (cr);
cairo_stroke (cr);
cairo_destroy (cr);
---
It intends to set a dotted rectangle around the
border of a GtkVBox. Then, it must be erased
without affecting the inner widgets.
I thought that having the current path
it could be used after to clear just that drawn
in this path. Is there a way to do it?
I've used gdk_window_clear (), but child widgets
in the box are cleared also, which is undesired
of course.
Any suggestion ?
Thanks in advance...
Carlos Savoretti.
___
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
File Chooser patches to review
Hi! I've made a few patches to fix several little bugs that we have in the GtkFileChooser for some time. Some have been reviewed, approved, but eventually forgotten, and others did not get any response. While there's no hurry to apply them before the next release, I suspect they won't get any attention until the final rush, and finally won't be committed. So many patches have rotten this way... ;-) These little details are IMHO the only remaining problems that make users angry about our nice file chooser (now that dialog size is fixed). I think fixing them is worth the pain! So here's the list: * Remove error dialog when directory does not exist http://bugzilla.gnome.org/show_bug.cgi?id=562579 - Improve my previous committed patch by extending its logic, should not be a problem. * Resume editing if name of new folder is Type name of new folder http://bugzilla.gnome.org/show_bug.cgi?id=171416 - Commit accepted by Federico, but I don't have commit rights. * File Dialog shows Backup Files http://bugzilla.gnome.org/show_bug.cgi?id=355851 - No response, the bug was dead since 2007. Pretty basic fix too. * 'Places' items should not move up and down the whole UI when selected http://bugzilla.gnome.org/show_bug.cgi?id=486839 - I've attached a patch that's not been reviewed. This one may require some discussion, but it works quite well. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File Chooser patches to review
2009/5/10 Milan Bouchet-Valat nalimi...@club.fr: Hi! I've made a few patches to fix several little bugs that we have in the GtkFileChooser for some time. Some have been reviewed, approved, but eventually forgotten, and others did not get any response. While there's no hurry to apply them before the next release, I suspect they won't get any attention until the final rush, and finally won't be committed. So many patches have rotten this way... ;-) These little details are IMHO the only remaining problems that make users angry about our nice file chooser (now that dialog size is fixed). I think fixing them is worth the pain! So here's the list: I'm in same situation as Milan, so I'll take the chance of his email to add mine to the list: * Focus issues in file chooser http://bugzilla.gnome.org/show_bug.cgi?id=534462 - I attached two alternative patches, for two different ways of fixing the bug, I would like review and opinion about what patch is preferred. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
Alexander Larsson schrieb: With gnome 2.26 out and the GResolver branch landed it is time to start look at merging the gnio network code into gio. I'm posting this here, plus CC:ing the involved people instead of on bugzilla in order to get feedback from others who may be interested but unaware of this work. Its a bit late - Is there an object called GResolver? If so could that be named GNameResolver or something simillar - or would it be GNIOResolver?. I feel GResolver sounds too generic. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: windows [Re: Review of gnio, round 2]
Alexander Larsson wrote: I was going to say we could make g_socket_listen() set it but actually, you need to do it before calling bind(). I'm not really familiar with the use cases of bind() on client sockets, but it seems like probably if the application is trying to bind to a specific local port, even for a client socket, then it probably really does want that port, so setting SO_REUSEADDR in g_socket_bind() even in the client case should be ok. Alternatively, maybe g_socket_bind() could just take a flag saying whether or not to set SO_REUSEADDR, or else g_socket_listen() could be modified to do both bind() and listen() (and SO_REUSEADDR), and then g_socket_bind() would be only for the client-side case and would not set SO_REUSEADDR. (This moves a little further from the underlying API, but it's always seemed a little pointless to me to have bind and listen be separate syscalls anyway...) Bind in the client is mainly done when you want to listen to only one interface, so then generally port == 0, so i guess we could autoset this if port == 0 when binding to a IPV4 or IPV6 SOCKET_STREAM type with NULL or tcp protocol. If port==0 then SO_REUSEADDR is irrelevant because the kernel is going to assign you a port that's not in use anyway, right? And anyway, I was talking about the case where you bind() and then connect(), not bind() and then listen(). If you're listening, then from an API POV, you're a server and presumably want SO_REUSEADDR (if you're listening on a specific port), even if you're a client from the protocol POV (eg, an ftp client doing an active transfer). But if you bind() and then connect() (eg, like the rcmd/rsh/rlogin suite) then maybe you don't want SO_REUSEADDR. (And looking at the glibc source for rresvport(), it doesn't use SO_REUSEADDR, and instead just keeps trying different ports at random until it either succeeds or gets an error other than EADDRINUSE.) I'm not sure if there are use cases for bind+connect that don't involve prehistoric authentication models... -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
