Re: Problem with gtkbuilder mingw cross (not the signal problem)
I did some sleuthing, and discovered that g_module_symbol() fails to find the symbol gtk_adjustment_get_type. Sorry, I have no idea why that would happen. gtk_adjustment_get_type is exported from the libgtk DLL (libgtk-win32-2.0-0.dll), just like all the other functions. You will have to dig into it more deeply. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problems with 64bit build for Windows
To be precise, the problem here is that the symbol exported is actually _libintl_fprintf. Umm, sorry, I was confused there. The symbols exported from the 64-bit libintl, libintl-8.dll, don't have any underscore prefixes, which is as it should be. (Even on 32-bit Windows, it is just import libraries that have the underscore-prefixed symbols.) I seem to have forgotten to upload the gettext_0.17-2_win64 build... It is there (http://ftp.gnome.org/pub/GNOME/binaries/win64/dependencies/ ) now. I think I forgot to use the -machine:x64 switch when building the import library in the -1 package. The -2 one has a correct import library intl.lib. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problems with 64bit build for Windows
I seem to have forgotten to upload the gettext_0.17-2_win64 build... It is there (http://ftp.gnome.org/pub/GNOME/binaries/win64/dependencies/ ) now. I think I forgot to use the -machine:x64 switch when building the import library in the -1 package. The -2 one has a correct import library intl.lib. Great. The program now links fine. Note that I had to assume that the dev package with suffix -1.1 is equivalent to the package with suffix -2 :-) It would be nice if you can make the same update to the bundle release when you make a next official release. Thank you for your help. It is very much appreciated. Regards, Miroslav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Background color problem
On Tue, 2009-03-17 at 07:41 +0300, Vlad Volodin wrote:
Sorry, I've asked this question, but I can't find any explanation:
GdkColor gdk_color = { 0, };
ClutterColor clutter_color = { 0, };
They are structures, why do you use commas before the last brackets?
because it will initialize all the members of a struct to 0. it's
equivalent to:
GdkColor gdk_color = { 0, 0, 0, 0 };
ClutterColor clutter_color = { 0, 0, 0, 0 };
or to:
GdkColor gdk_color;
ClutterColor clutter_color;
memset (gdk_color, 0, sizeof (GdkColor));
memset (clutter_color, 0, sizeof (ClutterColor));
or, in C99:
GdkColor gdk_color = {
.pixel = 0,
.red = 0,
.green = 0,
.blue = 0
};
ClutterColor clutter_color = {
.red = 0,
.green = 0,
.blue = 0,
.alpha = 0
};
I've found C99 standard, where the same rule is applied to enum type
too.
it doesn't have anything to do with enumerations -- enumerations will
use the number to set their value explicitly, and it's something coming
from ANSI C, way before C99.
ciao,
Emmanuele.
Best wishes,
Vlad Volodin
2009/3/17 Emmanuele Bassi eba...@gmail.com:
On Mon, 2009-03-16 at 23:28 +0300, Vlad Volodin wrote:
first of all, you really want to use the clutter list.
I'm using libclutter-gtk (with GtkClutterEmbed widget), where I want
to display some graphics. If somebody doesn't know it, I'll describe
it a bit. It is derived from GtkWidget. Then it uses it's own canvas.
The canvas is white, and it doesn't have some kind of transparency.
So, as I thought, I decided to fill it's background with color, got
from it's GtkStyle. After some experiments I realized, that widgets
(main window, container and GtkClutterEmbed) don't have needed color:
Containers in GTK+ do not usually have a background: they are assumed to
be transparent transparent. GtkWindow does have a background color,
though, since it'll have to provide the background for most widgets.
to set the color of the Stage embedded inside GtkClutterEmbed you can
get a specific color out of the GtkWindow style; you cannot do this at
any time you like: you'll have to connect to the style-set signal of the
GtkWindow that contains the GtkClutterEmbed-- at which point you have a
guarantee that a GtkStyle has been applied to the widget.
also, you have to remember that GdkColor and ClutterColor are not
compatible structures: you have to convert between the two.
GdkColor gdk_color = { 0, };
ClutterColor clutter_color = { 0, };
gdk_color = widget-style-bg[GTK_STATE_NORMAL];
clutter_color.red = CLAMP (((gdk_color.red / 65535.0) * 255), 0, 255);
clutter_color.green = CLAMP (((gdk_color.green / 65535.0) * 255), 0, 255);
clutter_color.blue = CLAMP (((gdk_color.blue / 65535.0) * 255), 0, 255);
clutter_color.alpha = 255;
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Not receving Signals from gtkhsclae
Hello, In my application (win32) I want to use a gtkhscale. I created the application with glade: widget class=GtkHScale id=hscale1 property name=visibleTrue/property property name=can_focusTrue/property property name=adjustment90 0 100 1 10 10/property property name=restrict_to_fill_levelFalse/property signal name=value_changed handler=on_hscale1_value_changed/ /widget and connected the Signal glade_xml_signal_connect (xml, on_hscale1_value_changed,G_CALLBACK (on_hscale1_value_changed)); But i never receive the Signal! The rest of the application works fine, I use a lot of Signals and callbacks, i googled and tried and check, but without success. Can someone give me a hint? regards Arne -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GIO channels and connection closed by foreign host on WIN32
I have a problem with the WIN32 port of a project. I use a GIO channel to wrap the socket, I handle the socket as async (so in case of error I check for EWOULDBLOCK/EINPROGRESS...), the program works ok and the callback is called when there is data on the socket. The problem I have is that on linux if the connecton is closed from the foreign host (ctrl + c in a shell with nc -lp 4000 in my basic tests) the callback is called and recv() returns a 0, so I can detect the socket is closed. On WIN32 closing the remote host connection has no effect at all, no callback is called. I detect the situation only if I send() something I thought it was a different behaviour of win32 / linux socket implementation, so I've built a small program that uses select() instead of GTK+ to wait for the sockets, and I get a consistent behaviour both in win32 and linux (select trigger - FD_ISSET sock - recv sock - returns 0). I checked the GIO channel documentation but except for the well known fact that polling a GSource on Win32 put the socket in async mode I found nothing else... -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GIO channels and connection closed by foreign host on WIN32
Do you have a minimal but complete sample program that exhibits the problem? --tml ___ 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)
(Adding gtk-app-devel-list back as Cc. Please let's keep this discussion on the list.) I'm statically linking libgtk-win32-2.0.a. That cross development environment I pointed out creates only static libraries for everything. I'll bet it has something to do with that. Is using the dll required?' Ah... Well, if you use a static öibgtk you are on your own;) If you then try to look up gtk+'s own functions with g_module_symbol, I am not surprised that it doesn't work, as those symbols are presumably not exported from the .exe into which gtk has been statically linked. (Yes, symbols can be exported not only from .dll files, but also .exe files. It is not common, but possible. Basically there is very little difference between a .dll and a .exe.) Do note that the concept of exported symbols is quite different in PE executables (on Windows) and ELF ones (on Linux). Why make it harder for yourself, why not use a shared library (dll) build of gtk+ like everyone else? --tml ___ 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
Re: GIO channels and connection closed by foreign host on WIN32
On Tue, Mar 17, 2009 at 4:26 PM, Tor Lillqvist t...@iki.fi wrote:
Do you have a minimal but complete sample program that exhibits the problem?
--tml
Here it is, I've made it as minimal as a crossplatform gtk socket
program can be, the code may give a pair of warnings and passes the fd
as userdata, this is to mimic the real code that passes a class base
pointer that contains also the FD and to specify that the code doesn't
use gio channels API to get FD or read/write.
It compiles both on win32 and linux, command line on linux for both builds:
Linux native:
gcc -o t test.c `pkg-config gtk+-2.0 --cflags --libs`
WIN32 cross:
/usr/i586-mingw32msvc/bin/gcc -o test.exe -gstabs
-I/usr/i586-mingw32msvc//include/glib-2.0
-I/usr/i586-mingw32msvc//lib/glib-2.0/include/
-I/usr/i586-mingw32msvc//include/cairo
-I/usr/i586-mingw32msvc//include/gtk-2.0
-I/usr/i586-mingw32msvc//include/atk-1.0
-I/usr/i586-mingw32msvc//include/pango-1.0
-I/usr/i586-mingw32msvc//lib/gtk-2.0/include -mno-cygwin
-mms-bitfields -DOOGTK_DEBUG socktest.c
-L/usr/i586-mingw32msvc//lib/gtk-2.0 -lgtk-win32-2.0 -lgdk-win32-2.0
-latk-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lpangowin32-1.0 -lgmodule-2.0
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -luser32 -lws2_32
How to reproduce:
On a linux server machine type (say with address 192.168.1.10):
nc -vlp 4000
On a client machine (if win32 you should run it from a cmd since it
does most of this output on stderr):
test 192.168.1.10 4000
Now type something in the shell where you launched netcat (hello
enter, hi enter...)
You should see the label of the gtk program update.
Last step, the one where the problem is, close netcat with CTRL+C.
If the gtk client is linux it will disconnect.
*** If the gtk client is win32 it will not receive any error ***
Test is done both on win32 and linux with GTK 2.14.x (latest version
before the 2.16 stable).
Source:
#include gtk/gtk.h
#include stdlib.h
#ifdef WIN32
#include winsock2.h
#else
#include sys/socket.h
#include netinet/in.h
#endif
GtkWidget *label;
void cbk(GIOChannel *c, int cond, int fd)
{
char buffer[1024];
int rc = recv(fd, buffer, sizeof(buffer), 0);
if (rc == 0) {
fprintf(stderr, Connection closed\n);
gtk_main_quit();
}
else if (rc 0) {
fprintf(stderr, Error handling removed!\n);
gtk_main_quit();
}
else {
fprintf(stderr, Received %d bytes\n, rc);
buffer[rc] = 0;
gtk_label_set_text(GTK_LABEL(label), buffer);
}
}
int main(int argc, char *argv[])
{
GtkWidget *w;
GIOChannel *ch;
struct sockaddr_in addr;
int fd;
if (argc != 3) {
fprintf(stderr, Use %s host port\n, argv[0]);
exit(0);
}
#ifdef WIN32
WSADATA wsaData;
if (WSAStartup(MAKEWORD( 2, 0 ), wsaData) != 0) return;
#endif
gtk_init(argc, argv);
w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
label = gtk_label_new(NULL);
gtk_container_add(GTK_CONTAINER(w), label);
fd = socket(AF_INET, SOCK_STREAM, 0);
memset((void*)addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(atoi(argv[2]));
addr.sin_addr.s_addr = inet_addr(argv[1]);
if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) {
fprintf(stderr, Error in connect to %s/%d!\n, argv[1], atoi(argv[2]));
exit(0);
}
#ifdef WIN32
ch = g_io_channel_win32_new_socket(fd);
#else
ch = g_io_channel_unix_new(fd);
#endif
g_io_add_watch(ch, G_IO_IN, cbk, fd);
gtk_widget_show_all(w);
gtk_main();
}
--
Bye,
Gabry
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GIO channels and connection closed by foreign host on WIN32
Here it is, I've made it as minimal as a crossplatform gtk socket program can be, the code may give a pair of warnings and passes the fd as userdata, this is to mimic the real code that passes a class base pointer that contains also the FD and to specify that the code doesn't use gio channels API to get FD or read/write. BTW if this can be useful: I've made a modified version of the program that uses GIO functions to read datas from the server, it also sets the encoding to NULL and buffering to FALSE since I've seen that is the right way to have a behaviour similar to a plain recv() and it checks the return code with G_IO_STATUS_EOF, the result is the same as the bare socket version: In linux a ctrl+c on the server notify the client that receive G_IO_STATUS_EOF, in windows it doesn't. -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GIO channels and connection closed by foreign host on WIN32
I've made a modified version of the program that uses GIO functions to read datas from the server, it also sets the encoding to NULL and buffering to FALSE That indeed is very often what one should do, yes. Additionally, if you make the cbk function a proper GIOFunc by making it be of type gboolean and return TRUE, and if you add also the G_IO_HUP condition to the g_io_add_watch() call, your program works. (Yes, it might well be that it should be considerd a bug that one on Windows has to explicitly watch for G_IO_HUP in addition to G_IO_IN to be able to catch EOF. Please file a bug for that. The exact intended semantics of the GIOChannel API isn' clearly specified IMHO, and even if it was, one can say that it is more important that code that de facto does work on Unix should also work on Windows, even if strictly speaking the code would not need to work even on Unix according to specs... ) --tml ___ 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
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: nm is in general the wrong tool to use for DLLs. What you are interested in is what symbols are exported from or imported into a DLL. That is what the error message above refers to. What nm is displaying, I think, are debugging symbols which are entirely optional and can be stripped from the DLL with no effect on its behaviour (except that it makes debugging harder, of course). Use objdump -p and look for the import and export tables, which are what actually direct how a DLL interacts with executables that load it and with any other DLLs that it in turn depends on. 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 ___ 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
Re: show signal problem
Hi again, As I can see, anyone knows how to solve this... Then I will overwrite the show method of my GscInfo object (inherit from GtkWindow) and I will emit a before-show signal or a show-info signal before to call GtkWindow-show. Regads, Perriman El Sun, 15 Mar 2009 04:06:59 +0100 Perriman chuchiperri...@gmail.com escribió: Hi all!!! I have a problem with show signal. I have a window and I need to change its size and position before showing it. Currently if I do: 1.- set the label text 2.- set the window size (based on label text) 3.- move the window 4.- show the window All works fine but if I have problems by doing: 1.- Connect to show signal 2.- set the label text 3.- gtk_widget_show (window); When show signal is emited: - set the window size (based on the label text previously setted) - move the window The problems are: 1.- The window size is not properly calculated 2.- I get a flicker because the window is show at (0,0) and then moved to the correct position. The show signal is emited after the real show mechanism and configure and map events don't work... Can you help me? Thanks a lot Perriman ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: show signal problem
The show signal is a Run-First signal, which means the default handler is always ran before any event handlers. Just override the show virtual function and do stuff before chaining up to the parent member function. Emitting a signal is not necessary if you are already using overriding. May I ask you what the desired behavior is when the label text is modified, after the window is shown? - Yu On Wed, 2009-03-18 at 00:43 +0100, Perriman wrote: Hi again, As I can see, anyone knows how to solve this... Then I will overwrite the show method of my GscInfo object (inherit from GtkWindow) and I will emit a before-show signal or a show-info signal before to call GtkWindow-show. Regads, Perriman El Sun, 15 Mar 2009 04:06:59 +0100 Perriman chuchiperri...@gmail.com escribió: Hi all!!! I have a problem with show signal. I have a window and I need to change its size and position before showing it. Currently if I do: 1.- set the label text 2.- set the window size (based on label text) 3.- move the window 4.- show the window All works fine but if I have problems by doing: 1.- Connect to show signal 2.- set the label text 3.- gtk_widget_show (window); When show signal is emited: - set the window size (based on the label text previously setted) - move the window The problems are: 1.- The window size is not properly calculated 2.- I get a flicker because the window is show at (0,0) and then moved to the correct position. The show signal is emited after the real show mechanism and configure and map events don't work... Can you help me? Thanks a lot Perriman ___ 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
