Re: gtk_container_new_child (was Re: Wrapping Box Container)
On Wed, 2010-09-01 at 10:59 -0400, Havoc Pennington wrote: > Hi, > > On Wed, Sep 1, 2010 at 6:41 AM, Tristan Van Berkom > wrote: > > I like this idea alot and as its a trivial patch I might write one > > up tonight or tomorrow ... > > well, it's trivial except for the need to add some kind of gobject API > (or you could do it in a somewhat hacky way without that, I think) > > > I can see how that can reduce some lines of code when building > > UIs directly with code (not GtkBuilder)... although I think it > > would be best to avoid as it throws property and packing property > > names into the same namespace (so if ever packing properties and > > object properties share the same name, this api will be a little > > ambiguous as to which will be assigned, or one or the other > > would be prioritized...). > > > > Thoughts ? > > I think packing props should "win" (for back compat, among other > reasons). If there's a collision and you want to set the prop on the > child, you would need to just avoid this convenience function or set > the one colliding prop separately, which seems simple enough. I don't > know that there would be too many collisions in practice especially if > we thought about that when naming props. > > It COULD be done where you had to do a NULL separator between > container and child sort of like this: > > new_child(container, "foo", 1, NULL, MY_TYPE_CHILD, "bar", 5, NULL); > > however since it's a convenience API I think "common case convenience" > might be better than "handles weird corner case of colliding > properties" > > Another option is to allow prefixes on the prop names, > > new_child(container, MY_TYPE_CHILD, "parent::foo", 1, "child::bar", 2, NULL); > > where the prefix would be optional and only needed in case of ambiguity. > > The new_child version is harder than just add_with_properties() > supporting child props, because it involves marshaling to object_newv > or something. (again needing more gobject API at least for max > efficiency) > Ahh I see I misunderstood your email... as I can see that gtk_container_add_with_properties() already exists. On the other hand... since g_object_new() will never return NULL... I'm not sure how much this api would be different than simply invoking these lines of code: gtk_container_add_with_properties (container, g_object_new (GTK_TYPE_FOO, "fill", FALSE, NULL), "expand", TRUE, NULL); Its just about the same amount of typing in C... and already has no ambiguities regarding properties/child-properties. We could also safely make g_object_set() return the input object for this type of convenience... like g_object_ref() already does. Allowing this construct: gtk_container_add_with_properties (container, g_object_set (child, "fill", FALSE, NULL), "expand", TRUE, NULL); Ofcourse its perfectly valid C code already to type: gtk_container_add_with_properties (container, (g_object_set (child, "fill", FALSE, NULL), child), "expand", TRUE, NULL); although not many people are fans of using the comma operator in this way... personally I think its quite elegant to use in some cases... for instance: "ptr = (g_free(ptr), NULL);". Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Thu, Sep 2, 2010 at 5:38 AM, Tristan Van Berkom wrote: > On the other hand... since g_object_new() will never return NULL... > I'm not sure how much this api would be different than simply > invoking these lines of code: > > gtk_container_add_with_properties (container, > g_object_new (GTK_TYPE_FOO, > "fill", FALSE, > NULL), > "expand", TRUE, > NULL); good point, this isn't bad, at least. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Does anyone have any opinions on the main idea here, i.e. move padding to GtkWidget instead of putting it in every container (and GtkMisc)? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Thu, Sep 2, 2010 at 10:35 AM, Havoc Pennington wrote: > Does anyone have any opinions on the main idea here, i.e. move padding > to GtkWidget instead of putting it in every container (and GtkMisc)? I haven't looked at it in detail yet, but the gut feeling is 'hell yes, anything that reigns in the zoo of padding properties is a good thing'. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: (Style) Property review
I have now committed a first round of cleanups to master (and corresponding deprectations to 2.22). In detail, > 1) GtkDialog::has-separator > GtkMessageDialog::use-separator These are gone. > 2) GtkStatusIcon::blinking Gone. > 3) GtkIconView::orientation > GtkCellRendererProgress::orientation > GtkProgressBar::orientation GtkIconView::orientation has been renamed to item-orientation, The progress orientation properties have been split into a GtkOrientation and an 'inverted' boolean. > 6) GtkEntry::state-hint > GtkTreeView::row-ending-details > GtkRange::activate-slider > GtkRange::stepper-position-details > GtkRange::trough-side-details > GtkWidget::wide-separators These are all gone, except for wide-separators, which may need some more study. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
2010/9/2 Havoc Pennington : > See bugs: > > https://bugzilla.gnome.org/show_bug.cgi?id=395578 > https://bugzilla.gnome.org/show_bug.cgi?id=491507 > > I'm attaching a patch which proposes some API to make GdkPixbuf > support the cairo RGB24/ARGB32 formats. > In this patch, there's no actual code to convert, it would come from > gdk/gdkcairo.c, I didn't mess with it yet. The functions are unnecessarily general. Only two functions are needed: an in-place conversion of an entire pixbuf, and duplication with conversion (to cover cases where the number of bytes per pixel is different, or lossy conversion). There's no need to support copying regions between pixbufs with conversion, because compositing is Cairo's job. > The idea would be to have a second patch, which would let you set up a > pixbuf loader to load the new formats; the pixbuf loader would then > convert on the fly for backends that didn't have support for the new > formats, initially that'd be all of them. But we could give loaders a > "format hint" later. The conversion between non-premultiplied BE RGBA to premultiplied native-endian ARGB is lossless in practice. E.g. even if you convert back to non-premul, it doesn't matter in most cases, because to display the image on the screen you'll have to convert back to premul anyway. So instead of modifying all the loaders, we could just convert to the new format after loading. Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Sun, Aug 29, 2010 at 7:02 PM, Havoc Pennington wrote: > > - one approach: put padding stuff in the size_request / size_allocate > *wrappers* in the same way that size groups and set_size_request are > handled. all widgets just work without modifications, is the big plus > of this. > Implementation-wise, I'm kind of leaning toward this, plus virtualizing "get the extra padding for request" and "remove the extra padding for allocation" and calling those virtual methods from the wrappers. So in this world, GtkSizeRequest, size_request, size_allocate are all unchanged. GtkWidget has "modify request" / "modify allocation" virtual functions. After size requesting the widget, those virtual functions might be called from _gtk_size_group_bump_requisition where we currently use aux_info->width,height. In fact, the aux_info forced size request could now be implemented inside gtkwidget.c by these vfuncs, so AuxInfo could be completely privatized. This would allow GtkWidget::padding-*, GtkWidget::h,valign, GtkMisc::scale,pad, and GtkContainer::border_width to all be implemented transparently (i.e. without subclasses having to do anything in their request/allocate methods). Making Misc and Container transparent would be incompatible changes (breaking subclasses) however, so maybe we don't want to do that. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Thanks for diving into this. As a datapoint, here is the current GTK/GDK api that directly involves GdkPixbuf: gtk_about_dialog_get_logo gtk_about_dialog_set_logo gtk_assistant_set_page_header_image gtk_assistant_get_page_header_image GtkCellRendererPixbuf::pixbuf GtkCellRendererPixbuf::pixbuf-expander-open GtkCellRendererPixbuf::pixbuf-expander-closed gtk_cell_view_new_with_pixbuf gtk_clipboard_set_image gtk_clipboard_wait_for_image gtk_drag_source_set_icon_pixbuf gtk_drag_set_icon_pixbuf gtk_entry_set_icon_from_pixbuf gtk_entry_get_icon_pixbuf gtk_icon_set_new_from_pixbuf gtk_icon_set_render_icon gtk_icon_source_set_pixbuf gtk_icon_source_get_pixbuf gtk_icon_theme_load_icon gtk_icon_theme_add_builtin_icon gtk_icon_info_new_for_pixbuf gtk_icon_info_get_builtin_pixbuf gtk_icon_info_load_icon gtk_image_new_from_pixbuf gtk_image_new_from_animation gtk_image_set_from_pixbuf gtk_image_set_from_animation gtk_image_get_pixbuf gtk_image_get_animation gtk_offscreen_window_get_pixbuf gtk_recent_info_get_icon gtk_selection_data_set_pixbuf gtk_selection_data_get_pixbuf gtk_status_icon_new_from_pixbuf gtk_status_icon_set_from_pixbuf gtk_status_icon_get_pixbuf gtk_style_render_icon gtk_text_buffer_insert_pixbuf gtk_text_iter_get_pixbuf gtk_tooltip_set_icon gtk_widget_render_icon gtk_window_get_icon gtk_window_set_icon gtk_window_set_default_icon gdk_cursor_new_from_pixbuf gdk_cursor_get_image gdk_draw_pixbuf gdk_pixbuf_render_* gdk_pixbuf_get_from_drawable gdk_pixbuf_get_from_image ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Hi, 2010/9/2 Krzysztof Kosiński : > The functions are unnecessarily general. Only two functions are > needed: an in-place conversion of an entire pixbuf, and duplication > with conversion (to cover cases where the number of bytes per pixel is > different, or lossy conversion). There's no need to support copying > regions between pixbufs with conversion, because compositing is > Cairo's job. The region copy is needed for incremental pixbuf load in GdkPixbufLoader, I think. If it isn't then I agree the function isn't super useful. The way I would see things working is that most of the image loader backends could continue to generate pixbuf's classic format, but if you'd asked for cairo format, the loader would create a second pixbuf in the cairo format and then copy over the areas as they load, exposing only the second cairo-formatted pixbuf to the application. (Assuming the app has requested cairo format.) I initially had a function that did a "destructive" convert of a pixbuf, which was in-place if possible. A trick is that all props on pixbuf are currently immutable (CONSTRUCT_ONLY). We could change that, of course. But it's sort of a messy change for only an optimization, and it's not like setting n_channels post-construct is allowed, so removing CONSTRUCT_ONLY is kind of wrong. Also, for the incremental load, you would end up with a pixbuf that was partly in one format and partly in another format. That would be... weird. Though it might work. Making the PNG and JPEG loaders load without a convert, and adding cairo's formats to the pixdata inline stuff, might be good enough to avoid conversion in practice in almost all real applications. With copying convert as a rare fallback which could just be slightly inefficient instead of in-place. i.e. TIFF support can have some extra overhead and we'll survive it. i.e. the idea is that in-place conversion is sort of thorny and the optimization really isn't important as long as we avoid conversion in the three or so common cases. And avoiding conversion entirely does save CPU, while in-place only saves memory but still uses CPU. > The conversion between non-premultiplied BE RGBA to premultiplied > native-endian ARGB is lossless in practice. E.g. even if you convert > back to non-premul, it doesn't matter in most cases, because to > display the image on the screen you'll have to convert back to premul > anyway. So instead of modifying all the loaders, we could just convert > to the new format after loading. The only reason to modify the loaders would be efficiency, just to avoid a convert. My thought was to first implement loading with a convert fallback, but then as an optimization, loaders could support directly loading to the proper format. Whether we optimize with an inplace convert or with loaders knowing about the destination format, a copying convert seems like a simple place to start, so that's why the initial API here is copying. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen wrote: > Thanks for diving into this. > > As a datapoint, here is the current GTK/GDK api that directly involves > GdkPixbuf: > Cool, thanks. In a quick grep, basically nothing has been changed to pass around cairo_surface_t as a representation of "an image" So the current situation really is that images are pixbufs it seems like. I don't know. I know it isn't The Plan, but I'd sort of lean toward *not* trying to change all pixbufs to cairo surface. I sort of like the idea that cairo objects are used just during the paint(), when they are created and immediately tossed. But for persistent objects, a GObject is nicer. Not to mention avoiding all the deprecations and portings and stuff. Each pixbuf could keep a cairo_surface_t which just pointed to the pixbuf pixels and that cairo_surface_t would be used in paint() or for other compositing/scaling/etc. kind of operations. In this plan, Loader and Animation would not be deprecated. However, arguably "classic pixbuf format" and the stuff in gdk-pixbuf that only works on it (scaling, compositing, saturate_and_pixelate, etc.) would all be deprecated; to do that kind of stuff, you'd use cairo. Maybe gdk-pixbuf would grow some nice convenience functions that used cairo internally, i.e. a scale_simple() is still nice to have, and it would use cairo to work on the cairo formats. (hmm. that's one approach - add gdk_pixbuf_get_cairo_surface(); then make all the pixbuf scaling/compositing APIs basically do "if cairo format, use cairo, else use old pixbuf code" - so the pixbuf APIs become convenience wrappers around cairo operations) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, Sep 2, 2010 at 1:29 PM, Havoc Pennington wrote: > On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen > wrote: >> Thanks for diving into this. >> >> As a datapoint, here is the current GTK/GDK api that directly involves >> GdkPixbuf: >> > > Cool, thanks. In a quick grep, basically nothing has been changed to > pass around cairo_surface_t as a representation of "an image" > > So the current situation really is that images are pixbufs it seems like. > There is some move to cairo surfaces in Benjamins rendering-cleanup branch (replacing pixmaps with surfaces in some places). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Hi, On Thu, Sep 2, 2010 at 2:05 PM, Matthias Clasen wrote: > There is some move to cairo surfaces in Benjamins rendering-cleanup > branch (replacing pixmaps with surfaces in some places). Replacing pixmaps seems right to me (because cairo_surface_t is basically replacing GdkDrawable). But pixbufs ... a "pixbuf has-a surface" model seems more sane. Deprecating all of the gdk-pixbuf library and GTK APIs using it seems 1) not worth it and 2) like it would result in a less-convenient API. I guess a counterargument is "maybe you want to use a non-image surface sometimes" so maybe we should go through your list and see if that's actually useful. But if we didn't have a GdkPixmap API before, I'm not sure there's much case that a pixmap-backended cairo_surface_t is useful either. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Hi, I thought of another approach to this problem. Don't expose the pixbuf format at all; keep it as-is. However, add: gdk_pixbuf_get_cairo_surface() gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface); Now, keep the cairo surface internally, strong-ref'd by the pixbuf. The pixbuf would have pixels == NULL. If someone does gdk_pixbuf_get_pixels(), then lazily create the old pixbuf format and keep that copy of the pixels around. Otherwise, never create the old format. If you create a pixbuf NOT from a cairo surface, then the reverse occurs. pixels != NULL, and a surface is lazily created and kept around if anyone does gdk_pixbuf_get_cairo_surface(). There are various APIs in gdk-pixbuf that call get_pixels() in the implementation. These would all be modified to use cairo_surface_t operations instead if the cairo_surface was set, and use the existing pixbuf code otherwise. So basically a GdkPixbuf can be either the old stuff internally, or a cairo surface internally, or have both cached, but with the same API either way. Some downsides: - two copies of the pixels would be kept for the two formats, in the case where we create a pixbuf in old format and then draw it. - APIs that modify the pixels might have to either modify both copies, or discard one of them to be lazily recreated - but wouldn't know which to toss - if you modified the surface pixels or the old-style pixels by hand, it would not affect the other format - this could be VERY surprising. The main upside would be zero new API, other than to/from cairo surface. The downside is that if something dumb is happening that ends up repeatedly converting pixels or keeping both pixel representations around eating memory, it would not necessarily be obvious. In this scheme, perhaps get_pixels, get_n_channels, get_colorspace, etc. (all the internal representation APIs) would be deprecated. You are supposed to port that code to get the surface and then mess with the cairo surface. Conceptually, GdkPixbuf's exposed pixel buffer representation becomes cairo_surface_t instead of colorspace, n_channels, get_pixels, etc.; GdkPixbuf is a cairo_surface_t wrapper instead of a guchar* wrapper. If/when get_pixels can be removed entirely, then the internal representation could always be cairo_surface_t _only_. The old constructors would immediately convert to cairo format. get_pixels() is the only reason external code would ever care about pixbuf internal representation. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, Sep 2, 2010 at 3:52 PM, Havoc Pennington wrote: > Hi, > > I thought of another approach to this problem. Don't expose the pixbuf > format at all; keep it as-is. However, add: > > gdk_pixbuf_get_cairo_surface() > gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface); > > Now, keep the cairo surface internally, strong-ref'd by the pixbuf. > The pixbuf would have pixels == NULL. If someone does > gdk_pixbuf_get_pixels(), then lazily create the old pixbuf format and > keep that copy of the pixels around. Otherwise, never create the old > format. Some variations of this theme (make GdkPixbuf a wrapper around a cairo surface) have been discussed. It is certainly attractive in terms of the amount of new api, and in terms of keeping the GdkPixbuf-based gtk apis intact. One thing I wonder about though: one of the big reasons to keep GdkPixbuf around is the image loaders. But in this scheme, every pixbuf thats loaded from a file would end up with an old-style internal representation, right ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Thu, Sep 2, 2010 at 12:50 PM, Havoc Pennington > > Implementation-wise, I'm kind of leaning toward this, plus > virtualizing "get the extra padding for request" and "remove the extra > padding for allocation" and calling those virtual methods from the > wrappers. > > So in this world, GtkSizeRequest, size_request, size_allocate are all > unchanged. GtkWidget has "modify request" / "modify allocation" > virtual functions. After size requesting the widget, those virtual > functions might be called from _gtk_size_group_bump_requisition where > we currently use aux_info->width,height. In fact, the aux_info forced > size request could now be implemented inside gtkwidget.c by these > vfuncs, so AuxInfo could be completely privatized. Yeah, this sounds like a good approach. Of course, this only handles the size_request side of things. It would be up to individual containers to respect the h/v-align in their size_allocate (basically replacing their current child properties), correct ? I also agree that just leaving GtkMisc and GtkAlignment as-is, and aiming for removing them in 4.0, is the best we can do at this point. One thing that is not addressed yet is how we will split this between application control and theme control. To illustrate the point, here is the list of 'layout' properties we have currently: GtkAlignment::bottom-padding GtkAlignment::left-padding GtkAlignment::right-padding GtkAlignment::top-padding GtkBox::spacing GtkButtonBox::layout-style GtkTable::column-spacing GtkTable::row-spacing GtkExpander::spacing GtkContainer::border-width GtkMisc::xalign GtkMisc::yalign GtkMisc::xpad GtkMisc::ypad And here are some of the 'layout' style properties: GtkDialog::action-area-border GtkDialog::button-spacing GtkDialog::content-area-border GtkDialog::content-area-spacing GtkInfoBar::action-area-border GtkInfoBar::button-spacing GtkInfoBar::content-area-border GtkInfoBar::content-area-spacing GtkMessageDialog::message-border GtkAssistant::content-padding GtkAssistant::header-padding GtkProgressBar::xspacing GtkProgressBar::yspacing GtkButton::default-border GtkButton::default-outside-border GtkButton::inner-border GtkButton::image-spacing GtkEntry::inner-border GtkEntry::progress-border GtkScale::value-spacing GtkMenu::horizontal-offset GtkMenu::horizontal-padding GtkMenu::vertical-offset GtkMenu::vertical-padding GtkMenuBar::internal-padding GtkMenuItem::horizontal-padding GtkMenuItem::toggle-spacing GtkToolbar::internal-padding GtkToolItemGroup::header-spacing GtkToolButton::icon-spacing GtkButtonBox::child-internal-pad-x GtkButtonBox::child-internal-pad-y GtkExpander::expander-spacing GtkScrolledWindow::scrollbar-spacing GtkCalendar::horizontal-separation GtkCalendar::vertical-separation GtkCalendar::inner-border GtkRange::stepper-spacing GtkWidget::focus-padding ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Hi, On Thu, Sep 2, 2010 at 5:07 PM, Matthias Clasen wrote: > One thing I wonder about though: one of the big reasons to keep > GdkPixbuf around is the image loaders. But in this scheme, every > pixbuf thats loaded from a file would end up with an old-style > internal representation, right ? > Loaders would have the option of using new_from_data() or new_from_cairo_surface(). We would probably say new_from_cairo_surface was preferred and port the interesting loaders to do that. I was thinking about the problem of wasting memory, writing to one internal representation and not changing the other, etc. How about this: we only keep one representation around. If you get_pixels we drop the surface, if you get_cairo_surface we drop the old-style pixels. We deprecate get_pixels() which is the only call that can force the old-style representation to be created. If you do use get_pixels(), what's going to happen is that you do your pixel editing, and on the next paint gdk_pixbuf_get_cairo_surface() will force conversion back to cairo representation. So the only "big fail" case is where you want to modify the pixbuf pixels on every frame, or with some frequency. Those cases would just have to be ported over to cairo_surface usage. But hang on: gdk_cairo_set_source_pixbuf() currently converts on *every paint*, *always*. So we have some evidence that this isn't even a huge deal. With the loaders, if they are unmodified then they create in old-style, but on first call to get_cairo_surface we drop the old style pixels. If they are updated to start from a surface, then the old-style is only created if someone uses deprecated get_pixels. I'm liking this approach. It's minimal code, and easy to make correct. The "hard part" is purging get_pixels usage, but that is a performance issue only, not a correctness one, and unlikely to be worse than gdk_cairo_set_source_pixbuf already is. Am I missing a big downside? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Sep 1, 2010, at 7:53 PM, John Ralls wrote: > > On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote: > >> On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: >>> It's now on Sourceforge because when Richard decided with his partner >>> wind up Imendio and to withdraw from Gtk+, he asked on his forum for >>> someone to take over maintaining the build system. I bit, and after >>> some probing discovered that he'd not been successful in getting >>> anyone to take over *any* of the components; he had some hope that one >>> or more of his former Imendio employees who were still involved with >>> Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered >>> that it would take some time and a lot of work to get a project >>> started at Gnome.org. It took a week at Sourceforge, and only that >>> long because I did a hostile takeover of a moribund project that was a >>> fork of Gtk 1 whose name I wanted. >> >> If you want a Git account so you can commit to Gtk+, it should be pretty >> easy. Three steps basically: >> 1. For the person requesting it: follow http://live.gnome.org/NewAccounts >> 2. A gtk+ maintainer: approving the Git account >> 3. Accounts team: setting it up >> >> This can all be done very quickly. >> >> If for some reason there is a delay in above process, feel free to >> send me a message. > > It seems likely that no. 2 will be the rub: I don't have a long track record > compared to others who don't have git commit priv (Paul Davis comes to > mind)... but maybe they never asked. So I just did. We'll see what happens, > eh? Well, much to my surprise, my Git account was approved in short order. So now the question is which pieces belong where? Gtk-quartz-engine already has a repo, so that's obvious. The GtkOSXApplication half of ige-mac-integration can go in gtk+/gtk, and its Python bindings to PyGtk if the devs over there are willing. But what about the build stuff and the proxy packages for docbook and gtk-doc-utils? Is there a logical home for them, should they have a new project on Gnome, or should they stay on SourceForge? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote: > Hi, > Am I missing a big downside? One downside that you've mentioned earlier is that with this approach, gdk-pixbuf grows a cairo (and thus libX11) dependency. That might inconvenience a few gdk-pixbuf users. But the one I know offhand, librsvg, already has a cairo dependency (via pango) anyway. So, probably not a big problem. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
Hi, On Thu, Sep 2, 2010 at 6:14 PM, Matthias Clasen wrote: > Of course, this only handles the size_request side of things. > It would be up to individual containers to respect the h/v-align in > their size_allocate (basically replacing their current child > properties), correct ? Couldn't we do it in gtk_widget_size_allocate ? I can just try this patch and any reason it won't work may become clear quickly > One thing that is not addressed yet is how we will split this between > application control and theme control. To illustrate the point, here > is the list of 'layout' properties we have currently: > GtkAlignment::bottom-padding > GtkAlignment::left-padding > GtkAlignment::right-padding > GtkAlignment::top-padding > GtkContainer::border-width > GtkMisc::xalign > GtkMisc::yalign > GtkMisc::xpad > GtkMisc::ypad The above would all be replaced by GtkWidget props I think > GtkBox::spacing > GtkButtonBox::layout-style > GtkTable::column-spacing > GtkTable::row-spacing > GtkExpander::spacing These would remain as container-specific probably (though I don't really know what Expander::spacing is and didn't look) > And here are some of the 'layout' style properties: I think we could add style props on GtkWidget that would modify the padding on the widget (I don't know if they'd just replace the programmer-set padding, or be an adjustment to it?). That would be simple once GtkWidget has padding, I think. I don't know if the widget style props would replace most of these though - it looks like most of these paddings and spacings are somewhere inside a widget, not on the border. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, 2010-09-02 at 13:29 -0400, Havoc Pennington wrote: > Each pixbuf could keep a cairo_surface_t which just pointed to the > pixbuf pixels and that cairo_surface_t would be used in paint() or for > other compositing/scaling/etc. kind of operations. Are you thinking of the loaders populating an image surface (and thus being in application memory) or populating an xlib surface (and thus being in X server memory?) People seem to have gone to a lot of effort over the years to find the right mix between GdkPixmap and GdkPixbuf and a fair bit of code has been written (using ie cairo_surface_create_similar()) to do caching, etc. Between your ideas here and Benjamin's work, I get the impression that the status quo is well and truly smashed [great!] but now I'm definitely vague about what's being loaded where, and when someone is going to have to worry [differently] about the performance implications of large copies between app and X server, etc. AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
Hi, On Thu, Sep 2, 2010 at 11:21 PM, Andrew Cowie wrote: > Are you thinking of the loaders populating an image surface (and thus > being in application memory) or populating an xlib surface (and thus > being in X server memory?) I'm not proposing any change here. Loaders currently go to pixbufs (which are always application memory), and I'm proposing that when a pixbuf uses a cairo surface as representation, that cairo surface is always an image surface. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf<->cairo_surface_t conversion
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote:
> I was thinking about the problem of wasting memory, writing to one
> internal representation and not changing the other, etc. How about
> this: we only keep one representation around. If you get_pixels we
> drop the surface, if you get_cairo_surface we drop the old-style
> pixels.
>
> We deprecate get_pixels() which is the only call that can force the
> old-style representation to be created. If you do use get_pixels(),
> what's going to happen is that you do your pixel editing, and on the
> next paint gdk_pixbuf_get_cairo_surface() will force conversion back
> to cairo representation.
>
Here is an (untested) patch to implement this.
From 08eea58e9fb0d1b28392bca1d6ac320d3264bbb2 Mon Sep 17 00:00:00 2001
From: Matthias Clasen
Date: Fri, 3 Sep 2010 00:55:43 -0400
Subject: [PATCH] cairo_surface_t <-> GdkPixbuf conversion
---
configure.ac|2 +-
gdk-pixbuf/gdk-pixbuf-cairo.h | 39 +
gdk-pixbuf/gdk-pixbuf-private.h |4 +
gdk-pixbuf/gdk-pixbuf.c | 293 ++-
gdk-pixbuf/gdk-pixbuf.h |1 +
5 files changed, 336 insertions(+), 3 deletions(-)
create mode 100644 gdk-pixbuf/gdk-pixbuf-cairo.h
diff --git a/configure.ac b/configure.ac
index 5bf8248..498432d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -903,7 +903,7 @@ if test $cross_compiling = yes; then
fi
fi
-GDK_PIXBUF_PACKAGES="gmodule-no-export-2.0 gobject-2.0 gio-2.0"
+GDK_PIXBUF_PACKAGES="gmodule-no-export-2.0 gobject-2.0 gio-2.0 cairo"
GDK_PIXBUF_EXTRA_LIBS="$STATIC_LIB_DEPS $MATH_LIB $MEDIA_LIB"
GDK_PIXBUF_EXTRA_CFLAGS=
GDK_PIXBUF_DEP_LIBS="`$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES` $GDK_PIXBUF_EXTRA_LIBS"
diff --git a/gdk-pixbuf/gdk-pixbuf-cairo.h b/gdk-pixbuf/gdk-pixbuf-cairo.h
new file mode 100644
index 000..1e4b048
--- /dev/null
+++ b/gdk-pixbuf/gdk-pixbuf-cairo.h
@@ -0,0 +1,39 @@
+/* GdkPixbuf library - GdkPixbuf data structure
+ *
+ * Copyright (C) 2010 Red Hat, Inc.
+ *
+ * Author: Matthias Clasen
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ */
+
+#if defined(GDK_PIXBUF_DISABLE_SINGLE_INCLUDES) && !defined (GDK_PIXBUF_H_INSIDE) && !defined (GDK_PIXBUF_COMPILATION)
+#error "Only can be included directly."
+#endif
+
+#ifndef GDK_PIXBUF_CAIRO_H
+#define GDK_PIXBUF_CAIRO_H
+
+#include
+
+G_BEGIN_DECLS
+
+cairo_surface_t *gdk_pixbuf_get_cairo_surface (const GdkPixbuf *pixbuf);
+GdkPixbuf *gdk_pixbuf_new_from_cairo_surface (cairo_surface_t *surface);
+
+G_END_DECLS
+
+#endif /* GDK_PIXBUF_CAIRO_H */
diff --git a/gdk-pixbuf/gdk-pixbuf-private.h b/gdk-pixbuf/gdk-pixbuf-private.h
index c060bd7..2ff22f2 100644
--- a/gdk-pixbuf/gdk-pixbuf-private.h
+++ b/gdk-pixbuf/gdk-pixbuf-private.h
@@ -31,6 +31,8 @@
#include
+#include
+
#include "gdk-pixbuf-core.h"
#include "gdk-pixbuf-io.h"
#include "gdk-pixbuf-i18n.h"
@@ -73,6 +75,8 @@ struct _GdkPixbuf {
/* Do we have an alpha channel? */
guint has_alpha : 1;
+
+cairo_surface_t *surface;
};
struct _GdkPixbufClass {
diff --git a/gdk-pixbuf/gdk-pixbuf.c b/gdk-pixbuf/gdk-pixbuf.c
index 824e290..5ea3e04 100644
--- a/gdk-pixbuf/gdk-pixbuf.c
+++ b/gdk-pixbuf/gdk-pixbuf.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#define GDK_PIXBUF_C_COMPILATION
#include "gdk-pixbuf-private.h"
#include "gdk-pixbuf-features.h"
@@ -178,10 +180,12 @@ static void
gdk_pixbuf_finalize (GObject *object)
{
GdkPixbuf *pixbuf = GDK_PIXBUF (object);
-
+
if (pixbuf->destroy_fn)
(* pixbuf->destroy_fn) (pixbuf->pixels, pixbuf->destroy_fn_data);
-
+if (pixbuf->surface)
+cairo_surface_destroy (pixbuf->surface);
+
G_OBJECT_CLASS (gdk_pixbuf_parent_class)->finalize (object);
}
@@ -441,6 +445,187 @@ gdk_pixbuf_get_bits_per_sample (const GdkPixbuf *pixbuf)
return pixbuf->bits_per_sample;
}
+static void
+convert_surface_to_pixels (GdkPixbuf *pixbuf)
+{
+ gint width = pixbuf->width;
+ gint height = pixbuf->height;
+ gint n_channels = pixbuf->n_channels;
+ gint gdk_rowstride = pixbuf->rowstride;
+ guchar *gdk_pixels;
+ guchar *cairo_pixels;
+ gint cairo_rowstride;
+ cairo_format_t format;
+ gint j;
+
+ gdk_pixels = g_malloc (height * gdk_rowstr
Re: pixbuf<->cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 12:59 AM, Matthias Clasen wrote: > On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington wrote: > >> I was thinking about the problem of wasting memory, writing to one >> internal representation and not changing the other, etc. How about >> this: we only keep one representation around. If you get_pixels we >> drop the surface, if you get_cairo_surface we drop the old-style >> pixels. >> >> We deprecate get_pixels() which is the only call that can force the >> old-style representation to be created. If you do use get_pixels(), >> what's going to happen is that you do your pixel editing, and on the >> next paint gdk_pixbuf_get_cairo_surface() will force conversion back >> to cairo representation. >> > > Here is an (untested) patch to implement this. > Oops. I just put one in bugzilla ;-) I should have worked on the widget padding today I guess. https://bugzilla.gnome.org/show_bug.cgi?id=491507 Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
