Re: GTK app development for windows.
On 01/30/2013 09:32 AM, Ardhan Madras wrote: One thing you should know that most version of GTK+ in today Linux system is using version 3.x. The latest maintained version of GTK+ for Windows is 2.24, this is pretty old (almost 2 years ago). I don't know when will the GTK+ 3 comes to Windows. Hoperfully someone would tell us what happen on GTK+ 3 for Windows. I recommended you to use also GTK+ 2 in Linux, and you can build it with no or less efforts in Windows compared if you use GTK+ 3 in Linux but build it with GTK+ 2 in Windows. Regards. Not sure where you are getting your information. I just built HandBrake using the mingw tools on Fedora 18 with gtk+ 3 support. Works spiffy. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK app development for windows.
On 01/30/2013 11:24 AM, Andrew Potter wrote: On Wed, Jan 30, 2013 at 10:52 AM, John Stebbins stebb...@jetheaddev.comwrote: Not sure where you are getting your information. I just built HandBrake using the mingw tools on Fedora 18 with gtk+ 3 support. Works spiffy. Presumably he is getting his information from http://www.gtk.org/download/win32.php It is relatively easy to cross-compile a Gtk3 Windows .exe with mingw. But how do you give users the program? They need the Gtk3 dependency .DLLs to run it. There is no Gtk3 installer. Do you have your own installer and distribute the .DLLs that are in the Fedora packages? I'm curious to know if that works. Also if you could share some details on your installer I would appreciate it. Thanks ___ Ah, never bothered to look for an official user oriented gtk release. I figure it's unreasonable to expect users to install all of gtk just so they can try out some random program that happens to use gtk. So I just package the necessary DLLs and other configuration information with the exe. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK app development for windows.
On 01/30/2013 11:24 AM, Andrew Potter wrote: On Wed, Jan 30, 2013 at 10:52 AM, John Stebbins stebb...@jetheaddev.comwrote: Not sure where you are getting your information. I just built HandBrake using the mingw tools on Fedora 18 with gtk+ 3 support. Works spiffy. Presumably he is getting his information from http://www.gtk.org/download/win32.php It is relatively easy to cross-compile a Gtk3 Windows .exe with mingw. But how do you give users the program? They need the Gtk3 dependency .DLLs to run it. There is no Gtk3 installer. Do you have your own installer and distribute the .DLLs that are in the Fedora packages? I'm curious to know if that works. Also if you could share some details on your installer I would appreciate it. Thanks ___ I realized I didn't answer your question completely. My installer is just a zip file containing the directory tree of everything needed. I have a simple script that copies everything needed into the directory, then I zip it up. Example script attached. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK app development for windows.
On 01/30/2013 01:08 PM, John Stebbins wrote:
On 01/30/2013 11:24 AM, Andrew Potter wrote:
On Wed, Jan 30, 2013 at 10:52 AM, John Stebbins
stebb...@jetheaddev.comwrote:
Not sure where you are getting your information. I just built HandBrake
using the mingw tools on Fedora 18 with gtk+ 3
support. Works spiffy.
Presumably he is getting his information from
http://www.gtk.org/download/win32.php
It is relatively easy to cross-compile a Gtk3 Windows .exe with mingw.
But how do you give users the program? They need the Gtk3
dependency .DLLs to run it. There is no Gtk3 installer. Do you have your
own installer and distribute the .DLLs that are in the Fedora packages? I'm
curious to know if that works. Also if you could share some details on your
installer I would appreciate it.
Thanks
___
I realized I didn't answer your question completely. My installer is just
a zip file containing the directory tree of
everything needed. I have a simple script that copies everything needed into
the directory, then I zip it up. Example
script attached.
Renaming script to prevent stripping by ML.
--
John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
#!/bin/bash
build=.
destdir=ghb.mingw64
mkdir -p ${destdir}/lib/
mkdir -p ${destdir}/bin/
# Copy EXEs
cp ${build}/gtk/src/.libs/ghb.exe ${destdir}/bin
cp ${build}/HandBrakeCLI.exe ${destdir}/bin
# Copy config info
cp -rL /usr/x86_64-w64-mingw32/sys-root/mingw/etc/ ${destdir}/
mkdir -p ${destdir}/share/glib-2.0/schemas
cp -r /usr/i686-w64-mingw32/sys-root/mingw/share/glib-2.0/schemas/*
${destdir}/share/glib-2.0/schemas
# Copy DLLs
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libatk-1.0-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-2.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk_pixbuf-2.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgio-2.0-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libglib-2.0-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgmodule-2.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgobject-2.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/iconv.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libintl-8.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpango-1.0-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangocairo-1.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangowin32-1.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpixman-1-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpng15-15.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libxml2-2.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libdl.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/pthreadGC2.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libffi-6.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangoft2-1.0-0.dll
${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfontconfig-1.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libexpat-1.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk-3-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgtk-3-0.dll ${destdir}/bin
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-gobject-2.dll
${destdir}/bin
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: DLL Hell on Windows..
On 08/06/2012 12:59 PM, Gabriele Greco wrote: I have wondered why we use dlls on windows, we should link statically to the libraries. I think the main reason is to make easier for app developer to be LGPL compliant. Also, GtkBuilder does not work statically linked on windows. It requires the export symbols in the dll to lookup and instantiate widgets. Or at least this was the case when I last tried this with Gtk 2. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk::FileChooserButton
On 05/01/2011 04:15 AM, John Emmas wrote:
** GTK+ (almost) exonerated **
I've spent quite a bit of time delving into the problems I encountered with
Gtk::FileChooserButton. I started by writing a minimal app using a main window
with a child button. The button launched a modal dialog box which contained a
Gtk::FileChooserButton. I built the app for Windows (using VC++ and gtk-win32)
and then for Linux (using gcc and gtk-x11). It behaved exactly as expected
(and pretty much identically) on both OS's.
The only problem with the above was that I couldn't find am obvious way to
preselect a startup folder for the FileChooser dialog. The only way I found
was to create a Gtk::FileChooser dialog separately, then attach it to a button
using gtk_file_chooser_new_with_dialog(). However, when I do that I see some
marked differences in the Linux behaviour compared to the Windows behaviour.
The main difference is that under Windows there seems to be an inherent link between the
FileChooser dialog and its associated FileChooserButton. e.g. if I choose a particular
file then press Open, the chosen filename appears automatically in the
associated FileChooserButton. This doesn't work when I build under Linux with gcc.
Likewise, with this new strategy I can preselect a startup folder using
gtk_file_chooser_set_filename() (see the code below). This works every time in my
Windows build but almost never works in the Linux build.
I've listed the code below on the assumption that I've maybe missed out an
important step somewhere. Can anyone see any obvious mistakes with my approach?
John
static void
button_clicked (GtkWidget *window, gpointer data)
{
gsize bytes_written, bytes_read;
GtkWidget *vbox;
GtkWidget *dialog;
GtkWidget *file_chooser_button;
GError *error = 0;
dialog = gtk_dialog_new_with_buttons(File Chooser, (GtkWindow*)data,
GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_STOCK_CANCEL, GTK_RESPONSE_REJECT,
NULL);
if (dialog)
{
// Choose an arbitrary file for pre-selection which is known to exist on both
OS's
#ifdef WIN32
const gchar* home = C:\\Users\\johne53\\.jackdrc;
#else
const gchar* home = /home/johne53/.jackdrc;
#endif
GtkWidget* file_chooser_dialog = gtk_file_chooser_dialog_new (Choose a
file, GTK_WINDOW(dialog),
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_OK,
NULL);
if (file_chooser_dialog)
{
file_chooser_button = gtk_file_chooser_button_new_with_dialog
(file_chooser_dialog);
if (file_chooser_button)
{
// This always works
printf (Initializing FileChooser file to:- %s\n, home);
// This works in the Win32 build but not in the Linux build
gtk_file_chooser_set_filename((GtkFileChooser*)file_chooser_dialog,
g_filename_to_utf8(home,
strlen(home),bytes_read,bytes_written,error))
vbox = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
gtk_box_pack_start (GTK_BOX(vbox), file_chooser_button, TRUE,
TRUE, 0);
gtk_widget_show_all (dialog);
}
}
gtk_dialog_run((GtkDialog*)dialog);
gtk_widget_destroy(dialog);
}
}
I know this is an old thread, but I just discovered a solution to a problem I've been having that I believe is the same
issue. gtk_file_chooser_set_filename and gtk_file_chooser_select_filename do not behave correctly under certain
circumstances. If you have enabled the display of hidden files in any app (right click popup menu in any file chooser
dialog) AND you do not set a filter on your file chooser dialog with gtk_file_chooser_set_filter, then
set/select_filename do not work. Simply setting a filter with * as the glob works around the issue.
gtk 2.22 definitely still has the problem (fedora 15). A quick read of the code indicates 2.24 still has the problem.
git head looks like it's fixed. Problem code is in gtkfilechooserdefault.c:show_and_select_files(). It only walks the
file list and selects an item if can_have_hidden || can_have_filtered.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Widget name is 0x0 after GtkWidget key-press-event
On 08/13/2010 06:22 AM, Tadej Borovšak wrote: Hi. Your problems are caused by the fact that GtkBuilder since GTK+-2.20 doesn't set widget's name property to id field anymore. API docs[1] warn about this change (see the first Note section in description). Tadej [1] http://library.gnome.org/devel/gtk/stable/GtkBuilder.html#GtkBuilder.description use gtk_buildable_get_name(GTK_BUILDABLE(widget)) instead. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
compositing + shape mask in gtk+ 2.18
I have a custom widget I've created that allows a collection of widgets
to be stacked and composited. Each widgets opacity can be individually
set when added to the zlist of the compositing widget. I use this to
create popup overlays for displaying controls over a video background.
All widgets added to the compositor must have associated GdkDrawable's
for compositing to work.
The problem I have is with widgets that I've set a shape mask on with
gtk_widget_shape_combine_mask(). When drawn for the first time after
showing the widget, the shape is respected and I get the output I
expect. But when one of the widgets that is lower in the zlist changes,
the parts of the shaped widget that should be transparent maintain the
pixels from the previous rendering of the widget that changed beneath it.
This used to work and stopped working with gtk+ 2.18. I'm wondering if
it is related to the introduction of child-side windows.
Here's what the expose event code that does the compositing looks like.
Anyone see something I should be doing differently?
static void
ghb_compositor_blend (GtkWidget *widget, GdkEventExpose *event)
{
GhbCompositor *compositor = GHB_COMPOSITOR (widget);
GList *link, *draw;
GdkRegion *region;
GtkWidget *child;
cairo_t *cr;
GhbCompositorChild *cc;
if (compositor-children == NULL) return;
/* create a cairo context to draw to the window */
cr = gdk_cairo_create (widget-window);
for (link = compositor-children; link != NULL; link = link-next)
{
cc = (GhbCompositorChild*)link-data;
for (draw = cc-drawables; draw != NULL; draw = draw-next)
{
/* get our child */
child = GTK_WIDGET(draw-data);
if (!GTK_WIDGET_VISIBLE(cc-widget) ||
!GTK_WIDGET_VISIBLE(child))
continue;
/* the source data is the (composited) event box */
gdk_cairo_set_source_pixmap (cr, child-window,
child-allocation.x,
child-allocation.y);
/* draw no more than our expose event intersects our child */
region = gdk_region_rectangle (child-allocation);
gdk_region_intersect (region, event-region);
gdk_cairo_region (cr, region);
cairo_clip (cr);
/* composite, with an opacity */
cairo_set_operator (cr, CAIRO_OPERATOR_OVER);
cairo_paint_with_alpha (cr, cc-opacity);
cairo_reset_clip(cr);
}
}
/* we're done */
cairo_destroy (cr);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
resource file styles ignored in gtk 2.19.5 and 2.19.7
This worked previously in gtk 2.18. I'm testing my code on the alpha
releases of ubuntu 10.04 and fedora 13 which have gtk 2.19.5 and 2.19.7
respectively. Am I doing something incorrect? Has this functionality
been changed in some way?
const gchar *hud_rcstyle =
style \ghb-hud\ {\n
bg[NORMAL]=\gray18\\n
bg[ACTIVE]=\gray32\\n
bg[PRELIGHT]=\gray46\\n
bg[SELECTED]=\black\\n
base[NORMAL]=\gray40\\n
text[NORMAL]=\white\\n
text[ACTIVE]=\white\\n
fg[NORMAL]=\white\\n
fg[ACTIVE]=\white\\n
fg[PRELIGHT]=\white\\n
}\n
widget \preview_window.*.preview_hud.*\ style \ghb-hud\\n;
...
gtk_rc_parse_string(hud_rcstyle);
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Images + labels in buttons
In previous versions of gnome/gtk, both images and labels appeared in buttons. Starting with gnome 2.28, if there is a label, the image will only appear if the gconf property desktop/gnome/interface/buttons_have_icons is True. In my application, the image on some buttons is an important clue to the function of the button. Is there any way to force the image to be displayed regardless of the setting of buttons_have_icons? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Images + labels in buttons
On 11/19/2009 11:39 AM, John Stebbins wrote: In previous versions of gnome/gtk, both images and labels appeared in buttons. Starting with gnome 2.28, if there is a label, the image will only appear if the gconf property desktop/gnome/interface/buttons_have_icons is True. In my application, the image on some buttons is an important clue to the function of the button. Is there any way to force the image to be displayed regardless of the setting of buttons_have_icons? If anyone cares, I found this in the GtkSettings documentation. It forces button icons to be enabled: g_type_class_unref(g_type_class_ref(GTK_TYPE_BUTTON)); g_object_set(gtk_settings_get_default(), gtk-button-images, TRUE, NULL); ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
toolbutton label not visible in gtk 2.18
I just installed fedora 12 beta on one machine and ubuntu 9.10 on another. Both have gtk 2.18.3. When I run my application on either system, my toolbutton labels are not visible. Am I missing some new property that needs to be set to make them visible, or is this a gtk bug? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: toolbutton label not visible in gtk 2.18
On 10/30/2009 09:24 AM, John Stebbins wrote: I just installed fedora 12 beta on one machine and ubuntu 9.10 on another. Both have gtk 2.18.3. When I run my application on either system, my toolbutton labels are not visible. Am I missing some new property that needs to be set to make them visible, or is this a gtk bug? I figured it out. The GtkToolBar property toolbar-sytle now must be set to GTK_TOOLBAR_BOTH. This wasn't necessary before. I don't know if it makes a difference, but my ui is being initialized with GtkBuilder. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: toolbutton label not visible in gtk 2.18
On 10/30/2009 10:25 AM, Colomban Wendling wrote: Hi , John Stebbins a écrit : On 10/30/2009 09:24 AM, John Stebbins wrote: I just installed fedora 12 beta on one machine and ubuntu 9.10 on another. Both have gtk 2.18.3. When I run my application on either system, my toolbutton labels are not visible. Am I missing some new property that needs to be set to make them visible, or is this a gtk bug? I figured it out. The GtkToolBar property toolbar-sytle now must be set to GTK_TOOLBAR_BOTH. This wasn't necessary before. I don't know if it makes a difference, but my ui is being initialized with GtkBuilder. GNOME has a global preference for this property (System → Preferences → Appearance → Interface), isn't it simply that it is set too show only icons? Ahh, Fedora 12 Beta does not yet have the Interface option in Appearance. I thought there might be such a thing and went looking for it, but couldn't find it. Ubuntu 9.10 does in fact have that, and it works as expected. Thanks everyone. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with GtkFileChooserDialog select_folder action
The problem occurs when I create a GtkFileChooserDialog with action
GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER and then set the default folder
with gtk_file_chooser_set_filename or gtk_file_chooser_select_filename.
Attempting to click Ok gives the message The folder could not be
created. Error creating directory: File exists. Simply selecting a
different file, then re-selecting the default and clicking Ok works
fine. I've attached a sample program that demonstrates the problem. Am
I doing something wrong, or is this a bug? If it's a bug, is there a
known work-around? I've tried various permutations of things and can't
find a way around it.
Fedora 11
gtk 2.16.5-1
#include gtk/gtk.h
#include stdlib.h
static gpointer
do_dialog(gpointer data)
{
GtkWidget * dialog;
gintresponse;
gchar * dir;
g_debug(do_dialog ());
dialog = gtk_file_chooser_dialog_new(Select Folder, NULL,
GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OK, GTK_RESPONSE_ACCEPT,
NULL);
dir = getenv(HOME);
gtk_file_chooser_set_filename(GTK_FILE_CHOOSER(dialog), dir);
response = gtk_dialog_run(GTK_DIALOG (dialog));
if (response == GTK_RESPONSE_ACCEPT)
{
gchar *filename;
filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER
(dialog));
if (filename != NULL)
{
g_debug(Filename is (%s), filename);
g_free(filename);
}
}
gtk_widget_destroy(dialog);
gtk_main_quit();
return FALSE;
}
int
main (int argc, char *argv[])
{
gtk_init (argc, argv);
g_idle_add((GSourceFunc)do_dialog, NULL);
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: How to do a graphic overlay?
Only certain widgets have their own GdkWindow. GtkDrawingArea, GtkWindow and GtkEventBox do. Pretty much all others don't. I don't know whether goocanvas does or not. But if it doesn't, then you would have really been drawing on one of it's ancestors GdkWindow. According to the GooCanvas documentation, it is a subclass of GtkContainer, which indicates to me that it probably doesn't have it's own GdkWindow. My guess is that what you are drawing is getting overwritten by the other widgets that share that window. Since GooCanvas is a container, it should work to put a GtkEventBox (also a container) or GtkDrawingArea in it and draw into that widgets GdkWindow. The GdkWindow documentation has an example of how set set up an eventbox for composited windows which is not quite what you are attempting, but similar. http://library.gnome.org/devel/gdk/2.16/gdk-Windows.html#composited-window-example On 09/02/2009 12:21 PM, Till Harbaum / Lists wrote: Hi, i'd like to do some graphic overlay. In this particular case i'd like to put two buttons on top of a goocanvas. I tried to hook into the expose event and just draw something to the gdkwindow of the widget. That simply doesn't work. It works with a gtkdrawingarea, but not with the goocanvas. What can prevent me from drawing to the gdkwindow of a widget? I also tried to use a seperate window, but that's pretty difficult to handle since you e.g. have to move those windows when you move the main window etc etc. So just painting their seems simpler ... but unfortunately doesn't work Till ___ 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: Alpha blending between DrawingArea and HBox
On 07/20/2009 03:43 PM, David Lucena wrote: Hi. I'm pretty much new to gtk. I've been about two days trying to draw a transparent widget over another. I am using a HBox layout widget actually where I put a DrawingArea, and use cairo to fill with a transparent red color (50% alpha). I've got the colormap of the Screen, and applied to the DrawingArea and the HBox. The HBox is inside a GtkWindow with the background painted with green using also cairo contex. The more transparency I give to the red color of the DrawingArea, the more white it appears, but I wanted that it blended with the green color. I have tried to do this avoiding the HBox, and putting the DrawingArea directly to the GtKwindow, but also does not work. BUT! If I set the colormap of the Screen to the GtkWindow, the more transparent y make the red color of the DrawingArea, the more I see my desktop Background, but I want to see just the red color blended with the GtkWindow green color. I also have tried to paint the HBox in green, but the expose-event for the box never gets called. I don't know If what I want to do is possible. My brains tells me it OUGHT to be possible, but I don't know if I have to use a X11 approach or another hack like getting the window background and then paint it to the DrawingArea and then drawing everything else. Thanks in advance for your help. By the way, I am using PyGTK, but I am sure this issue is not cause by a binding bug. I believe your problem my be that only widgets that have their own GdkWindow can be composited. If memory serves, the only widgets that have their own GdkWindow are GtkWindow, GtkEventBox, and GtkDrawingArea. ___ 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 make my own widget semi-transparent?
The documentation for GdkWindow has a good example of how to do translucent widgets. http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#composited-window-example Your attachments didn't go through, so I can't say what your doing wrong. But if I had to guess, I would say you're probably not correctly setting up the expose event. Also, I wrote a custom widget to generalize multiple overlapping translucent layers. You might want to have a look at it. http://www.stebbins.biz/home/node/5 On 04/08/2009 09:25 PM, Zhe Su wrote: Hi, I'm writing a program which uses cairo to paint some customized semi-transparent widgets.These widgets might overlap with each other. However I didn't find a way to make the widgets truely semi-transparent. If a widget is covered by another widget, then the covered area will always be erased by the upper widget. A test program and its screenshot is attached. The program draws a window with two fixed widgets, both are painted with cairo. One is semi-transparent green another is blue. No matter if composite extension is enabled or not, the result is not what I expect. Anyone know how to implement real semi-transparent widgets with current gtk? Regards James Su ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with gtkbuilder mingw cross (not the signal problem)
Tor Lillqvist wrote: (Adding gtk-app-devel-list back as Cc. Please let's keep this discussion on the list.) Oops, didn't notice that reply went direct to you instead of to the list. Why make it harder for yourself, why not use a shared library (dll) build of gtk+ like everyone else? --tml Short answer, I don't know what I'm doing ;-) . I saw that cross development environment announced on freshmeat, and on a whim I decided to try porting my application to windows. It looked like a nice self contained set of tools that could get me there. I didn't explicitly ask for it to build static. From the package's feature list, creates libraries to be linked statically, no DLL hell. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
missing entry point cairo_ft_font_face_create_for_pattern
I updated my tools and am now compiling my application with the mingw cross compiling tools found here: http://mingw-cross.sourceforge.net/ I'm getting the following error when starting my application, The procedure entry point cairo_ft_font_face_create_for_pattern could not be located in the dynamic link library libcairo-2.dll Doing an nm on all the dll's shows that the symbol only shows up in libpangocairo-1.0-0.dll: 6d4cb520 I __imp__cairo_ft_font_face_create_for_pattern 6d4c60b0 T _cairo_ft_font_face_create_for_pattern I'm guessing it's another set of broken tools. Can anyone expound on what the problem is? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: missing entry point cairo_ft_font_face_create_for_pattern
Tor Lillqvist wrote: Your problem seems to be that you have a libpangocairo DLL that is built with the fontconfig(+freetype)-based pango backend (i.e. a libpangocairo as typically used on X11), while your libcairo DLL does not have the freetype font backend (but presumably just the win32 one, which is all that gtk+ and pango normally need on Windows). Some serious confusion is going on... --tml Yes, that's exactly what was happening. I rebuilt pango from source and it works correctly now. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with gtkbuilder mingw cross (not the signal problem)
I'm cross compiling a gtk app that uses gtk builder with mingw. My build system is Fedora 10. I create my mingw env from this: http://www.profv.de/mingw_cross_env/ This is not the same problem others have had with connecting callbacks, but it may be related. The app builds fine. When the application starts, gtk_builder_add_from_string() fails. I did some sleuthing, and discovered that g_module_symbol() fails to find the symbol gtk_adjustment_get_type. I'm guessing it fails for other symbols as well, GtkAdjustment just happens to be the first object in my builder file. nm shows that the symbol is in the binary. Note that I can successfully lookup my callback functions using g_module_symbol(). So it just has something to do with exporting those symbols gtkbuilder relies on for instantiating objects. Any ideas? example compile line: i386-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src -I.. -DPACKAGE_LOCALE_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share/locale\ -DPACKAGE_SRC_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src\ -DPACKAGE_DATA_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share\ -mms-bitfields -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/gtk-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/gtk-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/atk-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/cairo -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pango-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/glib-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/glib-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pixman-1 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/freetype2 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/libpng12 -Wall -g -g3 -O3 -fno-common -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o /home/jstebbins/Source/HandBrake.mingw/build/../gtk/src/main.c example link line: i386-mingw32msvc-g++ -g -O2 -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -Wl,--export-dynamic -g3 -O3 -o ghb.exe callbacks.o queuehandler.o audiohandler.o x264handler.o main.o settings.o resources.o presets.o preview.o icons.o icon_tools.o values.o appcast.o plist.o hb-backend.o renderer_button.o ghbcellrenderertext.o ghb-dvd.o marshalers.o -L/home/jstebbins/Source/HandBrake.mingw/build//libhb -L/home/jstebbins/Source/HandBrake.mingw/build//contrib/lib -lhb /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/liba52.a -lm /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmkv.a -lavformat -lavcodec -lavutil /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libdca.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libdvdread.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaac.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmp3lame.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmpeg2.a -L/home/jstebbins/Source/HandBrake.mingw/build/contrib//lib /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbisenc.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbis.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libsamplerate.a -lx264 -lxvidcore /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmp4v2.a -lswscale /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libtheora.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libogg.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaad.a -lbz2 -lpthread -liberty -L/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgtk-win32-2.0.a -lcomdlg32 -lwinspool -lcomctl32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk-win32-2.0.a -limm32 -lshell32 -luuid /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libatk-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk_pixbuf-2.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libtiff.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libjasper.a -ljpeg /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpangocairo-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libcairo.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpng12.a -lmsimg32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpixman-1.a
