Does GTK has something similar to SC_KEYMENU from Windows API?
Hi everybody, Does GTK has something similar to SC_KEYMENU from Windows API? For example, when user press Alt-Space on Windows to evoke the system menu(or Alt-F to evoke the File menu, etc.), then the process would receive a message called WM_SYSCOMMAND with SC_KEYMENU as its parameter. Does GTK has something similar? The following link is the document of SC_KEYMENU from Microsoft's website: http://msdn.microsoft.com/en-us/library/ms646360%28VS.85%29.aspx See the wParam and Remarks part of the webpage. Thanks very much. Regards H Xu 2010/12/2 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Signal inside widget subclass
Lets say your buffer's class is like
typedef struct _MyTextBufferClass
{
GtkTextBufferClass parent_class;
// more stuff here
} MyTextBufferClass;
Basicaly in my_text_buffer_class_init override changed function
void my_text_buffer_class_init(MyTextBufferClass *klass)
{
GtkTextBufferClass* tbc = (GtkTextBufferClass*)klass;
tbc-changed = your_function_name_here;
}
And then in your function call previous function
void your_function_name_here(GtkTextBuffer *buffer)
{
// your stuff here
GTK_TEXT_BUFFER_CLASS(my_text_buffer_parent_class)-changed(buffer)
}
On 12/02/2010 04:42 AM, Erick Pérez Castellanos wrote:
Hi:
I have this design issue: I’m kinda newbie with gtk development, so
sorry is this is the first line on some mystery tutorial out there .
I’m subclassing a Gtk.TextBuffer and I want to know inside the widget
code when the “changed” signal is emitted. I know I always can connect a
callback to the signal, that why they exist anyway, but that sound like
something I wouldn't do inside the widget.
Is it correct ? At least from the Gtk development/design point view. It
works, really well, my point is purely about design, maybe there a
better and prettier way of doing this.
Thxs
___
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: libgdk_pixbuf, VC++ and TIFF files.
On 30 Nov 2010, at 15:47, John Emmas wrote:
gdk_pixbuf_new_from_file() opens the specified file using g_fopen() which in
turn, calls _wfopen(). This returns a FILE*. Next,
_gdk_pixbuf_generic_image_load() gets used to read the subsequent TIFF data.
That process starts with the FILE* getting sent to _fileno() which returns a
'C' run time file handle. That file handle eventually gets passed to
TIFFFdOpen() which in turn, calls TIFFClientOpen() to read in the TIFF header.
Unfortunately, the Win32 version tries to read the TIFF header courtesy of
the Windows function 'ReadFile()'. AFAIK, ReadFile() will only accept file
handles returned from CreateFile() - not from fopen() or _wfopen().
Consequently, libgdk_pixbuf fails to read the TIFF data (on Win32/VC++)
because it used g_fopen() to open the file, instead of using TIFF's own
TIFFOpen() function, which would have opened the file using CreateFile()
After posting a question on the libTIFF mailing list I discovered that there
were already some POSIX style file handlers available (read() / write() etc)
that I could use instead of the Win32 ones. This solved my problem but it
threw up another problem in the TIFF handler for libgdk-pixbuf, namely in the
module 'io-tiff.c'. Here's the relevant section from the function
'gdk_pixbuf__tiff_image_load()' (not sure if my formatting will work via the
mailing list):-
static GdkPixbuf*
gdk_pixbuf__tiff_image_load (FILE *f, GError **error)
{
TIFF *tiff;
int fd;
GdkPixbuf *pixbuf;
[ ... ]
fd = fileno (f);
tiff = TIFFFdOpen (fd, libpixbuf-tiff, r);
if (!tiff || global_error) {
tiff_set_error (error,
GDK_PIXBUF_ERROR_CORRUPT_IMAGE,
_(Failed to open TIFF image));
tiff_pop_handlers ();
return NULL;
}
pixbuf = tiff_image_parse (tiff, NULL, error);
TIFFClose(tiff);
[ ... ]
return pixbuf;
}
The important thing to note is that TIFFFdOpen() does not actually open a file.
The file must have already been opened by some external process, prior to
calling the above function. However, TIFFClose() does in fact close the file.
This means that when the external process tries to close it, there's a risk of
it crashing or asserting. AFAICT the call to TIFFClose(tiff); should really
have been TIFFCleanup(tiff);
I tried substituting the alternative function and it seemed to fix the problem.
This needs to be fixed quite urgently in libgdk-pixbuf because if it's
currently working on any given compiler, it's purely by luck..!
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GDK-Pixbuf question, creating and reading private data-chunk for png
Hello, I am using gdk_pixbuf_save to store a gdk_drawable into a PNG File. Now I want to add a private data-chunk to PNG to store some additional Information. Is it possible to add a private data-chunk with GDK functions? If not, what do you think would be the best way to create this file? Using libpng with png_set_unknown_chunks() ? Is there any examplke of how I get GDK-IMAGE-DATA to libpng? regards Arne ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Shrinking and growing widgets in GTK+ 3.x
On Thu, 2010-12-02 at 13:07 +0900, Tristan Van Berkom wrote: On Thu, 2010-12-02 at 00:56 +, Bastien Nocera wrote: Heya, snip If you want the whole window to shrink, a.) that's a little yuck, I'm not sure how much end-users like that behaviour ... b.) GTK+ doesnt like doing that... but if I recall correctly you might provoke GTK+ to do that by calling gtk_container_check_resize()... I'd have to take a deeper look to make sure. It might be yuck, but it's a feature other movie players implement, and something we implemented a long time ago: commit 9567aa7563ddd1cb6d38ee65bc42eb6ff5942804 Author: Bastien Nocera had...@hadess.net Date: Sun Sep 15 20:48:15 2002 + added /apps/totem/auto_resize implement automatically changing the ratio 2002-09-15 Bastien Nocera had...@hadess.net * data/totem.schemas.in: added /apps/totem/auto_resize * src/gtk-xine.c: (frame_output_cb), (gtk_xine_idle_signal), (gtk_xine_ratio_fits_screen), (gtk_xine_set_scale_ratio): implement automatically changing the ratio when the video changes size (Closes: #92320) Note that it's disabled by default. gtk_container_check_resize() is lacking documentation in my day old checkout of gtk+. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shrinking and growing widgets in GTK+ 3.x
Hi, It seems like the following would work but maybe I'm missing the obvious * have the video request natural size = its natural unscaled size, and min size of whatever lowest scale factor you want to allow * to snap to natural size, just size request the entire toplevel to get the natural size, then gtk_window_resize() to that size Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shrinking and growing widgets in GTK+ 3.x
On Thu, 2010-12-02 at 00:56 +, Bastien Nocera wrote: Heya, One of the features of Totem (and one implemented in a number of movie players) is to resize the video to match the actual video size (or a multiple of it). For example, a 320x480 video would see Totem resize its video canvas to 480x320, if the preference is enabled. The old GTK+ 2.x code did that by: - shrinking the toplevel to 1x1 (so all the widgets in the window get their minimum size set) - wait for the size-request - request our real size (480x320) in the size-request signal - and unset that size request in an idle (so that the window can be shrinked) Is there some reason that your real size is computable only in the size request signal? The simple thing to do would be something like: gtk_window_set_geometry_hints (window, video_canvas, /* geometry_widget */, NULL, 0); /* hints/mask */ gtk_window_resize_to_geometry (window, 480, 320); Then code in GtkWindow will take care of figuring out what that means for the size of your toplevel. [ I'm not 100% sure how this will interact with the GtkPaned usage in Totem without more thought and looking at the GtkPaned code. ] - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: IPv6 Link local addresses not supported.
On 11/30/2010 12:12 PM, Achuta wrote: Hi, GLib/GIO cannot listen on IPv6 link local address. This bug is because GSocketAddress does not have a field for sin6_scope_id to fill in interface index (as stated in `man 7 ipv6`). I would like to make the changes. Is there some manual/procedures on code contribution and submission? Not really... read the existing code and make something that looks similar basically. (And then attach it to the bug you filed, in git format-patch format, or use git-bz to automate that.) In this case you'd probably want to add g_inet_socket_address_get_scope_id() and g_inet_socket_address_set_scope_id(). -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
More GTK breakage
Hey everyone, If you read this mail, it's probably because GTK made your compile fail. Again. It might be because the final part of the GTK3 rendering cleanup has landed. This part only touches GDK APIs, so most applications should not be affected at all. If your app has been affected nonetheless, it's often one of these issues: - GdkDrawable has been removed. In that case, just replace all occurences of GdkDrawable with GdkWindow and you should be fine. - The GDK_DRAWABLE() macro is gone. Oftentimes, it can just be omitted. Otherwise, you likely want to use the GDK_WINDOW() macro. - GDK_WINDOW_XWINDOW() is gone. Use the gdk_x11_window_get_xid() to get it. I'm transitioning all code to provide a gdk_x11_foo_get_xid() function exclusively, so futureproof code should use that function. - A few remaining calls (mostly in gdkx.h) that were called gdk_drawable_foo() are now called gdk_window_foo(). Most prominently gdk_x11_drawable_get_xid() is now called gdk_x11_window_get_xid(). As always, if you have any issues, feel free to poke me. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shrinking and growing widgets in GTK+ 3.x
On Thu, 2010-12-02 at 11:51 -0500, Havoc Pennington wrote: Hi, It seems like the following would work but maybe I'm missing the obvious * have the video request natural size = its natural unscaled size, and min size of whatever lowest scale factor you want to allow * to snap to natural size, just size request the entire toplevel to get the natural size, then gtk_window_resize() to that size It might work :) I went with Owen's solution, and it seems to behave as expected even with the GtkPaned (though it already had some custom code to handle the resizing there). Thanks for the help. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
