Scrollbar detection for full container
Hi all I have two GtkTables which are inside its own GtkViewport and GtkScrolledWindow. Both tables are fixed size and dynamically populated with widgets. When adding widgets I want to keep adding them to the first table just before the scrollbars appear, then I want to new widgets to be added to the second one. When the second one get full too I want to add new widgets to the first table and now see scrollbars. My first attempt was checking GTK_WIDGET_VISIBLE(gtk_scrolled_window_get_vscrollbar(...)) but this only works after the widget has been shown so my guess is that I need to hook into the size allocation strategy used by GtkTable, is this the best approach? Thanks Per ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: outstream question [i think]
From: dev...@iamaquatics.org, Date: 25/08/2009 16:50, Wrote: The eventual goal is to create a program to log incidents at an aquatic facility. As of right now, I am just trying to write some small simple things to stretch out my [programming] legs. The goal is to connect to the database and retrieve some information on the click of the button. I can't seem to find the equivalent of a cout statement for gtk. I have googled it to no avail. GIO has I/O streams, though I can't imagine that being what you actually want. cout, if I remember my C++ correctly, is often used as a shorthand for printf() and the likes that are intrinsic to C/C++. If you're just wanting to write messages to the terminal temporally during development, that's probably the easiest way to go. GLib also has some message logging functions that'll write messages to the terminal, can be told to be considered an error, and other log message type support. If you're wanting to log messages, as in to a rotated log file, I believe there's libraries and/or glib functionality for that, some of which may include syslog support in Unix's. Then there's also GTKmm if you're working in C++, instead of trying to bang around in GTK directly. Or if you're trying to move to straight C without the ++, there's also Vala which is rather nice. I also believe I have read all the relevant documentation (including having to use the g_free() function. Again, GTKmm or Vala will make that mostly unnecessary. Fredderic Criminal Lawyers - Click here. Criminal Lawyer http://tagline.excite.com/fc/FgElN1g4hg7yQz5bFoAfhrQQndZbxK2MiyEtp8tru8FqIwNNTigE9IXmQmM/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Webkit-gtk and MacOSX
Hi, On Sun, Aug 23, 2009 at 6:26 AM, John Rallsjra...@ceridwen.us wrote: I wonder, though, if that's the best approach for Gtk+ applications using Quartz, since Webkit is already well integrated into the system. If I were Interesting question really. I can see that it feels like overkill to have a Quartz Webkit-GTK build next to the system's Webkit. to provide a Gtk-Carbon shim library using the approach in http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/Tasks/CarbonApps.html will it integrate OK with gdk-quartz and cairo-quartz? What I am wondering about is how this will work with GTK+ applications that are using Webkit. Does Webkit-GTK have any specific APIs? Does font rendering look similar? Does Webkit-GTK handle parts of GTK+ theming that are not possible using the Carbon shim approach you are suggesting? regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Tue, Aug 25, 2009 at 10:20 PM, Kristian Rietveldk...@gtk.org wrote: to provide a Gtk-Carbon shim library using the approach in http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/Tasks/CarbonApps.html will it integrate OK with gdk-quartz and cairo-quartz? What I am wondering about is how this will work with GTK+ applications that are using Webkit. Does Webkit-GTK have any specific APIs? WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Does font rendering look similar? Similar to what? The system WebKit? I believe WebKitGTK+ uses pango in OSX, so I suppose it depends on what pango does in OSX. Does Webkit-GTK handle parts of GTK+ theming that are not possible using the Carbon shim approach you are suggesting? I'm not sure of what that Carbon shim approach is or how it works, but WebKitGTK+ uses the current GTK+ theme for all its rendering, including web forms, media controls, etc. Cheers, Xan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote: WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Right, so another question: does the GObject API contain stuff that is not possible in the native layers for other platforms? Does font rendering look similar? Similar to what? The system WebKit? I believe WebKitGTK+ uses pango in OSX, so I suppose it depends on what pango does in OSX. Yes, that would be CoreText on recent releases. And I would guess system WebKit uses that as well. But combined with your following point: Does Webkit-GTK handle parts of GTK+ theming that are not possible using the Carbon shim approach you are suggesting? I'm not sure of what that Carbon shim approach is or how it works, but WebKitGTK+ uses the current GTK+ theme for all its rendering, including web forms, media controls, etc. If the Carbon shim approach does not take the GTK+ theme / fonts into account, there is a fair chance that the WebKit control will look kind of out-of-place in a GTK+ application. Especially if it also involves web form and media controls. What do you think? regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Tue, Aug 25, 2009 at 10:44 PM, Kristian Rietveldk...@gtk.org wrote: On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote: WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Right, so another question: does the GObject API contain stuff that is not possible in the native layers for other platforms? At this point in time it's mostly the other way around: there are still some APIs missing that the other more mature ports have, but we are closing the gap quickly. Do you have in mind anything specific though? Does Webkit-GTK handle parts of GTK+ theming that are not possible using the Carbon shim approach you are suggesting? I'm not sure of what that Carbon shim approach is or how it works, but WebKitGTK+ uses the current GTK+ theme for all its rendering, including web forms, media controls, etc. If the Carbon shim approach does not take the GTK+ theme / fonts into account, there is a fair chance that the WebKit control will look kind of out-of-place in a GTK+ application. Especially if it also involves web form and media controls. What do you think? Yeah, it would look out of place theming-wise, but probably also in other little things/interactions like bindings, copy/paste, etc. I think it general it makes lots of sense to use WebKitGTK+ if you are doing a GTK+ app, the library is not that big :) Cheers, Xan regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Tue, 2009-08-25 at 21:44 +0200, Kristian Rietveld wrote: On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote: WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Right, so another question: does the GObject API contain stuff that is not possible in the native layers for other platforms? Surely you'll want the GObject API for programming in your GObject-based toolkit. Otherwise you're effectively using a different widget and kill your portability. So surely the solution is WebKit-GTK+ on top of a system WebCore. I guess what would be attractive is to take the other existing system components used by WebKit on MacOSX and use those where possible too. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Aug 25, 2009, at 12:57 PM, Xan Lopez wrote: On Tue, Aug 25, 2009 at 10:44 PM, Kristian Rietveldk...@gtk.org wrote: On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote: WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Right, so another question: does the GObject API contain stuff that is not possible in the native layers for other platforms? At this point in time it's mostly the other way around: there are still some APIs missing that the other more mature ports have, but we are closing the gap quickly. Do you have in mind anything specific though? Does Webkit-GTK handle parts of GTK+ theming that are not possible using the Carbon shim approach you are suggesting? I'm not sure of what that Carbon shim approach is or how it works, but WebKitGTK+ uses the current GTK+ theme for all its rendering, including web forms, media controls, etc. If the Carbon shim approach does not take the GTK+ theme / fonts into account, there is a fair chance that the WebKit control will look kind of out-of-place in a GTK+ application. Especially if it also involves web form and media controls. What do you think? Yeah, it would look out of place theming-wise, but probably also in other little things/interactions like bindings, copy/paste, etc. I think it general it makes lots of sense to use WebKitGTK+ if you are doing a GTK+ app, the library is not that big :) Thank you both for hashing this out for me. I'll persevere with getting Webkit-Gtk to build with quartz, then. I'm not sure I agree that it's not that big: WebKit.framework clocks in at 78M. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GCancellable hints
From: Richard Hughes, Date: 25/08/2009 02:03, Wrote: The only functionality that ZifCancellable adds is two methods: void zif_cancellable_set_hint (GCancellable *cancellable, gboolean can_cancel); gboolean zif_cancellable_get_hint (GCancellable *cancellable); Why not just zif_cancellable_set_can_cancel or even zif_cancellable_set_cancellable? Seems pretty straight forward to me, and MUCH more obvious than hint, and I'm sure I remember seeing other instances similar to the latter functions naming floating around. Fredderic Scale Click for a wide selection of quality scales. http://tagline.excite.com/fc/FgElN1gvzpWfK4RBHVCIPCnVsYRAYUvR7HUV1ecHetxRp2TgyqcSUocXM9C/___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
2009/8/26 John Ralls jra...@ceridwen.us: Thank you both for hashing this out for me. I'll persevere with getting Webkit-Gtk to build with quartz, then. I'm not sure I agree that it's not that big: WebKit.framework clocks in at 78M. Whatever the WebKit.framework is, with that size it's bound to include something in addition to the WebKit library. The shared library is just 15MB on Linux. I don't think we are still missing *that* much API after all :) -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On Aug 25, 2009, at 10:10 PM, Kalle Vahlman wrote: 2009/8/26 John Ralls jra...@ceridwen.us: Thank you both for hashing this out for me. I'll persevere with getting Webkit-Gtk to build with quartz, then. I'm not sure I agree that it's not that big: WebKit.framework clocks in at 78M. Whatever the WebKit.framework is, with that size it's bound to include something in addition to the WebKit library. The shared library is just 15MB on Linux. I don't think we are still missing *that* much API after all :) Well, first off, Webkit drags in a bunch of dependencies (libsoup comes immediately to mind, but there are others) which aren't necessarily required by other parts of the application being bundled. Another major contribution is that MacOSX application binaries are roughly twice as big as Linux binaries because they must support two architectures (intel and power-pc) . Webkit is 4x, because it supports 32-bit and 64-bit for each. Even with all of that, the WebKit library itself (the equivalent of webkit.so on Linux) is only 7M. The WebCore library, tucked inside its own framework bundle inside WebKit.framework, is 63M, also with 4 architectures. There are also icon files, translations, and an application binary or two buried in each framework to account for the rest. Dividing 63 + 7 by 4 gets 17.5, so the single- binary Linux equivalent isn't that much different. I'm not at this point going to support 64-bit, so I guess I can expect WebKit-Gtk to add 43M (35M of binary and 8M of support stuff) to a client app download, assuming the person doing the bundling wants to support PPC. Since WebKit is already on every mac, it seems a waste of bandwidth, but if it's the only way to get WebKit to work with Gtk, it doesn't really matter. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
