Re: help wanted for implementing GdkGLContext on Windows and MacOS X
Hi Emmanuele, Based on your blog post updates, it looks like there's already some progress towards this. For what it's worth though, I've been using GTK+ and OpenGL in one of my programs for a few years and have it working with X11/Windows/Quartz. The implementation(s) can be found here, along with a sample program: http://pileus.org/git/?p=grits;a=blob;f=src/gtkgl.c http://pileus.org/git/?p=grits;a=blob;f=examples/cube/cube.c I'll see if I can test out the Windows and Mac versions, although I've never actually built GTK on Windows yet so that might take a bit of time. On 2014-11-16 14:32Z, Emmanuele Bassi wrote: hi all; I posted this on my blog, which is syndacated on Planet GNOME, but I thought about trying to reach out to more people by using the GTK+ mailing list as well. GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and Wayland. if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or 3.x, then I'm asking you to help out with patches and testing the OpenGL support in the master branch of GTK+. we'd really like to have OpenGL support working on all the major backends in GDK by the time we release GTK+ 3.16.0, next February. ciao, Emmanuele. signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: where i find a manual for write a wm in gtk3 ?
On 2014-02-27 12:40Z, Jasper St. Pierre wrote: Except you can't. GTK+ will deadlock your WM if you try to use it, unless you do it very carefully (read: add 5000 lines of code, fake out GDK all over the place, and implement an entire confusing state machine). You can't use GTK+ to build a WM. I thought metacity used GTK+ for things like right click menus at least, or is the issue a GTK+ 3 thing? Would it work better to use offscreen windows for the GTK stuff? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: where i find a manual for write a wm in gtk3 ?
On 2014-02-26 21:55Z, major_ghz wrote: i follow the begining of GTK-3 Reference Manual, but explan only for an application in gtk3 not for write a litle wm. can you help me for begining this projet ? All the other people who told you not to do this are probably correct, but since you did ask a specific question, I'll at least try to answer. Before you write an WM in GTK you'll want to learn how to write a WM without GTK. Start with some existing simple window managers and learn how they works (e.g. what SubstructureRedirectMask does). xcb would be better, but xlib will be easier just because there's more examples. Then once you have something that runs and manages windows, you can think about adding GTK to it to do title bar drawing, or context menu's, or whatever it is that you want to use GTK for. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 10:12, tarn...@tarnyko.net wrote: Out of curiosity, collecting info on my side : are you cross-compiling GTK+2 or GTK+3 ? I don't know if it was clear or not, but I have only cross compiled my application and have been using pre-build GTK libraries. I have built it using both GTK+2 and GTK+3, but I have only released GTK+2 versions. And if you cross-compile, I suppose you are using mingw ; do you install it using your distro's package manager (yum install mingw, apt-get install mingw), or is there such a thing as a standalaone mingw env available in a tarball ? I have installed mingw32 though my distos package manager (pacman on Arch and emerge/crossdev on Gentoo). I don't think I would use a standalone mingw env on Linux. If I didn't want to use my distos package manager I think I would just download the sources and build mingw myself. I think there are only a couple packages that are needed: the cross versions of gcc and binutils, and then the mingw runtime and w32api? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 15:03, Marc-André Lureau wrote: Also projects not using pkg-config have the same problems. Doing a grep under fedora-mingw sys-root reveals that there are many binaries that refer to hardcoded path too. I have this problem running my software on windows. I have many places in my Makefile.am's where I use something like: myfile_CPPFLAGS = -DPKGDATADIR=\$(pkgdatadir)\ Which results in a non-relocatable build. It seems like most of my issues with relative build could fixed by patching ./configure to support './configure --prefix=..'. Has anyone tried this, or are there better solutions? My current solution is basically to emulate with some autoconf hacks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 19:51, Kalev Lember wrote: The glib resource framework could be a solution. If the files are all the kind that get loaded each and every time when the app starts (.ui files, for instance), it makes sense to embed them within the binary. Easier to relocate the app and the startup gets faster. https://developer.gnome.org/gio/stable/gio-GResource.html They're not, for instance, I also use $(pkglibdir) for loading plugins and $(htmldir) for storing documentation that needs to be accessible by the system's default browser. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-09 22:33, tarn...@tarnyko.net wrote: It it's the case, then we could keep the buildenv as is. Or we could try to adapt it to a GCC cross-compile install under Linux, but I'd like to avoid that for reasons that I will explain further. Hm.. did I miss the further explanation? :) Personally, I would prefer to cross-compile the GTK libraries. That's what I do with the win32 builds for my application already. I also don't like the thought of having to depend on proprietary software in order to build GTK, even if it is for the windows build. For the Mac OSX build all the developers have to build their own libraries using Xcode because there are no official binaries and no cross compilers. I don't like that situation very much either. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GTK+ a cross-platform toolkit ?
On 2013-03-15 00:45, tarn...@tarnyko.net wrote: That's nice. I will patch the 3.6.4 bundle to integrate the fix, so GtkNotebooks work again. I added a patch to the bug report that should fix the tab position issue. It's also available from git: git://pileus.org/~andy/gtk win32 It does the same thing as what was done previously (flipping/rotating the win32 theme part), but I changed it to be windows specific so that it won't cause problems for other theme engines. I was only able to test it on an older version of GTK+ using Windows XP. pgp3MoVinBmnM.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GTK+ a cross-platform toolkit ?
On 2013-03-11 17:20, Martin Schlemmer wrote: Compared to 3.4.4: - GtkNotebooks with a non-default oritation is broken I opened a bug report for this issue a while back. I didn't realize it worked in 3.4.4 though: https://bugzilla.gnome.org/show_bug.cgi?id=691678 Taking a quick look at the logs I think it *may* be related to this commit. I'll see if I can do a build and check for sure sometime. If it is. I think there are better ways to implement tab positions in win32 anyway. https://git.gnome.org/browse/gtk+/commit/?id=7e917e54 pgplbf8yhBKI1.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GTK+ a cross-platform toolkit ? (fwd)
As always, thank you for your work on this. I have been hoping for a while that you, or someone else, would get the official builds going again, so please keep at it :) Unfortunately, there are still a few bugs in the windows and mac backends that have keep me from switching my project to Gtk 3.x. It would be nice to have an up-to-date version of 2.x as well. For example, I have been using the newer thread functions from Glib which are aren't supported in the 2.24 bundle from gtk.org. So far I have been using the .rpm files from the opensuse project and that's been working fine me, so unless some other people express an interest in the 2.x line it's probably not worth putting any effort into it. On the subject of installers vs. zip files. I think it would be useful to continue to provide installers, at least for the dev packages. I have worked on several in-house tools that use GTK for the UI. In those cases it's nice to be able to run the windows mingw32 installer, then run the GTK+ dev installer, and have a working development environment set up without having to mess around with paths and pkg-config files and all that. I don't really use the -bin installers very much though. When I make my packages I always go though and delete out some of the libraries that aren't needed, and then add in a few extras that aren't included. One nice thing about having a -bin installer is that it might be a nice example of how to create build a windows GTK installer. I like to think of it as the gtk-demo installer more so than the gtk runtime. Lastly, I think some people on this list have expressed an interested in having gtkmm in the installer. Personally, I also need libsoup and bzip2 for my package. Would it be possible to have the choice of doing a full, custom, or minimal install. Similar to how mingw gives you the option to install C/C++/Fortran/etc compilers? I hope that's not too much all at once, and thanks again for your help. pgpcU4IdiTfai.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On 2011-10-20 11:37, Dieter Verfaillie wrote: On Thu, 20 Oct 2011 08:37:35 +, Andy Spencer wrote: First off, when using the MS-Windows theme, some widgets don't render correctly and show up as black boxes. For example, notebooks with tab position set to GTK_POS_LEFT don't render. http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png To clarify: this happens with the Windows Classic theme which doesn't use uxtheme.dll for rendering. I tried it with the normal Windows XP Silver theme and my program won't run at all using the MS-Windows GTK+ theme. It segfault on startup.. The testnotebookdnd program that comes with the new 2.24 bundle runs, so it's possibly a problem with my application. I probably won't have a chance to do much debugging during the next week or so though.. I did notice however, that using the MS-Windows/Silver theme causes the testnotebookdnd program to crash when you try to drag the right-most 'beer' tab off onto the desktop. pgpR0N75u2jgg.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On 2011-10-20 09:39, Alexander Larsson wrote: I've not really used Gtk+ on windows for real, so I was mainly working from first principles in the code fixing stuff that was obviously wrong. Do you know of any other outstanding win32 bugs that I can look at? Thanks for your work! In my (very) brief testing, I did not notice any regressions since 2.22. I've had a couple long standing issues with GTK+ on windows though. I'm not sure if they're in scope for you, but here they are.. First off, when using the MS-Windows theme, some widgets don't render correctly and show up as black boxes. For example, notebooks with tab position set to GTK_POS_LEFT don't render. http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png Second, the GtkGLExt plugin has been broken since 2.18 I believe, the OpenGL area doesn't get set correctly because the widget you set it on doesn't have a native window (if I remember correctly). I've since given up on GtkGLExt and wrote my own x11 and win32 OpenGL interfaces, so I'm not sure if it's still an issue or not. pgpQ8blyAfu1A.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On 2011-10-20 10:47, Alexander Larsson wrote: I believe GtkGLExt should nominally work (as in there might be minor issues with it but it shouldn't be completely broken). Please test it if you can. It seems your latest 2.24 seems to work with GtkGLExt, sorry about the noise. pgp2gYMj86R8t.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On 2011-09-07, Carlos Garnacho wrote: That's the inverse of a recent commit of mine to master, not sure how it slipped in the diff, maybe the branch is being compared to a more recent master? Perhaps `git diff origin/master...origin/quartz-integration' would work better? P.S. As someone who's planning on porting a gtk+ application to OSX, thanks to everyone for working on some of these integration issues :) pgp71qDD6VSch.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: threading / timers / etc
On 2010-10-22 17:06, Ryan Lortie wrote: - We will add GTimeSpec which is GTimeVal using nanoseconds instead of microseconds (same story with struct timeval vs. struct timespec). The librt interfaces provide this level of accuracy so it would be a shame to needlessly discard it. So now we have seconds, microseconds, and nanoseconds? I'm sure this is all for compatibility with librt, but maybe we could cut to the chase, use a guint64, and represent it as attoseconds? If we do the same for seconds (gint64) we could conveniently represent any currently measurable time interval in the known universe.. and then avoid adding something involving picoseconds in a few more years. Bonus points if it makes consistent use of leap seconds. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATCH] GKeyFile: Switch gint to gint64
This effects the get_integer, set_integer, get_integer_list, and
set_integer_list functions.
---
I ran out of bits while trying to save an integer in a GKeyFile.
Swapping gint with gint64 seemed like the easiest solution.
I'm not entirely sure how this effects portability or backwards
compatibility (could be more of a problem with the _list functions).
You could also add separate get/set functions for longlong or int64, not
sure if that would be better or worse though. Thoughts?
glib/gkeyfile.c | 32 +++-
glib/gkeyfile.h |8
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/glib/gkeyfile.c b/glib/gkeyfile.c
index 2226e70..364d791 100644
--- a/glib/gkeyfile.c
+++ b/glib/gkeyfile.c
@@ -156,11 +156,11 @@ static gchar
*g_key_file_parse_value_as_string (GKeyFile
static gchar*g_key_file_parse_string_as_value (GKeyFile
*key_file,
const gchar
*string,
gboolean
escape_separator);
-static gint g_key_file_parse_value_as_integer (GKeyFile
*key_file,
+static gint64g_key_file_parse_value_as_integer (GKeyFile
*key_file,
const gchar
*value,
GError
**error);
static gchar*g_key_file_parse_integer_as_value (GKeyFile
*key_file,
- gint
value);
+ gint64
value);
static gdouble g_key_file_parse_value_as_double (GKeyFile
*key_file,
const gchar
*value,
GError
**error);
@@ -2085,7 +2085,7 @@ g_key_file_set_boolean_list (GKeyFile*key_file,
*
* Since: 2.6
**/
-gint
+gint64
g_key_file_get_integer (GKeyFile *key_file,
const gchar *group_name,
const gchar *key,
@@ -2093,7 +2093,7 @@ g_key_file_get_integer (GKeyFile *key_file,
{
GError *key_file_error;
gchar *value;
- gint int_value;
+ gint64 int_value;
g_return_val_if_fail (key_file != NULL, -1);
g_return_val_if_fail (group_name != NULL, -1);
@@ -2149,7 +2149,7 @@ void
g_key_file_set_integer (GKeyFile*key_file,
const gchar *group_name,
const gchar *key,
- gint value)
+ gint64 value)
{
gchar *result;
@@ -2181,7 +2181,7 @@ g_key_file_set_integer (GKeyFile*key_file,
*
* Since: 2.6
**/
-gint *
+gint64 *
g_key_file_get_integer_list (GKeyFile *key_file,
const gchar *group_name,
const gchar *key,
@@ -2190,7 +2190,7 @@ g_key_file_get_integer_list (GKeyFile *key_file,
{
GError *key_file_error = NULL;
gchar **values;
- gint *int_values;
+ gint64 *int_values;
gsize i, num_ints;
g_return_val_if_fail (key_file != NULL, NULL);
@@ -2209,7 +2209,7 @@ g_key_file_get_integer_list (GKeyFile *key_file,
if (!values)
return NULL;
- int_values = g_new (gint, num_ints);
+ int_values = g_new (gint64, num_ints);
for (i = 0; i num_ints; i++)
{
@@ -2251,7 +2251,7 @@ void
g_key_file_set_integer_list (GKeyFile*key_file,
const gchar *group_name,
const gchar *key,
-gint list[],
+gint64 list[],
gsizelength)
{
GString *values;
@@ -3629,17 +3629,16 @@ g_key_file_parse_string_as_value (GKeyFile*key_file,
return value;
}
-static gint
+static gint64
g_key_file_parse_value_as_integer (GKeyFile *key_file,
const gchar *value,
GError **error)
{
gchar *end_of_valid_int;
- glong long_value;
- gint int_value;
+ gint64 int_value;
errno = 0;
- long_value = strtol (value, end_of_valid_int, 10);
+ int_value = strtoll (value, end_of_valid_int, 10);
if (*value == '\0' || *end_of_valid_int != '\0')
{
@@ -3653,8 +3652,7 @@ g_key_file_parse_value_as_integer (GKeyFile *key_file,
return 0;
}
- int_value = long_value;
- if (int_value != long_value || errno == ERANGE)
+ if (errno == ERANGE)
{
gchar *value_utf8 = _g_utf8_make_valid (value);
g_set_error (error,
@@ -3672,10 +3670,10 @@ g_key_file_parse_value_as_integer (GKeyFile
*key_file,
