Re: GdkScreen size-changed and gdk_monitor_get_workarea problem

[Bastien Nocera]

On Thu, 2018-11-08 at 12:34 +0100, Sebastian Geiger (Lanoxx) wrote:
> Dear Bastien,
> 
> thanks for the reply. I will attach a sample next time.
> 
> My App runs with the X11 backend.
> 
> I was able to resolve the issue yesterday, and found that it was not 
> directly a Problem of GTK+.
> 
> The problem is, that the window manager computes the workarea 
> asynchronosly, presumably its handled in a g_add_idle callback.
> When I tried to use get_geometry instead of get_workarea I was
> always 
> getting the correct values, but I specifically needed the workarea
> so 
> that was not helping.
> 
> My solution was then to register a filter function with 
> gdk_window_add_filter which listens for _NET_WORKAREA property
> changes 
> and then queue a g_add_idle callback which handles the change.
> 
> I tested the behavior with mutter and metacity and both had the same 
> problem.
> 
> I am not sure if this is by design, or a bug. However, I would like
> to 
> suggest that we add a small note to the documentation of the 
> monitor-changed signal and the size-change signal, stating that
> values reported by gdk_monitor_get_workarea might arrive delayed.
> Alternatively, fixing mutter and metacity would be my preferred
> solution 
> but would probably be more work and I have not the necessary
> knowledge 
> about mutter code to fix this myself.

I'd start with filing a bug against mutter (I'm not sure metacity is
still maintained), and see whether the GDK API documentation should be
amended after discussing it there.

Unless you're writing a panel of sorts, I don't think end-user
applications should use this API in any case, with the window manager
taking care of the window layout.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GdkScreen size-changed and gdk_monitor_get_workarea problem

[Bastien Nocera]

On Tue, 2018-11-06 at 21:35 +0100, Sebastian Geiger (Lanoxx) wrote:
> Hi Gtk developers,
> 
> I am experiencing a wired issue and I am wondering if I am using the
> API
> in a wrong way of if there is a problem with Gtk.

On Wayland or X11?



> gdk_display_get_monitor_at_point and then gdk_monitor_get_workarea.

IIRC, the latter function isn't implemented in Wayland.

In the future, it would also probably be best if you could attach or
copy/paste a minimal test case, so folks on the mailing-list can try
your code, and see either if there are errors in the code, or those are
really bugs (or missing functionality).

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: An alternative to gdk-pixbuf

[Bastien Nocera]

On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
wrote:
> On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
>  wrote:
> > On Tue, 11 Sep 2018 00:07:27 +0200
> > Bastien Nocera  wrote:
> > > No, it really isn't:
> > > 
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
> > > 
> > > We want to have less CVEs, not more.
> > 
> > I see what you mean. A few of them (although none of the more
> > serious
> > ones) were even related to the GIF loader specifically. But the
> > sheer
> > volume kind of speaks for itself otherwise. :(
> 
> IM joined Google's OSS-Fuzz programme last year:
> 
> https://github.com/google/oss-fuzz
> 
> The huge surge in CVEs was caused by that --- they've been fixing one
> or two a day ever since. Once they are through this very painful
> process, IM ought to be rather safe.
> 
> I do agree though that it's a large and complex thing to use for such
> a (relatively) simple task.

I maintained ImageMagick in RHEL a long time ago, it was already that
way though security issues cropped up a bit less often than every day
(!). I don't see any reason for us to want to us it.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: An alternative to gdk-pixbuf

[Bastien Nocera]

On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:
> On Mon, 10 Sep 2018 11:31:42 +0200
> Bastien Nocera  wrote:
> 
> > > I've written loader for GIF that simply wraps abydos. In lines of
> > > code it's about a quarter the size of the current loader, even
> > > including
> > > the GIF plugin for abydos. It might even be slightly smaller with
> > > the whole of abydos included in the equation. On the downside it
> > > probably doesn't pass the test suite since I haven't tried it.
> > > But
> > > I will, and hopefully publish the whole thing in a couple of
> > > days.  
> > 
> > That's unfortunately not mergeable, and unless you use a library
> > for
> > your GIF plugin in abydos, would just be shifting the potential
> > bugs
> > to the abydos code base.
> 
> I do use a library (or two). I've written one plugin that uses giflib
> and one that uses ImageMagick. I assumed using giflib would be a
> straighter path, but it wasn't. Firstly it only supports reading
> images
> from disk (but abydos automatically creates temporary files then
> needed
> so that didn't add any extra code at least). Secondly it doesn't do
> much more than unpacking the pixels. How to interpret what comes out
> is
> left as an exercise for the user, and requires a bit of knowledge
> about
> the GIF formats and it's quirks. So that plugin isn't built by
> default.
> ImageMagick on the other hand did much more to be of help, and
> required
> far less code to use. So shifting the responsibility to ImageMagick
> seems reasonable, I think.

No, it really isn't:
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html

We want to have less CVEs, not more.

> I tested them both on all the GIF images included in the gdk-pixbuf
> test suit. Both plugins mostly work, but to varying degree. The one
> based on giflib segfaults with 1_partyanimsm2.gif (because the
> allocation containing the pixels which giflib provides is less than
> the
> images width x height, I haven't yet looked deeper into it). The
> ImageMagick based plugin on the other doesn't crash at least, and all
> the invalid images are correctly classified as invalid. The image
> 1_partyanimsm2.gif still shows as garbage except the first frame. The
> image aero.gif has the frame delay set to zero for every frame but
> the
> first. I'm not sure how that should be interpreted, so I simply
> exchanged zero values for a small delay (0.02 seconds). I will read
> up
> on the GIF format and hopefully get things working better.
> 
> It's available here if you want to try it out:
> http://snisurset.net/code/abydos/

Having looked at giflib, and knowing the author, the current plan still
is to have something based on libnsgif in the future.

> > > > - we disable every loader by default except the ones that the
> > > > core
> > > > desktop needs
> > > > - image viewers that rely on gdk-pixbuf ship their additional
> > > > loaders
> > > > in the app's Flatpak[1].  
> > > 
> > > I don't care much for Flatpak in particular. But generalised and
> > > rephrased as, leave it to the distributors to decide, I agree
> > > that
> > > this is absolutely the best approach.  
> > 
> > Without Flatpak, you're just removing image format support from
> > image
> > viewers, as many packaging guidelines in distributions forbid the
> > bundling of libraries. They'd want to ship a single copy of the
> > gdk-
> > pixbuf loaders, and the applications wouldn't have any protection
> > from
> > files that the loaders would trip over.
> 
> I'm not arguing against that. I just think it's an issue best left
> entirely to distributors (including the choice between bundling and
> dependencies).
> 
> How and where to implement sandboxing is an interesting question
> still.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: An alternative to gdk-pixbuf

[Bastien Nocera]

On Sun, 2018-09-09 at 01:23 +0200, Magnus Bergman wrote:
> On Fri, 07 Sep 2018 12:51:32 +0200
> Bastien Nocera  wrote:
> 
> > > > Gegl is great for image editing. But not as much for simple
> > > > viewing.  
> > > 
> > > This is debatable. If I'm viewing a 4000x4000 RGB image on a
> > > hidpi
> > > display I'm already pushing gdk-pixbuf and cairo to their limits
> > > because of the scaling factor applied to the window — not only
> > > the
> > > buffer gets loaded uncompressed to allow for zooming, but the
> > > image
> > > viewer needs to render a CPU-scaled down copy of the image.
> > > 
> > > Sure, for viewing a 500x400px image macro for a meme we're fine;
> > > but
> > > we're fine with gdk-pixbuf as well, so there's really no need to
> > > change to a different image loading library.  
> > 
> > I concur, 4000x4000 would likely OOM your machine, and it's not
> > really
> > fixable:
> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30
> > 
> > Viewers should use GEGL, and GEGL should be taught about more
> > formats.
> > That still leaves many GIF files unhandled though, and I'm not sure
> > we'd want apps writing their own GIF loader, seeing how complicated
> > that is.
> 
> How do you mean it's not fixable? Of course it's not fixable that
> processing larger amounts of data will require more processing power.
> So I think it's kind of obvious that creating thumbnails for many
> large
> images will take it's time. But that shouldn't need be too much of a
> problem. Without looking too deeply into it, it looks like a problem
> with nautilus to me. Obviously it's a bad idea to to run the
> thumbnailers synchronously (which I can't imagine Nautilus does), and
> it's also bad to run too many memory hungry tasks in parallel. But
> that must be fixable, right? Like limiting the the total size in
> bytes
> of files being allowed to be processed in parallel, for example.

It's not fixable without breaking the API and ABI of gdk-pixbuf. And
nautilus doesn't thumbnail images itself (there's a thumbnailer that
gets sandboxed by the thumbnailing code), or do it synchronously (the
thumbnailers are out-of-process).


> > >  The animation API is pretty much a garbage fire, so it may go on
> > > the chopping block as well. Of course, deprecated API will keep
> > > working as well—or as badly—as it works today, so people can
> > > still
> > > use it. Moving pixbuf loaders to separate processes, and wrap
> > > them
> > > in sandboxes, would be a fairly good thing to do; it need to be
> > > decided at run time, though, because there are many users of
> > > GdkPixbuf that already run in a sandbox, which prevents creating
> > > smaller sandboxes inside it.  
> > 
> > That'd be best left to an API that can do that natively, with the
> > API
> > being thought out ahead of time.
> > 
> > In the short term, my wishlist/TODO list would be:
> > - somebody writes a GIF loader that is readable, and passes the
> > test
> > suite.
> 
> I've written loader for GIF that simply wraps abydos. In lines of
> code it's about a quarter the size of the current loader, even
> including
> the GIF plugin for abydos. It might even be slightly smaller with the
> whole of abydos included in the equation. On the downside it probably
> doesn't pass the test suite since I haven't tried it. But I will, and
> hopefully publish the whole thing in a couple of days.

That's unfortunately not mergeable, and unless you use a library for
your GIF plugin in abydos, would just be shifting the potential bugs to
the abydos code base.

> > - we disable every loader by default except the ones that the core
> > desktop needs
> > - image viewers that rely on gdk-pixbuf ship their additional
> > loaders
> > in the app's Flatpak[1].
> 
> I don't care much for Flatpak in particular. But generalised and
> rephrased as, leave it to the distributors to decide, I agree that
> this is absolutely the best approach.

Without Flatpak, you're just removing image format support from image
viewers, as many packaging guidelines in distributions forbid the
bundling of libraries. They'd want to ship a single copy of the gdk-
pixbuf loaders, and the applications wouldn't have any protection from
files that the loaders would trip over.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: An alternative to gdk-pixbuf

[Bastien Nocera]

On Thu, 2018-09-06 at 11:39 +0100, Emmanuele Bassi via gtk-devel-list
wrote:
> On Wed, 5 Sep 2018 at 19:25, Magnus Bergman <
> magnus.berg...@snisurset.net> wrote:
> > On Wed, 5 Sep 2018 17:28:22 +0100
> > Emmanuele Bassi  wrote:
> > 
> > > We're phasing out Cairo in favour of the CSS rendering model,
> > > implemented on top of OpenGL and Vulkan, as it's the API that
> > most
> > > closely matches the requirements of GTK.
> > 
> > I'm not sure I quite understand what you are saying. What does this
> > mean for image loading if terms of actual implementation? What
> > would
> > ideally happen then GTK+ needs to load an image (because the
> > application called gtk_image_new_from_file() for example)?
> > 
> 
> We're still using GdkPixbuf, and for the 4.0 API series we still have
> GdkPixbuf types exposed in the GTK API.
> 
> For future API series (5.x, 6.x, …) we may revisit this, with the
> option of moving icon loading into GTK itself.

This uncertainty is the reason why I didn't work on moving the
thumbnailing code somewhere else, as it's bound to be made irrelevant
sooner rather than later.


> > Gegl is great for image editing. But not as much for simple
> > viewing.
> 
> This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi
> display I'm already pushing gdk-pixbuf and cairo to their limits
> because of the scaling factor applied to the window — not only the
> buffer gets loaded uncompressed to allow for zooming, but the image
> viewer needs to render a CPU-scaled down copy of the image.
> 
> Sure, for viewing a 500x400px image macro for a meme we're fine; but
> we're fine with gdk-pixbuf as well, so there's really no need to
> change to a different image loading library.

I concur, 4000x4000 would likely OOM your machine, and it's not really
fixable:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30

Viewers should use GEGL, and GEGL should be taught about more formats.
That still leaves many GIF files unhandled though, and I'm not sure
we'd want apps writing their own GIF loader, seeing how complicated
that is.


> In the near future, I'll very likely deprecate most of
> > GdkPixbuf's
> > > API, except for the I/O operations; I'd also be happy to seal off
> > > most of its internals, within the ABI stability promise, to avoid
> > > leakage of internal state.
> > 
> > Will the loader plugin API go away, you think?
> 
> No API will ever go away: there are no plans for a gdk-pixbuf-3.0.
> The deprecations would mostly apply to API that is either long since
> been replaced by Cairo (scale/composite), or that is weirdly ad hoc,
> like saturate_and_pixelate(). Ideally, I'd like to deprecate the
> option to build gdk-pixbuf without depending on GIO to do MIME type
> sniffing, as GIO has been fixed to work on Windows and macOS, and it
> is a required dependency anyway.

That's probably fine, though the current code in the stack is dumb as
rocks, and will try to thumbnail a JPG file with the PNG decoder if the
suffix is incorrect. The error message is also obnoxious, so that'll
need fixing before removing the content type sniffing.

>  The animation API is pretty much a garbage fire, so it may go on the
> chopping block as well. Of course, deprecated API will keep working
> as well—or as badly—as it works today, so people can still use it.
> Moving pixbuf loaders to separate processes, and wrap them in
> sandboxes, would be a fairly good thing to do; it need to be decided
> at run time, though, because there are many users of GdkPixbuf that
> already run in a sandbox, which prevents creating smaller sandboxes
> inside it.

That'd be best left to an API that can do that natively, with the API
being thought out ahead of time.

In the short term, my wishlist/TODO list would be:
- somebody writes a GIF loader that is readable, and passes the test
suite.
- we disable every loader by default except the ones that the core
desktop needs
- image viewers that rely on gdk-pixbuf ship their additional loaders
in the app's Flatpak[1].

That would already reduce the attack surface for gdk-pixbuf.

On a sidenote, I also use gdk-pixbuf as a pixel-perfect drawing API for
thumbnailers:
https://gitlab.gnome.org/Archive/gnome-nds-thumbnailer/blob/master/gnome-nds-thumbnailer.c#L72

[1]: I recently did this to add webp comics support to the evince
Flatpak:
https://gitlab.gnome.org/GNOME/evince/merge_requests/50

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with git.gnome.org

[Bastien Nocera]

On Thu, 2018-09-06 at 14:09 +0100, John Emmas wrote:
> Hi guys - sorry for posting this here but I've tried gnome's 
> 'gitlab-issues' mailing list and couldn't get any response.  Maybe 
> someone here can help..?
> 
> For the past few weeks I've been seeing errors if I try to update
> (i.e. 
> pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc). 
> Here's what I see...
> 
>  Looking up git.gnome.org ... done.

It's gitlab.gnome.org, not git.gnome.org anymore.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Using "user.mime_type" xattr for MIME guessing

[Bastien Nocera]

On Thu, 2018-08-09 at 13:09 -0400, Colin Atkinson wrote:
> On Thu, Aug 9, 2018 at 10:47 AM Bastien Nocera 
> wrote:
> > On Thu, 2018-08-09 at 10:35 -0400, Colin Atkinson via gtk-devel-
> > list
> > wrote:
> > > Hi everyone,
> > > I'm working on a FUSE file system which makes network requests
> > > whenever a file is read. So obviously, I would like to avoid
> > excess
> > > read requests to files.
> > > 
> > > The current implementation [0] of gio's MIME guessing seems to
> > check
> > > the file extension, and then immediately fall back on reading
> > magic
> > > bytes when this is not possible (i.e. files with an ambiguous or
> > no
> > > extension). In my situation, this can potentially lead to many
> > > network requests any time a user opens a directory in Nautilus or
> > a
> > > file selection dialog.
> > > 
> > > According to the FreeDesktop specs [1], implementations may query
> > the
> > > user.mime_type xattr for a given file's MIME. But the current
> > version
> > > of glib seems not to make use of this.
> > > 
> > > Would there be any interest in a patch to add this functionality?
> > If
> > > so, I would be happy to work on it.
> > > 
> > > Please let me know if there's anything I've missed/misunderstood.
> > 
> > It's probably something interesting to add to GIO, though checking
> > xattrs also has a cost, especially on local disks.
> > 
> > Depending on what your FUSE is, you might want to consider writing
> > a
> > gvfs backend instead, where the backend is responsible for
> > providing
> > the mime-type/content-type (and all the other metadata), so you can
> > use
> > whichever method is the most useful to you, with no added costs
> > because
> > the metadata and the enumeration can be done in one go.
> > 
> > Cheers
> 
> While there is an overhead for getting the value of an xattr, it also
> potentially prevents the expense of doing glob lookups

A glob look is essentially free. There's an mmapped cache with those,
and it takes microseconds to do a lookup.

>  and magic guessing. It was added partially to help avoid those very
> operations, as they were deemed expensive.

magic guessing is only going to be expensive because it needs to do
I/O. So would looking up the xattr.

> I'm hesitant to commit to writing a full gvfs backend. Correct me if
> I'm wrong, but from reading through some of the backends in the gvfs
> repo, it seems like writing one would require essentially duplicating
> all of that effort.

Well, yes and no. We've not seen your code, we just know that it's for
a network filesystem. A gvfs backend will integrate better with GNOME
in general, but most of the code should be trivial if you're using a
library to hide all the intricacies of the underlying protocol.

As for the benefits of writing a gvfs backend, there's an "afc" (Apple
File Conduit, for iOS devices) FUSE backend, but we also wrote a gvfs
backend. The gvfs backend integrates with a separate backend that
watches for plugged in devices, and uses that to mount the filesystems.
There's integration with GNOME because it knows how to tell you about
unlocking your device, it can set thumbnails or icons, and mime-types
on files without doing extra I/O.

Using a file manager that speaks gvfs on top of a gvfs backend is just
going to be more efficient. A FUSE backend is nice when you're
prototyping, and want people to test out the code, and kick the tires.
It's just not a long-term solution for a lot of use cases. (Though it's
plenty fine if the filesystem is a local one, and the format matches
POSIX expectations, such as local filesystems that are unsupported by
the kernel, you'd then teach udisks how to mount them and integration
would be good enough).

>  And then duplicating it again for KDE. All while maintaining support
> for the FUSE system so that it is usable on Windows/OS X.

Depends what your target is. I doubt that Windows will read xattrs, but
then again, I don't know anything about FUSE under Windows.

> This also isn't an isolated situation. There are tons of situations
> where excess reads should be avoided (e.g. slow disk with lots of
> files in a directory),

Again, xattr reads are not free. And there might not even be a
user.mime_type xattr in there!

>  or where a FUSE or application has explicitly set the MIME (e.g.
> curl setting user.mime_type based on the Content-Type header).
> 
> I may try to whip up a minimal proof-of-concept patch sometime in the
> next week (unless there's strong opposition to it). From there, it
> should be feasible to see how checking user.mime_type affects
> performance.

Alex Larsson looked into that, and reading xattrs when most of them
didn't have the user.mime_type xattr will just waste I/O. It might need
to be a special case for specific FUSE filesystems to avoid every
directory read being slower.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Using "user.mime_type" xattr for MIME guessing

[Bastien Nocera]

On Thu, 2018-08-09 at 10:35 -0400, Colin Atkinson via gtk-devel-list
wrote:
> Hi everyone,
> I'm working on a FUSE file system which makes network requests
> whenever a file is read. So obviously, I would like to avoid excess
> read requests to files.
> 
> The current implementation [0] of gio's MIME guessing seems to check
> the file extension, and then immediately fall back on reading magic
> bytes when this is not possible (i.e. files with an ambiguous or no
> extension). In my situation, this can potentially lead to many
> network requests any time a user opens a directory in Nautilus or a
> file selection dialog.
> 
> According to the FreeDesktop specs [1], implementations may query the
> user.mime_type xattr for a given file's MIME. But the current version
> of glib seems not to make use of this.
> 
> Would there be any interest in a patch to add this functionality? If
> so, I would be happy to work on it.
> 
> Please let me know if there's anything I've missed/misunderstood.

It's probably something interesting to add to GIO, though checking
xattrs also has a cost, especially on local disks.

Depending on what your FUSE is, you might want to consider writing a
gvfs backend instead, where the backend is responsible for providing
the mime-type/content-type (and all the other metadata), so you can use
whichever method is the most useful to you, with no added costs because
the metadata and the enumeration can be done in one go.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [g-a-devel] No module anymore & perfect zoom feature

[Bastien Nocera]

On Mon, 2018-03-05 at 15:05 +0100, Samuel Thibault wrote:
> Hello,
> 
> Emmanuele Bassi, on jeu. 01 mars 2018 20:27:04 +, wrote:
> > I was not claiming that the Shell’s zoom is perfect; I’m saying
> > that the Shell
> > is where things need to be fixed, as it’s where things are
> > implemented already.
> 
> Well, that is for gnome.  Users shouldn't be tied with gnome just to
> get
> good zoom of gtk applications, and we want good zoom of other widget
> libraries too, so we need a window magnification interface which is
> independent from gnome.

If you implement the feature in GTK+ and gnome-shell in a way that
makes either of those replaceable, you can then add support for non-
GTK+ apps, or non-gnome-shell compositors.

I don't see how you could implement it without the compositor knowing
about the feature. The compositor already knows how to modify what
appears on the screen, can modify on-screen data quickly (for all the
brightness, contrast, etc. changes), and using the GPU knows how to
scale.

> > The shell does not currently ask the toolkit to render an area at a
> > different
> > scaling factor, but it could. The shell can also change the
> > rendering pipeline
> > to apply an effect like color inversion.
> 
> But that means it'll only benefit the gnome shell, and not other
> desktops.  Writing a *good* magnifier, which means not only just the
> graphical effect, but also mouse tracking, focus tracking, smooth
> transition, etc. is not something that we want to see having to be
> implemented several times for several desktops, there are not enough
> people who have the skills, context, and time to do that.

Perhaps, but you'd be doing a disservice to your users trying to
implement this as a "can run anywhere" solution. I don't think there's
any way you can implement this generically so that there's no work
needed on other desktops.

Implementing this in GTK+ and gnome-shell gives you the opportunity to
experiment with an interface that should hopefully be applicable to
other compositors, and compositing window managers.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Bastien Nocera]

On Sat, 2018-02-10 at 16:43 +0100, Salvatore De Paolis wrote:
> On Thu, 08 Feb 2018 02:00:16 +
> Sriram Ramkrishna  wrote:
> 
> > Every contributor who takes an actionable step and reports a bug is
> > a
> > potential future core contributor.  Please remember that.  A person
> > who
> > attempts to fix a bug with a patch is even more valuable.
> 
> It's a waste of time, I just received today a bug I reported from
> 2010. Sadly
> I prefer to move to some other project which cares of application
> developers. 
> Maybe one day GTK+ will be fine, maybe not.

For those playing at home, it's this one:
https://bugzilla.gnome.org/show_bug.cgi?id=584402

Maybe re-testing and reopening the bug if it still applies would be
useful. I'm not going to blame you for giving up, but patches inside
the comments, and no clear test case for the bug means it's very very
time-consuming to reproduce let alone fix.

This problem is going to apply to more projects than just GTK+,
especially those with nearly 2000 bugs opened against them.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Tue, 2018-01-30 at 14:45 +, Debarshi Ray wrote:
> On Tue, Jan 30, 2018 at 02:06:01PM +0100, Bastien Nocera wrote:
> > On Tue, 2018-01-30 at 11:06 +, Debarshi Ray wrote:
> > > Also, it's not primarily about the location of the cache but the
> > > thumbnailer. To me, the real value in using the generic
> > > thumbnailers
> > > is not having to worry about all kinds of weird MIME type
> > > problems,
> > > sketchy files, and the various problems that arise from those
> > > things.
> > 
> > What files are you interested in thumbnailing that your application
> > doesn't support?
> 
> It's not about thumbnailing MIME types that the application doesn't
> support, no.  Sorry, I could have been clearer.
> 
> It's about dealing with sandboxing the thumbnailer, dealing with
> CVEs,
> crashes and broken output arising out of weird files, etc..  Some of
> these are potentially fixable at the codec level, which is why I
> mentioned that standardizing around a smaller set of codec
> implementations will also be a win, even if the thumbnailing layer on
> top is different.
> 
> (An example of a weird file would be a panorama generated by a
> Samsung
> Galaxy: https://forums.adobe.com/thread/2131432)

OK. This would however just protect you until the point you open the
image in question, unless you consider the thumbnailer's response to be
authoritative. Much like the existing sandboxing of thumbnailers won't
protect eog or evince itself, just the associated thumbnailers.

But we could make some internal changes to that API to allow you to
pass associated metadata, maybe, so you could do something like:
- tell the thumbnail API to only consider this private thumbnailer you
have, and no other
- find a way to pass 2 files, or maybe one file and a serialised
string/metadata to the thumbnailer which would do its job.

There's currently no way to do the 2nd part, but I'll try to see
whether we can make the API extensible at least, so writing something
like that is possible.

> > > One could imagine asking the generic thumbnailer to thumbnail the
> > > original file, and then have the application run the edits on top
> > > of
> > > it. However, that won't work if the image was cropped because
> > > you'd
> > > have to crop the original thumbnail and then proceed, which will
> > > affect the resolution of the final thumbnail. If I am not
> > > mistaken, I
> > > coded Photos' thumbnailer to load the image at a lower resolution
> > > if
> > > it wasn't cropped, else it loads at full scale and downscales
> > > later.
> > 
> > At this point, you could very well apply the edits and thumbnail
> > internally, as the app would know which one of the photos have
> > edits
> > attached to them.
> 
> Umm... I didn't understand whether you meant that as an alternative
> or
> as something to complement the existing setup.
> 
> I'd like to do what you mentioned above to complement the existing
> setup.  Say you started with an empty cache or you added a new online
> account or whatever, and now you have a large number of items queued
> up for thumbnailing.  Meanwhile, if you open an unthumbnailed item at
> full resolution, then it should be possible to jump the queue and
> create a thumbnail from the hi-res.  It's just nice to do that for so
> many reasons.  Also, if you have a provider that doesn't offer
> server-generated thumbnails, then this can serve as a workaround.
> 
> This is regardless of which thumbnailing API is being used.  For
> example, you can do this for Documents too, which uses the generic
> stuff; and for viewers/players and Files.  Although, it would be
> hindered by every Flatpak having its own thumbnail cache.  Do/will
> they have a shared cache?  Or not?

In Flatpak, no, it's expected that each app has its own cache.

> (One thing that I didn't mention so far is that Photos also has
> online
> thumbnailers.  They grab server-side generated thumbnails for online
> content which sometimes requires credentials for the GOA account.
> Currently these are in-process and are a glorified g_file_copy over
> HTTP.)

The thumbnailing processes are sandboxed with no network access right
now. I don't think that's something we want to change, but it just
makes it a 2-step process.


> > > > > Last but not the least, I find it important to version the
> > > > > cache
> > > > > to tide over bugs in the thumbnailer.
> > > > 
> > > > You don't need the whole cache to be versioned. Thumbnailers
> > > > can
> > > > add metadata to the thumbnails if they want, and doing:
> > > > gdk_

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Tue, 2018-01-30 at 11:06 +, Debarshi Ray wrote:
> Hey,
> 
> On Tue, Jan 30, 2018 at 10:46:30AM +0100, Bastien Nocera wrote:
> > On Mon, 2018-01-29 at 15:42 +, Debarshi Ray wrote:
> > > However, the edits are application-specific [2], so it is not
> > > reasonable to expect the generic OS-wide thumbnailers to be able
> > > to
> > > handle them.
> > 
> > This is solved/worked-around when using Flatpak, as the cache is
> > private to the app.
> 
> Yes, that's right. Although, the non-Flatpak case would probably
> linger on for a while?
> 
> Also, it's not primarily about the location of the cache but the
> thumbnailer. To me, the real value in using the generic thumbnailers
> is not having to worry about all kinds of weird MIME type problems,
> sketchy files, and the various problems that arise from those things.

What files are you interested in thumbnailing that your application
doesn't support?

> One could imagine asking the generic thumbnailer to thumbnail the
> original file, and then have the application run the edits on top of
> it. However, that won't work if the image was cropped because you'd
> have to crop the original thumbnail and then proceed, which will
> affect the resolution of the final thumbnail. If I am not mistaken, I
> coded Photos' thumbnailer to load the image at a lower resolution if
> it wasn't cropped, else it loads at full scale and downscales later.

At this point, you could very well apply the edits and thumbnail
internally, as the app would know which one of the photos have edits
attached to them.

> I edited this bit from the blog because it was already getting too
> long. :)
> 
> > > Secondly, it is important to be able to create and lookup
> > > thumbnails
> > > of a specific size, as opposed to enumerated constants with pre-
> > > determined presets.
> > 
> > This is a problem with the thumbnail spec's storage section. Jon
> > added
> > a larger version quite some time ago, and somebody would need to go
> > through the process to make it any bigger.
> 
> I see, ok. By larger version, you mean one for 512x512 icons?
> 
> I haven't had the occasion to see what a N > 2 display looks like.  I
> can imagine that upscaling 512x512 raw pixels to cover 256x256
> logical
> pixels might be passable. It'd still be better than LoPPI, but not
> better than N=2 HiPPI. I don't know.

Seems to be 256x256:
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#THUMBSIZE

Unfortunately, we (GTK+/GNOME) don't control the thumbnail spec. As
mentioned, any additions would need to go through discussions on xdg-
list.

> > > Last but not the least, I find it important to version the cache
> > > to
> > > tide over bugs in the thumbnailer.
> > 
> > You don't need the whole cache to be versioned. Thumbnailers can
> > add
> > metadata to the thumbnails if they want, and doing:
> > gdk_pixbuf_save(pixbuf, "/path/to/thumbnail", "png", ,
> > "tEXt::Thumb::Software::Version", "1.0", NULL);
> > is do-able from within the thumbnailer, and that extra metadata
> > would
> > be kept.
> 
> Yes, that's right. It will be good if the generic thumbnailers would
> version their output like that. Maybe it should be added to the
> standard?

I'll add a "FORCE" flag to the API. As you'd control both the
thumbnailer and how it's called, you could do thumbnail the file, and
if the version in the GdkPixbuf is too old, re-run the thumbnailing
with the "FORCE" flag to force the thumbnail to be re-created.

> However, if all you have is one thumbnailer, then it's just
> convenient
> to version the entire cache and do a "rm -rf" when the version is
> bumped. :)

And is utterly wasteful if you have a shared thumbnail cache, as your
thumbnailer isn't the only one around.

> Also, it can be useful to version the whole cache, if for whatever
> reason, you decide to change its layout. I have been wondering if it
> would be good to add sub-directories for various sources. It could be
> for individual GOA accounts or at the provider level (eg., Flickr).
> It's not essential, but might make it easier or more flexible to
> remove the thumbnails for a disabled account. For the generic case,
> suppose the standard decides to use the actual sizes (ie., 128x128,
> 256x256) as folder sizes instead of "normal" and "large", because,
> you
> know, words like "new" and "large" are kind of risky.  What's beyond
> "new" or "large"? "Shiny" and "huge"? :)
> 
> Anyway, I did it mostly for the

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-29 at 15:42 +, Debarshi Ray wrote:
> On Mon, Jan 22, 2018 at 12:46:51PM +, Emmanuele Bassi wrote:
> > On 22 January 2018 at 09:28, Philip Withnall  > k> wrote:
> > > From the GLib side of things, my thoughts are that this
> > > shouldn???t live
> > > in GLib, since it deals with pixbufs. As long as it integrates
> > > with
> > > GIO???s thumbnail attribute support, GLib will be happy.
> > 
> > We could add a GThumbnail interface, like we did for GIcon,
> > GThemeIcon, and friends.
> 
> In the past, I had discussed making the thumbnailing APIs in GLib
> more
> complete with Allison. See:
>   https://bugzilla.gnome.org/show_bug.cgi?id=686895#c20

I extracted 3 comments which could be relevant to the discussion:

> However, the edits are application-specific [2], so it is not
> reasonable to expect the generic OS-wide thumbnailers to be able to
> handle them.

This is solved/worked-around when using Flatpak, as the cache is
private to the app.

> Secondly, it is important to be able to create and lookup thumbnails
> of a specific size, as opposed to enumerated constants with pre-
> determined presets.

This is a problem with the thumbnail spec's storage section. Jon added
a larger version quite some time ago, and somebody would need to go
through the process to make it any bigger.

> Last but not the least, I find it important to version the cache to
> tide over bugs in the thumbnailer.

You don't need the whole cache to be versioned. Thumbnailers can add
metadata to the thumbnails if they want, and doing:
gdk_pixbuf_save(pixbuf, "/path/to/thumbnail", "png", ,
"tEXt::Thumb::Software::Version", "1.0", NULL);
is do-able from within the thumbnailer, and that extra metadata would
be kept.

So there's definitely not much a thumbnailing API could do that you'd
need. The thumbnailing API takes files, and wouldn't make taking 2
sources (file + serialised image operations) possible. You want a
private cache because the on-disk file itself doesn't change. You want
bigger thumbnails, and the spec we implement doesn't allow that.

Thanks for the write-up. Let me know whether I missed anything.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-22 at 15:22 +0100, Carlos Garnacho wrote:
> Hey,
> 
> On Wed, Jan 17, 2018 at 6:15 PM, Bastien Nocera <had...@hadess.net>
> wrote:
> > On Wed, 2018-01-17 at 13:15 +0100, Bastien Nocera wrote:
> > > Hey,
> > > 
> > > I wanted to start a discussion about replacing
> > > GnomeDesktopThumbnail
> > > with an API that would live in the GLib/GTK+ stack.
> > 
> > 
> > > 
> > > To sum up, here are the questions:
> > > - Do we want the API in GTK+ and depending on gdk-pixbuf, even if
> > > it's
> > > only really meant to be used on "freedesktop" platforms?
> > > - Are there specific API entry points that people need besides
> > > the
> > > current API (including [1]) with async support?
> > 
> > This is the API that I came up with, which could live in either
> > gdk-
> > pixbuf, or GTK+, dependency-wise. It might also be small enough to
> > copy/paste although I count 15 users of just the C API in Debian
> > Codesearch[1], so it might be worth having in a shared library
> > anyway.
> > 
> > typedef enum {
> > GNOME_DESKTOP_THUMBNAIL_FLAGS_NONE = 0,
> > GNOME_DESKTOP_THUMBNAIL_FLAGS_SAVE,  // Whether to save the
> > created (successful or failed) thumbnail to the cache
> > } GnomeDesktopThumbnailFlag;
> > 
> > #define GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES \
> > G_FILE_ATTRIBUTE_THUMBNAIL_PATH "," \
> > G_FILE_ATTRIBUTE_THUMBNAILING_FAILED ","\
> > G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID "," \
> > G_FILE_ATTRIBUTE_PREVIEW_ICON ","   \
> > G_FILE_ATTRIBUTE_TIME_MODIFIED ","  \
> > G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE
> > 
> > // About @info:
> > // NULL means we'll look it up if necessary, otherwise must include
> > // GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES,
> > // G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE will however be used
> > rather
> > // than G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE if present
> > 
> > GdkPixbuf *
> > gnome_desktop_thumbnail_generate_thumbnail_sync
> > (GnomeDesktopThumbnailFactory  *factory,
> >  GFile 
> > *file,   // instead of a URI?
> >  GFileInfo 
> > *info,
> >  GnomeDesktopThumbn
> > ailFlags flag,
> >  char  
> >**ret_thumbnail_path,
> >  GError
> >**error);
> 
> Maybe having both operations split (#1 generating the thumbnail, #2
> loading it as a GdkPixbuf) might help see the layer to which each
> more
> clearly belongs?

I don't think it's really helpful. If you chose not to save the
thumbnail for example (maybe for privacy reasons?), you'd end up with
nothing. This also makes it more difficult to use the macOS APIs, which
just give back an image, and doesn't have any easily accessible caches.

macOS:
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/Articles/QLDrawGraphContext.html#//apple_ref/doc/uid/TP40005020-CH8-SW4

The Windows API requires to save the thumbnail in the cache, if you
want to lookup whether a thumbnail already exists in the cache.

Windows:
https://stackoverflow.com/questions/19523599/how-to-get-thumbnail-of-file-using-the-windows-api

Both the Windows and macOS APIs also seem to use their own image
formats. Will we want to convert those to GdkPixbuf? Or pass them back
as NativeImage opaque pointers for each platform?

>  GdkPixbuf generation from a GFile(Info) might easily
> be gdk-pixbuf or gtk+ helpers, thumbnail generation requests might be
> into a separate library, or behind a GIO interface.
> 
> Cheers,
>   Carlos
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-22 at 12:46 +, Emmanuele Bassi wrote:
> On 22 January 2018 at 09:28, Philip Withnall <phi...@tecnocode.co.uk>
> wrote:
> > On Wed, 2018-01-17 at 18:15 +0100, Bastien Nocera wrote:
> > > On Wed, 2018-01-17 at 13:15 +0100, Bastien Nocera wrote:
> > > > Hey,
> > > > 
> > > > I wanted to start a discussion about replacing
> > > > GnomeDesktopThumbnail
> > > > with an API that would live in the GLib/GTK+ stack.
> > > 
> > > 
> > 
> > From the GLib side of things, my thoughts are that this shouldn’t
> > live
> > in GLib, since it deals with pixbufs. As long as it integrates with
> > GIO’s thumbnail attribute support, GLib will be happy.
> 
> We could add a GThumbnail interface, like we did for GIcon,
> GThemeIcon, and friends.

We could return a GIcon/GdkPixbuf. But that doesn't stop it from having
to live in a layer above GIO, where GdkPixbuf is available to the
implementation.

I guess I'll have to dive in and check out the Windows and macOS
thumbnailing APIs.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

Hey Philip,

On Mon, 2018-01-22 at 09:28 +, Philip Withnall wrote:
> On Wed, 2018-01-17 at 18:15 +0100, Bastien Nocera wrote:
> > On Wed, 2018-01-17 at 13:15 +0100, Bastien Nocera wrote:
> > > Hey,
> > > 
> > > I wanted to start a discussion about replacing
> > > GnomeDesktopThumbnail
> > > with an API that would live in the GLib/GTK+ stack.
> > 
> > 
> 
> From the GLib side of things, my thoughts are that this shouldn’t
> live
> in GLib, since it deals with pixbufs. As long as it integrates with
> GIO’s thumbnail attribute support, GLib will be happy.

OK. Now the question is whether gdk-pixbuf or GTK+ would be the best
place for it.

> What about https://wiki.gnome.org/DraftSpecs/ThumbnailerSpec? I don’t
> know if the API is entirely relevant (or whether explicitly exposing
> the cache over D-Bus makes sense), but there may be some useful ideas
> there even if the API as a whole is not a good fit.

It's an implementation, rather than an API. As an API, it fails to
bring anything more to the table, apart from conflict resolution when
two thumbnailers offer to thumbnail the same mime-type. Nothing that
interesting as to make the API any more complicated.

> What did you have to say about making things free-Unix-specific (or
> more Linux specific)?

Well, I just didn't know which other API I should base the
implementation on. Should this also work on Windows or macOS, or at
least be prepared to? What APIs do they use, and are they similar
enough that this proposed API would work for them?


> Seems reasonable, though I assume people will typically use the
> *_async() version?

Right, it's easier to just show the sync version, and readers can infer
the (more versbose) async API.

>  The *_sync() version should still have a
> GCancellable argument.

Yes, I forgot that.

>  I agree with using a GFile rather than a raw
> URI.

OK.

>  If this is done as a shared library then you can implement it
> using bwrap or D-Bus as you see fit, and change the implementation
> later on without problems.

Indeed, I'll ask people in the know how they think this would play out.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GnomeDesktopThumbnail API replacement

[Bastien Nocera]

Hey,

I wanted to start a discussion about replacing GnomeDesktopThumbnail
with an API that would live in the GLib/GTK+ stack.

Why
---

We want to replace/move the current API because it lives in gnome-
desktop, which is a collection of helpers used by the core desktop, and
highly dependent on the environment in which it runs, which makes it
highly unsuitable for sandboxed applications, and given that has no API
guarantees, makes it unsuitable for applications to use.

It's currently not packaged inside the Freedesktop or GNOME runtimes
for Flatpak, and applications that need the thumbnailing API usually
build gnome-desktop with udev/hwdb support disabled.

The API
---

This is the current API:
https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail.h

It requires GIO, which is fine, but also GdkPixbuf for its API. This
means that it would likely be a better for GTK+, but I also know that
we're trying to ween ourselves off of GdkPixbuf in GTK+.

I would also like the API to be free Unices specific, with an obvious
slant towards running on Linux (I'll get into that a bit later).

The obvious shortcomings of the API are:
- No builtin async support, so applications usually run the
thumbnailers inside threads, each using their own code for that,
meaning that some apps end up having GnomeDesktopThumbnailer I/O inside
the main thread because what API is blocking isn't clear. This should
also allow cancellation
- The function names are unclear, meaning that we end up with calls
like gnome_desktop_thumbnail_factory_give_me_a_thumbnail() in patches.
Maybe a single I/O bound entry point with flags is do-able.

Implementation
--

Finally, we have the internal implementation to look into. I plan on
reusing the same ".thumbnailer" files to declare thumbnailers, as those
are used in a number of GNOME forks. The question here is more whether
we want to change the current internal implementation.

When asked to thumbnail a file, we look at whether the file is already
thumbnailed, and load it up if so, then check whether the filesystem
itself provides a preview icon, via GIO, and if not, look for a
thumbnailer which supports that file type.

Once we have the thumbnailer to use, we launch it either directly, or
inside bwrap on Linux systems to avoid both security and privacy
problems occurring through specially-crafted files.

But this is pretty slow (is this a real problem?), so I'm wondering
whether we could instead use a sandboxed/locked down longer-running
helper through D-Bus/systemd (turning off the network, disable reads or
writes in specific locations, etc.). This would run multiple
thumbnailers in parallel or in a series, which could have security
impact, though a much lower one than without any sandboxing, obviously.

The questions
-

To sum up, here are the questions:
- Do we want the API in GTK+ and depending on gdk-pixbuf, even if it's
only really meant to be used on "freedesktop" platforms?
- Are there specific API entry points that people need besides the
current API (including [1]) with async support?
- Do we want to have a first implementation using bwrap (and directly
spawning thumbnailers on non-Linux platforms) and experiment with a
longer-running daemon, or should we implement this first in gnome-
desktop and then carry it over?

Cheers

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=684026
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Bastien Nocera]

On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
> 

> With "soft API breaks" (i.e. just removing an API that was deprecated
> in
> a previous major version), I think this would improve a lot the
> situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

It already exists. Look at the "DISABLE_DEPRECATED" macros in the
current version of libraries, and which usually get removed in the +1
version.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GApplication process uniqueness, saving config files and multi-seat support

[Bastien Nocera]

On Sun, 2017-09-10 at 13:27 +0200, Sébastien Wilmet wrote:
> Hi,
> 
> With GApplication process uniqueness, an application has a unique
> process per user *session*. But with multi-seat support, it is
> possible
> AFAIK to open several graphical sessions for the same user.
> 
> Some GTK+ apps save some config/data in e.g. XML files for stuff that
> don't fit well in GSettings, saved typically in ~/.config/ or
> ~/.local/share/.
> 
> So it means that if the same app is opened for the same user in two
> different sessions, several processes can write to the same XML file,
> so
> there can be races, and ideally the app needs to synchronize its
> state
> wrt the XML file.
> 
> I think a lot of applications don't cope well with that situation.
> 
> If I'm not mistaken, the same problem can happen with NFS-mounted
> home
> directories.
> 
> So I think in those setups, there are a lot of potential bugs in GTK+
> applications, because developers (prefer to) think that process
> uniqueness is per *user*.
> 
> Some questions:
> - Does the problem really exists?
> - Is there a recommended way to handle that situation?
> - Is there a way to test easily the situation without multi-seat
>   hardware? E.g. with VMs. Something automated, to also being able to
>   write unit/integration tests, or something that e.g. GNOME
> developers
>   could launch easily.
> - Or nobody cares about that problem?

As a general rule, we don't support being logged in to the same account
on 2 different seats, whether they share the same physical machine, or
just the backing storage.

On physical machines, this is enforced by gdm, and a shared user D-Bus, 
which mimicks the old session bus.

In short, not something to worry about.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus signal reaches after GDBus method returns

[Bastien Nocera]

On Wed, 2017-08-30 at 20:18 +0900, Takao Fujiwara wrote:
> Do you have any ideas how to receive a GDBus signal before the GDBus
> method returns?
> When I run the following program, the return of "KeyEvent" is always
> output faster than "CommitText" signal in the client program.
> Or do you have any ideas to know if the returned GDBus method emitted
> a GDBus signal in the server side?

>  result = g_dbus_proxy_call_sync (proxy,

This is a blocking call, so it's your client that's badly designed.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[Bastien Nocera]

On Sat, 2017-08-12 at 16:45 +0100, John Emmas wrote:
> On 12/08/2017 14:04, Sébastien Wilmet wrote:
> > >From the news file for version 2.53.4:
> > 
> > https://git.gnome.org/browse/glib/tree/NEWS
> > 
> > * glib-genmarshal and glib-mkenums have been rewritten in python.
> >   Every effort has been made to keep compatibility. Please report
> >   problems related to these tools
> > 
>  
> Thanks Sebastien,
> 
> Although I'm building with MSVC I don't use the official MSVC
> projects (mostly because I need to build 3 x targets:- 1) Debug
> build, 2) Release build and 3) Debuggable Release build).  I've
> figured out how to generate the file called "glib-genmarshal" -
> namely,

It'll be generated by configure, simply replace the python executable:
https://git.gnome.org/browse/glib/tree/gobject/glib-genmarshal.in

> python.exe  gen_util_scripts.py --type=glib-genmarshal --
> version=$(GlibVersion)
> 
> But I'm then stuck...  I can't figure out how to use that file to
> generate 'glib-genmarshal.c' (and/or any other files which need to
> get generated from it).

There's no C to generate, it's been ported to Python.

>   Can someone tell me the relevant command?  It isn't likely that
> this issue will affect anyone else.  Thanks,
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH v2] glib/gpoll: Remove if conditional

[Bastien Nocera]

Patches are best attached to bugzilla. You can use "git-bz" to file the bug and 
attach your path directly there.

Don't hesitate to reply if you have trouble filing the bug or attaching the 
patch.

Cheers

> On 26 Jul 2017, at 22:16, Alistair Francis  wrote:
> 
> On Fri, Jul 7, 2017 at 11:02 AM, Alistair Francis
>  wrote:
>> The original ready < nhandles - 1 can be re-written as ready + 1 < nhandles
>> which is the same confition that we are checking on the first
>> itteration of the for loop. This means we can remove the if statement
>> and let the for loop check the code.
>> 
>> This also has the side effect of removing an invalid check as
>> WAIT_OBJECT_0 was not subtracted from ready in the if statement.
>> 
>> Signed-off-by: Alistair Francis 
> 
> Ping!
> 
>> ---
>> v2:
>> - Rebase on master
>> - Remove the first patch in the series as it was incorrect
>> 
>> glib/gpoll.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/glib/gpoll.c b/glib/gpoll.c
>> index 265cb9210..b6c83d8ed 100644
>> --- a/glib/gpoll.c
>> +++ b/glib/gpoll.c
>> @@ -235,9 +235,8 @@ poll_rest (gboolean  poll_msgs,
>>{
>>  /* Remove the handle that fired */
>>  int i;
>> - if (ready < nhandles - 1)
>> -   for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>> - handles[i-1] = handles[i];
>> + for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>> +   handles[i-1] = handles[i];
>>  nhandles--;
>>  recursed_result = poll_rest (FALSE, handles, nhandles, fds, nfds, 
>> 0);
>>  return (recursed_result == -1) ? -1 : 1 + recursed_result;
>> --
>> 2.11.0
>> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Color fonts

[Bastien Nocera]

On Thu, 2017-06-29 at 23:18 -0400, Matthias Clasen wrote:
> I had another go at this here:  
> https://github.com/matthiasclasen/cairo/tree/emoji-again

I rebased your old branch on top of 1.14.10 (the current stable):
https://fedorapeople.org/~hadess/emoji/cairo-emoji-5-rebased-on-1.14.10.patch
for posterity more than anything.

I've also updated the COPR. Installing both packages in there should
get you colored emojis in Characters and other GTK+ 3.x apps.

https://copr.fedorainfracloud.org/coprs/hadess/emoji/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving to glade and GtkInspector

[Bastien Nocera]

On Mon, 2017-04-03 at 01:29 -0400, Martin Owens wrote:
> Hi Gtk Devs,
> 
> I'm brining this up in devel mailing list because it might not be
> possible to do well enough, but I'm interested in raising the
> question
> of moving projects from widget code to glade ui files.
> 
> I work on Inkscape. The next version of Inkscape (0.93) will be Gtk3
> and Gtk2 is now removed from our codebase. But we're still generating
> all of our widget trees in-code and is kinda hurts redesigning our
> dialogs.
> 
> Is it worth moving to glade for parts of a large gtk3 app, does it
> help
> with css adjustments at all and would it be an acceptable patch to
> make
> the gtkinspector dump out our existing widget trees (it would be
> really
> nice to have it generate glade xml, but that's just silly right). At
> least getting the data out of the inspector and into a python script
> for generating the xml would be a start.
> 
> Any ideas, or thoughts?

I wrote this horror a long time ago:
http://www.hadess.net/2009/04/because-i-suck-at-glade.html

I'm pretty sure you could reimplement this in the inspector without too
much trouble, even if it would likely suck codewise.

HTH
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gdk-pixbuf - JPEG comments patch

[Bastien Nocera]

On Sat, 2017-03-11 at 17:08 +0100, The Xj wrote:
> Hi,
> 
> I'm looking for someone who can commit my small patch to official
> repository.
> The patch it's a partial solution for this:
> https://bugzilla.gnome.org/show_bug.cgi?id=143608
> 
> Originally I've made the change as a pull request on GitHub:
> https://github.com/GNOME/gdk-pixbuf/pull/2/commits/1cede25038a2b43da0
> 361265ed36dbb2a94ceabd
> 
> The official way to submit patches is too complicated for me ( in
> bureaucratic way ;-).

Please attach the patch to the bugzilla bug, that's where reviews will
be made.

The patch doesn't look too far off something we could merge, but
there's still plenty of changes necessary.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC/Outreachy ideas for gdk-pixbuf

[Bastien Nocera]

On Mon, 2017-01-09 at 16:50 +0530, Nirbheek Chauhan wrote:
> On Fri, Jan 6, 2017 at 7:31 PM, Bastien Nocera <had...@hadess.net>
> wrote:
> > 2) Use giflib to load GIF files
> > Again, the gif loader is kind of hard to read and maintain and
> > giflib
> > seems to be well maintained. It would start with a new loader,
> > which we
> > could force load and check that it can pass all the test cases we
> > have
> > for the home-made GIF loader, and then use it to fix the additional
> > bugs.
> > 
> > This would be a single GSoC, with 1) being used to become familiar
> > with
> > gdk-pixbuf loaders, and 2) the actual target.
> > 
> 
> It would also be an interesting/useful project to add Rust-based
> pixbuf loaders which can then replace the C-based ones once they're
> working at-par (or close enough).
> 
> I remember hearing Federico mention that he'd be interested in
> working
> on that himself—perhaps he'd also be interested in mentoring someone
> to work on that?

I'd wait to see how the librsvg partial port pans out.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GSoC/Outreachy ideas for gdk-pixbuf

[Bastien Nocera]

Hey,

I spent a bit of time with gdk-pixbuf at the end of December, and had
an idea for gdk-pixbuf.

I know a few people want to get rid of gdk-pixbuf, but let's be
realistic, the amount of work needed to shift away from it would be far
too great to be done in one go, so why not make gdk-pixbuf
better/smaller to make it easier.

1) ICO/BMP code sharing
Both uncompressed ICO and BMP use the same DIB format, though the
headers are different. I think there's quite a few pieces of code that
could be shared.

Patches to share structures between both would be a good first patch
contribution, which we now require for GSoC at least.

2) Use giflib to load GIF files
Again, the gif loader is kind of hard to read and maintain and giflib
seems to be well maintained. It would start with a new loader, which we
could force load and check that it can pass all the test cases we have
for the home-made GIF loader, and then use it to fix the additional
bugs.

This would be a single GSoC, with 1) being used to become familiar with
gdk-pixbuf loaders, and 2) the actual target.

We'd need someone that knows about GIF to help mentor 2), I'd be happy
helping out with mentoring 1) and handling the test suite.

Any takers?

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Bastien Nocera]

On Mon, 2017-01-02 at 16:02 +0100, Stefan Sauer wrote:
> On 12/30/2016 12:09 PM, jcup...@gmail.com wrote:
> > On 29 December 2016 at 23:55, Emmanuele Bassi 
> > wrote:
> > > As Philip explained earlier in the thread, Valgrind can only
> > > accept a
> > > single suppression file. So, if GTK+ ships a suppression file, it
> > > would need to include suppression rules for all its dependencies,
> > > and
> > > you would still be unable to add your own on top of that. The
> > > only way
> > 
> > I realize you're talking about the default suppressions file, but
> > of
> > course valgrind can load many non-default suppression files at
> > once.
> > Up to 100, according to the man page.
> 
> you were quicker than me :) But yep, up to 100 and I think if an app
> has
> more that 100 dependencies they've got worse problems that exceeding
> this count.

Would be nice to be able to pass a directory of suppression files, so
that we don't need to do this manually.

> > 
> > $ valgrind --suppressions=/first/file.supp --
> > suppressions=/second/file.supp ...
> > 
> > So I think there would be some value in shipping separate, official
> > .supps for glib, gobject, gio, gtk etc etc.
> > 
> > We'd need one for each .pc file, so Stefan's suggestion of a
> > pkg-config var sounds very reasonable to me.
> > 
> > John
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk changes in the jhbuild moduleset

[Bastien Nocera]

On Fri, 2016-10-07 at 06:33 -0400, Matthias Clasen wrote:
> Hi,
> 
> we are getting ready to start development of gtk 3.90 in master.
> To avoid causing lots of breakage and irritation, here is the plan:
> 
> 1) Switch the modulesets to use the gtk-3-22 branch for the gtk
> module
> 2) Rename the gtk module to gtk3
> 3) Add a gtk4 module that follows master
> 4) Switch applications over to  use gtk4 as they are found to work
> 
> If you see a problem with that, please let me know.

Which would mean nothing called "gtk+" in the modulesets? Why not keep
either gtk 3.x or gtk 4.x with that name?

I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk 3.21.6?

[Bastien Nocera]

On Mon, 2016-09-12 at 14:33 +0100, Phillip Wood wrote:
> I've just noticed that the Gtk blog says the 3.21.5 release is likely
> to
> be the last release before 3.22.0. I'm not sure if that is still the
> case, but I'd like to do a 3.21.92 release for sound-juicer that
> relies
> on a Gtk version containing commit 0984d16 - GtkScrolledWindow: Bug
> 766569 - Make propagation of natural child sizes optional
> 
> As the behaviour of GtkScrolledWindow has changed since the last
> unstable release would it be possible for there to be a 3.21.6
> please.

> I want this to fix the super-tall panels in gnome-control-center as
> well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving thumbnailing code

[Bastien Nocera]

On Sun, 2016-06-26 at 13:45 +0200, Bastien Nocera wrote:
> Hey,
> 
> gnome-desktop, the library, is a remnant of the old "libgnomeui" with
> useful widgets that could not be in GTK+, and helper utilities that
> might not be ready for merging in GLib.
> 
> Nowadays, gnome-desktop only contains utilities that are shared
> between
> desktop components (gnome-settings-daemon, gnome-control-center,
> gnome-
> shell and gnome-initial-setup) and code to create thumbnails.
> 
> The thumbnailing code has been something we've wanted to move to
> another part of the stack for a while, as a dependency on API/ABI
> unstable gnome-desktop really shouldn't be needed, but the problem is
> always "where".
> 
> In https://bugzilla.gnome.org/show_bug.cgi?id=686895#c20
> Allison mentions D-Bus, or a giomodule.
> 
> I've started shaving the yak slightly by moving images thumbnailing
> to
> an external process, the same used by every other thumbnailer:
>     https://bugzilla.gnome.org/show_bug.cgi?id=768043
> https://bugzilla.gnome.org/show_bug.cgi?id=768062
> https://bugzilla.gnome.org/show_bug.cgi?id=768064
> 
> The code needs a bit more work, as I'd want to keep
> the G_FILE_ATTRIBUTE_PREVIEW_ICON usage within the thumbnailer.
> Should
> be done before anything else.
> 
> Because I think that it would be nice for GLib/gio to contain both
> the
> code to generate and consume thumbnails, I'm leaning towards
> implementing the API in gio, returning GObjects *, with the pixbuf
> processing handled in a giomodule shipped in gdk-pixbuf.
> 
> Another option would be to avoid all the giomodules, and either
> implement all the thumbnailing code in GTK+, or maybe the GdkPixbuf-
> handling parts in GIO, and non-graphical parts in GLib.
> 
> Using a giomodule would allow us to eventually move away from gdk-
> pixbuf (if we are ever going to do this).
> 
> Opinions?

Or we could just move it to gdk-pixbuf, which might be just high enough
in the stack to have gio and gdk-pixbuf support. Though that would mean
that thumbnailer and consumer would be in different places.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Moving thumbnailing code

[Bastien Nocera]

Hey,

gnome-desktop, the library, is a remnant of the old "libgnomeui" with
useful widgets that could not be in GTK+, and helper utilities that
might not be ready for merging in GLib.

Nowadays, gnome-desktop only contains utilities that are shared between
desktop components (gnome-settings-daemon, gnome-control-center, gnome-
shell and gnome-initial-setup) and code to create thumbnails.

The thumbnailing code has been something we've wanted to move to
another part of the stack for a while, as a dependency on API/ABI
unstable gnome-desktop really shouldn't be needed, but the problem is
always "where".

In https://bugzilla.gnome.org/show_bug.cgi?id=686895#c20
Allison mentions D-Bus, or a giomodule.

I've started shaving the yak slightly by moving images thumbnailing to
an external process, the same used by every other thumbnailer:
    https://bugzilla.gnome.org/show_bug.cgi?id=768043
https://bugzilla.gnome.org/show_bug.cgi?id=768062
https://bugzilla.gnome.org/show_bug.cgi?id=768064

The code needs a bit more work, as I'd want to keep
the G_FILE_ATTRIBUTE_PREVIEW_ICON usage within the thumbnailer. Should
be done before anything else.

Because I think that it would be nice for GLib/gio to contain both the
code to generate and consume thumbnails, I'm leaning towards
implementing the API in gio, returning GObjects *, with the pixbuf
processing handled in a giomodule shipped in gdk-pixbuf.

Another option would be to avoid all the giomodules, and either
implement all the thumbnailing code in GTK+, or maybe the GdkPixbuf-
handling parts in GIO, and non-graphical parts in GLib.

Using a giomodule would allow us to eventually move away from gdk-
pixbuf (if we are ever going to do this).

Opinions?

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Bastien Nocera]

On Wed, 2016-06-22 at 14:14 +0200, Sébastien Wilmet wrote:
> On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote:
> > > 2. Add experimental features through external libraries (libsexy
> > > and so
> > > on?)
> 
> 
> 
> > and linking a large number of tiny libraries has a measurable
> > startup
> > cost for applications.
> 
> https://blogs.gnome.org/alexl/2008/10/07/towards-a-ridley-based-platf
> orm/
> 
> """
> Before:
> 
> ldd `which nautilus` | wc -l
> 91
> 
> After:
> 
> ldd `which nautilus` | wc -l
> 60
> """
> 
> Now:
> 
> ldd `which nautilus` | wc -l
> 98

Link it against gtk-3.0-wayland instead of both the x11 and wayland
versions, and try again? My nautilus links against 25 X libraries, both
the old-school versions and the xcb async versions. And to wayland libs
as well as Wayland.

> Time for another Project Ridley?

It's nearly 8 years later, and the costs of linking to all those
libraries is likely hidden by even the slowest of NANDs, eMMCs or SSD.
Even a stock GNOME install will have all those cached by the OS by the
time you get to launch nautilus.

There might be benefits to reducing the library count, but startup
speed isn't likely to be one.

> And it doesn't count the dlopen'ed libraries, like for the GIO
> extension
> points.
> 
> --
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: wayland tablet support redux

[Bastien Nocera]

On Wed, 2016-03-30 at 16:46 +0200, Carlos Garnacho wrote:
> Hey all,
> 
> Now that 3.22 is open, and that the v1 of the wayland tablet protocol
> is formalized, I'll be attempting to merge wip/wayland-tablet again.
> Some random concepts:
> 
> =What's new in the branch=
> The main new API feature is GdkDeviceTool, it (almost, more on this
> ahead) univocally represents physical tablet tool (usually a pen),
> these structs contain a GdkDeviceToolType saying the kind of tool it
> is (pen, eraser, airbrush,...) and their serial number if available.
> 
> The idea behind this struct is that interested apps can do per-tool
> tracking/configuration/etc, using a same tool will always result in
> the same GdkDeviceTool pointer reported in events, etc. And the
> serial
> number can be used to compose GSettings paths and whatnot.

If you use the serial to construct the settings path, that means you
can't replace your broken airbrush pen with another airbush pen because
it would have separate settings. That's not likely what you want to
do. 

This also doesn't give you information about the tool type (airbrush,
inking pen, grip pen, etc.).

It is however useful for applications to directly monitor the pen in
use, which takes away gnome-settings-daemon from the loop to monitor
and switch tool configuration on proximity changes.

How would you export the configuration from the Wacom panel to the
applications though?

> The branch also resuscitates proximity events, they are a thing
> again,
> and I added some kind of support for these for X11/XI2.
> 
> There's though low-range tablets that don't report serials (and most
> usually, you can't use further/different tools than the one coming
> with the device), in wayland it's the compositor which takes care of
> creating the separate tool interfaces for those, in x11 we create
> extra GdkDeviceTools with serial=0, which are shared for all devices
> for all devices with these characteristics.

I still don't think that the serial is interesting, compared to the
tool ID.

> =...but we had already an eraser device?=
> Yes, and in the branch we still do, all events from the eraser tool
> will be sent with a GDK_SOURCE_ERASER device, and all other tools
> will
> be always sent with a GDK_SOURCE_PEN device. That's kind of
> unfortunate and something that'd be great to switch on 4.0.
> 
> Another option could have been going the other way around, and adding
> extra GdkInputSources and devices. I don't think that option scales
> as
> well.

Do we receive information about which tool this eraser is attached to?

The API for the eraser should match what is done for the tools above.

> =Relationship between tablets and tools=
> The typical noncontroversial setups are those with one tablet+one
> tool, or multiple tablets each with their own tool. Things complicate
> soon though when you add multiple tools and multiple compatible
> tablets, tools can then be used interchangeably across tablets.
> 
> This is one thing that IMO the wayland protocol got right, both
> tablets and tools are announced by the seat, it is tools which do
> "emit" the events, have axes, etc. And you can only relate a tool to
> a
> tablet on proximity_in.
> 
> And this is something we kind of do too in gdk. In the end you
> shouldn't expect that a given GdkDeviceTool will always be
> accompanied
> with the same GdkDevice in events. The difference here is that in gdk
> it is GdkDevices which have axes, "emit" events, etc. In order to
> keep
> doing this, slave pen/eraser devices do change their axes in order to
> resemble the tool in proximity_in, just like master devices currently
> do in x11 on slave device switch. The end message is the same,
> event->xxx.axes is only guaranteed to map correctly to the current
> device axes at the time of dispatching the event.
> 
> This also affects the lifetime of objects, unplugging a tablet will
> tear down the associated GdkDevices, but GdkDeviceTools may stay
> indefinitely longer.

How will you know that a GdkDeviceTool that you instantiated for tablet
#1 is usable for tablet #2?

> =Tablets and pointer cursors=
> One fundamental difference between X11 (with default XI2 behavior)
> and
> wayland is that in the former all plugged in devices drive the
> Virtual
> Core Pointer, whereas in wayland each tool in proximity (1 per
> tablet,
> effectively) will get their own.
> 
> This leads to differences in how are those are tablets mapped to
> GdkDevices, which I expect GdkSeat to help even out. in wayland we'll
> create a separate "master pointer" device for each tablet, its cursor
> can be set independently, etc. GTK+ has been prepared for the most
> part to deal with multiple pointers since 3.0, and it finally pays
> off
> :). The difference is that these several pointers come from the same
> seat, so they should all be able to interact with popup menus, etc.
> This is one place where GdkSeat grabs came to help, those will
> perform
> the input redirection for all devices 

Re: elementary would like to participate :)

[Bastien Nocera]

On Sun, 2015-11-08 at 20:24 -0500, Matthias Clasen wrote:
> 
> 
> On Thu, Nov 5, 2015 at 4:32 PM, Daniel Foré 
> wrote:
> > Hey folks,
> > 
> > Sri and Matthias pointed us here. Basically the idea is we want to
> > start a discussion about how elementary can be more involved in
> > Gtk+ development and Sri thought a good place to start would be to
> > try getting some of our Granite widgets into Gtk+. I think I know
> > someone who would be interested in porting widgets and getting them
> > into upstream. I guess the big question is what you all find most
> > interesting.
> > 
> > 
> Hey, thanks for coming in here. The tab bar widget is one that has
> been on the GNOME designer wishlist for a long time too.
> It is certainly the most complex widget on your list, but also the
> most interesting one from my perspective. 
> I think there were some people (Carlos ?) who said they would take
> this on, but so far nothing has materialized. 
> Using your implementation as a starting point would be great.

The "Storage" widget is pretty naff. Have you seen the "Segmented bar"
used in Rhythmbox (in C), Banshee (in C#) and probably other places?

Build rhythmbox, and you'll see a test widget in:
widgets/test-rb-segmented-bar

It's non-trivial, but there would be very few users for it. A good
cut'n'paste widget?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: elementary would like to participate :)

[Bastien Nocera]

On Thu, 2015-11-05 at 13:32 -0800, Daniel Foré wrote:
> 

> If you're not familiar with Granite, it's a Gtk+ based library that
> elementary uses in our apps. It contains some widgets and utils and
> things for stuff that we found ourselves rewriting over and over.
> It's written in Vala and you can view the source here: https://code.l
> aunchpad.net/~elementary-pantheon/granite/granite . It has a granite-
> demo that you can use to explore some of the widgets.

Had to install bzr, cmake. And I couldn't make it work within jhbuild.
Do you have a gallery of widgets on a web page? Wrestling with build
tools different from the ones in GTK+ to test widgets that would
eventually be in GTK+ is kind of bizarre.

At the very least, a kind soul should setup it up in jhbuild in the
world module.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

[Bastien Nocera]

On Tue, 2015-09-22 at 01:20 +0200, Bastien Nocera wrote:
> On Mon, 2015-09-21 at 18:38 -0400, Matthias Clasen wrote:
> > 
> > On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi <cosi...@gnome.org>
> > wrote:
> > > 
> > > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor <otay...@redhat.com>
> > > wrote:
> > > > Do we trust this code or not? If not, we should either a)
> > > > sandbox
> > > > it or b) delete it.
> > > > 
> > > > Moving less-trusted loaders into a separate repo is a blame-
> > > > the-
> > > > user or blame-the-os-vendor move, depending on who installs
> > > > them
> > > > onto the system.
> > > The only way to prevent the blame game you mention in a typical
> > > distribution where everything is installed through packages would
> > > be to stop supporting out of tree modules entirely, if I
> > > interpret
> > > your concern correctly.
> > > 
> > > My point is that as long as that's the case, at least maintaining
> > > them in a central location gives people an aggregation point for
> > > fixes.
> > > 
> > But they are not being maintained by anybody, and the fixes have
> > not
> > been aggregating... every few years some security researchers
> > decide
> > to have a look at image loaders, and then we get a bunch of
> > overflows
> > and corruptions reported, and either me of Benjamin grudgingly fix
> > them. And both of us are tired of doing that.
> 
> I would argue that at least I have taken care of some of that work at
> the end of 2014. I didn't get to see coverity scans or cppchecks, but
> this isn't the most complicated code to fix up and review.
> 
> If removing some of those loaders helps lighten the number of
> potential
> bugs, sure, go for it.
> 
> As for removing those loaders, I'd double-check whether GIMP has
> native
> support for those (not through a gdk-pixbuf loader), so that at least
> some modicum of support is left for those, making it less likely that
> we'll crash when somebody has a duff file in their file manager.

I tested all those formats, and I think we can remove the PCX and TGA
loaders, and leave those to be loaded by GIMP, in the very short term.

For QTIF, either support in GIMP or in GStreamer (it's usually only
used along with QuickTime) would be fine.

ANI files really need to be supported by GIMP before we remove the
support for it.

In short, remove all the mentioned modules, except ANI, and file bugs
against GIMP/GStreamer for the unsupported ones.

Cheers

Supported by GIMP:
PCX [2]
TGA [2]

Unsupported by GIMP:
ANI [1]
QTIF [3]
WBMP [4] (display broken in gdk-pixbuf)
RAS [5] (broken/unsupported in gdk-pixbuf)

[1]: Tests in shared-mime-info and gdk-pixbuf
[2]: Tests in shared-mime-info
[3]: 
https://github.com/daeken/QtChaos/blob/master/Harnesses/Quicktime/Sample.qtif?raw=true
[4]: http://www.thepcmanwebsite.com/wap_images.shtml
[5]: http://samples.libav.org/image-samples/sunrast/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Reinstate support for OS X versions older than 10.9

[Bastien Nocera]

On Tue, 2015-09-22 at 18:58 -0500, Ryan Schmidt wrote:
> On Sep 22, 2015, at 6:32 PM, John Ralls wrote:
> 
> > I’m a bit conflicted about this. Yes, 10.9 is a bit new for a
> > cutoff, but on the other hand upgrades to 10.10 are free and run on
> > any machine that can run 10.7
> 
> Per the EveryMac URL I posted, in addition to older PowerPC Macs that
> cannot be upgraded past 10.4, newer PowerPC Macs that cannot be
> upgraded past 10.5, and 32-bit Intel Macs that cannot be upgraded
> past 10.6, there are some 64-bit Intel Macs that cannot be upgraded
> past 10.7.
> 
> Further to that, there are users who do not wish to upgrade their OS,
> even if their machine can support it. They may have any number of
> reasons for that. For example, 10.6 is the last OS that can run
> PowerPC applications on Intel systems; a user may have PowerPC
> software they wish to continue using. Or a user may dislike the
> significant user interface changes Apple made in 10.7 or 10.10.
> 
> 
> > There’s always the option of sticking with the last releases of
> > GLib and Gtk+ if you want to build/run on older machines.
> 
> Considering the options we have in the MacPorts package management
> system, the possibilities I see are as follows:
> 
> - Keep glib2 at version 2.44.1 until all MacPorts users have upgraded
> to OS X 10.9 or later. This will not occur for years if ever. We
> still have MacPorts users today that use OS X 10.4.
> 
> - Upgrade glib2 to version 2.46.0 now, thereby preventing users on OS
> X 10.8 and earlier from using all the software in MacPorts that
> depends in some way on glib2.
> 
> - Add conditional logic to the glib2 port to use 2.46.0 on OS X 10.9
> and later and 2.44.1 on OS X 10.8 and earlier. This might be viable.
> Some other MacPorts ports for other gnome software is already doing
> something like this. But it is more complicated for the port
> maintainer (me) and it might break some use cases. For example, it is
> possible to build *on* 10.9 *for* 10.8; such an attempt might fail
> with 2.46.0.
> 
> - Change glib 2.46.0 so that it can be built without GNotification
> support on older systems. This is what I'm asking for.

I don't think that making new APIs do nothing, or ABI changing between
OSX versions is a good idea. You might want to work on adding support
for another notification sub-system (I don't think that OSX had one
builtin before 10.9, or without the needed feature), such as Growl.
Then make GNotification choose which one to use at run-time.

Depending on what the code ends up looking like, it might be too much
of a burden for upstream to consider it, but at least you have
something you can maintain inside MacPorts.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

[Bastien Nocera]

On Mon, 2015-09-21 at 18:38 -0400, Matthias Clasen wrote:
> 
> On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi 
> wrote:
> > 
> > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor 
> > wrote:
> > > Do we trust this code or not? If not, we should either a) sandbox
> > > it or b) delete it.
> > > 
> > > Moving less-trusted loaders into a separate repo is a blame-the-
> > > user or blame-the-os-vendor move, depending on who installs them
> > > onto the system.
> > The only way to prevent the blame game you mention in a typical
> > distribution where everything is installed through packages would
> > be to stop supporting out of tree modules entirely, if I interpret
> > your concern correctly.
> > 
> > My point is that as long as that's the case, at least maintaining
> > them in a central location gives people an aggregation point for
> > fixes.
> > 
> But they are not being maintained by anybody, and the fixes have not
> been aggregating... every few years some security researchers decide
> to have a look at image loaders, and then we get a bunch of overflows
> and corruptions reported, and either me of Benjamin grudgingly fix
> them. And both of us are tired of doing that.

I would argue that at least I have taken care of some of that work at
the end of 2014. I didn't get to see coverity scans or cppchecks, but
this isn't the most complicated code to fix up and review.

If removing some of those loaders helps lighten the number of potential
bugs, sure, go for it.

As for removing those loaders, I'd double-check whether GIMP has native
support for those (not through a gdk-pixbuf loader), so that at least
some modicum of support is left for those, making it less likely that
we'll crash when somebody has a duff file in their file manager.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: MSVC build error in gdk-pixbuf

[Bastien Nocera]

On Fri, 2015-09-11 at 18:22 +0800, Fan, Chun-wei (范君維) wrote:
> Hi Bastien and John,
> 
> In fact, I have a patch for this at bug 734556 comment 7, because the
> change that brought about this issue was from that bug.
> 
> With blessings, thank you!

Don't leave patches in closed bugs. Re-open it, or file a new one if
you don't have the rights to do that.

Commenting on closed bugs is probably the best way for the fixes and
comments to be ignored/lost.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: MSVC build error in gdk-pixbuf

[Bastien Nocera]

On Fri, 2015-09-11 at 10:47 +0100, John Emmas wrote:
> Hi guys.  I'm hoping this is the right place to report a build error 
> with gdk-pixbuf (git master).

Bugzilla is a better place for reporting bugs.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBusProxy missing bus signals during construction

[Bastien Nocera]

On Thu, 2015-07-23 at 21:59 +0100, Roger James wrote:
 
snip
 I propose to get this by round this by subscribing to the Avahi 
 ItemNew 
 signal  on my AvahiServer  proxy to catch the updates and then 
 unscribing it after I have connected the gobject signal on the 
 'AvahiServiceBrowser' proxy.  Even just typing that makes ny head 
 hurt!  
 I have no idea how that will play in the heavily multi-threaded  
 enviroment this is eventually to be deployed in.
 
 I will post the new code back here for posterity later.

Or fix Avahi directly?
https://github.com/lathiat/avahi/issues/9

That will all save us time in the long run...

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I'm done with O_CLOEXEC

[Bastien Nocera]

On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote:
 hi,
 
 On Sat, Mar 21, 2015, at 01:27, Jürg Billeter wrote:
  Doesn't the following standard POSIX functionality provide what you
  want?
  
  fcntl(fd, F_DUPFD_CLOEXEC, 0)
 
 Yes.  It does.  Thank you very much.
 
 It seems that this is a (slightly) recent addition.  It's documented:
 
F_DUPFD_CLOEXEC (int; since Linux 2.6.24)
 
 so I'm sure we'll probably still need to write an ifdef with a
 fallback...

7 years old:
http://kernelnewbies.org/Linux_2_6_24

 The wider question about the usefulness of O_CLOEXEC still stands.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: HAVE_NETLINK

[Bastien Nocera]

On Tue, 2014-12-16 at 13:12 +, John Emmas wrote:
 When building libglib, should I define 'HAVE_NETLINK' only when building 
 for Linux ??
 
 I'm building for Windows (with MSVC).  When I updated glib this morning 
 (from git master) I noticed that a new source file was recently added 
 (gio/gnetworkmonitornm.c).  I added it to my MSVC project but it then 
 failed to link, with this error:-
 
error LNK2019:  unresolved external symbol: 
 __g_network_monitor_netlink_get_type
 
 I found that symbol in 'gio/gnetworkmonitornetlink.c'.  But when I added 
 'gnetworkmonitornetlink.c', it wouldn't compile (couldn't find 
 'linux/netlink.h').  So am I right in thinking this is all Linux-only?  
 Or do I need to take a closer look at my configuration?  Thanks.

netlink is Linux-only, yes[1].

Cheers

[1]: https://en.wikipedia.org/wiki/Netlink

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building gdk-pixbuf loaders as static libs

[Bastien Nocera]

On Tue, 2014-12-02 at 12:10 +0100, Ignacio Casal Quinteiro wrote:
 John,
 
 in the link you can find out a couple of patches that needed to be
 applied,
 also here is the option we pass using mingw:
 https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gdk-pixbuf2/PKGBUILD#L45
 
 
 Not sure though how you can do that from msvc.
 
 
 Hope it helps.

Relevant patches should already be in gdk-pixbuf 2.31.2


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: State of gdk-pixbuf

[Bastien Nocera]

On Thu, 2014-10-23 at 17:29 +0200, Bastien Nocera wrote:
 On Thu, 2014-10-23 at 13:02 +0100, Emmanuele Bassi wrote:
  hi;
  
  On 23 October 2014 11:55, Matthias Clasen matthias.cla...@gmail.com wrote:
  
  
   I'm particularly interested to know what cairo, pixman and other image
   manipulation libraries can do for us. Benjamin surely has comments[2] :)
  
   When I last talked to Soeren about it (several years ago), pixman
   didn't support the pixel format that gdk-pixbuf is using.
  
  pixman supports RGBA (r8g8b8a8 and r8g8b8x8) since 2011, because it's
  used on big-endian architectures as well as being a requirement for
  OpenGL ES 2.0.
  
  this means that it should be possible to feed a GdkPixbuf pixel buffer
  to a pixman_image_t internally back and forth without copies, or, even
  better, to replace the GdkPixbuf internal storage and pixops with
  pixman_image_t and pixman operators.
 
 Indeed, that's one of the options we can take that wouldn't break ABI
 compatibility.
 
   it should also be possible to
  create a tiled buffer composed by pixman_image_t tiles for large image
  data.
 
 I have no idea what the API would look like for that.
 
 There's still the problem of handling huge files, especially the ones in
 grayscale or bw. The uncompressed in-memory usage would balloon
 compared to what it could use if we kept it in grayscale/bw [1].
 
 Which gets us to the problem discussed in:
 https://bugzilla.gnome.org/show_bug.cgi?id=491507
 
 We could start hiding the backing store and use cairo or pixman
 internally.
 
 gdk_pixbuf_get_pixels() would need to convert from whatever is the
 native format, to the GdkPixbuf format. Which would break applications
 expecting it to change the backing storage (say, adding borders to
 pixbufs). I'd probably do that with a slight ABI break, adding API to
 change the internal representation to the GdkPixbuf native format.

Actually, gdk-pixbuf already does that internally after Colin's commit
in https://bugzilla.gnome.org/show_bug.cgi?id=732297

So we could potentially store a pixman_image_t internally.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: State of gdk-pixbuf

[Bastien Nocera]

On Fri, 2014-10-24 at 13:30 +, Benjamin Otte wrote:
 Bastien Nocera hadess at hadess.net writes:
 
  I'm particularly interested to know what cairo, pixman and other image
  manipulation libraries can do for us. Benjamin surely has comments[2] :)
  
 I think gdk-pixbuf should just die already, but it won't. And now you're
 resurrecting it, dammit!

While there's nothing to replace it, probably not. And so far, I'm
mainly wrangling patches and fixing small bugs.

 The reason is that I think that gdk-pixbuf is both a rather old library so
 it has very sucky conventions in lots of places (like exposing way too many
 externals) and that it isn't a good fit for the use cases we have.
 But it's ubiquitous and easy to use when it does work, so it's always the
 place people go to.

Exposing too many internals? Or do you mean its API is too wide?

 I'll try to elaborate on the use cases we have and why it's not been
 replaced for each of those
 
 1. image loading
 gdk-pixbuf provides a generic way to hand it a file or stream and get pixels
 out the other end. There is no other way to do this, unless you are a
 masochist and want to use the image loading libs directly. The loaders in
 gdk-pixbuf have also been sanitized well enough to be safe (enough) against
 random data from the Internet.
 The reason gdk-pixbuf is used here is because there's no replacement that is
 as easy to use and integrates as well into the Gnome stack. Webkit has its
 own loaders, but they are internal to Webkit (I'd expect them to be even
 safer). Gimp/Gegl has its own loaders, but they pull in libgimp (or you need
 to code your own widgets to display them).

OK, so we agree that we should be keeping that part at least. If I
remember correctly, fixing potential security problems in the loaders is
how Matthias got started ;)

We could probably do with a fuzzer and throwing images at it, or with a
couple of coverity runs.

 2. holding pixel data
 A GdkPixbuf is a kind of agnostic way to hold a (width, height, contents)
 object. It's rather ad at this because it uses the worst format possible
 (unpremultiplied RGBA in the wrong order). 
 GTK is slowly replacing its internal APIs with cairo_surface_t here. And I
 expect this to potentially change again to some sort of texture thing once
 we move towards GL.

I've been looking at a way to make this more efficient, and babl might
be a good way to store decoded data in a format that's closer to the
format used internally. Eg. a grayscale picture shouldn't take as much
room in memory as a same-dimension colour one.

Once you actually want to display, you'd need to convert it to a format
cairo understands. We have some pixbuf/cairo APIs in GDK, should those
be in gdk-pixbuf instead?

 3. an area of custom drawing
 GTK kindly kindly provides lots of API to use GdkPixbuf everywhere - from
 gdk_cairo_set_source_pixbuf() to lots of widgets that can display it
 (GtkImage, GtkEntry, GtkClipboard, GdkCellRendererPixbuf...). So people use
 pixbufs whenever they have some custom drawing that they want displayed
 (like icons, custom avatar pictures or even graphs). There are various
 limitations here - the most important one being the problems around resizes,
 but it's the best thing we have.
 One could use cairo_surface_t for this, but I'm not very happy with exposing
 it, because cairo_surface_t has too many weird additional features, like
 device scales, device offsets, it being Cairo backend-bound, its ability to
 be changed at will and last but not least it's just not a GObject.
 What you really want is some sort of object that has width, height and a
 draw function and have lots of subclasses for pixbufs, gradients, single
 color, whatever. But such an object doesn't exist.
 https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssimageprivate.h is what GTK
 uses internally for the different image types CSS supports. You can look for
 the various subclasses that implement those from url() and linear-gradient()
 to -gtk-icontheme() and cross-fade().

gdk_cairo_surface_create_from_pixbuf() already exists. If we moved this
sort of call into gdk-pixbuf, it could know about the internals of the
storage, and convert it more efficiently, without an intermediate step.

 4. animations
 GdkPixbuf has rudimentary animation API. That API is very sucky from both
 sides - the gif loader is as ugly at implementing it as it is inconvenient
 to use.

What would this API look like ideally?

I think the GIF loader should use giflib instead of its own code, would
reduce the maintenance burden and probably make the code easier to read.

  Animations are separate from regular pixbufs, so you often need
 multiple code paths if you want to support animations. But it's the only
 thing we have and you don't have to think about it when passing a filename
 to GtkImage, so it's seen various usages.
 There's no good replacement. All solutions that really support animating
 images are really complex. SVG requires full renderers (usually

Re: State of gdk-pixbuf

[Bastien Nocera]

On Fri, 2014-10-24 at 09:07 -0700, Jim Nelson wrote:
 To chime in with my two cents here:
 
 
 When we started Shotwell in 2009, we got tremendous mileage out of
 GdkPixbuf.  We looked into GAGL/BABL at one point and got worried
 about speed.  (Remember, Shotwell has a non-destructive photo editor,
 meaning all transformations are applied at runtime, i.e. whenever the
 photo is accessed.)  Shotwell's transformation pipeline still uses
 GdkPixbuf; I wouldn't be opposed to moving it to pure Cairo, but why
 fix what's not broken?

By nuking the rest I meant remove from the gdk-pixbuf releases. You
could still copy/paste the utility functions that do blending,
compositing, copying, etc. Or move them to a library that doesn't have
the same API guarantees that gdk-pixbuf needs to have. That's still some
ways off.

 GdkPixbuf's photo loaders saved us a lot of work (although we got bit
 by the large-image bugs discussed previously).  Also, LibRaw produces
 bitmap data that's in the exact format as GdkPixbuf, and so we could
 plug in those buffers without touching the bytes.

I would expect that using using babl storage internally would diminish
the memory usage. That's probably something that I'll look at next week.

  We could certainly nuke the rest if we think that other libraries
  would be better equipped for resizing, clipping, scaling, and
  compositing.
 
 
 Compositing I wouldn't miss, but the other operations ... if you need
 to load an image, do a quick operation on it, and get it into a widget
 or on the screen, GdkPixbuf is the way to go.

Right. Those are mostly utility functions. You could, right now, use
pixman instead of gdk-pixbuf to resize for example. That would be much
faster than gdk-pixbuf. If somebody is interested in porting the pixops
to pixman, we'd all owe that person a debt of gratitude ;)

 For lack of a better analogy, it would be like C++ dropping strlen,
 strncpy, etc. in place of their string object.  Sometimes when you
 have a pointer to ASCII char and need to quickly process it in a basic
 or fundamental way, the old warhorses are the way to go.

I don't see the operations disappearing, just moving somewhere else,
longer term. I'll make sure to mail this list when/if we get to that
point though.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: State of gdk-pixbuf

[Bastien Nocera]

On Thu, 2014-10-23 at 08:39 +0200, Ignacio Casal Quinteiro wrote:
 Hi Bastien,
 
 for what is worth here are the pathes that we need to apply downstream
 on windows:
 
 https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdk-pixbuf2

It would be great if you could review the patches that are already in
bugzilla, and make sure that gdk-pixbuf upstream is usable for Windows.

Cheers

 On Thu, Oct 23, 2014 at 4:31 AM, Bastien Nocera had...@hadess.net
 wrote:
 Hey,
 
 I've spent a couple of days triaging all the gdk-pixbuf bugs,
 wrangling
 patches, and testing what was testable. The bugs left over
 basically
 fall in a few categories:
 - Bugs or feature requests in the loaders. There's quite a few
 of them
 that could probably be handled in minutes, or maybe in a
 couple of hours
 if one doesn't know a particular format. It would be great to
 have an
 OPW or GSoC project based on those.
 - API additions. A few of those for animation features which
 we might or
 might not want to support, quite a few for async versions of
 existing
 functions, or variants of existing functions (stream-based
 loading).
 - GDI loader bugs
 - Pixops bugs (Argh [1])
 - Handling of huge images
 - Cairo interaction support
 
 The last 3 are related in that GdkPixbuf is a format that
 doesn't lend
 itself to handling big images (especially black and white
 pictures would
 balloon in memory usage), and that its coverage for
 acceleration in
 manipulation and compositing is small (basically unaccelerated
 on
 anything but 32-bit x86 and Solaris).
 
 I think we need to start looking at a replacement for pixops,
 and a
 replacement for the GdkPixbuf format.
 
 I'm particularly interested to know what cairo, pixman and
 other image
 manipulation libraries can do for us. Benjamin surely has
 comments[2] :)
 
 Cheers
 
 PS: Now is a good time to look at your pet feature, dig in a
 little, and
 get your patches reviewed.
 
 [1]:
 
 https://bugzilla.gnome.org/buglist.cgi?product=gdk-pixbufbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=pixops
 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13
 
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 
 
 
 -- 
 Ignacio Casal Quinteiro


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: State of gdk-pixbuf

[Bastien Nocera]

On Thu, 2014-10-23 at 13:02 +0100, Emmanuele Bassi wrote:
 hi;
 
 On 23 October 2014 11:55, Matthias Clasen matthias.cla...@gmail.com wrote:
 
 
  I'm particularly interested to know what cairo, pixman and other image
  manipulation libraries can do for us. Benjamin surely has comments[2] :)
 
  When I last talked to Soeren about it (several years ago), pixman
  didn't support the pixel format that gdk-pixbuf is using.
 
 pixman supports RGBA (r8g8b8a8 and r8g8b8x8) since 2011, because it's
 used on big-endian architectures as well as being a requirement for
 OpenGL ES 2.0.
 
 this means that it should be possible to feed a GdkPixbuf pixel buffer
 to a pixman_image_t internally back and forth without copies, or, even
 better, to replace the GdkPixbuf internal storage and pixops with
 pixman_image_t and pixman operators.

Indeed, that's one of the options we can take that wouldn't break ABI
compatibility.

  it should also be possible to
 create a tiled buffer composed by pixman_image_t tiles for large image
 data.

I have no idea what the API would look like for that.

There's still the problem of handling huge files, especially the ones in
grayscale or bw. The uncompressed in-memory usage would balloon
compared to what it could use if we kept it in grayscale/bw [1].

Which gets us to the problem discussed in:
https://bugzilla.gnome.org/show_bug.cgi?id=491507

We could start hiding the backing store and use cairo or pixman
internally.

gdk_pixbuf_get_pixels() would need to convert from whatever is the
native format, to the GdkPixbuf format. Which would break applications
expecting it to change the backing storage (say, adding borders to
pixbufs). I'd probably do that with a slight ABI break, adding API to
change the internal representation to the GdkPixbuf native format.
Applications that used to call _get_pixels() could be ported with a
one-liner. Applications that want to be able to handle bigger images can
then do their modifications at the drawing stage.

In any case, short-term, fixing all the pixops buglets by using pixman
would be a great step forward, and would lower our maintenance burden
(not that pixops bugs saw much more than inhaling through clenched teeth
and words of kind-of-encouragement).

Cheers

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=666391 and all the dupes

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

State of gdk-pixbuf

[Bastien Nocera]

Hey,

I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling
patches, and testing what was testable. The bugs left over basically
fall in a few categories:
- Bugs or feature requests in the loaders. There's quite a few of them
that could probably be handled in minutes, or maybe in a couple of hours
if one doesn't know a particular format. It would be great to have an
OPW or GSoC project based on those.
- API additions. A few of those for animation features which we might or
might not want to support, quite a few for async versions of existing
functions, or variants of existing functions (stream-based loading).
- GDI loader bugs
- Pixops bugs (Argh [1])
- Handling of huge images
- Cairo interaction support

The last 3 are related in that GdkPixbuf is a format that doesn't lend
itself to handling big images (especially black and white pictures would
balloon in memory usage), and that its coverage for acceleration in
manipulation and compositing is small (basically unaccelerated on
anything but 32-bit x86 and Solaris).

I think we need to start looking at a replacement for pixops, and a
replacement for the GdkPixbuf format.

I'm particularly interested to know what cairo, pixman and other image
manipulation libraries can do for us. Benjamin surely has comments[2] :)

Cheers

PS: Now is a good time to look at your pet feature, dig in a little, and
get your patches reviewed.

[1]: 
https://bugzilla.gnome.org/buglist.cgi?product=gdk-pixbufbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=pixops
[2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Physically based kinetic scrolling

[Bastien Nocera]

Hey,

On Mon, 2014-05-05 at 13:58 +0100, Lieven van der Heide wrote:
 I modified the scrolled windows kinetic scrolling to match the actual
 physics laws for friction and springs. IMHO, this gives a much more
 pleasing result. 
 
 
 
 A branch with these changes is at
 
 
 https://github.com/lievenvanderheide/gtk-kineticscrolling
 
 
 I hope that someone can have a look at it, and maybe merge it into the
 main gtk branch.

Very interesting work. You should create a bug in the GNOME Bugzilla,
and attached a patch that squashes your 2 commits from your git tree.
The patch review will be done in Bugzilla instead. You'll at least want
to add a more detailed commit explaining all the changes you've made.

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Physically based kinetic scrolling

[Bastien Nocera]

On Mon, 2014-05-05 at 10:04 -0400, Hashem Nasarat wrote:
 Sweet feature! But
 
 Is this legal to implement? As far as I know, doesn't a portion of the
 Apple v Samsung trial have to do with the way Samsung implemented touch
 scrolling? Also, aren't apple's patents the reason why Android doesn't
 have the bounce animation in their scrolling lists?
 
 I'm not a lawyer, but these two patents seem to describe what you have
 implemented (and to a lesser degree, the pre-existing touch physics in
 GTK+).

Don't discuss, or link to patents on the developer list. The less we
know, the less we are likely to infringe, or the less likely we are to
be condemned for infringing if that were to be the case.

It's the same reason why we don't go scouring patent archives when
implementing or designing new features.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

G-i annotations for transformation functions

[Bastien Nocera]

Heya,

I'm trying to solve:
https://bugzilla.gnome.org/show_bug.cgi?id=728504

These functions:
https://git.gnome.org/browse/gom/tree/gom/gom-resource.h#n64
create the following warning:
gom/gom-resource.h:77: Warning: Gom: gom_resource_class_set_property_transform: 
argument to_bytes_func: Missing (scope) annotation for callback without 
GDestroyNotify (valid: call, async)
gom/gom-resource.h:77: Warning: Gom: gom_resource_class_set_property_transform: 
argument from_bytes_func: Missing (scope) annotation for callback without 
GDestroyNotify (valid: call, async)

Any ideas which annotation to use, or what changes to make to those
functions to make them introspectable?

g_value_register_transform_func(), an equivalent function in GValue, is
marked as skipped.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: JavaScript stack trace in ABRT bug reports

[Bastien Nocera]

On Tue, 2014-03-18 at 04:30 -0400, Jakub Filak wrote:
 Hello,
 
 I a member of the ABRT team. We have recently found an interesting page about
 GNOME Shell debugging[1]. According to that page, it is possible to obtain a
 stack trace of executed JavaScript code in gdb. So we got an idea to include
 the JavaScript stack trace in Bugzilla bugs filed by ABRT. I tried to obtain
 the JavaScript stack trace by attaching gdb to a core dump file but it didn't
 work because we can call a method only when gdb is connected to a process.
 
 But we got another idea. Would it be possible to write the JavaScript stack
 trace to a file (or journald) in a well known path upon receiving a UNIX
 signal? This already works for JVM, which creates the hs_err_pid.log file[2]
 when a JVM process is to die and ABRT includes the hs err log file in Bugzilla
 bugs.

Wrong mailing-list, try:
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: libsoup + gsettings-desktop-schemas for server code

[Bastien Nocera]

On Mon, 2014-03-03 at 14:40 +, Colin Walters wrote:
 Hi,
 
 
 I use GLib/gjs for server side code in several places.  For example, I
 recently wrote
 https://github.com/cgwalters/min-metadata-service
 which uses libsoup.  Which at the RPM level, Requires: glib-networking
 which in turn requires gsettings-desktop-schemas.
 
 
 It's a little ugly to pull this in on minimal servers just so that I
 can resolve the proxy config.
 
 
 Furthermore - as a daemon running as root, I don't even have a
 non-Memory GSettings backend.  That presently causes a warning, which
 is a bit ugly.  Now as I understand it, the idea is servers could use
 the keyfile backend - except I don't want to have my own keyfile for
 the proxy setup.
 
 
 How about this as a strawman:
 
 
 1) Split off some of the core settings like org.gnome.system.proxy
 into gsettings-core-settings or something
 2) Have a common keyfile in /etc/gsettings-core.conf that headless
 server code can use

What about shipping the keyfile in gsettings-desktop-schemas? Does it
hurt to have more schemas than the ones you use?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: gestures

[Bastien Nocera]

On Tue, 2014-03-04 at 00:55 +0100, Carlos Garnacho wrote:
 Hey everyone,
 
 In the past days I've been hacking again on the gestures branch, and
 it's reaching an state where I feel it's getting quite solid, so I would
 like to get discussion started, tentatively aiming to get this included
 early in 3.13.
 
 Overview
 
 
 The two object types this relies on are GtkEventController and
 GtkGesture. GtkEventController is a very lowlevel abstraction for
 something that just handles events. GtkGesture is a subclass very
 centered around handling single or multiple sequences of
 press/update.../release events, by default it's restricted to handling
 touch events, although can be made to listen to mouse events, either
 though API or through the GTK_TEST_TOUCHSCREEN envvar (a NULL
 GdkEventSequence is used in those cases).
 
 Multiple GtkGesture implementations are offered in the branch:
 
   * Drag: keeps track of drags, reporting the offset from the drag
 start point.
   * Swipe: reports x/y velocity at the end of a begin/update/end
 sequence.
   * LongPress: reports long presses, or those being canceled after
 threshold/timeout excess.
   * MultiPress: reports multiple presses, as long as they're within
 double click threshold/timeout
   * Rotate: reports angle changes from two touch sequences
   * Zoom: reports distance changes from to touch sequences as a
 factor of the initial distance.

What about the single tap/press? Do the gestures for which it makes
sense also give back the center of the operation? Do the gestures know
about each other? (like, if there's no long-press in my widget, will it
understand that I'm starting a drag or I'm slow at tapping?)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Bastien Nocera]

On Tue, 2014-02-04 at 15:20 +0530, Ankit Vani wrote:
 Hi
 
 I have set up gobject-introspection in Pidgin -- and it works well for
 libpurple, pidgin and finch. However, g-ir-scanner dies with a very
 cryptic error when g-ir-scanner scans libgnt.
 
 
 The error looks like:
   GISCAN   Gnt-2.8.gir
 
 (process:13172): GLib-CRITICAL **: g_key_file_has_group: assertion
 'key_file != NULL' failed

Try getting a backtrace of the crash. It's likely a bug in the library
itself.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Bastien Nocera]

On Tue, 2014-02-04 at 15:34 +0530, Ankit Vani wrote:
 On Tue, Feb 4, 2014 at 3:27 PM, Bastien Nocera had...@hadess.net wrote:
  Try getting a backtrace of the crash. It's likely a bug in the library
  itself.
 
 Can you tell me how exactly to go about getting a backtrace?
 
 I've tried using gdb on python (to run g-ir-scanner) without any special
 setting, but I'm unable to break on g_log.

ulimit -c unlimited
G_DEBUG=fatal_criticals make

And examine the coredump with gdb.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Print module for Google Cloud Print

[Bastien Nocera]

On Fri, 2014-01-31 at 13:17 +, Tim Waugh wrote:
 Hello!
 
 I've made a simple print module to support printing to Google Cloud
 Print. This is a web service provided by Google that allows people to
 share their printers.
 https://www.google.com/cloudprint/learn/
 
 In addition to being able to print to printers shared on Google Cloud
 Print, there is an equivalent of Print to file in the form of Save to
 Google Drive. Here's a screenshot of the print dialog gedit shows:
 http://cyberelk.net/tim/wp-content/uploads/2014/01/cloudprint.png
 
 The cloudprint module uses gnome-online-accounts to obtain the OAuth 2.0
 access token for the Google account, so I needed to add another scope
 in the google goa backend.
 
 Currently it can discover available printers, get simple details about
 them such as display name and status, and submit jobs without any
 special options. I plan to add options-setting based on the capabilities
 advertised by the printer.
 
 What's the best way for me to submit this?

Bugzilla for the various components involved. We're adding support for
Video permissions to the Google account as well in
gnome-online-accounts.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH 0/3][RFC v2] gdbus: Preliminary kdbus-support patches

[Bastien Nocera]

On Wed, 2014-01-08 at 14:44 +0100, Lukasz Skalski wrote:
 Changes since v1:
 =

This should probably go to bugzilla instead. git-bz can help you attach
series of patches easily.

(and I'd like to know the bug URL when you do :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GdNotification in GTK+?

[Bastien Nocera]

Hey,

Seems that GdNotification didn't make the jump into GTK+ itself. Does
anyone have a bug reference for the port if there's one?

Otherwise I'll file one and might write that code up, it should be quite
a lot less of code using GtkRevealer instead of the custom animation
code.

For those who don't know what GdNotification is, it's not a replacement
for libnotify, or the GNotification work, it's used for in-app
notifications, and looks like this:
https://bug720444.bugzilla-attachments.gnome.org/attachment.cgi?id=264239

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Regarding Maintainer of package gdk-pixbuf

[Bastien Nocera]

On Thu, 2013-11-28 at 01:59 -0500, s...@linux.vnet.ibm.com wrote:
 Thanks Jasper. Will contact Matthias Clasen.

You should attach your patches to bugzilla instead...

 Quoting Jasper St. Pierre jstpie...@mecheye.net:
 
  The maintainer is Matthias Clasen, although you should simply attach your
  patches to a Bugzilla bug...
 
 
  On Thu, Nov 28, 2013 at 1:51 AM, s...@linux.vnet.ibm.com wrote:
 
  Hi,
 
  I am working on a new architecture - ppc64le (powerpc 64-bit Little
  Endian) and I was looking at building gdk-pixbuf. The package failed to
  build due to an outdated config.guess.
 
  Can I get the information about the maintainer of the package, so that I
  can talk to him/her about sending a patch to support the new architecture.
 
 
  Thanks,
  Narasimhan V
 
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 
 
 
 
  --
Jasper
 
 
 
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Removal of icons in buttons/menus

[Bastien Nocera]

On Wed, 2013-10-09 at 22:14 +0200, Olivier Brunel wrote:
 Ok, but this isn't about a change in GNOME, but in GTK. And the
 default
 for those options was still TRUE a few days ago in GTK 3.8

As we're on this subject, I think it's pretty clear, from the committers
to where the mailing-lists are hosted that GTK+ is the GNOME toolkit.
People deeply involved in other desktops that rely on GTK+ should try to
get more involved in decisions made for the GNOME toolkit.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Bastien Nocera]

On Wed, 2013-10-09 at 22:01 +0200, Sébastien Wilmet wrote:
snip
 For a command line application, Enchant is still available. So it's 
 maybe a better idea to implement the spell checking directly in GTK+.  
 I'll think about the possible API additions.

I wouldn't want to use 2 different APIs when creating
command-line/curses APIs or GTK+ though. Otherwise, whatever syntactic
sugar the GObject bindings would add would be lost.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Removal of icons in buttons/menus

[Bastien Nocera]

On Wed, 2013-10-09 at 22:45 +0200, Michael Natterer wrote:
 On 10/09/2013 10:40 PM, Bastien Nocera wrote:
  On Wed, 2013-10-09 at 22:14 +0200, Olivier Brunel wrote:
  Ok, but this isn't about a change in GNOME, but in GTK. And the
  default
  for those options was still TRUE a few days ago in GTK 3.8
 
  As we're on this subject, I think it's pretty clear, from the committers
  to where the mailing-lists are hosted that GTK+ is the GNOME toolkit.
  People deeply involved in other desktops that rely on GTK+ should try to
  get more involved in decisions made for the GNOME toolkit.
 
 Oh please, not this silly GNOME Toolkit stuff again. GIMP runs on
 windows and osx, so do many other applications. So please...

They're GTK+ apps running on Windows and OS X, not Windows apps, or OSX
apps.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Removal of icons in buttons/menus

[Bastien Nocera]

On Wed, 2013-10-09 at 23:15 +0200, Tristan Van Berkom wrote:
 GNOME: A desktop environment / User experience
 
 By this definition (which seems to be a common slur these days), then
 no,
 GTK+ is certainly not just a toolbox for the purpose of assembling a
 particular user experience.
 
 Let's try not to discredit GTK+, and try not to use slurs which might
 imply that GTK+ is becoming just a toolbox for GNOME.

I'll gladly use that slur again and again. And I'm happy with GTK+
being the toolset of GNOME, especially when you consider what's driving
most of the new widget development for example.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Bastien Nocera]

On Tue, 2013-07-02 at 09:41 -0400, William Jon McCann wrote:
 Hi,
 
 
 As some of you may have noticed we have recently deprecated Stock
 Items in master.
 
 
 Some details on this change may be found here:
 https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub
 
 
 Please let us know what you think.

The biggest loss is the need to re-translate, usually with consistency
about the mnemonic used, things such as _About, _Save, etc.

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Bastien Nocera]

On Tue, 2013-07-02 at 10:44 -0400, Matthias Clasen wrote:
 On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote:
 
 
  Besides what Bastian already points out, I have another concern if we
  are to consider moving
  away from stock items completely.
 
  The document above points to this list of icon names:
 
  http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names
 
  What guarantees do we have that referring to an icon name in the icon
  naming spec will
  actually produce an icon ?
 
 GTK+ ships with a built-in icon theme that covers the named icons used
 by the stock system (not all listed in the naming spec).

Will we keep those:
https://developer.gnome.org/gtk3/3.4/gtk3-Stock-Items.html
somehow listed in the documentation (even if the declarations are
deprecated)?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Storage API

[Bastien Nocera]

On Thu, 2013-05-02 at 11:29 +0200, Murray Cumming wrote:
 On Wed, 2013-05-01 at 16:31 +0200, Bastien Nocera wrote:
  Heya,
  
  I've started writing a simple database-like application in Javascript
  using GTK+, and I wondered about what to use for storage.
  
  gjs currently doesn't have bindings for SQLite, and using intermediate
  bindings like libgda I found too low-level (provider-specific SQL,
 
 libgda's GdaSqlBuilder makes this a bit more pleasant and safer,
 avoiding most provider-specific stuff. Of course, it doesn't hide SQL
 entirely.

It's nicer, but still SQL.

Migration between versions of schemas is pretty complicated, you still
need to create the schemas, and though not directly related to SQL, you
still need to put a lot of effort marshalling objects in the DB to and
from your own object type.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Storage API

[Bastien Nocera]

On Wed, 2013-05-01 at 12:31 -0400, Colin Walters wrote:
 On Wed, 2013-05-01 at 16:31 +0200, Bastien Nocera wrote:
   Dumping
  serialised Javascript objects to the filesystem isn't really elegant
  either.
 
 It isn't, but for what it's worth that's what I do currently:
 https://git.gnome.org/browse/gnome-ostree/tree/src/js/jsonutil.js
 
 But this app is basically Tiny Data.  One starts to want SQLite and such
 when getting to Medium-Small Data and needing efficient indexing in
 process.

If a SQLite DB is used in the backend and the API is nice to use, there
should be no difference in usage between tiny and medium-small data.

It would be pretty nice to be able to scale if your application needs it
without having to rewrite code.

   Finally on the Large and Big Data sides you're just doing RPC
 to some server.
 
  I was wondering whether an API based on HTML5's IndexedDB[1] (and maybe
  a GtkTreeModel to display the database contents/filtered results) would
  be of interest in GLib.
 
 I don't have any experience with IndexedDB myself; on the surface it
 looks nice.
 
 This particular domain though is tricky because a nice data binding
 API really wants language-specific hooks.  The old pygtk treemodel
 binding had some smarts here.

Sure. But even stuffing objects into a treemodel shouldn't be overly
complicated even if not optimal.

 Don't forget though you always have the ability to write a C library
 that does whatever you want (sqlite via C for example), and exports
 results to JS.
 
 There's obviously a lot of other stuff in this domain... libgda long
 predates introspection, but it claims to have something useful here:
 http://www.gnome-db.org/Bindings

libgda still uses SQL, making it not so nice for in-development
applications.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New drawing/scrolling model

[Bastien Nocera]

Em Thu, 2013-05-02 às 14:40 -0400, Alexander Larsson escreveu:
 I've tried a bunch of apps and most things seem to work. Currently I
 know of two problems:
 
 The control-center background panel calls gdk_cairo_create() inside
 the draw() handler, which draws directly to the window rather than the
 passed in cairo_t. This works in a sense, but the rendering is then
 unaffected by the cairo_push()/pop() that the stack uses for
 crossfading, so the crossfade effect breaks. This could possibly
 happen in other cases, but it seems like it is pretty uncommon (I
 didn't find any other problematic use in all of Gnome).
 
 The control-center display panel does this weird thing where it
 draws areas using cairo, and then reads it back to use as input
 regions. This code assumes that the coordinates on the cairo_t when
 converted via cairo_user_to_device() is in the coordinate space of the
 widgets windows, whereas it is now in the coordinate space of the
 toplevel. This makes the input regions offset by the position of
 the widget making it hard to click/drag them. This is a pretty
 weird thing to do, and i don't expect we'll run into other apps
 doing the same thing.

Both of those are just plain bugs/misuse of cairo. The display panel at
least is ported from old GNOME2 code, and hasn't been eyeballed properly
(at least, I stopped when mine started bleeding). It's also due a
rewrite/redesign.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Storage API

[Bastien Nocera]

Heya,

I've started writing a simple database-like application in Javascript
using GTK+, and I wondered about what to use for storage.

gjs currently doesn't have bindings for SQLite, and using intermediate
bindings like libgda I found too low-level (provider-specific SQL, the
need to write SQL and highly manual schemas upgrade paths). Dumping
serialised Javascript objects to the filesystem isn't really elegant
either.

I was wondering whether an API based on HTML5's IndexedDB[1] (and maybe
a GtkTreeModel to display the database contents/filtered results) would
be of interest in GLib.

If it's of interest, I'd like to start discussing and designing the API
with interested parties.

Cheers

[1]: http://www.html5rocks.com/en/tutorials/offline/storage/#indexed-db

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing settings between Nautilus and Filechooser

[Bastien Nocera]

On Tue, 2012-11-20 at 18:51 -0800, Timothy Arceri wrote:
 Hi Guys,
 I'm looking a fixing
 https://bugzilla.gnome.org/show_bug.cgi?id=143599 (Share show hidden
 option with Nautilus). There is also a bug to do with sharing the
 single clicking settings however this is more complex so I thought I
 would see if I could get this one fixed first.
 It seem to be pretty easy fix as Nautilus already implements GSettings
 and so its just a matter of implementing this in file chooser also.
 
 Anyway my question before I start is should I be splitting out the
 common settings between Nautilus and filechooser into a different
 schema_id? Currently Nautilus has everything under
 org.gnome.nautilus.preferences if this is what I should do can you
 guys give me a hint as to what you think is a good id? 
 What do you think of org.gnome.file-view-preferences?

Add a schema to GTK+:
org.gtk.file-chooser show-hidden-files

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Mainloop debugging tool idea

[Bastien Nocera]

Em Mon, 2012-11-19 às 13:20 +, Chris Vine escreveu:
 On Mon, 19 Nov 2012 00:55:49 +0100
 Bastien Nocera had...@hadess.net wrote:
  I had some problems with gnome-shell's responsiveness on particularly
  dodgy hardware, and was wondering whether the shell was actually
  blocking at any point.
 
 I cannot answer your question about diagnosing this, and I am not sure
 if it counts as dodgy hardware, but since gnome-3.6 my netbook with
 1.6GHz Atom and 2GB of ram suffers from periods when the shell jams.

The dodgy epithet in this case is the pretty lame touchscrene which
seems to eat touches. And the machine is still running GNOME 3.4 from
Fedora 17 for now.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Mainloop debugging tool idea

[Bastien Nocera]

Heya,

I had some problems with gnome-shell's responsiveness on particularly
dodgy hardware, and was wondering whether the shell was actually
blocking at any point.

Came the idea of using of watchdog thread, based on the mainloop, which
would check for how long the mainloop was running a particular
iteration, and have to dump a backtrace if the main loop was blocking on
a particular task for more than X amount of time.

Does anyone have code like that available? If not, where would one plug
that code into the main loop code in gmain.c?

This would make testing problems like the ones split off from:
https://bugzilla.gnome.org/show_bug.cgi?id=687362
much easier.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: notifications in gtk

[Bastien Nocera]

A couple of comments:
- Would system software (eg. battery notification) be using parts of
this API, or would we need to come up with our own helpers on top of the
D-Bus API?
- gtk_application_get_notifications() doesn't mention that activated
notifications will still be present if recurring.
- For recurring notifications (say, alarms), we have no way of knowing
for which GDateTime/GTimeSpan the display was for.
- What are the application use cases?
  - Alarm? (wake me up at 7AM every weekday not at the week-end, and
don't forget to amend for daylight saving changes; snooze)
  - Timer? (notify me in 10 minutes)
  - Music Player track notifications? (always visible, setting of the
image after the notification was shown for cover art)
  - Meetings (every Tuesday at 2 PM, but only until the end of the year;
every week until end of time, but not those 2 weeks I'm on holidays)
- it's unclear to me how applications that do light processing from the
network might behave when not running and an event occurs (weather
application with notifications turned on for a storm for example), is
that something we could use to extend GtkApplication with. iOS can go
and poke at the network on behalf of applications for example.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Adding gtkparasite to gtk?

[Bastien Nocera]

Hey Christian,

On Wed, 2012-10-10 at 01:16 +0200, Rui Tiago Cação Matos wrote:
 Hi Christian,
 
 On 10 October 2012 01:10, Christian Hammond chip...@chipx86.com wrote:
  That's a fine goal and all, but I must ask why people haven't sent us these
  patches and worked around our repository? We're not dead, just the tool's
  been working fine for our needs and we haven't seen any activity or support
  around it.
 
  It would have been much appreciated to be contacted before assuming
  maintainership of the project. We weren't intending to relinquish that just
  yet, and would like to discuss it with people before that were to happen.

I've had a gtkparasite fork going with GTK+ 3.0 support for a year:
https://github.com/hadess/gtkparasite/commit/770db8faacde1aba9eaf3e45da6e39e27b565859

And the requests to get GTK+ 3.0 support committed have fallen on deaf
ears:
http://code.google.com/p/gtkparasite/issues/detail?id=18

So the patches have been sent, just that they've been ignored.

 Oh, I'm not claiming maintainership on it at all. But you're right
 that I should have contacted you first about this, my apologies.
 
 It's just that people have been doing gtkparasite forks all over the
 internet and today I decided to finally push all the fixes I knew to a
 place where a lot of interested parties can share the maintenance
 burden.
 
 If you're not happy on having it in git.gnome.org we can take it back
 down I guess.

Or we can rename it and carry on using a single shared git repo so we
don't block on a single person for maintenance.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib branched

[Bastien Nocera]

On Wed, 2012-10-03 at 08:20 +0200, David Nečas wrote:
 On Wed, Oct 03, 2012 at 12:35:57AM -0400, Matthias Clasen wrote:
  I have now created a glib-2-34 branch, so master is now open for
  ... GTask ...
 
 Is this also intended, at least in the future, for things like
 long-running calculations that need some monitoring/reporting of
 progress not just the final result?  I mean, some monitoring can be
 always implemented on top of GTask but once I get my hands dirty with
 explicit asynchronous communication I can implement that directly on top
 of GThread as well.  I always look hopefully at the asynchronous
 interfaces in GLib with hope, however, the intended use cases do not
 seem to match mine...

Popping results out of a running thread is easy to do.

Create a GAsyncQueue.
In your thread, add your results to the queue, a schedule a function to
be called from the main loop with g_idle_add().

In your g_idle_add() callback, use g_async_queue_pop() to get the
results, and free your results.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir

[Bastien Nocera]

Em Thu, 2012-09-27 às 12:42 +0700, Ivan Shmakov escreveu:
   [This issue is currently being discussed in debian-devel@ [0],
   and it was suggested to bring it to gtk-devel-list@ as well.]

What's the TL;DR?

It's a very long mail, weirdly formatted, and I don't understand what
you expect GLib to do vs. what it does now.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ meetup at Guadec

[Bastien Nocera]

On Tue, 2012-07-31 at 00:20 +0200, Philip Chimento wrote:
 On Sat, Jul 28, 2012 at 3:30 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
  - We need to document how one extends GTK+ itself (eg how to create a
  new widget class), to make it easier for new people to get involved
  (I'll try to get this started)
 
 I wrote a tutorial on extending GtkContainer in C
 (http://ptomato.name/advanced-gtk-techniques/html/custom-container.html).
 It's even current for 3.0. I wrote it for the advanced developer
 rather than the new one, but perhaps you can recycle some of it.

I think Matthias' comment has more to do with:
- Adding the C files and headers to the correct sections of the
Makefile.am
- Making sure all the functions are documented
- Add the filenames and sections to the API docs
- Adding the new symbols to be exported
- Adding a test application or widget to gtk-demo
- Adding the AVAILABLE_IN... macro to the public headers

etc.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

[Bastien Nocera]

On Tue, 2012-06-26 at 16:02 +0300, Mark Vender wrote:
 Hello,
 
 Is there any reason why preprocessor macros are used to define the GDK 
 keysym constants in gdk/gdkkeysyms.h instead of an enum? For what it's 
 worth, there's no advantage in using macros. They are inconsistent with 
 other enumerations within GTK+ library, which universally use enums. An 
 enum offers better scoping and would be easier to wrap on the C++ side.
 
 If there's support, I could prepare a patch that converts the keysym 
 macros to an enum. From the user's point of view enum and macro 
 constants are equivalent, so there's no need to wait for an API/ABI break.

If we used enums, we would restrict the keysyms to the declared values.
It's possible for keysyms not to have a constant declared in GDK, for
example when a new keysym has been added to X.org but GDK hasn't been
updated yet. So using enums instead of constants is detrimental to
applications and GTK+ not breaking when keysyms get added.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

[Bastien Nocera]

On 26 Jun 2012, at 22:56, Mark Vender markv...@yahoo.co.uk wrote:
 which has no chance of negative effects. Even if we add values, they are 
 still stored in an int, that is, GdkKeySym is never used.

If its definition is public, it will be used.

 Thus, in my opinion, even a small improvement is worthwhile.

I don't see how it improves anything. It changes things certainly, but you've 
yet to explain how it improves upon well tested, automated code.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Adding gtkparasite to gtk?

[Bastien Nocera]

On Fri, 2012-04-27 at 10:10 -0400, D.H. Bahr wrote:
 On a similar hand: is there a Gtk(3)Parasite yet??

In this thread...
http://thread.gmane.org/gmane.comp.gnome.gtk+.devel.general/22127/focus=22139

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Adding gtkparasite to gtk?

[Bastien Nocera]

Em Fri, 2012-02-17 às 03:14 +, Alberto Ruiz escreveu:
 Hey,
 
 
 Has anyone stepped up to port it to Gtk+3?

Numerous times. And my hack of a port is even in jhbuild.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Multitouch review 2: press-and-hold

[Bastien Nocera]

On Thu, 2012-02-02 at 19:43 +0100, Carlos Garnacho wrote:
snip
 Also, most widgets that might want press-and-hold won't listen by
 default to touch events, so they'll just receive events from the
 emulating touch anyway.

Wouldn't a WebKit view use both (zooming vs. text selection)?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Multitouch review 2: press-and-hold

[Bastien Nocera]

On Tue, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:
 API:
 
 GtkWidget::press-and-hold
 GTK_PRESS_AND_HOLD_{QUERY,TRIGGER,CANCEL}
 GTK_STYLE_CLASS_PRESS_AND_HOLD style class
 GtkSettings::gtk-press-and-hold-timeout setting
 
 This feature has a long history going back to 2005 and Hildon [1][2].
 
 The way it works is that  ::press-and-hold is emitted upon button
 press (only button 1), scroll or touch events with an action of
 GTK_PRESS_AND_HOLD_QUERY. Widgets have to opt-in to press-and-hold by
 handling that and returning TRUE. GTK+ then plays the press-and-hold
 animation (which is adapted to whether you are using a tiny cursor or
 a fat thumb). If you hold still until the time determined by
 gtk-press-and-hold-timeout has passed, ::press-and-hold is emitted
 again with the TRIGGER action, and widgets are expected to handle that
 by doing whatever action they want to tie to long presses. If the
 press-and-hold is canceled because the pointer was moved (beyond the
 drag threshold), ::press-and-hold is emitted with the CANCEL action.
 If the widget goes away while the press-and-hold animation is running,
 it gets removed and cleaned up.
 
 One interesting aspect here is that ::press-and-hold is emitted on the
 target widget of the event before the capture phase. There is a
 comment in the code that explains that this is 'so a parent capturing
 events doesn't delay nor prevent a child from doing the press-and-hold
 action'.
 
 Questions, comments:

I still think that the press and hold animation has no place here. Apart
from Windows, I've not seen any touch or stylus devices use this, and I
seriously doubt its usefulness (versus it looking tacky, out of place,
etc.).

Can we please get the code writers' reasoning behind having this
animation? What do the designers think? Should it be something the theme
chooses to implement (so that the Windows theme would use the Windows
animation for that for example)?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Multitouch review 3: kinetic scrolling

[Bastien Nocera]

On Thu, 2012-02-02 at 00:48 +0100, Carlos Garnacho wrote:
 Hey :),
 
 On mié, 2012-02-01 at 23:37 +0100, Florian Müllner wrote:
  On mié, 2012-02-01 at 08:00 -0500, Matthias Clasen wrote:
   - Restricting kinetic scrolling to touch devices is correct,
   experience-wise
  
  Is it? I don't think Windows 8's Metro interface limits kinetic
  scrolling to touch devices (but I may be misremembering here), and Allan
  explicitly mentions kinetic scrolling with mouse input[0].
  To me it sounds like a desirable feature for non-touch input in some
  situations like missing scroll wheel or crappy touchpads.
 
 My feeling is that mixing interaction paradigms is a wrong thing to do,
 kinetic scrolling inherently comes with its oddities wrt selection and
 DnD, those are kinda expected and sorted out in a way or another on
 other touch platforms, but bringing those changes to mice users may be
 frustrating.
 
 A more generic principle I agree we should follow is direct
 manipulation, in the case of scrolling:
 
 * On touch devices: the content follows your finger
 * On touchpads: the content scrolls smoothly, proportionally to the
 finger(s) movement/velocity in the touchpad [1]. Note that the synaptics
 driver already does it's sort of kinetic scrolling itself.
 * On mice: you move via the scrollbar

I've had those same discussions with Jon when we were discussing
Scrolling [1] and, despite agreeing with you when we started the
conversation, I think that we should at least have the ability to
experiment with that behaviour for non-touch, if only to integrate with
platforms that use kinetic scrolling with non-touch.

Cheers

[1]: https://live.gnome.org/GnomeOS/Design/Whiteboards/Scrolling

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Bastien Nocera]

On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote:
 Hopefully this isn't getting old, but I'm sort of just throwing these
 out there as I think of them.
 
snip
 BACKGROUND OPACITY
 It would be nice to have the ability to alter the opacity of a window
 without altering the opacity of GdkWindow'd widgets inside it. This is
 useful for utility windows that float over a primary window. Right now,
 you have to handle changes with the visual and/or screen and modify the
 background yourself. This breaks possible theming and is tedious.
 http://www.pixelmator.com/ is a good example of why this might be
 useful.

Had that problem in the Wacom calibration screen. I wanted the elements
to be opaque but on a translucent dark background. It wasn't possible
without resorting to hacks (such as having 2 windows, one translucent
with the black background, one with the opaque elements on a transparent
background).

Do you mind filing a bug about that?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Bastien Nocera]

On Fri, 2012-01-13 at 15:04 +, Bastien Nocera wrote:
 On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote:
  On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
 snip
   MENU BUTTON
   A GtkButton that shows a menu when clicked (and handles positioning,
   etc). Some would just use a combobox, but I find them pretty different.
   You'll find this sort of menu button in various VMware products on
   Linux. (I know the fullscreen toolbar used to have it at least).
  
  Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to
  do but would be nice to have in a single place. Also, it needs some help
  from the theme to look good, like adwaita does here:
  http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705
 
 Totem has a menu button as well, look for popup_button in:
 http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c
 
 Hacky.

Filed https://bugzilla.gnome.org/show_bug.cgi?id=668013

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Bastien Nocera]

On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote:
 On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
snip
  MENU BUTTON
  A GtkButton that shows a menu when clicked (and handles positioning,
  etc). Some would just use a combobox, but I find them pretty different.
  You'll find this sort of menu button in various VMware products on
  Linux. (I know the fullscreen toolbar used to have it at least).
 
 Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to
 do but would be nice to have in a single place. Also, it needs some help
 from the theme to look good, like adwaita does here:
 http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705

Totem has a menu button as well, look for popup_button in:
http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c

Hacky.

  WIDGET STACK
  Like a notebook with no tabs or decoration. You push and pop widgets
  on and off the stack. This is the navigational structure often found on
  iOS. The reason I think abstracting it might make sense is more about
  animating between widgets once Gtk starts landing animation (post
  clutter integration obviously). It would be great if this nicely
  integrated with a navigation bar type widget. Here[3] is a video of
  some crappy animation code I wrote to do this.
 
 Not only does it help with animation, but its also nice in terms of size
 allocation. Often you want a set of widgets that can temporarily change
 into another set (for instance during editing) without causing a UI
 reflow. Having a widget stack like this helps with this size allocation
 handling.

This is a problem in a number of control-center panels where we want
widgets not to move when switching from one item's properties to
another. Animation isn't the problem here, the problem is hide it but
still take space in the layout.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib resource framework

[Bastien Nocera]

Em Thu, 2011-12-22 às 08:49 +0100, Enrico Weigelt escreveu:
 * Hub Figui?re hfigui...@teaser.fr schrieb:
 
  Maybe we could actually support bundles like it is done on MacOS.
 
 ./configure --prefix=foo ?

It doesn't magically make libraries and binaries relocatable.

I tried reading this thread and ended having to read your dismissive,
and usually utterly wrong, rants. Just don't post, it'll save me some
reading, and spare your blushes.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GVariant singletons

[Bastien Nocera]

On Thu, 2011-12-08 at 10:15 +, Simon McVittie wrote:
 On Wed, 07 Dec 2011 at 20:06:32 +0100, Mikkel Kamstrup Erlandsen wrote:
  And yes, yes, I know this is another slap in the face for the
  valgrind camp. Sorry!
 
 Commit a Valgrind suppressions file to GLib and all will be forgiven :-)
 
 (But seriously: would people be interested in GLib having/installing a
 suppressions file that silences many of the one-per-process
 deliberate leaks? We have an incomplete one in telepathy-glib that would
 be a good start.)

A way to disable the use of those singletons would also be good, as it
would mean a valgrind warning when you unref the last reference to the
singleton.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 3.3.4 released

[Bastien Nocera]

On Mon, 2011-11-21 at 20:03 -0500, Matthias Clasen wrote:
 * GtkApplication no longer uses gtk_main internally 

What do we replace g_main_quit() with then?

The documentation for g_application_release() doesn't inspire
confidence:
http://developer.gnome.org/gio/unstable/GApplication.html#g-application-release

g_object_unref()? If g_application_release() is the correct call (as the
docs for g_application_set_inactivity_timeout() [1] makes it sound,
could the docs please be changed?

[1]:
http://developer.gnome.org/gio/unstable/GApplication.html#g-application-set-inactivity-timeout

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New modes for GtkProgressBar

[Bastien Nocera]

On Mon, 2011-10-31 at 17:44 +0100, Milan Bouchet-Valat wrote:
 Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit :
 
  First mode would be an activity mode which could be used for showing
  ongoing indeterminate activity
 ...and wouldn't you use a GtkSpinner for this? ;-)

Or the activity mode of GtkProgressBar, if you want to switch that
progress bar to a determinate progress. See gtk_progress_bar_pulse().

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: New modes for GtkProgressBar

[Bastien Nocera]

On Mon, 2011-10-31 at 17:44 +0100, Milan Bouchet-Valat wrote:
 Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit :
 
  First mode would be an activity mode which could be used for showing
  ongoing indeterminate activity
 ...and wouldn't you use a GtkSpinner for this? ;-)

Or the activity mode of GtkProgressBar, if you want to switch that
progress bar to a determinate progress. See gtk_progress_bar_pulse().

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk-2-24 has new strings

[Bastien Nocera]

On Tue, 2011-07-12 at 18:46 -0500, Federico Mena Quintero wrote:
 Dear translators,
 
 I've just pushed some changes to the file chooser in the gtk+ module,
 specifically to the gtk-2-24 branch.  Although right now the focus is
 3.x, we will likely have another release in the 2.24.x series for GTK+.
 Please update your translations there :)
 
 (The idea is to have the file chooser as similar as possible between
 2.24.x and 3.x, so that even apps which still require GTK+ 2 will get
 all the goodness - and users will get consistent behavior.)

But why do that in stable releases? Unless there's a very very (very
very) good reason to break the freeze, the stable branches should only
see bug fixes. Why was this pushed to stable branches?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib: libffi dependency

[Bastien Nocera]

On Fri, 2011-05-06 at 11:02 -0400, David Zeuthen wrote:
 Hi,
 
 On Fri, May 6, 2011 at 10:51 AM, Maarten Bosmans mkbosm...@gmail.com wrote:
  Is it possible to make that an optional dependency? e.g. --with-libffi
  or --enable-gdbus-codegen
 
 No, this dependency is part of the ABI, the newly added
 g_cclosure_marshal_generic() function will not work without libffi. I
 think a better question would be why did it take us so long to add
 this?.

Can I get rid of my marshallers yet? :)

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: libegg: Removing old directories

[Bastien Nocera]

On Tue, 2011-03-22 at 13:03 +1300, John Stowers wrote:
 On Mon, 2011-03-21 at 10:51 +0100, Murray Cumming wrote:
  On Sun, 2011-03-20 at 20:03 -0400, Matthias Clasen wrote:
   On Fri, Mar 18, 2011 at 6:42 PM, Murray Cumming murr...@murrayc.com 
   wrote:
libegg has lots of directories that have just a README saying how the
code has successfully moved into GTK+. But that's mostly old news now.
If there's no objection then I'll remove the directories so it's easier
to see at a glance what's still interesting.
   
   
   Sounds fine to me.
 
 While we are talking about egg.
 
 I recently copied eggaccelerators.{c,h} and tomboykeybinder-ish for
 global keybinding in a project.
 
 I wonder if these are worth having in egg. eggaccelerators.{c,h} gets
 copied all over the place but the most up-to-date copy lives in
 gnome-control-center currently [1].
 
 tomboykeybinder too exists in many different forms, copied into at least
 tomboy [2], guake terminal and kupfer (which also ships bindings for
 it).
 
 Would anyone be interested in these in egg [3]?

In the future, we'll want to be able to capture keys from one place,
either gnome-settings-daemon or gnome-shell, to avoid clashes, work
properly in the overview mode for some, etc.

If all those applications are supposed to be integrated in GNOME, then
it would be better to extend gnome-settings-daemon to support that (see
https://bugzilla.gnome.org/show_bug.cgi?id=525428 ) rather than having
those copy-pasting the code in each module.

Furthermore, libegg is supposed to be a stop-gap for API to be tested
before it goes into GTK+, not a random dumping ground, and I really
don't think we want to see this code going into GTK+.

Cheers

 [1]
 http://git.gnome.org/browse/gnome-control-center/tree/panels/common/eggaccelerators.h
 [2] http://git.gnome.org/browse/tomboy/tree/libtomboy/tomboykeybinder.h
 [3] I might GObject-ify tomboykeybinder first, so it is introspectable
 
 
 ___
 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