Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: > On 11/08/2009 10:54 AM, Alexander Larsson wrote: > > I've been working on some API for gio (more details later) that involves > > having an API for (de)compression. Having this as a public API makes > > zlib a mandatory dependency for libgio (and thus the glib tarball). > > Hi, > > Will there some kind of plug-in architecture so it is possible to add > say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib > dependency also be made optional? Not that I see a problem with a > mandatory zlib dependency. The API in question includes compression and decompression as streams (among other things), and is pluggable. Code to do automatic detection of compression type could easily be added. However, having some level of support being guaranteed (i.e. a mandatory dependency) has additional value that something being pluggable doesn't. For instance you could distribute zlib compressed data (as file or linked into your app) and depend on all glib installations being able to decompress that data. It also means you can e.g. design file formats based on a specific compression algorithm and never run into issues with some platform not having what is needed to read the file. Plugin-based optional compression support is basically only useful for best-effort decompression of "unimportant" document files. Thats obviously nice to have, but not as important as reliable compression support. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: > On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson wrote: > > I've been working on some API for gio (more details later) that involves > > having an API for (de)compression. Having this as a public API makes > > zlib a mandatory dependency for libgio (and thus the glib tarball). > > > > We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps > > already pull this in, however there could be non-gtk+ using glib apps > > that now get an additional dependency. Its a very small (74K .so) and > > very widely availible/used library though, so I don't think this is a > > huge deal. > > > > Anyone who thinks this is a bad idea? > > > > Well - as I already said earlier, I think GIO - in the long run - has > a potential of becomming *the* free desktop API for file-management. > Simply because it's design is modern, universal and reminiscent of IO > APIs, which people already know from other programming languages (i.e. > Java). And it's sitting very low in the stack. Such an API is hard to > design and takes long to consolidate. I know you're really interested in cross-desktop VFS support, and I don't disagree with having something like that. However, the fact is that libGIO is an important part of the Gtk development stack, that contains all the stuff that developers that want to write Gtk+ apps want. Just like Qt contains all that Qt developers want/need. We will never artificially limit our platform just because of cross-desktop compatibility. And additionally, I don't see GIO as the thing that should really be shared between glib and Qt, but rather GVFS. I'd much rather see some cooperation between the gvfs and Qt people to stabilize the gvfs protocols such that Qt could directly talk to gvfs mounts. Obviously some could could be shared, but a straight dependency on libgio isn't necessary. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Unsubscribe
Hi, Kindly unsubscribe from the mailing list. Regards, Shashi Information transmitted by this e-mail is proprietary to MphasiS, its associated companies and/ or its customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmas...@mphasis.com and delete this mail from your records. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unsubscribe
Am Mon, 9 Nov 2009 03:28:57 -0800 schrieb Shashidhara B : > Hi, > > Kindly unsubscribe from the mailing list. > > Regards, > Shashi Please use http://mail.gnome.org/mailman/listinfo/gtk-devel-list like everyone else to unsubscribe yourself. You managed to subscribe on your own as well, didn't you? Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:23 +0100, Alexander Larsson wrote: > On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: > Obviously some could could be shared, but a straight dependency on > libgio isn't necessary. Eh, "some code could be shared" is what i meant. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: > On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: > > On 11/08/2009 10:54 AM, Alexander Larsson wrote: > > > I've been working on some API for gio (more details later) that involves > > > having an API for (de)compression. Having this as a public API makes > > > zlib a mandatory dependency for libgio (and thus the glib tarball). > > > > Hi, > > > > Will there some kind of plug-in architecture so it is possible to add > > say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib > > dependency also be made optional? Not that I see a problem with a > > mandatory zlib dependency. > > The API in question includes compression and decompression as streams > (among other things), and is pluggable. Code to do automatic detection > of compression type could easily be added. > > However, having some level of support being guaranteed (i.e. a mandatory > dependency) has additional value that something being pluggable doesn't. > For instance you could distribute zlib compressed data (as file or > linked into your app) and depend on all glib installations being able to > decompress that data. It also means you can e.g. design file formats > based on a specific compression algorithm and never run into issues with > some platform not having what is needed to read the file. > > Plugin-based optional compression support is basically only useful for > best-effort decompression of "unimportant" document files. Thats > obviously nice to have, but not as important as reliable compression > support. Could this be used by libsoup for websites that zlib-compress their data? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus API Questions; was: GDBus/GVariant plans for next GLib release
Hey Mikkel, Sorry for not replying sooner! On Wed, 2009-10-28 at 21:23 +0100, Mikkel Kamstrup Erlandsen wrote: > >> Attached is a series of patches (0001 should be identical to my > >> previous) implementing what you describe, except adding the gboolean > >> enumerated arg to @introspect and @dispatch. I will get around to > >> that. Yeah, on second thought, it's probably best to skip that. > >> The failing unit tests I described was really just me b0rking up the > >> linking between some installed gdbus components and my devel version. > >> I have them running now[1] and I added some testing for the dynamic > >> objects as well (see 0003). > > > > Some more tests to go with the other patches attached. > > And of course the attachment :-S This looks great, thanks for working on it and for writing unit tests too. I've committed the patches with a small patch for white-space / style fixes on top! Thanks, David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
Hey Ryan,
Sorry for the lag,
On Sat, 2009-10-31 at 17:27 -0400, Ryan Lortie wrote:
> On Tue, 2009-10-20 at 11:17 -0400, David Zeuthen wrote:
> > So how about something like 1. and 2. below? We'd put
> >
> > g_dbus_connection_get_handle_for_unix_fd()
> > g_dbus_connection_set_handle_for_unix_fd()
>
> I was actually thinking that we could introduce a GDBusFDSet:
>
> gint g_dbus_fd_set_add_fd (gint fd) {
> list_of_fds[fd_count] = dup (fd);
> return fd_count++;
> }
>
> gint g_dbus_fd_set_get_fd (gint index) {
> return dup (list_of_fds[index]);
> }
>
> g_dbus_fd_set_finalize () {
> foreach (fd in list_of_fds) close (fd);
> }
>
> You'd add fds to that and get ints back (starting at 0 per the set).
> Then when sending the dbus message you'd give the GVariant and the
> DBusFDSet to the appropriate function.
>
> var fd = open("file");
> var fdset = new FDSet ();
> var message = new GVariant ("(sh)",
> "hello world",
> fdset.add_fd (fd));
>
> g_dbus_proxy_invoke_with_fds (proxy, "Foo", message, fdset, ...);
>
> When receiving messages, you get a DBusFDSet handed to you in the event
> that there were file descriptors (or just %NULL in case not).
>
> The fds held in the GDBusFDSet are closed when the set is finalized.
> There is no doubt about who owns which fd in this case -- and in the
> case you elect to ignore fds that were sent to you then everything is
> still cleaned up properly.
Hmm, I don't like this approach. It means you'd have to pass this
GDBusFDSet object around in code you use to build/parse the GVariant. In
particular, your proposed GTypeSerializer would need support for it.
That's problematic because that one lives in libgobject, not libgio
(where GDBusFDSet would live).
I still think the approach I described works better.
For example, suppose I have a C type mapping that maps a{sh} to a
GHashTable from strings to gint. I'd like to write code like this
my_hash = g_hash_table_new (g_str_hash, g_str_equal);
g_hash_table_insert (my_hash,
"fd-for-client",
GINT_TO_POINTER (fd_for_client));
/* need to keep fd_for_client alive until we hand off the hash */
foo_bar_invoke_process_client (proxy, my_hash, );
g_hash_table_unref (my_hash);
/* it's now safe to close the fd, the dbus stuff has already dupped
* it... note that we could have just used a GDestroyNotify for the
* values in my_hash to do this.
*/
close (fd_for_client);
where the latter function represents a generated function for the
ProcessClient() method on the foo.Bar interface that takes a single
a{sh} parameter represented by a GHashTable.
On the receiving end it would look like this. Suppose the GimmeFds
function returns a a{sh}:
my_hash = foo_bar_invoke_gimme_fds_sync (proxy, cancelable, &error);
fd = GPOINTER_TO_INT (g_hash_table_lookup (my_hash, "stream1"));
if (fd > 0)
{
fd_for_stream1 = dup (fd);
}
/* the value destroy notifier on my_hash closes all fds */
g_hash_table_unref (my_hash);
Thoughts?
Thanks,
David
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus/GVariant plans for next GLib release
Hey Alex, On Fri, 2009-11-06 at 21:05 +0100, Alexander Larsson wrote: > On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote: > > > http://cgit.freedesktop.org/~david/gdbus-standalone/ > > I just read through this for basic review, and I must say that I like > it. Very nice stuff. Some comments: Thanks for reading through it! > In nautilus I'd like to have an object path which is basically a pointer > to another object. Say I have these objects: > > /nautilus/window/1/tabs/1/view > /nautilus/window/1/tabs/2/view > > Then i want something like: > > /nautilus/window/1/active_view > > That always points to the view object in the active tab. > > Now, i could constantly be re-creating this object all the time, but > thats not really very nice. What i instead want to do is basically > register a subtree at /nautilus/window/1/active_view which dynamically > looks up which tab is active and then re-routes to the right tab. > > To implement this cleanly I would need to be able to lookup an object at > a given path (returning the ifaces, vtables and user data) and to > enumerate the children of a given path. All this would be in-client > registered objects/subtrees only, and is enough to implement > GDBusSubtreeVTable for the "pointer subtree". Yeah, I guess that's a reasonable thing to add. How about? gboolean g_dbus_connection_lookup_object (GDBusConnection *connection, const gchar *object_path, const gchar *interface_name, GDBusInterfaceInfo **out_introspection_data, GDBusInterfaceVTable **out_vtable, gpointer *out_user_data, guint *out_id); gboolean g_dbus_connection_lookup_subtree (GDBusConnection *connection, const gchar *object_path, GDBusInterfaceVTable **out_vtable, GDBusSubtreeFlags *out_flags, gpointer *out_user_data, guint *out_id); > I don't see any call to dbus_threads_init() or > dbus_threads_init_default(). Surely this should be done if gthread is > enabled. Ideally in g_thread_init_glib(), but thats a bit hard for > something in libgio... Yeah, oops, good point - I guess we should do this in gdbusconnection.c > I'd like it to be possible to specify a non-default main context when > creating a connection with g_dbus_connection_new() or > g_dbus_connection_bus_get_private(). Hmm, yeah, I was thinking about that. It's for specifying the mainloop for processing D-Bus messages, right? I was actually thinking that it might be nicer to always have a dedicated thread for handling D-Bus messages. This would be shared by all connections and it would just pop messages to the mainloops for method invocations and signals. This is feasible even if g_thread_init() has not be called, we'd just use libpthread directly (which libdbus-1 pulls in already). > g_dbus_connection_send_dbus_1_message_with_reply() has a race condition > if called on a thread other than the one dispatching the reply. The > pending call may be completed before dbus_pending_call_set_notify() is > reached. See _g_dbus_connection_call_async in gvfs/common/gdbusutils.c > for a possible workaround. Will do. > The way e.g. properties are implemented is very static. There is no way > to expose an object with a dynamic set of properties (apart from > removing and re-adding the object with new introspection data each time > dynamic properties/methods can't be implemented? (lazy, i.e. not remove > and re-add each time they change). I guess this is sort of weird wrt how > dbus usually works, but might be useful when exporting an object from a > more dynamic language like javascript or python. Hmm, yeah, but remember that D-Bus properties (like GObject properties) is part of the actual type - e.g. they are declared in introspection data. So it would be very weird to have dynamic properties, it would be similar to having dynamic properties on GObject. If you want dynamic properties it's much better to just define your own interfaces/methods for this (like e.g. HAL does). > Maybe we should not claim to implement org.freedesktop.DBus.Properties > if set/get_property are NULL? Yeah, probably not. > I'm not sure if I missed it, because i didn't try it out, but how do > registered object with a a child that is specified by registering a > subtree get enumerated when introspecting the registered object? I'm not sure I understand this question - can you clarify? > The foo_bar_error_quark example in gdbuserror.c clearly should just call > a standard helper that does all this, just given the pointer to an array > of data. Yeah, I guess we can add some convenience for that. > org.gtk.GDBus.UnmappedGError.Quark0xHEXENCODED_QUARK_NAME_.Code_ERROR_CODE > Why use a hex encoding fo
Re: GDBus/GVariant plans for next GLib release
On Mon, 09 Nov 2009 at 08:52:08 -0500, David Zeuthen wrote: > Yeah, we can choose another encoding that hex. The problem is that D-Bus > is very strict about what characters it accepts for names - in > particular, '-' is not accepted. So we'd need some kind of way to escape > things. You're very welcome to copy telepathy-glib's tp_escape_as_identifier() (HTTP-style escaping using _ instead of %, fitting within all the restricted character sets of D-Bus, and also the character set of C identifiers) to any project that needs it. I think so far I've implemented it at least three times in two languages... It's a reversible encoding in order to guarantee that it preserves uniqueness, but so far I've never needed to write a function to decode it (we usually use it to encode account names, etc. into our object paths, either for uniqueness, ease of debugging or both). It's pretty good for strings that are "nearly identifiers", and pessimal for arbitrary natural-language text (every escaped byte produces three bytes of output, so it'd triple the size of any non-ASCII text). Simon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 12:23 PM, Alexander Larsson wrote: > On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: >> On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson wrote: >> > I've been working on some API for gio (more details later) that involves >> > having an API for (de)compression. Having this as a public API makes >> > zlib a mandatory dependency for libgio (and thus the glib tarball). >> > >> > We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps >> > already pull this in, however there could be non-gtk+ using glib apps >> > that now get an additional dependency. Its a very small (74K .so) and >> > very widely availible/used library though, so I don't think this is a >> > huge deal. >> > >> > Anyone who thinks this is a bad idea? >> > >> >> Well - as I already said earlier, I think GIO - in the long run - has >> a potential of becomming *the* free desktop API for file-management. >> Simply because it's design is modern, universal and reminiscent of IO >> APIs, which people already know from other programming languages (i.e. >> Java). And it's sitting very low in the stack. Such an API is hard to >> design and takes long to consolidate. > > I know you're really interested in cross-desktop VFS support, and I > don't disagree with having something like that. However, the fact is > that libGIO is an important part of the Gtk development stack, that > contains all the stuff that developers that want to write Gtk+ apps > want. Just like Qt contains all that Qt developers want/need. We will > never artificially limit our platform just because of cross-desktop > compatibility. > > And additionally, I don't see GIO as the thing that should really be > shared between glib and Qt, but rather GVFS. I'd much rather see some > cooperation between the gvfs and Qt people to stabilize the gvfs > protocols such that Qt could directly talk to gvfs mounts. > > Obviously some could could be shared, but a straight dependency on > libgio isn't necessary. > Hmm... I don't really understand the neccessity to rewrite the entire GVFS client in Qt/C++. All the other programming languages use bindings, therefore why should Qt/C++ be different? * While writing a pure Qt/C++ client would certainly be possible (apart from the issue with the UriMappers), it would be a huge effort. * With one disadvantage: Standardizing all the D-Bus mechanics inside GVFS would probably make it harder to move forward. My feeling is that it's always the best approach to define the stable public interface at the "narrowest" part of the chain. Which not neccessarily has to be the IPC part. * Just compare this to libdbus: The IPC protocol is standardized, but almost everyone uses the libdbus as "the real interface". * "libGIO is an important part of the Gtk development stack". Yes, but - at least at the moment - it doesn't carry a lot of things in it, which are Gnome/Gtk specific. Most of the things are either the implementation of freedesktop-standards, or GVFS related. So it just looks like the "all you need for file-management" API, I just can't help it. And in my opinion it's a really cool one. Sorry, Alexander, that i'm asking to put a different label on it. I think GIO deserves to be more than a detail in the Gtk stack. :-) * I think if GIO/GVFS can pull Qt and KDE into their boat, this would be an important signal for all the 3rd party applications to link a proper VFS interface. Because at the moment many of them won't, as this implies deciding for a certain desktop environment. * Hopefully, one day people will realize, that KDE, Gnome and Qt are kind of living in the same appartment. There is no way to escape from that - independence is a dream. For one simple reason: applications, applications, applications. They are the most important desktop feature, the primary reason to buy a computer. So what's the point of having all the "infrastructure" duplicated: The toaster, the dish-washer, the washing-machine... ;-) This duplication just causes an enormous amount of chaos. However, i think a pure Qt implementation of GVFS would definitely be a very important move into the right direction. Cheers, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On 11/09/2009 07:53 AM, Bastien Nocera wrote: > Could this be used by libsoup for websites that zlib-compress their > data? It could (and eventually would), but "passing data to zlib" isn't the hard part of the problem there. (And this will actually be working in libsoup in 2.28.2.) -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote: > On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: > > On 11/08/2009 10:54 AM, Alexander Larsson wrote: > > > I've been working on some API for gio (more details later) that involves > > > having an API for (de)compression. Having this as a public API makes > > > zlib a mandatory dependency for libgio (and thus the glib tarball). > > > > Hi, > > > > Will there some kind of plug-in architecture so it is possible to add > > say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib > > dependency also be made optional? Not that I see a problem with a > > mandatory zlib dependency. > > The API in question includes compression and decompression as streams > (among other things), and is pluggable. Code to do automatic detection > of compression type could easily be added. > > However, having some level of support being guaranteed (i.e. a mandatory > dependency) has additional value that something being pluggable doesn't. > For instance you could distribute zlib compressed data (as file or > linked into your app) and depend on all glib installations being able to > decompress that data. It also means you can e.g. design file formats > based on a specific compression algorithm and never run into issues with > some platform not having what is needed to read the file. > > Plugin-based optional compression support is basically only useful for > best-effort decompression of "unimportant" document files. Thats > obviously nice to have, but not as important as reliable compression > support. That sounds fair. Right now, Yelp will happily build without bzip2 and lzma support if you don't have them. I consider it a distro problem: if distros want to ship man and info pages compressed with bzip2 or lzma, then they need to make sure their Yelp is built right. I have no problems pushing that policy decision lower. How do you envision the optional extra support being provided? Would there be extension points that GVFS could plug into? Or compile-time optional modules like the GdkPixbuf loaders? Or would applications be expected to provide the extra juice? I'm willing to do the grunt work to add these. It's work I'd have to do in Yelp anyway to fully transition to GIO. Thanks for tackling the hard part of the problem. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
On Mon, 2009-11-09 at 08:21 -0500, David Zeuthen wrote:
> Sorry for the lag,
No problems :)
> Hmm, I don't like this approach. It means you'd have to pass this
> GDBusFDSet object around in code you use to build/parse the GVariant. In
> particular, your proposed GTypeSerializer would need support for it.
> That's problematic because that one lives in libgobject, not libgio
> (where GDBusFDSet would live).
I disagree. I'd actually like to keep support for file descriptors out
of the type serialiser entirely. It's just a little bit "too magic" for
my tastes.
A file descriptor is not normally considered to be a serialisable
object.
> I still think the approach I described works better.
>
> For example, suppose I have a C type mapping that maps a{sh} to a
> GHashTable from strings to gint. I'd like to write code like this
>
> my_hash = g_hash_table_new (g_str_hash, g_str_equal);
> g_hash_table_insert (my_hash,
> "fd-for-client",
> GINT_TO_POINTER (fd_for_client));
>
> /* need to keep fd_for_client alive until we hand off the hash */
This, for example, is *way* too magic. I can't ever think of a case
where I store fds in hash tables, much less want to send a hash table
full of fds over DBus.
>{
> fd_for_stream1 = dup (fd);
>}
>
> /* the value destroy notifier on my_hash closes all fds */
> g_hash_table_unref (my_hash);
I agree with the general idea of file descriptor ownership you expose
here. Does that imply that if you send a single file descriptor over
DBus to a handler function that takes an 'int' then you'll have to
close() the fd in the same way as you're responsible to free the hash
table?
> Thoughts?
In general, I think that sending file descriptors over DBus is done
sufficiently rarely that it is not worth it to have support for it *this
deeply* integrated. In particular, I think that it's definitely not
appropriate to support it in the GTypeSerialiser code.
I also can never imagine a (non-hypothetical) case of wanting to send an
entire hash table of file descriptors over DBus. Even if I could
imagine one, it would be highly specialised, and I wouldn't mind writing
the code to do it myself -- and it wouldn't be hard to do.
One reason that I particularly like the GDBusFdSet approach is that, on
receive, it allows the user to give a NULL pointer for the out
parameter. In that case, the file descriptors received from the bus
will be automatically closed and the user needn't worry about doing
anything at all (ie: no fd leaks).
I appreciate that doing the GDBusFdSet thing results in some
uglification of the GDBus API (ie: addition of a new type and some new
functions call variants in some places) but I think this is the
reasonable thing to do. fd-passing is *very* DBus-specific. Please
remember that GVariant and GTypeSerialiser are general purpose datatypes
with many potential uses (eg: dconf, GSettings, mmap files, etc) and
that for these other uses, serialising a file descriptor makes no sense
at all.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why are no developers completing/maintaining native Gtk+ for OS X?
Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. I must say I find this rather baffling. I would have thought a platform like OS X to be a priority? I know that solutions like MacPorts provide Gtk+ for the X server in OS X, but I strongly doubt that the average OS X user would know where to begin with a project like MacPorts, and to be honest the look 'N feel * compared to native OS X. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. I would urge anyone with the time and knowledge to consider helping complete Gtk+ for native OS X. Sincerely Jacob Juul Kolding Juvul Tech ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 2009-11-09 at 19:10 +0100, Jack Skellington wrote: > Hello All > > I'm currently in charge of the development of a cross-platform OpenGL > app which uses GTk+ for it's interface. > The app runs on both *nix/X.org and win32 but when I started looking > into OS X I found that the Quartz OS X version of Gtk+ is neither > complete nor being actively developed. > > I must say I find this rather baffling. I would have thought a > platform like OS X to be a priority? Why do you think that? > I know that solutions like MacPorts provide Gtk+ for the X server in > OS X, but I strongly doubt that the average OS X user would know where > to begin with a project like MacPorts, and to be honest the look 'N > feel * compared to native OS X. > > Also if a native Gtk+ OS X framework were available people who are > maintaining Gtk+ apps would have the option to extend their user base > to OS X quite quickly. > > I would urge anyone with the time and knowledge to consider helping > complete Gtk+ for native OS X. Someone like for example you? This is a mostly volunteer driven project, and people usually tend to scratch their itches first before they do stuff that "needs to be done". So if it's itching you, please help completing and fixing OS X support. regards, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls & co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira wrote: > > Besides, glib is only a dependency of Qt on the X11 platform. I can justify a > VFS API that requires D-Bus to work properly (with some effort, on some > platforms other IPC mechanisms would be preferable), but I cannot do it if it > requires using glib & gobject in platforms that its own maintainers currently > don't support. Hmm ... I think a VFS API shouldn't even require D-Bus to work. Just like GIO only uses D-Bus/GVFS on X11. I agree that a QtVFS shouldn't depend on GIO in the API. But perhaps it would make sense to design it close to GIO so that it can act as a thin binding when GIO is available. My feeling is that the tough part of a new QtVFS is designing and consolidating the API. Therefore my thought was: If GIO has proven to be portable, an API which is designed to wrap GIO should be portable itself. Without necessarly depending on GIO. So this approach might save lot's of time. Cloning GIO in QObject/C++ style should save months racking one's brain about little details like which virtual methods and signals are required in which class. And if such an API moves towards a pure QDBus implementation later, why not. But starting with that might be putting the cart before the horse. Because I'm a bit worried that a complete rewrite of GVFS in Qt/C++ is just a too ambitios undertaking to get started. Regards, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_test_find_widget bug?
This seems to be either a bug in my understanding of how to use this
functionality or a bug in the gtk_test_find_widget function itself.
Here's the smallest working code I could come up with to demonstrate
the problem:
#include
#include
#include
static void
do_import (GtkWidget *widget, gconstpointer data)
{
printf ("Import!\n");
}
static void
do_quit (GtkWidget *widget, gconstpointer data)
{
printf ("Quit!\n");
}
GtkWidget*
build_menu (void)
{
GtkWidget *menu;
GtkWidget *import;
GtkWidget *quit;
menu = gtk_menu_new ();
import = gtk_image_menu_item_new_with_label ("Import");
gtk_menu_shell_append (GTK_MENU_SHELL (menu), import);
g_signal_connect (G_OBJECT (import), "activate", G_CALLBACK
(do_import), NULL);
quit = gtk_image_menu_item_new_with_label ("Quit");
gtk_menu_shell_append (GTK_MENU_SHELL (menu), quit);
g_signal_connect (G_OBJECT (quit), "activate", G_CALLBACK (do_quit), NULL);
return menu;
}
int
main (int argc, char* argv[])
{
GtkWidget *menu;
GtkWidget *found_import;
GtkWidget *found_quit;
gtk_test_init (&argc, &argv, NULL);
menu = build_menu ();
found_quit = gtk_test_find_widget (menu, "Quit", GTK_TYPE_MENU_ITEM);
g_assert (NULL != found_quit);
gtk_menu_item_activate (GTK_MENU_ITEM (found_quit));
found_import = gtk_test_find_widget (menu, "Import", GTK_TYPE_MENU_ITEM);
g_assert (NULL != found_import);
gtk_menu_item_activate (GTK_MENU_ITEM (found_import));
return 0;
}
When I run this I expect it to print:
Quit!
Import!
Instead I get:
Quit!
Quit!
If I change "Import" in the last call to gtk_test_find_widget with
"Anything", I get the expected failure from the next g_assert.
--
Michael C. Libby
www.mikelibby.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 9 Nov 2009, Kristian Rietveld wrote: > No, [the Quartz port of GTK+] is not fully complete, but getting > close. Recently, I have been working on reviewing outstanding > patches [and other good stuff] ... I do not get paid for this > at all. Saying that the OS X port is not being actively > developed is actually close to insulting to me; I have been > trying my best to pick it up after the previous maintainer > stopped working on it. It's good to hear that GTK on Quartz has not gone to sleep; thanks very much for your work on this! Unfortunately this is not immediately clear if you google, say, "gtk osx". Top of the search is the defunct Immendio page; if you follow that link you get a redirect to live.gnome.org, which is pretty much a placeholder. Finally you get to gtk-osx.sourceforge.net, but this page is a bit "scatter-gun" and, unlike the old Immendio page, there's no link (that I can find) to download a current build of GTK for OS X. You get a d/l link if you go to www.gtk-osx.org, but this offers GTK 2.14 which is quite dated by now, and gives the impression there can't be anything going on. I suspect that many GTK app developers (who probably work on Linux by preference) really don't want to build the GTK stack for OS X themselves (any more than they want to build the stack for win32). So if there's no reasonably current d/l available one assumes support is lacking. Bottom line: If there's any way to improve the web presence of GTK/OS X, and to provide a current pre-built GTK framework for downloading, that could make a big difference. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls & co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
> > On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: > > Hello All > > > > I'm currently in charge of the development of a cross-platform OpenGL > > app which uses GTk+ for it's interface. > > The app runs on both *nix/X.org and win32 but when I started looking > > into OS X I found that the Quartz OS X version of Gtk+ is neither > > complete nor being actively developed. > > No, it is not fully complete, but getting close. Recently, I have > been working on reviewing outstanding patches, fixing up the last few > kinks remaining after the transition to client side windows and > implemented proper and complete multi monitor support. I do have > plans on how to continue my work on the backend. Development of the > Mac port is actually pretty active. I only have very ample spare time > to work on this and I do not get paid for this at all. Saying that > the OS X port is not being actively developed is actually close to > insulting to me; I have been trying my best to pick it up after the > previous maintainer stopped working on it. Well, let me be the first to thank you for all you efforts Kris, you have been extremely helpful to me, and I am actively developing a ERP (Ordering, purchasing, Inventory, CRM) for the company I work for. The work you and John Ralls et al. have done has made it possible for me to do my work. So keep up the good work. > > Also if a native Gtk+ OS X framework were available people who are > > maintaining Gtk+ apps would have the option to extend their user base > > to OS X quite quickly. > > The basics for this have been worked out in the past and are available > for everybody to pick up. John Ralls & co have been doing a good job > at making GTK+ easy to build and looking into scripts for simplifying > the creation of application bundles for GTK+ applications and a > framework. http://gtk-osx.sourceforge.net/ I have successfully used this on OS X Leopard (build the framework and app using jhbuild, with ige-mac-integration), and have been able to build the framework on SN (but my application crashes out, I think because of libglade which I really need to move away from, fix it for GtkBuilder). I to wish it was more complete (window transparency and shaping, is what I'm looking for), but I do not have a good enough grasp of Cocoa and Carbon (Not very familiar with Next Step windowing system) to be of any use, but I will certainly try to help were I can. Two years moving from Windows to Linux, and now OS X, V1 to be deployed in 010110. I'm not quite sure what you mean (Jacob) when you say "native" implementation, if you look at the quartz backend it looks pretty close to me, again with a lot of FIXME's in non-essential areas such as (window shaping), but that is not at all important for our functionality. It works, and it works well on OS X, just follow the jhbuild procedures form the above link. > > > > -kris. > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) > Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS > X? > From: ja...@juvul.com > Date: Tue, 10 Nov 2009 00:35:44 +0100 > To: k...@gtk.org > CC: gtk-devel-list@gnome.org > > On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: > > > On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: > >> Hello All > >> > >> I'm currently in charge of the development of a cross-platform OpenGL > >> app which uses GTk+ for it's interface. > >> The app runs on both *nix/X.org and win32 but when I started looking > >> into OS X I found that the Quartz OS X version of Gtk+ is neither > >> complete nor being actively developed. > > > > No, it is not fully complete, but getting close. Recently, I have > > been working on reviewing outstanding patches, fixing up the last > > few kinks remaining after the transition to client side windows and > > implemented proper and complete multi monitor support. I do have > > plans on how to continue my work on the backend. Development of the > > Mac port is actually pretty active. I only have very ample spare > > time to work on this and I do not get paid for this at all. Saying > > that the OS X port is not being actively developed is actually close > > to insulting to me; I have been trying my best to pick it up after > > the previous maintainer stopped working on it > > I can't tell you how happy reading this makes me. I love Gtk+ and have > been using it in projects for like a decade, mostly on *nix, but > lately cross-platform. > As for the insult part, it was never my intention, I was merely > relaying the present information thats available on the Gtk+ OS X > sourceforge site. > > Keep up the good work! > If I had money, I'd pay you ;) > > >> Also if a native Gtk+ OS X framework were available people who are > >> maintaining Gtk+ apps would have the option to extend their user base > >> to OS X quite quickly. > > > The basics for this have been worked out in the past and are > > available for everybody to pick up. John Ralls & co have been doing > > a good job at making GTK+ easy to build and looking into scripts for > > simplifying the creation of application bundles for GTK+ > > applications and a framework. > > A framework as in the Gtk.framework folder you add to the Xcode > project and then build? > > Ever since I started developing in OS X I've found this approach quite > beautiful in its simplicity. > I will seriously consider looking into this myself if/when I have the > time, > > Thanks again! > Jacob Juul Kolding > Juvul Tech > > > > > -kris. > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
On Mon, 9 Nov 2009, Shawn Bakhtiar wrote: > To build the latest framework: > > 1) Get the latest using jhbuild and build > 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ App developer here again: Right now I can get a fully functional GTK+ framework (but one that relies on X11, not native) from http://r.research.att.com/ . It's stable, and does what I need, so that's what I use when packaging my project for OS X. I'd much prefer to use a native (non-X11) OS X GTK+ framework, but not if I have to build it myself (sorry, life is too short). I've tried what I think is the only downloadable native package (namely, the old Imendio one) but it's not good enough for production use. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about "jhbuild + URL", could you please list all commands needed? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) > Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? > From: ja...@juvul.com > Date: Tue, 10 Nov 2009 00:35:44 +0100 > To: k...@gtk.org > CC: gtk-devel-list@gnome.org > > On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: > > > On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: > >> Hello All > >> > >> I'm currently in charge of the development of a cross-platform OpenGL > >> app which uses GTk+ for it's interface. > >> The app runs on both *nix/X.org and win32 but when I started looking > >> into OS X I found that the Quartz OS X version of Gtk+ is neither > >> complete nor being actively developed. > > > > No, it is not fully complete, but getting close. Recently, I have > > been working on reviewing outstanding patches, fixing up the last > > few kinks remaining after the transition to client side windows and > > implemented proper and complete multi monitor support. I do have > > plans on how to continue my work on the backend. Development of the > > Mac port is actually pretty active. I only have very ample spare > > time to work on this and I do not get paid for this at all. Saying > > that the OS X port is not being actively developed is actually close > > to insulting to me; I have been trying my best to pick it up after > > the previous maintainer stopped working on it > > I can't tell you how happy reading this makes me. I love Gtk+ and have > been using it in projects for like a decade, mostly on *nix, but > lately cross-platform. > As for the insult part, it was never my intention, I was merely > relaying the present information thats available on the Gtk+ OS X > sourceforge site. > > Keep up the good work! > If I had money, I'd pay you ;) > > >> Also if a native Gtk+ OS X framework were available people who are > >> maintaining Gtk+ apps would have the option to extend their user base > >> to OS X quite quickly. > > > The basics for this have been worked out in the past and are > > available for everybody to pick up. John Ralls & co have been doing > > a good job at making GTK+ easy to build and looking into scripts for > > simplifying the creation of application bundles for GTK+ > > applications and a framework. > > A framework as in the Gtk.framework folder you add to the Xcode > project and then build? > > Ever since I started developing in OS X I've found this approach quite > beautiful in its simplicity. > I will seriously consider looking into this myself if/when I have the > time, > > Thanks again! > Jacob Juul Kolding > Juvul Tech > > > > > -kris. > > > smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_test_find_widget bug?
On Mon, Nov 9, 2009 at 3:57 PM, Michael Libby wrote:
> This seems to be either a bug in my understanding of how to use this
> functionality or a bug in the gtk_test_find_widget function itself.
After reading the source for the various gtk_test_find_* functions and
the documentation over again, the bug was my own understanding.
The function gtk_test_find_widget() is trying to find a widget *near*
a label with the text in question, whereas I was thinking it would
find the widget that *contained* the text in question.
No surprise that the existing function has somewhat strange behavior
when attempting to locate menu items.
Suggest to add something like to find the widget with the actual text:
GtkWidget*
gtk_test_find_widget_by_text (GtkWidget *widget,
const gchar *label_pattern,
GType widget_type)
{
if (GTK_IS_LABEL (widget))
{
const gchar *text = gtk_label_get_text (GTK_LABEL (widget));
if (g_pattern_match_simple (label_pattern, text))
return widget;
}
if (GTK_IS_CONTAINER (widget))
{
GList *node, *list = gtk_container_get_children (GTK_CONTAINER (widget));
for (node = list; node; node = node->next)
{
GtkWidget *label = gtk_test_find_widget_by_text (node->data,
label_pattern, widget_type);
if (label)
{
if (g_type_is_a (G_OBJECT_TYPE (widget), widget_type))
{
return widget;
}
else
{
return label;
}
}
}
g_list_free (list);
}
return NULL;
}
--
Michael C. Libby
www.mikelibby.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 3:34 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about "jhbuild + URL", could you please list all commands needed? Please forgive me if it sounded "bossy", that wasn't the plan... I've tried following the instructions on the gtk+osx sourceforge page, but "jhbuild bootstrap" fails because "tex" is missing. Anyone know where I can get that? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) > Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? > From: ja...@juvul.com > Date: Tue, 10 Nov 2009 00:35:44 +0100 > To: k...@gtk.org > CC: gtk-devel-list@gnome.org > > On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: > > > On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: > >> Hello All > >> > >> I'm currently in charge of the development of a cross-platform OpenGL > >> app which uses GTk+ for it's interface. > >> The app runs on both *nix/X.org and win32 but when I started looking > >> into OS X I found that the Quartz OS X version of Gtk+ is neither > >> complete nor being actively developed. > > > > No, it is not fully complete, but getting close. Recently, I have > > been working on reviewing outstanding patches, fixing up the last > > few kinks remaining after the transition to client side windows and > > implemented proper and complete multi monitor support. I do have > > plans on how to continue my work on the backend. Development of the > > Mac port is actually pretty active. I only have very ample spare > > time to work on this and I do not get paid for this at all. Saying > > that the OS X port is not being actively developed is actually close > > to insulting to me; I have been trying my best to pick it up after > > the previous maintainer stopped working on it > > I can't tell you how happy reading this makes me. I love Gtk+ and have > been using it in projects for like a decade, mostly on *nix, but > lately cross-platform. > As for the insult part, it was never my intention, I was merely > relaying the present information thats available on the Gtk+ OS X > sourceforge site. > > Keep up the good work! > If I had money, I'd pay you ;) > > >> Also if a native Gtk+ OS X framework were available people who are > >> maintaining Gtk+ apps would have the option to extend their user base > >> to OS X quite quickly. > > > The basics for this have been worked out in the past and are > > available for everybody to pick up. John Ralls & co have been doing > > a good job at making GTK+ easy to build and looking into scripts for > > simplifying the creation of application bundles for GTK+ > > applications and a framework. > > A framework as in the Gtk.framework folder you add to the Xcode > project and then build? > > Ever since I started developing in OS X I've found this approach quite > beautiful in its simplicity. > I will seriously consider looking into this myself if/when I have the > time, > > Thanks again! > Jacob Juul Kolding > Juvul Tech > > > > > -kris. > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 10, 2009, at 4:03 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 3:34 AM, Jacob Juul Kolding wrote: On Nov 10, 2009, at 1:05 AM, Shawn Bakhtiar wrote: To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I know absolutely nothing about "jhbuild + URL", could you please list all commands needed? Please forgive me if it sounded "bossy", that wasn't the plan... I've tried following the instructions on the gtk+osx sourceforge page, but "jhbuild bootstrap" fails because "tex" is missing. Anyone know where I can get that? Nevermind the tex thing, the actual problem is that glib fails to build because gettext is missing? /Jacob I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) > Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? > From: ja...@juvul.com > Date: Tue, 10 Nov 2009 00:35:44 +0100 > To: k...@gtk.org > CC: gtk-devel-list@gnome.org > > On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: > > > On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: > >> Hello All > >> > >> I'm currently in charge of the development of a cross- platform OpenGL > >> app which uses GTk+ for it's interface. > >> The app runs on both *nix/X.org and win32 but when I started looking > >> into OS X I found that the Quartz OS X version of Gtk+ is neither > >> complete nor being actively developed. > > > > No, it is not fully complete, but getting close. Recently, I have > > been working on reviewing outstanding patches, fixing up the last > > few kinks remaining after the transition to client side windows and > > implemented proper and complete multi monitor support. I do have > > plans on how to continue my work on the backend. Development of the > > Mac port is actually pretty active. I only have very ample spare > > time to work on this and I do not get paid for this at all. Saying > > that the OS X port is not being actively developed is actually close > > to insulting to me; I have been trying my best to pick it up after > > the previous maintainer stopped working on it > > I can't tell you how happy reading this makes me. I love Gtk+ and have > been using it in projects for like a decade, mostly on *nix, but > lately cross-platform. > As for the insult part, it was never my intention, I was merely > relaying the present information thats available on the Gtk+ OS X > sourceforge site. > > Keep up the good work! > If I had money, I'd pay you ;) > > >> Also if a native Gtk+ OS X framework were available people who are > >> maintaining Gtk+ apps would have the option to extend their user base > >> to OS X quite quickly. > > > The basics for this have been worked out in the past and are > > available for everybody to pick up. John Ralls & co have been doing > > a good job at making GTK+ easy to build and looking into scripts for > > simplifying the creation of application bundles for GTK+ > > applications and a framework. > > A framework as in the Gtk.framework folder you add to the Xcode > project and then build? > > Ever since I started developing in OS X I've found this approach quite > beautiful in its simplicity. > I will seriously consider looking into this myself if/when I have the > time, > > Thanks again! > Jacob Juul Kolding > Juvul Tech > > > > > -kris. > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson wrote: > I know you're really interested in cross-desktop VFS support, and I > don't disagree with having something like that. However, the fact is > that libGIO is an important part of the Gtk development stack, that > contains all the stuff that developers that want to write Gtk+ apps > want. i've written some relatively big GTK apps. i've never wanted to use any of the facilities that GIO offers me. how is it central to GTK? maybe to GNOME apps? i don't know - I don't target GNOME at all. > Just like Qt contains all that Qt developers want/need. This was one of the primary reasons I chose GTK over Qt. I'll make my own choices about libraries for IPC, sockets, UUIDs and the like, thank you very much. I was looking for a widget-based GUI toolkit, not MFC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 7:19 PM, Jacob Juul Kolding wrote: Nevermind the tex thing, the actual problem is that glib fails to build because gettext is missing? Then you didn't do jhbuild bootstrap. Everyone: Please, if you're having trouble building with jhbuild, ask in the gtk-osx-us...@lists.sourceforge.net mailing list or on the Gtk- OSX forum at http://sourceforge.net/apps/phpbb/gtk-osx/ Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 3:35 PM, Jacob Juul Kolding wrote: On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) In light of all of the work Kristian has done in the last few weeks, I've taken out the stuff about "not actively maintained". There's still a fair number (about 80) "FIXME: Implement" comments, so for now I think it's still accurate to say that it's not feature complete. Sorry, Kristian, I should have updated that sooner. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
