Re: Alternative to swallow GtkContainer into GtkWidget

[Jasper St. Pierre]

What you miss is that GtkWidget already has container-like behaviors with
gtk_widget_set_parent. In fact, the whole API has been awkward. GtkWidgets
themselves can have children. GtkContainer is a "convention" interface for
a way of manipulating an object that can have children. Not every widget
that has children has to implement GtkContainer (though there *are* some
features that won't work automatically, like drawing of children, since
gtkwidget.c often has checks for GTK_IS_CONTAINER).

It makes sense to me to merge these two APIs so we don't have this
impedance mismatch.

On Tue, Aug 2, 2016 at 10:57 AM, Sébastien Wilmet  wrote:

> Hi,
>
> I see at:
> https://wiki.gnome.org/Hackfests/GTK2016/Day1
>
> That there is maybe a plan to merge GtkContainer into GtkWidget.
>
> From a software engineering point of view, this looks like a bit scary
> to me.
>
> $ wc -l gtkwidget.c
> 17510 gtkwidget.c
> $ wc -l gtkcontainer.c
> 3880 gtkcontainer.c
>
> GtkWidget can already be considered a God Class.
>
> GTK+ is not without bugs. It is already a challenge to maintain a good
> stability for a project as big as GTK+. So IMHO the trend should be to
> extract some code into new, smaller classes. When there are too many
> instance variables, it is more complicated to work on the code and
> ensure that what we change is correct. With small classes, we can be
> more confident that the code is correct.
>
> But I think you know well all of this.
>
> So, instead of inheritance, the alternative is of course composition. A
> GtkWidget could use internally a reference to a GtkContainer-like
> utility object. And the real GtkContainer subclass could use the same
> utility class internally. But using the GtkContainer utility by
> composition would require a fair amount of boilerplate, when overriding
> the GtkWidget vfuncs. But I'm sure there is a solution to have less
> boilerplace. E.g. another utility class that is setup in class_init()
> that handles the proxy to the internal container object.
>
> Just my 2 cents, maybe it's a crack idea. But at least I've shared my
> thoughts. I think it's possible to split out more classes, writing more
> utilities to share code between widgets, and being able to implement new
> widgets more easily. GtkEventController is a good example.
>
> --
> Sébastien
> ___
> 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

Re: Gtk+4.0

[Jasper St. Pierre]

On Sun, Jul 10, 2016 at 1:28 PM,  wrote:

> On Sat, Jul 9, 2016 at 1:14 PM Peter Weber 
> wrote:
>
>> Hi!
>>
>> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote:
>>
>> > I'm expecting this will become less and less of a problem as apps move
>> > to Flatpak as a means of distribution.
>>
>> Uhuuu. I'm sorry, but this is bad.
>>
>> This mixes two completely different problems together, packaging and a
>> toolkit. So enforcing Flatpak on distributions, developers and users
>> should solve a problem with Gtk+?
>>
>
> No, nothing about any of this proposal forces people to use Flatpak.
>
> The problem Emilio mentioned was,
>
> > some third party apps pick a dependency on the vte for GTK+ 4.2 but
> don't update it for GTK+ 4.4, as then distros would need to ship an
> increasing number of versions that are unlikely to get any support upstream.
>
> In my opinion, the expectation is that app developers who sign on to the
> unstable series will see it through until the next long-term stable
> release, and not abandon development while still targeting an unstable
> release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2,
> VTE-for-GTK-4.4, etc. because apps are all stuck at different versions.
>
> Of course, nothing is stopping developers from doing that anyway. The same
> way nothing is stopping me right now from putting this line in my app's
> configure.ac:
> PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20])
> However, if I did that then any distros trying to package it would quite
> rightly complain.
>
> I'm saying that if an app developer feels the need to do that, then they
> will be better off targeting a Flatpak runtime.
>
> Having said all this, I'm thinking about sketching out a proposal that
> doubles down on Flatpak like Jasper was suggesting. Paradoxically I think
> it might seem more palatable to more people... more updates later.
>

I intended my proposal as an strawman explanation that I thought was
obviously silly. It wasn't a serious proposal, and I don't think it's the
correct direction for the project to move in.


> Regards,
> Philip C
>
> ___
> 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

Re: Gtk+4.0

[Jasper St. Pierre]

On Sat, Jul 9, 2016 at 12:36 PM, <philip.chime...@gmail.com> wrote:

> On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>
>> On Sat, Jul 9, 2016 at 12:06 PM, <philip.chime...@gmail.com> wrote:
>>
>>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort <
>>> poch...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 21/06/16 16:26, Peter Weber wrote:
>>>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
>>>> to
>>>> > write about my thoughts, in a careful way. In the first moment, I
>>>> thought
>>>> > this is a good idea and just the numbering is misleading. Stability
>>>> is what
>>>> > developers want, we need it, we love it. With a few days distance,
>>>> > numbering is just a small issue, I see this now entirely different and
>>>> > three major issues:
>>>>
>>>> Here are some thoughts I have about all this, from a downstream
>>>> maintainer POV.
>>>>
>>>
>>> Thanks! It's good to get opinions from all over the place.
>>>
>>> My concern with this new scheme is that GTK+ libraries will have to bump
>>>> the
>>>> soname every 6 months (if they want to support the latest GTK+). That
>>>> can be
>>>> manageable for say vte or gnome-desktop, although it may be bad if some
>>>> third
>>>> party apps pick a dependency on the vte for GTK+ 4.2 but don't update
>>>> it for
>>>> GTK+ 4.4, as then distros would need to ship an increasing number of
>>>> versions
>>>> that are unlikely to get any support upstream.
>>>>
>>>
>>> I'm expecting this will become less and less of a problem as apps move
>>> to Flatpak as a means of distribution.
>>>
>>
>> How does Flatpak solve this problem?
>>
>
> If an app was released as a Flatpak, it would target a Flatpak runtime.
> There would not be a choice between targeting VTE-for-GTK-4.2 or
> VTE-for-GTK-4.4, and so distributions would not need to ship a
> VTE-for-GTK-4.2 straggler that some app was still targeting.
>

Er, so, with this model, we're working around the fact that we're breaking
ABI without changing the soname? If we're relying on Flatpak to solve this,
why bother bumping the soname at all and releasing new stable versions?
It's effectively no different from having GTK+ 4.8, since it still breaks
every release.

In fact, this could be a new plan. If we double down on Flatpak, then we
could simply not bump soname / major version, leave it at 4, break ABI
every point release, and have the ".6-multiple" releases be LTS releases
which are "maintained more than most".

This doesn't solve the fact that application development is more difficult
inside a Flatpak, and not all application authors are going to have to want
to maintain Flatpaks and an infrastructure to build and test them.


> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>>>>
>>>
>>> That does seem to point to a problem — if an app uses Library X which
>>> does follow the unstable GTK series, and Library Y which doesn't, then the
>>> app developer is forced to stick to the stable series of GTK and an old
>>> version of Library X in order to accommodate Library Y.
>>>
>>> Any thoughts?
>>>
>>> I feel like the X.[024] releases are just snapshots of a development
>>>> branch,
>>>> with X.6 being the stable release, and I wonder if X.[024] shouldn't
>>>> clearly be
>>>> labelled as that, regardless of what version number is chosen (be it
>>>> 4.0,
>>>> 3.99.0, 4.0beta1 or whatever).
>>>>
>>>
>>> In my opinion the label "unstable release" communicates exactly that.
>>> I'm not sure what "development branch" communicates that "unstable release"
>>> doesn't?
>>>
>>
>> The convention in GNOME up until know has been that even numbers are for
>> stable releases, and odd ones are for unstable releases. I didn't know GTK+
>> 4.0 would be considered an unstable release.
>>
>
> There are several different version numbering schemes proposed on this
> wiki page [1]. I was referring to the term "unstable release" versus
> "development branch".
>

The messaging here is very confused and inconsistent, and I think that's
one of our major stumbling blocks here. I would be happier with "4.0alpha",
"4.0beta", "4.0rc", "4.0final" or similar, rather than the .[024] which
imply stability with our current version naming scheme.


> [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
>

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

Re: Gtk+4.0

[Jasper St. Pierre]

On Sat, Jul 9, 2016 at 12:06 PM,  wrote:

> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
> wrote:
>
>> Hi,
>>
>> On 21/06/16 16:26, Peter Weber wrote:
>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> > write about my thoughts, in a careful way. In the first moment, I
>> thought
>> > this is a good idea and just the numbering is misleading. Stability is
>> what
>> > developers want, we need it, we love it. With a few days distance,
>> > numbering is just a small issue, I see this now entirely different and
>> > three major issues:
>>
>> Here are some thoughts I have about all this, from a downstream
>> maintainer POV.
>>
>
> Thanks! It's good to get opinions from all over the place.
>
> My concern with this new scheme is that GTK+ libraries will have to bump
>> the
>> soname every 6 months (if they want to support the latest GTK+). That can
>> be
>> manageable for say vte or gnome-desktop, although it may be bad if some
>> third
>> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it
>> for
>> GTK+ 4.4, as then distros would need to ship an increasing number of
>> versions
>> that are unlikely to get any support upstream.
>>
>
> I'm expecting this will become less and less of a problem as apps move to
> Flatpak as a means of distribution.
>

How does Flatpak solve this problem?


> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>>
>
> That does seem to point to a problem — if an app uses Library X which does
> follow the unstable GTK series, and Library Y which doesn't, then the app
> developer is forced to stick to the stable series of GTK and an old version
> of Library X in order to accommodate Library Y.
>
> Any thoughts?
>
> I feel like the X.[024] releases are just snapshots of a development
>> branch,
>> with X.6 being the stable release, and I wonder if X.[024] shouldn't
>> clearly be
>> labelled as that, regardless of what version number is chosen (be it 4.0,
>> 3.99.0, 4.0beta1 or whatever).
>>
>
> In my opinion the label "unstable release" communicates exactly that. I'm
> not sure what "development branch" communicates that "unstable release"
> doesn't?
>

The convention in GNOME up until know has been that even numbers are for
stable releases, and odd ones are for unstable releases. I didn't know GTK+
4.0 would be considered an unstable release.


> Regards,
> Philip C
>
> ___
> 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

Re: G_UTF8String: Boxed Type Proposal

[Jasper St. Pierre]

The major issue is that "Unicode character" doesn't have a good
definition. The most likely definition is a "Unicode code point",
however, Windows uses "Unicode character" to mean a UTF-16 byte
sequence, which means that any code point above the Basic Multilingual
Plane is really composed of two "Unicode characters", which are, of
course, surrogate pairs.

This confusion also extends to JavaScript, which composes its String
type of "characters" which are actually UTF-16 values. You can see
this with astral plane characters like emoji:

> "".length
2
> "" == "\uD83D\uDCA9"
true

As an example of a grapheme cluster without a precomposed,
single-code-point form, look at the Regional Indicators, which were
the politics-free way to add flag symbols to the Emoji block. There
are 26 code points, "A" through "Z", and when put next to each other
in language codes, like "", it's expected that certain
combinations will show up as flags, without explicitly defining which
one. But a sequence of regional indicator code points is entirely one
grapheme cluster.

Go drops the term "character" or "code point" entirely and opts for
"rune" instead, which is just a 32-bit value.

Swift has an even crazier "Character" type [0], which can hold an
entire Grapheme Cluster, rather than just a single code-point. This
actually means that Swift's "Character" type is of potentially
infinite length, since Regional Indicators aren't capped at a maximum
of two code points.

Unicode is fun.

[0] 
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/StringsAndCharacters.html#//apple_ref/doc/uid/TP40014097-CH7-ID285

On Thu, Mar 17, 2016 at 12:42 PM, Matthias Clasen
<matthias.cla...@gmail.com> wrote:
> On Thu, Mar 17, 2016 at 2:26 PM, Jasper St. Pierre
> <jstpie...@mecheye.net> wrote:
>
>> I'll also ask what "character" means in this case, even though I know
>> glib also has the same confusion. Are you talking about the number of
>> Unicode code points in the string, or the number of grapheme clusters,
>> as defined by Unicode TR29 [0]? The number of code points isn't useful
>> for editing in all cases, even after NFC normalization. Some grapheme
>> clusters just don't have a single code-point representation.
>
> I don't think there is any confusion in glib about this, really.
> There is no mention of graphemes in GLib at all, its all just
> characters. If you want graphemes, you need pango.



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

Re: G_UTF8String: Boxed Type Proposal

[Jasper St. Pierre]

I'll also ask what "character" means in this case, even though I know
glib also has the same confusion. Are you talking about the number of
Unicode code points in the string, or the number of grapheme clusters,
as defined by Unicode TR29 [0]? The number of code points isn't useful
for editing in all cases, even after NFC normalization. Some grapheme
clusters just don't have a single code-point representation.

[0] http://unicode.org/reports/tr29/

On Thu, Mar 17, 2016 at 11:18 AM, Randall Sawyer
 wrote:
> On 03/17/2016 10:39 AM, Randall Sawyer wrote:
>>
>>
>> On 03/17/2016 09:30 AM, Matthias Clasen wrote:

 I believe that you haven't found such a proposal because most people
 don't see much use in a separate boxed type for utf8 strings. Every
 string we pass around in GLib and GTK+, and every char * in their APIs
 is expected to be in utf8. The few exceptions to this rule are
 explicitly documented.
>>>
>>> GLib already provides a number of utilities for dealing with utf8
>>> strings in terms of characters, such as g_utf8_strlen,
>>> g_utf8_substring, g_utf8_find_next/prev_char. We can certainly discuss
>>> adding to that list, if there are glaring omissions.
>>
>> Here is the vision: Once raw string data - or gunichar value - has been
>> passed and validated into the construction of a "G_UTF8String" structure,
>> then contents of two-or-more of these can be easily combined without the
>> need for additional measuring or validating.
>
>
> Alright Matthias, after your thoughtful response, I have come to the
> following conclusion:  When considering management of dynamically allocated
> UTF-8 strings, there are actually two points to consider: 1) Whether the
> byte sequences are valid per IETF RFC 3629 Section 4 - and - 2) The number
> of distinct characters represented in the string vs. the total number of
> bytes used to represent these.
>
> If someone were to write a widget library or an application using libraries
> which ensure valid UTF-8 as input - Gdk key-press events and GtkIMContexts
> for example - then it wouldn't make sense to run those strings through yet
> another course of validation. That addresses the first issue.
>
> There is still the question of character length vs. byte length.
>
> Therefore - from what you have told me - I will be sure to present methods
> which feature validation as an option and not as the rule.
>
> Thank you.
>
>
>
> ___
> 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

Re: Application id, XDG App, and you.

[Jasper St. Pierre]

Well, having "Aliases" means that to look up "gnome-clocks.desktop",
we would have to parse through and read every desktop file at startup,
for anything that wanted to match, since we still don't have a
.desktop file cache. But it would help in the reverse case -- when the
file gets renamed, also check out the aliases. But we also have the
reverse merging problem (what if there's multiple aliases and each one
has a different policy? Yikes)

At some point I should probably make a proposal to xdg-list. I think
we should probably also have a .desktop file cache as a general
component so we can make proposals like this without having to worry
about implementation cost. I know desrt was working on this at some
point, but I don't know how far she got with it.

On Thu, Feb 4, 2016 at 9:02 AM, Simon McVittie
<simon.mcvit...@collabora.co.uk> wrote:
> On 04/02/16 05:23, Jasper St. Pierre wrote:
>> One thing I've wanted in the past is a very simple file to allow
>> someone to declare an alias for an application. So GNOME Clocks would
>> ship both an org.gnome.clocks.desktop and a gnome-clocks.desktop, the
>> latter looking something like:
>>
>> [Desktop Entry]
>> AliasFor=org.gnome.clocks.desktop
>
> Or maybe org.gnome.clocks.desktop could grow a key
>
> Aliases=gnome-clocks.desktop;
>
> or something?
>
> This seems like something to take to the xdg (not -app) mailing list and
> the main Desktop Entry Specification document.
>
> --
> Simon McVittie
> Collabora Ltd. <http://www.collabora.com/>



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

Re: Application id, XDG App, and you.

[Jasper St. Pierre]

There's one giant hole here, which is that the app ID is used as a
primary key for lots of things, like Favorited Applications, Preferred
MIME Type Handlers, Notification and Privacy settings and such, and a
lot more.

Currently, we get around Favorited Applications in GNOME by having a
giant hashmap of changes, but this isn't scalable.

https://git.gnome.org/browse/gnome-shell/tree/js/ui/appFavorites.js#n9

One thing I've wanted in the past is a very simple file to allow
someone to declare an alias for an application. So GNOME Clocks would
ship both an org.gnome.clocks.desktop and a gnome-clocks.desktop, the
latter looking something like:

[Desktop Entry]
AliasFor=org.gnome.clocks.desktop

Unless this is also taken care of in another way by xdg-app.
Otherwise, it's really unfortunate and kinda broken that we don't have
a good migration path here, especially as we're asking a lot of people
to make yet *another* change.

Also, we should probably update GApplication to emit a warning when
passing it an invalid ID like this.

On Tue, Feb 2, 2016 at 4:58 AM, Simon McVittie
 wrote:
> On 02/02/16 12:04, Emmanuele Bassi wrote:
>> In other words, if your app is named:
>>
>>   org.gnome.foo-bar
>>
>> please consider renaming it to:
>>
>>   org.gnome.FooBar
>
> Or org.gnome.foo_bar would also be fine.
>
> Similarly, if you own awesome-apps.example.com and want to use it for
> application IDs or D-Bus names, they should probably be called something
> like com.example.awesome_apps.MyApp.
>
> --
> Simon McVittie
> Collabora Ltd. 
>
> ___
> 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

Re: g_error_free() warning on null pointer

[Jasper St. Pierre]

But if you have an error, shouldn't you either want to a) handle it,
or b) propagate it up?

I can't imagine a case where you want to free a GError without first
attempting to handle it. If you do want to ignore errors, you can
simply pass NULL for a GError ** pointer to a function, since those
should always handle NULL correctly.

On Sat, Aug 29, 2015 at 11:13 AM, Michael McConville
mmcco...@sccs.swarthmore.edu wrote:
 Nicolas George wrote:
 But maybe I am forgetting another case: can you imagine a code snippet
 where g_error_free(error) would make sense with error == NULL?

 I may have already mentioned this, but the simplest example is just
 adding a g_error_free() at the end of a function when adding a GError*
 declaration at the beginning. This prevents an irrelevant line from
 cluttering the error-handling logic and makes it more trivially obvious
 to auditors that there isn't a memory leak.
 ___
 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

Re: Null check in g_hash_table_lookup()

[Jasper St. Pierre]

It will fix it in that it will warn and then return NULL (and only if
you build glib with the flag that turns those return_val_if_fail's on,
which it does by default), but it's considered improper behavior to
call g_hash_table_lookup with a NULL key.

On Sat, Aug 15, 2015 at 1:27 PM, Michael McConville
mmcco...@sccs.swarthmore.edu wrote:
 Currently, if you pass a null key pointer to g_hash_table_lookup(), it
 will sometimes segfault in g_str_hash(). This often happened in the
 Pidgin development tip until we added this check:

 https://hg.pidgin.im/pidgin/main/rev/7e57fa4513f4

 I was running GLib 2.44.1 on OpenBSD 5.8 (-current).

 It seems like adding:

 g_return_val_if_fail (key != NULL, NULL);

 Here:

 https://github.com/GNOME/glib/blob/master/glib/ghash.c#L1145

 Should fix it. However, it seems saliently missing, so maybe I'm
 misunderstanding and NULL can be a valid key pointer.
 ___
 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

Re: g_error_free() warning on null pointer

[Jasper St. Pierre]

Lots of things in GLib fail when passed a NULL pointer, like g_object_unref.

The idea is that passing a NULL pointer is probably a sign of a bug
somewhere, so you shouldn't do it. While the C standard's free() is
NULL-safe, I'd say that this is quite strange for the C standard,
since any other invalid pointer passed to free() would (most likely,
though yes, implementation-defined) crash.

On Sat, Aug 15, 2015 at 1:28 PM, Michael McConville
mmcco...@sccs.swarthmore.edu wrote:
 If you call g_error_free() on a null pointer, you'll see something like
 this:

 (process:345): GLib-CRITICAL **: g_error_free: assertion 'error != NULL' 
 failed

 However, POSIX specifies:

 If ptr is a null pointer, no action shall occur.

 http://pubs.opengroup.org/onlinepubs/009695399/functions/free.html

 From what I've seen, all major Unices comply with this and mention it in
 their man page. While printing that warning may not be a program action,
 it's definitely disconcerting and dilutes debug logs. It seems to me
 that POSIX intends free() to be used in situations in which the pointer
 may be null. This is common practice.

 Additionally, g_clear_error() doesn't print a warning when passed NULL.

 Fixing this would just involve removing this line:

 https://github.com/GNOME/glib/blob/master/glib/gerror.c#L467

 Thoughts?
 ___
 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

Re: Missing dependencies in GLib build system

[Jasper St. Pierre]

Hi,

The first specifies source files shipped with the tarball. It should
be extremely difficult to get into this position, so we rarely specify
files in this way.

The second looks wrong -- libgio-2.0.la should have libgmodule-2.0.la
as a dependency. None of the tools use libgmodule directly, it's GIO
that needs GModule. That dependency might change in the future, since
it's a private dependency of GIO. It doesn't make sense to specify as
a dependency of the binaries to me.

The third patch, unfortunately, seems bizarre as well --
$(glib_compile_resources) is found and set by configure.ac, so it must
be there in order for the Makefile to have been generated. It doesn't
make much sense to me to also check it in the Makefile.

Let me know if you have any other questions.

On Tue, Aug 4, 2015 at 8:05 AM, Shane McIntosh mcint...@cs.queensu.ca wrote:
 Hi all,

 I’m part of a research team that's working on a tool that scans build systems 
 for missing dependencies. We ran a prototype of our tool on the GLib build 
 system, and detected a few bugs:

 https://bugzilla.gnome.org/show_bug.cgi?id=752239
 https://bugzilla.gnome.org/show_bug.cgi?id=752232
 https://bugzilla.gnome.org/show_bug.cgi?id=752227

 We’ve attached patches that address the missing dependencies to those bug 
 reports. We hope that the patches are useful. It would be great if a GLib 
 maintainer could have a look, and get back to us! The feedback would be very 
 helpful for when we scale the approach out to larger build systems — perhaps 
 even scanning the whole of GTK+ or GNOME if there is interest.

 All the best,
 -Shane

 http://shanemcintosh.org/
 ___
 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

Re: gtk consistently getting stuck at poll function in ../sysdeps/unix/syscall-template.S

[Jasper St. Pierre]

Being stuck in poll simply means you're waiting for an event to come
in. So your application isn't hung, it's just sitting there waiting.
As soon as something comes in, like a mouse click or a network
message, poll will exit and return one of those events.

Is your application multi-threaded?

On Sun, Jun 28, 2015 at 9:04 AM, Lokesh Chakka
lvenkatakumarcha...@gmail.com wrote:
 hello,

 following is bt

 #0  0x7f11f566f8dd in poll () at ../sysdeps/unix/syscall-template.S:81
 #1  0x7f11f64b6ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 #2  0x7f11f64b7242 in g_main_loop_run () from
 /lib/x86_64-linux-gnu/libglib-2.0.so.0
 #3  0x7f11f73b8de5 in gtk_main () from
 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0

 Usage of gdk_threads_init / gdk_threads_enter / gdk_threads_leave is not
 fetching any benefit here.

 can some one please help me getting rid of this issue ?

 Thanks  Regards
 --
 Lokesh Chakka,
 Mobile: 9731023458

 ___
 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

Re: gtk consistently getting stuck at poll function in ../sysdeps/unix/syscall-template.S

[Jasper St. Pierre]

Using gdb, you can see the stack trace of all of the threads with
thread apply all bt.

Do the other threads not in poll look stuck?

On Sun, Jun 28, 2015 at 10:53 PM, Lokesh Chakka
lvenkatakumarcha...@gmail.com wrote:
 jasper,

 Thanks for responding. My application is multi-threaded.
 Actually the whole gui is becoming grey and not responding for any events
 (like mouse click or tab or anything)
 Also CPU consumption for that thread is becoming 99.9%.

 so I had to kill the application as i am left with no other option.


 Thanks  Regards
 --
 Lokesh Chakka,
 Mobile: 9731023458

 On Sun, Jun 28, 2015 at 9:37 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Being stuck in poll simply means you're waiting for an event to come
 in. So your application isn't hung, it's just sitting there waiting.
 As soon as something comes in, like a mouse click or a network
 message, poll will exit and return one of those events.

 Is your application multi-threaded?

 On Sun, Jun 28, 2015 at 9:04 AM, Lokesh Chakka
 lvenkatakumarcha...@gmail.com wrote:
  hello,
 
  following is bt
 
  #0  0x7f11f566f8dd in poll () at
  ../sysdeps/unix/syscall-template.S:81
  #1  0x7f11f64b6ebc in ?? () from
  /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #2  0x7f11f64b7242 in g_main_loop_run () from
  /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #3  0x7f11f73b8de5 in gtk_main () from
  /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
 
  Usage of gdk_threads_init / gdk_threads_enter / gdk_threads_leave is not
  fetching any benefit here.
 
  can some one please help me getting rid of this issue ?
 
  Thanks  Regards
  --
  Lokesh Chakka,
  Mobile: 9731023458
 
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 



 --
   Jasper





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

Re: GMemVTable broken

[Jasper St. Pierre]

Yeah, we've all been sort of aware of this for some time. I've abused
it to the fact where I know that malloc and g_new / free and g_free
will *always* be the same since a specific glib version.

I think removing all the code is fine.

On Fri, Jun 26, 2015 at 8:38 PM, Alexander Larsson al...@redhat.com wrote:
 So, I just tried to use the memory profiler in glib, and I crashes
 really early because the gobject constructor (gobject_init_ctor) calls
 g_malloc before main() is reached.

 This means g_mem_set_vtable() is impossible to use. I don't necessarily
 think this is all that bad. Honestly we should never have made it a
 vtable (one extra vfunc per malloc...) and instead do memory profiling
 etc the normal way, i.e. LD_PRELOAD something with malloc
 interceptors. Maybe we should just remove all this code and keep
 g_mem_set_vtable as a dummy function that prints a deprecation warning?
 ___
 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

Re: Outdated win32 bundle

[Jasper St. Pierre]

Would it be possible for me to fund / help maintain official GNOME
Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
but I'm never sure where the status is. Last time I tried jhbuild it
failed on something early on -- I believe fontconfig, so that was a
bummer.

On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
 Hi;

 On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
 On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote:

 The current stance of everyone involved in the Windows backend for
 GLib and GTK+ is to stop advertising binary builds for Windows — as we
 don't do that for any other platform, and nobody sticks around long
 enough to keep doing that or to set up a continuous integration build
 for GTK.

 Stop advertising == stop supporting?

 If I wanted to say stop supporting, I would have said that. Not that
 we *ever* supported binary builds, on any platform. If you want
 commercial support, you should contract somebody.

 Currently, we advertise ad hoc Windows builds on gtk.org; those are
 out of date, and lack many of the bug fixes that went into GTK. This
 situation is confusing for application developers, and makes the
 project look bad. It also reflect badly on the great work that
 developers have been doing in order to make GTK work well on Windows.

 On top of that, we don't offer binary builds for any other platform,
 and instead rely on distributors — like Homebrew on Mac; the *BSD
 ports; or the various Linux distributions — to provide binary builds
 for them. Windows is an anomaly, mostly because there weren't
 good/usable software distributions in the past. This has now changed,
 and it's a good thing to ensure that developers on Windows get
 reliable, up to date software.

 Developers using the G* core platform libraries on Windows are
 strongly encouraged to use the MSYS2 distribution:

   https://msys2.github.io/

 Like Git? Ship 200Mb of additional value on top? Just for comparison
 Mercurial installation is 37Mb compared with 267Mb of Git. And that for
 every GTK application?

 MSYS2 is for developers, not for end users.

 You're supposed to set up the development enviroment on *your*
 development machine(s); once you have built your application, you can
 take your binary artefacts, including the DLLs you depend on, put them
 into an installer, and let your users download the installer — which
 is exactly what you should have done in the past, even with pre-built
 DLLs. The intended change is for application developers to get
 pre-built, up to date binaries using MSYS2, instead of downloading zip
 files from gtk.org that we cannot reliably keep up to date.

 Telling your users to download your application; download DLLs from
 gtk.org; shove them into some directory; and, finally, hope for the
 best, was never a good software distribution mechanism.

 This will provide you with pre-built packages that are known to work
 and maintained. It also allows you to build your own packages on top
 of it, and create an installer from the result.

 Can GTK be cross-compiled for Windows?

 Yes, it can, and it routinely is.

 What the GTK team would love, on the other hand, is somebody putting
 the effort in setting up and maintaining a continuous integration
 service — similar to https://build.gnome.org — for Windows builds.
 This way we would be able to catch build regressions after every
 commit, without relying on the application developers to file bugs.

 http://www.appveyor.com/ if using closed source service is okay.

 No, it's really not — especially if it has to run on the gnome.org
 infrastructure.

 Ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]
 ___
 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

Re: Outdated win32 bundle

[Jasper St. Pierre]

I can take a look at the gobject-introspection work. Bugzilla links?

On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro
nacho.r...@gmail.com wrote:


 On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Would it be possible for me to fund / help maintain official GNOME
 Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
 but I'm never sure where the status is. Last time I tried jhbuild it
 failed on something early on -- I believe fontconfig, so that was a
 bummer.


 Well the current status is quite good compared with how it was a few years
 ago.
 The main problems are still:
 1. that we have lots of downstream patches still on msys2, even though I
 spent quite a lot of time pushing them upstream.
 2. building anything out of git is a nightmare, you need a tarball or
 everything gets in your way
 3. gobject-introspection could get quite a bit of love for windows. There
 are though some patches in bugzilla that are waiting some review.
 4. jhbuild would require some serious work.

 Cheers.




 On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
  Hi;
 
  On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
  On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com
  wrote:
 
  The current stance of everyone involved in the Windows backend for
  GLib and GTK+ is to stop advertising binary builds for Windows — as we
  don't do that for any other platform, and nobody sticks around long
  enough to keep doing that or to set up a continuous integration build
  for GTK.
 
  Stop advertising == stop supporting?
 
  If I wanted to say stop supporting, I would have said that. Not that
  we *ever* supported binary builds, on any platform. If you want
  commercial support, you should contract somebody.
 
  Currently, we advertise ad hoc Windows builds on gtk.org; those are
  out of date, and lack many of the bug fixes that went into GTK. This
  situation is confusing for application developers, and makes the
  project look bad. It also reflect badly on the great work that
  developers have been doing in order to make GTK work well on Windows.
 
  On top of that, we don't offer binary builds for any other platform,
  and instead rely on distributors — like Homebrew on Mac; the *BSD
  ports; or the various Linux distributions — to provide binary builds
  for them. Windows is an anomaly, mostly because there weren't
  good/usable software distributions in the past. This has now changed,
  and it's a good thing to ensure that developers on Windows get
  reliable, up to date software.
 
  Developers using the G* core platform libraries on Windows are
  strongly encouraged to use the MSYS2 distribution:
 
https://msys2.github.io/
 
  Like Git? Ship 200Mb of additional value on top? Just for comparison
  Mercurial installation is 37Mb compared with 267Mb of Git. And that for
  every GTK application?
 
  MSYS2 is for developers, not for end users.
 
  You're supposed to set up the development enviroment on *your*
  development machine(s); once you have built your application, you can
  take your binary artefacts, including the DLLs you depend on, put them
  into an installer, and let your users download the installer — which
  is exactly what you should have done in the past, even with pre-built
  DLLs. The intended change is for application developers to get
  pre-built, up to date binaries using MSYS2, instead of downloading zip
  files from gtk.org that we cannot reliably keep up to date.
 
  Telling your users to download your application; download DLLs from
  gtk.org; shove them into some directory; and, finally, hope for the
  best, was never a good software distribution mechanism.
 
  This will provide you with pre-built packages that are known to work
  and maintained. It also allows you to build your own packages on top
  of it, and create an installer from the result.
 
  Can GTK be cross-compiled for Windows?
 
  Yes, it can, and it routinely is.
 
  What the GTK team would love, on the other hand, is somebody putting
  the effort in setting up and maintaining a continuous integration
  service — similar to https://build.gnome.org — for Windows builds.
  This way we would be able to catch build regressions after every
  commit, without relying on the application developers to file bugs.
 
  http://www.appveyor.com/ if using closed source service is okay.
 
  No, it's really not — especially if it has to run on the gnome.org
  infrastructure.
 
  Ciao,
   Emmanuele.
 
  --
  https://www.bassi.io
  [@] ebassi [@gmail.com]
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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




 --
 Ignacio Casal Quinteiro



-- 
  Jasper

Re: GDK_KP_Decimal (on Windows)

[Jasper St. Pierre]

It was likely left out by accident, and nobody so far hit this code
path yet. Thanks for finding it! It looks super easy to fix.

On Wed, Apr 29, 2015 at 8:01 AM, John Emmas john...@tiscali.co.uk wrote:
 On 29/04/2015 08:54, John Emmas wrote:


 The Windows version looks slightly different:-

 case VK_ADD:
   *ksymp = GDK_KP_Add; break;
 case VK_SEPARATOR:
   *ksymp = GDK_KP_Separator; break;
 case VK_SUBTRACT:
   *ksymp = GDK_KP_Subtract; break;

 // some others

 However, the list for Windows doesn't seem to include 'GDK_KP_Decimal'.
 Might this explain why the decimal point key is getting ignored on Windows?


 Just for the hell of it I decided to add an entry for GDK_KP_Decimal - and
 sure enough, it seems to have fixed the problem.  Does anyone know of a
 valid reason why that one got left out for the Windows list?  Thanks.


 John
 ___
 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

Re: dependency graph

[Jasper St. Pierre]

The one in here, perhaps?

https://github.com/hexchat/gtk-win32/blob/master/README.md

On Mon, Apr 6, 2015 at 10:55 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 sometime in the last few months, somebody posted a link to (or the actual
 image of) a really really nice diagram laying out the dependencies in the
 GTK stack. i am having a hard time finding it. does anyone have any
 pointers? it was nicely organized by functionality etc.

 ___
 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

Re: I'm done with O_CLOEXEC

[Jasper St. Pierre]

Thanks. I have refactored this code to use GSubprocess:

https://git.gnome.org/browse/mutter/commit/?id=d4e8d97e58f9c931a14ea9b6484890d7a66e65e7

Not overly happy with the hardcoded fd assignments, but it's not the
end of the world.

On Fri, Mar 20, 2015 at 10:28 PM, Ryan Lortie de...@desrt.ca wrote:
 hi,

 On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote:
 Right now, we use raw fork/exec in mutter where we need to do some tricky
 management and explicitly leak an FD into the correct place [0]. Does
 this
 mean that from now on, glib might leak an FD and we need to be prepared
 to
 handle that? Refactoring the code to use a child setup func and using
 g_spawn isn't quite really what I want to do (can I even leak an FD made
 with socketpair through in that case?), but I want to be aware of what
 might break in the future, and whose bug it should be.

 I recommend using GSubprocess.

 g_subprocess_launcher_take_fd() lets you give an fd (along with a
 target_fd number).  This fd will appear in the newly-spawned process as
 the target number you gave.  This is what I mean by code that spawns
 processes having explicit control over what they do.

 For example:

   int sv[2];

   socketpair (..., sv);
   g_subprocess_launcher_take_fd (launcher, sv[1], 3);
   g_subprocess_launcher_spawn (launcher, NULL, /usr/bin/whatever);

 will put the sv[1] end of the socket pair into the launched process as
 fd 3.

 I know it's difficult to set a policy about this, but is there anything I
 can do to prevent too much damage in the future? If I file a patch
 against
 glib for where it might not set CLOEXEC with an easy flag the syscall,
 will
 you accept it, or are you going to reject it to stop me from relying on
 CLOEXEC?

 I'm not sure.  It probably depends on the outcome of this thread.  I'm
 leaning towards we won't do it if it complicates the code.

 Cheers



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

Re: GTK+, WM, desktops and CSD

[Jasper St. Pierre]

On Mon, Mar 23, 2015 at 2:25 PM, Pavel Machek pa...@ucw.cz wrote:

 Hi!

  I am not one of them, but there are a lot of people (including KDE
  devs apparently) concerned about CSD because it means different
  decorations depending on the apps/toolkit = Consistency might
  suffer.

 Consistency already suffers. Chromium pulls this trick, and it means
 you can't move such web browser to other workspace, easily (as right
 click produces useless Chromium's menu, while right click on normal
 windows produces expected WM's menu, including move to another
 desktop).

  I think it's very little change in GTK+ as it's already able to do
  both SSD and CSD (currently, decision to use CSD or SSD being made at
  run time based on the availability of a compositor).

 If you are modifying protocol between WM and application, would it be
 possible to arrange right click on title event to windowmanager, so
 that it can display its full menu?


This request already exists.

http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n187


 Thanks,
 Pavel

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures)
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 ___
 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

Re: I'm done with O_CLOEXEC

[Jasper St. Pierre]

Sorry, I'm not overly familiar with this sort of stuff.

Right now, we use raw fork/exec in mutter where we need to do some tricky
management and explicitly leak an FD into the correct place [0]. Does this
mean that from now on, glib might leak an FD and we need to be prepared to
handle that? Refactoring the code to use a child setup func and using
g_spawn isn't quite really what I want to do (can I even leak an FD made
with socketpair through in that case?), but I want to be aware of what
might break in the future, and whose bug it should be.

I know it's difficult to set a policy about this, but is there anything I
can do to prevent too much damage in the future? If I file a patch against
glib for where it might not set CLOEXEC with an easy flag the syscall, will
you accept it, or are you going to reject it to stop me from relying on
CLOEXEC?

[0]
https://git.gnome.org/browse/mutter/tree/src/wayland/meta-xwayland.c#n458

On Fri, Mar 20, 2015 at 10:10 PM, Ryan Lortie de...@desrt.ca wrote:

 On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote:
  So,  you found that dup3 doesn't do what you want, and now you want to
  throw out the baby with the bathwater and just say I don't care
  anymore if we leak fds ?

 dup3() was a bit of a straw that broke the camel's back case.  I could
 point at the existence of g_unix_open_pipe() as a similarly ridiculous
 case, or many others.

 I'm also not impressed by the inaccurate categorisation.  I thought I
 explained fairly clearly why I believe that leaked fds will _not_ be the
 case, even without O_CLOEXEC.

 I was looking for some slightly more constructive arguments...

 Cheers
 ___
 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

Re: GL and libepoxy

[Jasper St. Pierre]

Are you sure? This shouldn't be the case since

https://github.com/anholt/libepoxy/commit/e3051481cc9f5b7b36b317aff1454ee16ea9cdb9

On Fri, Mar 6, 2015 at 7:54 PM, John Ralls jra...@ceridwen.us wrote:

 It looks like we've committed to using libepoxy[1] as a shim for GL
 support. It looks quite nice, but there's a catch: In spite of the claim in
 our INSTALL that it's cross-platform, it actually depends on X11.

 I think that means that we need to have a separate GL interface
 per-backend.

 Regards,
 John Ralls

 ___
 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

Re: GTK+, WM, desktops and CSD

[Jasper St. Pierre]

Ah, I think I see the disagreement.

We don't decide between SSD and CSD based on the presence of a compositor
and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD
fallback.

It's a subtle difference, but it shows our preference: we don't want a hint
to say that the DE prefers SSD, we want a hint to say that the DE can
support/not support CSD.

If you want to help improve CSD fallbacks to behave better when we don't
have a compositor, that would be great! But ultimately, SSD does not lead
to the types of applications and the types of experiences we want to
create, so a hint asking us to prefer to use SSD that we would
realistically mostly ignore isn't particularly useful.

On Thu, Mar 5, 2015 at 12:29 PM, Olivier Fourdan four...@gmail.com wrote:

 Hi

 On 5 March 2015 at 20:09, Emmanuele Bassi eba...@gmail.com wrote:
  On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote:
  What about apps that rely on CSD for part of their UI? Will those
 have the
  final word as well, or are they just screwed?
 
  The same as now without a compositor :)
 
  a) X11 without a compositor is a deeply uninteresting case; I'd go as
  far as saying that if you're running X11 without a compositor you're
  basically asking for a broken system

 I am not sure I am following you here, but people do run WM without a
 compositor, it is a reality.

 And GTK supports that, at least up until now, and that's fine by me.

  b) not having a compositor is not at all equivalent to changing a UI
  from a CSD to a SSD scenario. The UI *changes*, even in drastic ways
  for the user interaction. The application has to be informed about it,
  and has to be designed with those two cases in mind. It has to ship
  with two fairly different sets of UIs. It already happens for menus,
  but you'll have to convince application developers to ship those two
  UIs, maintain them, and keep them from going out of sync. Your idea
  stops at providing a patch for a hint. You're vastly underestimating
  the effort that such hint entails on the larger ecosystem.

 But it's already the case, I am not advocating to reinvent the entire
 ecosystem of UI interactions here, I am merely asking if a setting to
 help GTK decide to go CSD or SSD instead of just detecting the
 presence of the compositor alone would be interesting...

 Cheers,
 Olivier
 ___
 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

Re: GTK+, WM, desktops and CSD

[Jasper St. Pierre]

On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan four...@gmail.com wrote:

 +gtk-devel-list

 Argh sorry, I didn't mean to make that email private,  thought my
 mailer would copy the list as well, my bad :(

 On 5 March 2015 at 19:29, Olivier Fourdan four...@gmail.com wrote:
  Emmanuele,
 
  Let's face it, I doubt GTK+ will ever dominate the world, so the it's
  not consistent because we're not using a single toolkit is not going
  to be solved overnight. And frankly, as much as I like GTK+, I do not
  wish other toolkits to go away either, so we shall have to deal with
  heterogeneous toolkits for any foreseeable future.
 
  GTK already check for a compositor and detecting the DE to adapt is
  really not a good approach, it doesn't scale, and worse it ends up
  being really confusing (I can't remember which famous app was doing
  that, but I do remember that we ended up pretending to be gnome in the
  session just so it would work reliably...).


Hi,

GTK+ should not try to detect the DE it is running under. It should check
for the _GTK_FRAME_EXTENTS protocol in _NET_SUPPORTED on the root window.


  As I wrote, the final word would remain the to apps, just like now,
  all I'm proposing is to replace the decision made by GTK to use CSD
  based on a compositor with a hint from the DE instead, nothing more.
 
  Cheers,
  Olivier
 
 
  On 5 March 2015 at 19:18, Emmanuele Bassi eba...@gmail.com wrote:
  Hi;
 
  On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com wrote:
 
  I am not one of them, but there are a lot of people (including KDE
  devs apparently) concerned about CSD because it means different
  decorations depending on the apps/toolkit = Consistency might suffer.
 
  I don't strictly buy the consistency argument at all.
 
  Right now, on my desktop, I have open two different browsers — Firefox
  and Chrome — that do not look like anything on my desktop. I also have
  an office suite using its own toolkit which passes a slight
  resemblance to GTK, if I squint my eyes and tilt my head a bit. If I
  were so inclined, I could be probably running some non-GTK
  applications, and those would look fairly different.
 
  There's no consistency because we're not running a platform with a
  single toolkit.
 
  If you're referring to the window controls, you can specify them even
  for GTK windows using client-side decorations; it's a setting that can
  be changed to reflect your environment — that's why both server-side
  and client-side decorated GTK windows have the same buttons.
 
  I think it's very little change in GTK+ as it's already able to do
  both SSD and CSD (currently, decision to use CSD or SSD being made at
  run time based on the availability of a compositor).
 
  That's not entirely correct. The decision to use client-side
  decorations is up to the application developers, not to the toolkit.
  An application developer may decide to support both the UIs, and opt
  for client-side decorations if they detect that the application is
  running under GNOME, but the toolkit is only tangentially involved.
  The only place where GTK decides to use an header bar or not is for
  the dialog windows it creates — file selection dialogs, print dialogs,
  color selection dialogs, etc. Those are under the control of the
  toolkit, so the toolkit can make a decision. The UI of an application,
  on the other hand, is the remit of its developer. The toolkit cannot
  really move widgets around, because it's missing context to do so. If
  I use a GtkHeaderBar with a button at the top left, and the
  environment does not support CSD properly, where should the toolkit
  put that button? Keep the header bar, but still have decorations on
  top, thus replicating things like titles?
 
  Your proposal for an hint could be simply solved with a check on
  whether the screen is composited (which is already available) and/or a
  check on the desktop environment. Sure, we can add a freedesktop.org
  spec that tells us if the application is running under GNOME, KDE,
  XFCE, or whatever. Obviously, it all breaks apart as soon as choice
  is factored in — if somebody is running under KDE with KWin without
  compositing, what would the environment be? Same with XFCE running
  with another window manager. Let's ignore that for a minute, though,
  and figure out the issues of such a hint.
 
   • How does that hint get specified? Is it an X11 property on the root
 window?
   • How does it get monitored? What happens if the user changes the
  setting at run time? Do we get a client message?
   • How are applications supposed to react when that setting is found,
  or when it changes? Do they ship with two different UIs, one for CSD
  and one for SSD?
   • What happens if the application does not have two UIs? Is the
  setting ignored, and the application stays with client-side
  decorations even if the window manager does not support the Motif WM
  hints?
 
  At the end of the day, though, if the application developer 

Re: GTK+, WM, desktops and CSD

[Jasper St. Pierre]

On Thu, Mar 5, 2015 at 1:21 PM, David Nečas y...@physics.muni.cz wrote:

 On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote:
   It's a subtle difference, but it shows our preference: we don't want a
 hint
   to say that the DE prefers SSD, we want a hint to say that the DE can
   support/not support CSD.
 
  That would work as well, why not.

 As long as I can set up my DE to pretend not to support CSD, whatever
 the actual state is.  Because this is, at the end, user's preference.


It's the application developer's decision to build the application and the
UI they want to build. GtkHeaderBar, like GtkButton or GtkMenuBar, is
simply a widget in their box of tools to construct their UI. These
applications might be free software, in which case you have the freedom to
change the code and the UI. You are still welcome to do this. GTK+ is an
application toolkit and is not in the business of constructing policy about
what the application developer can and cannot do.

If you do not like CSD, do not use applications that use CSD in their UI,
or change the application's code to stop it from using CSD.

We wouldn't accept a patch that radically changed GtkButton because it is,
at the end, user's preferenece about whether GtkButton should be allowed.
The same can be said about other UI elements that application developers
use to construct your UI.


   But ultimately, SSD does not lead to the types of applications and
   the types of experiences we want to create...

 This is sad.  Once your mission becomes creating certain types of
 experience, instead of enabling them, everything else gets destroyed,
 whether the types of experience it enables are also good or not.  And
 there does not seem anything capable of stopping the destructive mindset
 at this moment...


Honest question: What is the everything else that is being destroyed? Are
there some issues you have with our CSD implementation? I can try to help
fix them.


 Yeti




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

Re: RFC: GtkPreview library

[Jasper St. Pierre]

After talking to Owen today, I'm wondering if it makes sense to consider
GtkPreview a portable widget. These platforms tend to already have their
own document preview systems, and I'm not sure it makes sense to port all
our apps (evince preview system, LibreOffice preview system) to use our own
system instead of simply using the native preview widget.

OS X has QuickLook:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/Introduction/Introduction.html

While I can't find a Win32 equivalent, it seems file pickers use
IThumbnailCache:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774628%28v=vs.85%29.aspx



On Wed, Jan 28, 2015 at 1:23 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 All of this is part of wl_event_loop, which is an unfortunate public API
 that should probably go away.

 On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento 
 philip.chime...@gmail.com wrote:

 On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net
  wrote:

 Gah. I always get those backwards. I actually typed SCM_RIGHTS and
 then changed it to SCM_CREDENTIALS. I still don't understand why fd
 passing is called rights.

 On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie 
 simon.mcvit...@collabora.co.uk wrote:

 On 27/01/15 15:55, Jasper St. Pierre wrote:
  Wayland requires two features that would perhaps make it unportable:
 FD
  passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
  files, ftruncate it, mmap it, unlink it and then send the fd across
 the
  wire). Everything else is just a simple Unix domain socket. Does OS X
  support those two features?

 I think you mean SCM_RIGHTS?

 SCM_RIGHTS is here's a message with an open fd attached. It's how
 D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
 platform, Wayland fd-passing should too.

 SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
 attached, the kernel will check that I haven't lied to you (also called
 SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
 syscall to query those things or both, but most Unixes also have their
 own unique spelling for the API, because standards are hard.[2]

 S

 [1] Strictly speaking the uid, gid and pid I had at the time I opened
 this socket
 [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
 several platforms (sadly not including Linux) share getpeereid(). For
 the gory details see libdbus source code.


 I put it to the test and tried to build Jasper's proof of concept (and
 therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac
 checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses
 signalfd() and timerfd(), not available on OSX. I guess the replacement
 would be something with kqueue though I really haven't the faintest idea
 what I'm talking about there.

 Wayland also wants clock_gettime() - not insurmountable to provide on OSX
 but afaik uses a different API, quick googling showed up this:
 http://stackoverflow.com/a/6725161/172999

 PS. Funny thing that this is one of the top results for googling
 SFD_CLOEXEC, even without adding osx or wayland:
 http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland

 Best,
 --
 Philip




 --
   Jasper




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

Re: gtk_style_context_get()

[Jasper St. Pierre]

This is a pipe dream, I imagine, but would it be possible to get people to
cache their stuff only inside size_allocate(); or draw();, and just do
something dumb like lie to the user and warn if they do it outside of one
of those paths?

I think doing drawing of the DND window outside of the frame clock is a bit
much --  we should be synchronized to that in any case.

I haven't investigated how much breakage something like that would cause.

On Thu, Jan 29, 2015 at 11:51 PM, Benjamin Otte o...@gnome.org wrote:

 Hey,

 Here's a problem I'm currently thinking about and would like input on. I
 discussed it with Matthias on #gtk+ today and he suggested I'd reach out to
 more people. I've included the log below and formatted it for clarity so
 that it reads like a QA-style interview. I hope it is not too inconvenient
 to read.

 Company the question we're trying to answer is this: What CSS values
 does GtkStyleContext return?
 Company this question is relevant because every time we change the CSS
 tree, we need to (potentially) update the value

 Company 3.0.0 used the approach of immediately updating everything once
 the css tree changed somehow
 Company so if you did: context.add_class(a); context.add_class(b);
 context.add_class(c);
 Company it would recompute the CSS 3x
 Company which gets real slow really fast

 Company in 3.4 or so I changed that to always return a stale value
 Company until we validated the style via gtk_container_idle_sizer()
 (when the frame clock runs)
 Company so from that point on everything was fast, but the values were
 sometimes incorrect

 mclasen wouldn't you want to mark the values as stale, and force a
 recompute when somebody asks for a value ?
 Company ideally, you would
 Company the reason I did not do that was the style-updated signal
 Company when should that be emitted?
 Company if we emit it once a context gets invalid, we go back to 3.0
 performance
 Company because every widget queries values in the style-updated
 handler...

 mclasen you could do some freeze/thaw to batch the 3 emissions from 3
 add_class calls
 Company I don't want to add freeze/thaw calls though, everybody would
 get those wrong

 mclasen who needs to listen to style-updated anyway ?
 mclasen other than the gtk redraw machinery
 Company mostly just that
 Company GtkWidget needs to update the pango context
 Company GtkImage needs to release the cached surface
 Company things like that
 Company and of course we need to queue_draw() or queue_resize()

 Company here's another caveat: computing the CSS values requires
 computing the CSS values of the parent

 mclasen is that on the person changing the style context, or do we do
 that automatically ?
 Company GtkWidget::style-updated does that
 Company based on the GtkCssAffects settings of the changed style
 properties

 mclasen my mental model of this is that css values are used when drawing
 happens, so they need to be current at that point
 mclasen and drawing happens when the frame clock comes around to tell us
 Company yes
 Company when the frame clock triggers, we (1) recompute styles, (2)
 size_allocate everything pending, (3) draw

 mclasen whether css values are up-to-date at other points in the frame
 cycle should not be important
 mclasen except for those 3rd party users who randomly poke at style
 contexts...
 Company but it is important
 Company otherwise you get shrinking gnome terminals and white firefox
 text
 Company the gnome terminal case is actually rather complex to get right
 with the should not be important assumption
 Company because it needs to compute a bunch of values based on multiple
 different widgets
 Company and it needs to compute those before size allocation happens
 Company in short: It needs to happen in style_updated() at the latest -
 but which style-updated, when it depends on multiple widgets?

 halfline can't you just give the right value any time the user asks for
 it (updating the cache for that property if it's stale), but also keep
 style-updated where it happens now ?
 Company that's one thing we could do
 Company there's many solutions to the problem(s)
 Company I haven't reached the point yet where want to talk about
 solutions
 Company so far I'm trying to list the problem(s) :)

 mclasen 'before size allocation' sounds like a global thing though ?
 like a point in the frame cycle
 mclasen as long as we keep information about which styles are
 up-to-date, doing on-the-spot validation for people who call
 gtk_style_context_get_foo outside of regular frame-based drawing may just
 fine ?
 mclasen at least, only the people doing the poking are paying the price
 of extra recomputations then

 Company lemme do a short jsfiddle to show you how the web does it
 Company http://jsfiddle.net/nbt2myzb/1/
 Company I hope that example is simple enough
 Company you wanna understand why uncommenting that 1 line of JS makes
 the animation restart
 Company (disclaimer: I'm using firefox, no idea if webkit does things
 

Re: RFC: GtkPreview library

[Jasper St. Pierre]

I've done the above.

https://github.com/magcius/wakefield

Check it out, run make, then run:

$ LD_LIBRARY_PATH=. ./test-compositor
$ ./test-client-2

Right now it's a very basic prototype -- it doesn't support all
functionality, it doesn't dynamically resize the surface the client handed
us, and will easily crash, but for a day and a half of work, I think it
proves that it can be done.


On Tue, Jan 27, 2015 at 5:19 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 So you're effectively proposing that the transport of the data between
 plugins and the widget is always Wayland, even if the session is running
 under X11? That sounds like a good idea to me if it's possible to
 implement. I would definitely welcome a proof of concept!

 Thanks,
 Cosimo

 On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 We could indeed write a tiny Wayland compositor that composited a single
 wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could
 even do it while under X11, and it might be an interesting proof of
 concept. I could do a PoC if you guys want.
 On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Fair enough, those are good points.
 To rephrase my last message I am not well-versed in the details of
 subsurfaces and how they would help in this case, so I will appreciate help
 to evolve my API proposal in that direction :-)

 Cosimo

 On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com
 wrote:

 hi;

 On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk
 wrote:

  That's why my proposal doesn't enforce this specific design; I'm
  definitely open to think more about how a multi-process design looks
  like, but I wouldn't want to block until that is figured out.
 
  To me, the security and rendering architecture of this seems pretty
 core
  in the design, so I _would_ block on figuring it out. It doesn’t feel
  like the kind of thing which can easily be bolted on or fixed
  afterwards.

 I tend to agree; we need to start designing our API with sandboxing
 and security context separation from the start, these days, otherwise
 we'll have nothing but grief (in the form of API changes or, worse,
 complete rewrites) down the line.

 ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]



 ___
 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

Re: RFC: GtkPreview library

[Jasper St. Pierre]

All of this is part of wl_event_loop, which is an unfortunate public API
that should probably go away.

On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento philip.chime...@gmail.com
wrote:

 On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Gah. I always get those backwards. I actually typed SCM_RIGHTS and then
 changed it to SCM_CREDENTIALS. I still don't understand why fd passing is
 called rights.

 On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie 
 simon.mcvit...@collabora.co.uk wrote:

 On 27/01/15 15:55, Jasper St. Pierre wrote:
  Wayland requires two features that would perhaps make it unportable: FD
  passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
  files, ftruncate it, mmap it, unlink it and then send the fd across the
  wire). Everything else is just a simple Unix domain socket. Does OS X
  support those two features?

 I think you mean SCM_RIGHTS?

 SCM_RIGHTS is here's a message with an open fd attached. It's how
 D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
 platform, Wayland fd-passing should too.

 SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
 attached, the kernel will check that I haven't lied to you (also called
 SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
 syscall to query those things or both, but most Unixes also have their
 own unique spelling for the API, because standards are hard.[2]

 S

 [1] Strictly speaking the uid, gid and pid I had at the time I opened
 this socket
 [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
 several platforms (sadly not including Linux) share getpeereid(). For
 the gory details see libdbus source code.


 I put it to the test and tried to build Jasper's proof of concept (and
 therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac
 checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses
 signalfd() and timerfd(), not available on OSX. I guess the replacement
 would be something with kqueue though I really haven't the faintest idea
 what I'm talking about there.

 Wayland also wants clock_gettime() - not insurmountable to provide on OSX
 but afaik uses a different API, quick googling showed up this:
 http://stackoverflow.com/a/6725161/172999

 PS. Funny thing that this is one of the top results for googling
 SFD_CLOEXEC, even without adding osx or wayland:
 http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland

 Best,
 --
 Philip




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

Re: RFC: GtkPreview library

[Jasper St. Pierre]

Gah. I always get those backwards. I actually typed SCM_RIGHTS and then
changed it to SCM_CREDENTIALS. I still don't understand why fd passing is
called rights.

On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie 
simon.mcvit...@collabora.co.uk wrote:

 On 27/01/15 15:55, Jasper St. Pierre wrote:
  Wayland requires two features that would perhaps make it unportable: FD
  passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
  files, ftruncate it, mmap it, unlink it and then send the fd across the
  wire). Everything else is just a simple Unix domain socket. Does OS X
  support those two features?

 I think you mean SCM_RIGHTS?

 SCM_RIGHTS is here's a message with an open fd attached. It's how
 D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
 platform, Wayland fd-passing should too.

 SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
 attached, the kernel will check that I haven't lied to you (also called
 SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
 syscall to query those things or both, but most Unixes also have their
 own unique spelling for the API, because standards are hard.[2]

 S

 [1] Strictly speaking the uid, gid and pid I had at the time I opened
 this socket
 [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
 several platforms (sadly not including Linux) share getpeereid(). For
 the gory details see libdbus source code.

 ___
 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

Re: RFC: GtkPreview library

[Jasper St. Pierre]

We could indeed write a tiny Wayland compositor that composited a single
wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could
even do it while under X11, and it might be an interesting proof of
concept. I could do a PoC if you guys want.
On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Fair enough, those are good points.
 To rephrase my last message I am not well-versed in the details of
 subsurfaces and how they would help in this case, so I will appreciate help
 to evolve my API proposal in that direction :-)

 Cosimo

 On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com wrote:

 hi;

 On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk
 wrote:

  That's why my proposal doesn't enforce this specific design; I'm
  definitely open to think more about how a multi-process design looks
  like, but I wouldn't want to block until that is figured out.
 
  To me, the security and rendering architecture of this seems pretty core
  in the design, so I _would_ block on figuring it out. It doesn’t feel
  like the kind of thing which can easily be bolted on or fixed
  afterwards.

 I tend to agree; we need to start designing our API with sandboxing
 and security context separation from the start, these days, otherwise
 we'll have nothing but grief (in the form of API changes or, worse,
 complete rewrites) down the line.

 ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]



 ___
 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+ brochure for FOSDEM

[Jasper St. Pierre]

On Fri, Jan 23, 2015 at 3:37 AM, Sébastien Wilmet swil...@gnome.org wrote:

 On Thu, Jan 22, 2015 at 10:51:38PM +, Alberto Ruiz wrote:
  I agree with Paul here, GTK+ targets people who want to do desktop apps.
 I
  would actually try to sell all the new stuff for developers like the new
  introspection tool, the new widgets and some of the new CSS work with
  snippets.

 One purpose of the flyer that I had in mind is to explain what to learn
 for writing a GLib/GTK+ program, providing an overview. If people have
 never heard of GObject, they will look at some code and will be afraid
 of all the macros and other boilerplate code that they don't understand.

 The learning path for writing a GTK+ application should be: GLib -
 GObject (at least the basis) - a bit of GIO - and finally GTK+. All
 GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's
 important to explain what it is, at least briefly.


I disagree. The learning path for writing a GTK+ app should start with GTK+
and let them venture into the utility libraries of GLib and Gio when they
need to. No need to start with here's the library that seemingly reinvents
all of C99 because people sometimes still use SunCC in TYOOL 2015.


 Also, it's important to note that GObject was intentionally designed
 with bindings in mind. It's also a selling point for many people.

 In general, Linux users know what is GTK+. GLib, GObject and GIO on the
 other hand are less well known, but deserve more attention (e.g. for
 writing daemons, as explained in the brochure).

 For the images, there is already a GNOME flyer with some screenshots if
 I remember correctly, so in my opinion it's not really important to
 include lots of GTK+ screenshots (but one more image at the end could be
 better).

 Sébastien
 ___
 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

Re: GTK+ brochure for FOSDEM

[Jasper St. Pierre]

On Jan 23, 2015 12:06 PM, Sébastien Wilmet swil...@gnome.org wrote:

 On Fri, Jan 23, 2015 at 06:18:02PM +, Alberto Ruiz wrote:
  I don't see much of a debate there. Most people want to solve a problem,
  and start from the problem, not from the tool to solve it

 That's why the brochure begins by an introduction to GTK+ and an
 architecture overview.

  People who are likely to use GTK will start from the problem they want
to
  solve and are in need for a graphical toolkit to draw widgets that do
what
  they want.

 Exactly. People who use GTK+ applications already know what is possible
 to do with GTK+. Or if they use KDE or Windows or whatever, the
 applications and the desktop are the visible part that they already
 understand well. You just need to say you can do that with GTK+.

 On the other hand, what happens under the hood isn't obvious, and can be
 interesting (e.g. for a CS student) even if the person doesn't want to
 write a GTK+ app.

 At FOSDEM there are some Belgian students (like me several years ago)
 that traverse every stand and take as many things as possible, be it
 stickers, brochures, pens, etc. I have that public in mind too. Imagine
 a young student who reads the GTK+ brochure, and then several years
 later he/she wants to write a daemon, ideally the student will remember
 the brochure about GLib/GObject and event-driven programming and will
 start learning GLib!

That seems like an extremely bizarre and specific use case to optimize for,
especially given that GLib's event loop isn't that well designed for server
scenarios. They'd be better served by libev / libevent.

  Point them at what the toolkit does and the easiest way to use it,
  and people will learn as they go. GObject and GIO by themselves are of
no
  interest for most people wanting to write apps, specially in C.

 Uh, it's quite the contrary IMHO. If a developer chooses the C language
 and wants to write a GTK+ application, it's advised to write GObject
 classes to have a good code architecture. Look at gedit for instance,
 it's full of GObject classes. You create a subclass of GtkApplication, a
 subclass of GtkWindow for your main window, subclasses of GtkGrid or
 GtkBox for some other components that you have in your application, etc.
 Without GObject, you can write structs, allocate them and pass a pointer
 as the self argument, but GObject is much more powerful. It's
 interesting to create signals for example.

 For developers who choose a higher-level language, knowing the basis of
 GObject is useful too: what is a GObject signal, what is a property, oh
 there is actually an object hierarchy and I can call a function from the
 parent class, etc.


 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: GObject introspection for cairo

[Jasper St. Pierre]

Cairo-GObject provides access to enums, but it won't automatically get you
great cairo bindings. It might actually get you 90% of the way there,
though, and I'd be interested seeing how far you can run with just that,
and be happy to merge patches that make it easier.

Why? cairo has a subtype system where you have subtypes of cairo_surface_t
(e.g. cairo_image_surface_t) or cairo_pattern_t (e.g.
cairo_gradient_pattern_t) where some objects have special methods. You
determine which type this is by calling cairo_surface_get_type(); and
matching it against a closed enum (cairo_surface_type_t).

It might be enough to do 90% of the work with GObject-Introspection and
write some small by-hand functions when you need to cast to a specific
type in your binding, but you do always need some small native glue code
that calls cairo_surface_get_type();

On Thu, Jan 22, 2015 at 9:39 AM, Nicola Fontana n...@entidi.it wrote:

 Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi eba...@gmail.com
 scrisse:

  Cairo is not a GObject library, so introspection is fairly useless.

 Hi Emmanuele,

 the cairo source tree includes cairo-gobject [1] that already wraps
 enums and structs in GObject style. I just browsed the code and added
 the missing types to the gir file.

  for Cairo, you should always prefer native bindings — like pycairo, or
  the cairo GJS module.

 I'm using LGI [2] which provides automatic bindings based on GObject
 introspection. This gives me the ability to access all the libraries I
 need (cairo is only one of them) through the same interface.

 One of my API needs the cairo_surface_type_t enum, so adding a new
 dependency only for that is not an option. If the patches are rejected
 I'll wrap the enum on my side instead (or drop that particular feature).

  if you have patches, please attach them on Bugzilla.

 Sorry, my bad. I had really hard time trying to figure out how to submit
 bugs to gobject-introspection. I just discovered (10 mins ago) I need to
 select GLib as product first.

 Ciao.
 --
 Nicola

 [1] http://cgit.freedesktop.org/cairo/tree/util/cairo-gobject
 [2] https://github.com/pavouk/lgi
 ___
 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

Re: a new combo box

[Jasper St. Pierre]

So let me ask a very basic question here, since I feel it's at the heart of
the dumb internet argument we're having.

What is this design trying to solve? What problems with the old ComboBox
are we trying to fix? What use cases is it designed for?

Is it the usability problems? Are we adding the search field to behave more
like Chosen [0] ? Because that's really cool. If that's the main purpose of
the redesign, I'd like to keep the old GtkComboBox API so that users
benefit by the new usability immediately.

Is it a just a visual refresh, making the new widget seem more new GTK+
than the old one?

Is it the ability to use widgets instead of cell renderers in ComboBox? OK.
Is that worth a new visual refresh and new usability scenario? Could we
upgrade both at the same time, and have one API for widgets, and one API
for cell renderers? Would that be feasible?

My issue, really, is that I haven't really been keeping up with GTK+
development and new widgets over the course of time. I hack on some
personal apps in my spare time.

If we add GtkCombo as a separate question, I have one simple question: when
should I use GtkCombo and when should I use GtkComboBox?

Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
stunned. Why should I use one instead of the other? We have GtkMenuButton,
GtkMenu, GtkModelMenu, GtkModelButton, GtkPopover, GtkPopoverMenu, and they
all sort of do the thing. I have no idea which to use nowadays.

(This is not a chance to explain what they do: I have an understanding of
what does what after reading the docs. But imagine someone who's never done
GTK+ development before. What's the new hot, correct, widget to use if
you want a menu button in your app? What's it called? OK. Why are the
others there?)

[0] http://harvesthq.github.io/chosen/

On Sat, Dec 27, 2014 at 5:02 AM, Matthias Clasen matthias.cla...@gmail.com
wrote:

 Hi,

 over Christmas, I had some for a little side project, a  new combo
 box. It is based on these mockups:

 https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png

 One question I need some feedback on is naming: We currently have
 GtkComboBox and
 GtkComboBoxText. I've gone with GtkCombo for now, which has the
 downside that there is a widget by that name in gtk2. Alternatives
 might be GtkChoice or GtkComboButton (with a possible avenue for
 making the list-of-choices available for direct embeeding as
 GtkComboWidget later).

 There are some lose ends in the code, like the interaction of grouping
 and search, but it is complete enough to give it a try and evaluate
 the design. If you want to try it, the code is in the wip/combo
 branch, and there is a testnewcombo test app with some examples.

 I'm off for a few days now - would be great to hear some feedback when
 I come back.

 Matthias
 ___
 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

Re: gtk_widget_set_double_buffered() is deprecated, so what can replace it?

[Jasper St. Pierre]

On Wed, Nov 26, 2014 at 10:40 AM, Lance Arsenault lance.arsena...@gmail.com
 wrote:

 Hello GTK developer,

 I've read the latest docs, looked at the latest (git) GTK+3 code, and
 searched the archives, and found not direct answer to this question:

 1.  Is there a method, that is not deprecated, that can give the effect of
 gtk_widget_set_double_buffered() for GTK3?


No. It will continue to work on X11, but it won't work on new backends like
Wayland or Mir.


 There are a lot of apps that must use the underlying/native drawing APIs
 like libX11 and OpenGL to draw to a X11 window that is within a GTK+3.0
 app.  It is very clear that drawing to, or transferring content to, a Cairo
 surface is far too slow for apps that render real-time animations in an X11
 window.


Why would it be too slow? GDK has also recently gained support for native
GL drawing: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html which
works perfectly in tandem with the double buffering drawing. Both of these
options should be performant enough, and if not, we'd prefer to improve the
performance of our cross-platform APIs rather than add new ways to work
around it.

Many apps must use X11 and/or OpenGL, and GTK+3.0 together, so what's the
 new hook that will stop GTK from using Cairo surface double buffering in a
 GTK+ drawing area.

 cheers
 lance





 ___
 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

Re: gtk_widget_set_double_buffered() is deprecated, so what can replace it?

[Jasper St. Pierre]

Hey,

I just built Quickscope from source, and can't find any code that draws
using cairo inside it. Where is it?

On Wed, Nov 26, 2014 at 6:08 PM, Lance Arsenault lance.arsena...@gmail.com
wrote:

 Hi  Emmanuele,

  apps using X11 to draw directly should stop doing that, because this is
 not 1997 any more, and we have better drawing API.


 Many many apps need a faster drawing API than Cairo in order to do high
 frame rate animations.  Interactive games is the most popular example.

 I have an unusual app that requires faster drawing without animations.
 It's the difference between being able to use the app for some purposes or
 not, that is to say it's the difference between working and not working.
  So Cairo is just not usable in this case, it's far to slow.  Why should I
 care that libX11 is old?

 This is not a small set of users that need this.  People don't care that
 the code is old, so long as it works for what we are doing.  Please
 consider that Cairo is too slow for many applications.  The largest group
 of apps that require fast drawing are openGL apps, but there is also a
 somewhat smaller group of apps that need faster 2-D drawing too.  Cairo
 does not meet many minimum speed requirements.  I hear that GtkGLArea is
 coming of age.  I hope that I can use it for 2-D drawing too, but I will be
 sticking with libX11 drawing if that is faster than OpenGL for my use case,
 and I expect that drawing with libX11 will be faster for my use case.  (see
 below for more verbose with real runnable examples)

 I got two responses from my query.   I attach more below.  I forgot to CC
 the list in the email I sent before this one.

 cheers
 lance



 I'm not sure where this is going but I need to make sure I'm clearly
 understood.  Sorry for being too verbose. If you respond, please read it
 all.


 1.  on Cairo speed:   I've spent many days testing Cairo for speed.  Cairo
 draws lines very slowly compared to libX11 XDrawLines().  It does lots of
 nice things, but sometimes you just need to draw as fast as possible.  In
 the current app I'm developing I can't even use XDrawLines().  I use
 XDrawPoints() with my own line drawing code, and I use my own anti-aliasing
 code for some of the lines.

 2.  The GtkGLArea https://developer.gnome.org/
 gtk3/unstable/GtkGLArea.html is news to me.  I will look into it.
 Currently I'd like to use it to draw with libX11 and not directly with
 openGL given I'm just doing 2-D drawing with just point drawing.  It's a
 little unclear what the fastest simple 2-D pixel drawing method is, because
 I see the X-server may be doing the right things already for fast 2-D
 drawing, i.e. I see it's using shared memory to get my pixels from my
 program, it links with OpenGL libs, and etc.  Sounds like way way more than
 I need, and it's likely to slow things down, compared to what I have now.
 I'm also looking into libXrender, but know almost nothing about it yet.

 3.  If you'd like to understand my perspective about drawing speed I have
 an example that explains it well when using a GNU/Linux system.  Install
 quickplot (available on debian apt-get install quickplot) and run
 `quickplot LARGESOUNDFILE' where LARGESOUNDFILE is about a 3 minute sound
 file.  You will see quickplot display the whole sound file in about 3
 seconds.   Running `quickplot -c LARGESOUNDFILE' takes about 15 seconds to
 display.  That is because the '-c' option makes quickplot use Cairo to
 draw.  Of course back when I wrote quickplot using GTK+3.0 the difference
 was much more dramatic.  This may be a stupid example, but it makes my
 point, Cairo is slow.

 4.  Now I'm making a software oscilloscope and 2-D drawing speed is
 paramount.  I see that in the GTK+3.0 code that there is Cairo code in
 gtk_widget_send_expose() that is adding system resource waste with
 gdk_cairo_create(), which I don't need, given I'm drawing with libX11 and
 not Cairo.   This is not so bad, for this scope, given that most of the
 time the GTK+ draw event and its callbacks are not used in most of my
 draw display frames (just used in initial draws).  My code just draws over
 the X11 window without using GTK events, at like, for example, 60 times a
 second.  This seems like a nasty hack.  Clearly if GTK+3.0 has a method to
 add animations I do not want to use it, given that it will do a bunch of
 Cairo stuff that I'll just want to work around it order to get the speed
 that I need.

 5.   Optional:  If you got this far.   You can see for yourself what I'm
 up too and why GTK+3.0 needs to support fast 2-D drawing:

 sudo apt-get install libsndfile-dev  # the prerequisite you may not have
 \
 mkdir -p ${HOME}/tmp_quickscope  \
 cd ${HOME}/tmp_quickscope  \
 git clone https://github.com/lanceman2/quickscope.git  \
 cd ${HOME}/tmp_quickscope/quickscope  \
 ./bootstrap  \
 ./configure --enable-debug --enable-tests --prefix ${HOME}/tmp_quickscope
  \
 make -j3  ./tests/alsaCapture

 I just successfully cut and pasted and ran that on my 

Re: help wanted for implementing GdkGLContext on Windows and MacOS X

[Jasper St. Pierre]

Yeah, this is an unfortunate bug with libepoxy right now. There's a PR on
GitHub if you want to see if that fixes it.

https://github.com/anholt/libepoxy/pull/28

All we can do is pressure Eric Anholt to merge it at this point.

On Wed, Nov 19, 2014 at 12:03 AM, Philip Chimento philip.chime...@gmail.com
 wrote:

 On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi eba...@gmail.com wrote:

 hi all;

 I posted this on my blog, which is syndacated on Planet GNOME, but I
 thought about trying to reach out to more people by using the GTK+
 mailing list as well.

 GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and
 Wayland.

 if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're
 using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or
 3.x, then I'm asking you to help out with patches and testing the
 OpenGL support in the master branch of GTK+. we'd really like to have
 OpenGL support working on all the major backends in GDK by the time we
 release GTK+ 3.16.0, next February.


 I've started trying to build GTK master on OSX; looks like libepoxy is now
 a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that
 dependency? It seems to me that I shouldn't need X11 for the Quartz backend.
 --
 Philip

 ___
 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

Re: GTK+ scene graph, API deprecations

[Jasper St. Pierre]

On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet swil...@gnome.org wrote:

 On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
  On 16 August 2014 16:23, Sébastien Wilmet swil...@gnome.org wrote:
 
   With GskLayerContent, will it be possible to unify cell renderer and
   widget drawing models? To simplify significantly the GtkTreeView
   implementation, for example, and be able to insert a GtkWidget in a
   GtkTreeView.
 
  not without breaking API.
 
  we cannot really re-implement GtkWidget using GSK layers without
  breaking ABI in any case — think of whoever connects to
  GtkDrawingArea's ::draw signal, or whoever subclasses a GtkWidget and
  overrides the draw() virtual function; suddenly, they wouldn't be
  drawing on a cairo_t associated with a whole GtkWidget, but on a GSK
  layer's content. where would that layer go? on top? at the bottom of
  the stack? what happens if I connect to ::draw and then stop the
  signal emission?
 
  for GTK+ 3.x, the scene graph API is going to be available for you to
  write new widgets with a scene inside them, and to put widgets inside
  a scene. the short term goal is to fully replace the current usage of
  Clutter and Clutter-GTK (and possibly Clutter-GStreamer) throughout
  the GNOME stack; anything else is on a purely speculative basis, and
  it will land if and only if it does not break API and/or ABI. a full
  rework of the GTK widgets to use the scene graph API is going to wait
  until we can release GTK+ 4.

 Ok I see.

  it is also my opinion that, if we break API, we may as well deprecate
  GtkTreeView and replace it with the list widget backend by a model,
  and drop the whole cell renderer scene API in the first place.

 But GtkTreeView has the advantage that it already works and is mostly
 feature complete (to display trees too), and is used in lots of
 libraries and applications, with custom models etc. It seems easier to
 me to do code refactorings in GtkTreeView than creating a completely new
 widget from scratch.


... ahahahahaha


 And if GSK can potentially simplify a lot the
 GtkTreeView implementation in the future, and with the API break for GTK
 + 4, another solution is to simplify both the API and implementation of
 GtkTreeView for GTK+ 4.

 That said, I've never worked on the GtkTreeView code.


Ah, that's why. I vote you a volunteer for the GSK-ification of GtkTreeView
then.


 Maybe one of the
 reasons to create a new widget from scratch is because nobody wants to
 work on GtkTreeView anymore. But if that is the case, maybe in 10 years
 nobody will want to work on GtkListBox anymore, and developers will
 reinvent the wheels continually, by deprecating more and more APIs,
 creating new ones every decade, and make application developers grumpy.

 So in short, if some of the GTK+ code is a mess, why not keeping the
 same APIs while improving internally the code?


Because every time we try to clean up GtkTreeView, we break some random
application. It's a widget that has twenty three gazillion use cases, and
so we have to keep it a mess, because removing the mess means removing one
use case, and we can't do that.

You're welcome to try, though.


 --
 Sébastien

 ___
 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

Re: GTK+ scene graph

[Jasper St. Pierre]

On Sun, Aug 3, 2014 at 6:08 AM, Sébastien Wilmet swil...@gnome.org wrote:

 Thanks for the explanation.

 On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
  snip

  yes, it was considered, and no: depth (or similar terms) won't be used.
 
  people using a canvas with 3D transformations intuitively grasp the
  concept of a Z axis, as well as that of a coordinate on that axis.
  they understand rotations around that axis, as well as scaling and
  translation.
 
  using depth would be confused with the possibility of having real
  3D objects, with a width, height, and depth.

 Ok so there are good reasons behind that. depth-axis would be a
 solution, but it's too long and x/y/z is a widespread convention. I was
 just wondering if the GSK API contains other conventions, maybe less
 widespread.


An API designed to be commonly used and understood by graphics programmers
is exactly the place where you don't want to use obscure, less widespread
conventions.


 ___
 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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Hey everyone again

I wasn't expecting this much fallout from the change. I was hoping most of
the GTK+ applications were only using widgets and draw signals. I was wrong.

I've effectively pushed a revert of these changes:

https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf

Note that gtk_widget_set_double_buffered is still deprecated, and calling
gdk_cairo_create outside of a begin_paint_region / end_paint is still
considered legacy and isn't guaranteed to work on any backends other than
X11. Everything should be functioning correctly. So, we're choosing to make
these things work for X11, but new backends like Wayland, Broadway and Mir
might not work with them.

If your application still has flickering or prints runtime warnings or
crashes, *please* let me know. We should be back to where we were
beforehand, but things do sometimes slip through the cracks.

Thanks to everyone who gave me feedback -- it's been a frustrating past few
days for everyone, and I'm sorry for the breakage I caused. I have a much
better handle on the situation now and the way applications are using our
toolkit.

If you have any other feedback about modern drawing in GTK+, please let us
know. We're always trying to support application developers, even if it may
not seem like it, and if our existing APIs aren't suiting your use cases,
we need to know.


On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 To better support Wayland with fewer copies and less drawing artifacts,
 I've pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.


 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848

 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of
 a begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return
 a dummy surface which won't ever be composited back into the main surface.

 Additionally, it is now forbidden to call gdk_window_begin_paint_region
 more than once. Previously, the code had a paint stack which tracked
 paints, but since GTK+ never used this codepath it was never actually
 tested and was indeed broken on Wayland due to the way the Wayland backend
 was written. Again, we will print a warning in this case and return.

 As part of these changes, gtk_widget_set_double_buffered was deprecated
 and removed. Again, it will never work on Wayland, as that is natively
 double-buffered, and it would simply break there.

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse, or any big GTK+ apps like Inkscape or The GIMP.

 Please double-check to make sure your apps still work fine. If you have a
 problem with any of this or I broke your apps by accident, please reply and
 I'll try to fix it.

 Thanks!

 --
   Jasper




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Sure, I'm not familiar with the Win32 or Quartz backends, so I didn't want
to say anything too definitive about those backends. But it's nice to hear
that it works as well.


On Mon, Jun 23, 2014 at 6:39 PM, Morten Welinder mort...@gnome.org wrote:

 For the record, the use of gdk_cairo_create outside of a
 begin_paint_region / end_paint pair also seems to work fine on win32.

 Morten


 On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre
 jstpie...@mecheye.net wrote:
  Hey everyone again
 
  I wasn't expecting this much fallout from the change. I was hoping most
 of
  the GTK+ applications were only using widgets and draw signals. I was
 wrong.
 
  I've effectively pushed a revert of these changes:
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
 
 https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf
 
  Note that gtk_widget_set_double_buffered is still deprecated, and calling
  gdk_cairo_create outside of a begin_paint_region / end_paint is still
  considered legacy and isn't guaranteed to work on any backends other than
  X11. Everything should be functioning correctly. So, we're choosing to
 make
  these things work for X11, but new backends like Wayland, Broadway and
 Mir
  might not work with them.
 
  If your application still has flickering or prints runtime warnings or
  crashes, *please* let me know. We should be back to where we were
  beforehand, but things do sometimes slip through the cracks.
 
  Thanks to everyone who gave me feedback -- it's been a frustrating past
 few
  days for everyone, and I'm sorry for the breakage I caused. I have a much
  better handle on the situation now and the way applications are using our
  toolkit.
 
  If you have any other feedback about modern drawing in GTK+, please let
 us
  know. We're always trying to support application developers, even if it
 may
  not seem like it, and if our existing APIs aren't suiting your use
 cases, we
  need to know.
 
 
  On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre 
 jstpie...@mecheye.net
  wrote:
 
  To better support Wayland with fewer copies and less drawing artifacts,
  I've pushed some potentially breaking changes to GDK, namely around
  gdk_cairo_create and gdk_window_begin_paint_region.
 
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e
 
  With these changes, it is now illegal to call gdk_cairo_create outside
 of
  a begin_paint / end_paint. This was always sketchy, and would never
 work on
  Wayland anyway. If your code does this, we will print a warning and
 return a
  dummy surface which won't ever be composited back into the main surface.
 
  Additionally, it is now forbidden to call gdk_window_begin_paint_region
  more than once. Previously, the code had a paint stack which tracked
  paints, but since GTK+ never used this codepath it was never actually
 tested
  and was indeed broken on Wayland due to the way the Wayland backend was
  written. Again, we will print a warning in this case and return.
 
  As part of these changes, gtk_widget_set_double_buffered was deprecated
  and removed. Again, it will never work on Wayland, as that is natively
  double-buffered, and it would simply break there.
 
  I tested with some local big applications like Ardour and the GNOME
  applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse,
  or any big GTK+ apps like Inkscape or The GIMP.
 
  Please double-check to make sure your apps still work fine. If you have
 a
  problem with any of this or I broke your apps by accident, please reply
 and
  I'll try to fix it.
 
  Thanks!
 
  --
Jasper
 
 
 
 
  --
Jasper
 
  ___
  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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

I can't reproduce any issue in scrolling with evince locally -- does it
only happen with certain documents? Can you point to a document where you
have problems?

I also just built Scintilla and SCiTE from source, but they both appear to
be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or port, or
did I do something wrong when building Scintilla/SCiTE?


On Mon, Jun 23, 2014 at 7:45 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 00:02, Jasper St. Pierre a écrit :
  Hey everyone again
 
  [...]
 
  I've effectively pushed a revert of these changes:
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
 
 https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf
 
  [...]
 
  If your application still has flickering or prints runtime warnings or
  crashes, *please* let me know. We should be back to where we were
  beforehand, but things do sometimes slip through the cracks.

 Sorry, but apparently 984e811c16891cb4945a090bea8ec9e81ce3dba6 (result
 of a bisect) breaks badly in some situation.  With it, if I scroll
 aggressively in some apps (at least Evince and SciTE) I can get the X
 server to start consuming extreme CPU (even after the scroll ended).

 Not only the application gets extremely slugish, but other apps too,
 e.g. scrolling a terminal is equally slow and consumes resources, as
 well as drawing other apps.

 However, as soon as I close the initial app, everything comes back to
 normal.

 I don't know really how to debug this, but tell me if I can do anything.

 Regards,
 Colomban
 ___
 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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

May I ask why you can't paint in the draw signal? GDK already tracks
invalidated windows marked by exposes and gdk_window_invalidate_rect
itself. It should be as efficient as drawing in an idle handler, and also
cooperates with the paint clock, where we can be synchronized to a
compositor's redraw cycle.


On Mon, Jun 23, 2014 at 8:53 PM, Krzysztof Kosiński tweenk...@gmail.com
wrote:

 2014-06-21 3:00 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
  To better support Wayland with fewer copies and less drawing artifacts,
 I've
  pushed some potentially breaking changes to GDK, namely around
  gdk_cairo_create and gdk_window_begin_paint_region.
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e
 
  With these changes, it is now illegal to call gdk_cairo_create outside
 of a
  begin_paint / end_paint. This was always sketchy, and would never work on
  Wayland anyway. If your code does this, we will print a warning and
 return a
  dummy surface which won't ever be composited back into the main surface.

 This will also break the GTK 3 version of Inkscape, which paints its
 canvas in an idle handler, and the draw signal only marks areas for
 redraw. However, it may be fixable by using the begin_paint APIs.

 Regards, Krzysztof




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Thanks, I managed to reproduce the issue with this. It only happens with
thumbnails visible, though, which suggests that evince is doing something
funny for the thumbnails view. I'll also check out Scintilla later.

On Mon, Jun 23, 2014 at 8:19 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 02:03, Jasper St. Pierre a écrit :
  I can't reproduce any issue in scrolling with evince locally -- does it
  only happen with certain documents? Can you point to a document where
  you have problems?

 I doubt it's document-related, as it worked with the first three PDFs
 I tried with.  Anyway, I can reproduce with e.g.
 http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf   Note however
 that you have to scroll *aggressively*, meaning I'm was assaulting my
 mouse wheel for several seconds, or take the scrollbar grip and shake it
 quick.  Also it's less directly visible with Evince itself which seems
 to have a very cheap scroll draw (yet you probably notice something),
 but other apps gets slow-slow (for example gedit's gear menu takes like
 5s to open).

 I also just tried to enable Metacity's compositing as I was using it
 without, and I can reproduce with and without compositing.

  I also just built Scintilla and SCiTE from source, but they both appear
  to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or
  port, or did I do something wrong when building Scintilla/SCiTE?

 you need to set the GTK3 make variable to 1:

 $ cd gtk
 $ make GTK3=1

 Regards,
 Colomban


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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Great eye! Pushed, thanks! I'm sure that's what it was.


On Mon, Jun 23, 2014 at 9:41 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 03:03, Jasper St. Pierre a écrit :
  Thanks, I managed to reproduce the issue with this. It only happens with
  thumbnails visible, though, which suggests that evince is doing
  something funny for the thumbnails view. I'll also check out Scintilla
  later.

 OK, it's fairly obvious after looking at the diff: there's a missing
 cairo_surface_destroy() in the new version of gdk_cairo_create(), hence
 the surface will probably be leaked and God knows what happens on the
 server side.  Patch attached.

 Regards,
 Colomban




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

You can draw to a pixbuf or cairo image surface from another thread or in
an idle handler, and then paint it to your window in the draw handler.
That's probably the best idea, actually. This is what things like the new
GtkListBox do -- cache the pixels in a pixel cache, and use that to draw to
your window, synchronized with the paint clock.


On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński tweenk...@gmail.com
wrote:

 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
  May I ask why you can't paint in the draw signal? GDK already tracks
  invalidated windows marked by exposes and gdk_window_invalidate_rect
 itself.
  It should be as efficient as drawing in an idle handler, and also
 cooperates
  with the paint clock, where we can be synchronized to a compositor's
 redraw
  cycle.

 If all drawing happens in the draw signal and the document has a lot
 of demanding effects, e.g. SVG filters, it would completely kill
 responsiveness of the UI. The idle handler solution also allows us
 easily move drawing to a separate thread in the near future.

 In general, the document displayed in Inkscape cannot be drawn in one
 piece; it must be rendered as a series of strips that are shown on the
 screen once they are ready. Otherwise it takes far too long.

 Although I heavily rewrote the lower levels of Inkscape canvas (those
 dealing with SVG objects) to use Cairo and generally cleaned it up,
 the upper levels, dealing with editing controls and scheduling the
 rendering, are still barely changed from the Sodipodi days. It is
 certainly possible to do all drawing in a draw signal, for example by
 submitting an invalidate request once a piece of the drawing has
 finished rendering, but it will require a nontrivial amount of work.

 Regards, Krzysztof




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Can you two explain exactly what Abiword and Gnumeric are doing, what APIs
they're using and why and so on? We're trying to come up with a solution
that will work well under both X11 and Wayland.

As I said, if it's a really bad break and would require intensive changes
to apps, I'll revert the patches. This is exactly why I sent out the mail.

On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 This will break abiword as well.

 Jean

 Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a écrit :
  Argh!
 
  Will the stream of ABI changes never end?
 
  Gnumeric uses this to provide a walking-ant cursor large selected areas
 -- areas
  too big for processing in the normal paint loop.
 
  Morten


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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Yes, that should work. Make sure to test it, though, as begin_paint_rect /
begin_paint_region currently clears the specified rect/region to the
background set on the GdkWindow. If passing a more exact region is too much
of an annoyance, I should be able to also change this without breaking too
much so that the clear to background only happens on expose events.

It's difficult to balance the requirements of everybody.


On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 Both abiword and gnumeric do something like:

 cr = gdk_cairo_create(win);
 ...do some drawing
 then relase the cairo.

 Will this still work if we use

 gdk_window_begin_paint_rect (win, rect);
 cr = gdk_cairo_create (win);
 ...do some drawing
 gdk_window_end_paint (win);

 ?



 Le samedi 21 juin 2014 à 09:33 -0400, Jasper St. Pierre a écrit :
  Can you two explain exactly what Abiword and Gnumeric are doing, what
  APIs they're using and why and so on? We're trying to come up with a
  solution that will work well under both X11 and Wayland.
 
  As I said, if it's a really bad break and would require intensive
  changes to apps, I'll revert the patches. This is exactly why I sent
  out the mail.
 
 
  On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort
  jean.bref...@normalesup.org wrote:
  This will break abiword as well.
 
  Jean
 
  Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a
  écrit :
   Argh!
  
   Will the stream of ABI changes never end?
  
   Gnumeric uses this to provide a walking-ant cursor large
  selected areas -- areas
   too big for processing in the normal paint loop.
  
   Morten
 
 
  --
Jasper
 





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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Honest question: which ones? The only requirement we have with Wayland is
that we know when a paint has begun and when it has ended, and also the
rough area of paint, so we can tell the Wayland compositor when to swap
buffers, and from which rectangles.

The draw signal does this automatically, but we can expose this in other
places.

I'm skeptical of the performance concerns of the draw signal. With the new
paint clock system we have, draw events are throttled and locked to the
compositor, so it should be faster to queue a redraw and wait until the
frame is drawn, and do it all in one go. But I'm fine with changing
begin_paint_region so that it no longer clears to background, if only to
help people trying to port to the crazy new drawing world.


On Sat, Jun 21, 2014 at 10:05 AM, Paul Davis p...@linuxaudiosystems.com
wrote:




 On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort 
 jean.bref...@normalesup.org wrote:


  you're drawing on the window outside of an expose/draw event?

 Yes, because using draw events presents serious performance issues.


 can you describe these or point to a description of them? there are
 several native window(ing) systems where this is actually impossible to
 do.




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

On Sat, Jun 21, 2014 at 11:18 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 I know that an expose event contains a region, but this does not help,
 we use the draw event, and I don't know how to reliably access the
 region. More, it is not really easy to determine what needs to be
 redrawn from inside a draw event.


The cairo context you get in the draw signal is clipped to the expose
region by default, which means that cairo will do culling for you
automatically. If you need to do extra processing to determine if some
complex update method should be run based on the clip region (which is
really a big edge case -- you shouldn't need to do this!), you can use
cairo_in_clip or cairo_clip_extents.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 Honest question: which ones? The only requirement we have with Wayland is
 that we know when a paint has begun and when it has ended, and also the
 rough area of paint, so we can tell the Wayland compositor when to swap
 buffers, and from which rectangles.

 The draw signal does this automatically, but we can expose this in other
 places.

 I'm skeptical of the performance concerns of the draw signal. With the new
 paint clock system we have, draw events are throttled and locked to the
 compositor, so it should be faster to queue a redraw and wait until the
 frame is drawn, and do it all in one go. But I'm fine with changing
 begin_paint_region so that it no longer clears to background, if only to
 help people trying to port to the crazy new drawing world.


Heads-up: I went ahead and pushed a branch for this at
https://git.gnome.org/browse/gtk+/log/?h=wip/paint-stack-cleanup

Basically, gdk_window_begin_paint_region / gdk_window_begin_paint_rect no
longer clear to the background automatically, which means you can use them
out-of-band. To clear to the background explicitly, you can use
gdk_window_paint_background.

Since it adds new API, I'm not going to push it to master until I can get
some peer review, which likely means it won't get pushed until Monday. If
you could test with this branch and let me know the results, that would be
great!

I do encourage everyone to try using the draw event / draw signal
again. With our recent paint clock and event throttling work from 3.8
onwards, we should be able to make it fast without having to resort to
hacks like gdk_cairo_create.

Sorry for all the breakage! I really don't want to bug anybody too much,
but I do want to make sure that our toolkit and all our applications can
work out of the box on modern platforms like Wayland.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

On Sat, Jun 21, 2014 at 11:42 AM, Paul Davis p...@linuxaudiosystems.com
wrote:


 the expose region or the expose area ? the former is a potentially
 discontiguous set of rectangles, the latter is their union. yes?


The expose region. See gtk_widget_send_expose:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c#n7518

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

On Fri, Jun 20, 2014 at 11:57 PM, A. Walton awal...@gnome.org wrote:

 On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 To better support Wayland with fewer copies and less drawing artifacts,
 I've pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.


 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848

 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of
 a begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return
 a dummy surface which won't ever be composited back into the main surface.

 Additionally, it is now forbidden to call gdk_window_begin_paint_region
 more than once. Previously, the code had a paint stack which tracked
 paints, but since GTK+ never used this codepath it was never actually
 tested and was indeed broken on Wayland due to the way the Wayland backend
 was written. Again, we will print a warning in this case and return.

 As part of these changes, gtk_widget_set_double_buffered was deprecated
 and removed. Again, it will never work on Wayland, as that is natively
 double-buffered, and it would simply break there.

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse, or any big GTK+ apps like Inkscape or The GIMP.

 Please double-check to make sure your apps still work fine. If you have a
 problem with any of this or I broke your apps by accident, please reply and
 I'll try to fix it.


 While I don't have anything negative to say about this particular patch
 series (I honestly think it's somewhat overdue), encoding knowledge such as
 this into commits and mailing list messages make it much, much harder to
 develop applications against Gtk+.

 None of the commits that changed this did anything to touch the
 documentation saying why this was the case and how to fix your applications
 if they're busted. This is not allowed should be This is not allowed
 since [when]. The commit that removed the double buffering property should
 emit a warning if an application sets the flag to false so that application
 developers can catch this kind of thing in development.


We haven't ever emitted runtime warnings for using deprecated APIs, and I'm
not sure I want to start doing that for now. Are the compile-time
deprecation warnings not enough for you?

I'm not aware of how applications might be broken by the
gtk_widget_set_double_buffered deprecation, and the other cases had runtime
warnings attached to them.


 I beg of you guys as both a commercial and open source GTK+ application
 developer, show us a tiny bit of mercy and document changes like this in
 places other than commit messages and mailing list threads.


Any suggestions for where else to document them? I marked all the
appropriate functions as deprecated and changed their documentation to say
that they do nothing. I'd be happy to adjust the documentation, but I'm not
aware of anywhere else I can do it.

Thanks for your work Jasper,

 -Andrew Walton


 Thanks!

 --
   Jasper

 ___
 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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

On Fri, Jun 20, 2014 at 9:30 PM, Paul Davis p...@linuxaudiosystems.com
wrote:

 On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:


 As part of these changes, gtk_widget_set_double_buffered was deprecated
 and removed.


 Yay!

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse, or any big GTK+ apps like Inkscape or The GIMP.


 Wait. You managed to build Ardour with GTK3 ? Seriously? Tell me more!


Hah, the dark theme fooled me :)

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Jasper St. Pierre]

Thanks for your use case. I've added a runtime warning for you! Let me know
if you hit it and are having trouble solving it -- there's not much in the
way of recommendations about how to solve it if it's causing a bug, since
the code that was there before was removed.

https://git.gnome.org/browse/gtk+/commit/?id=6bc251692a202c6ec54572cdab0dd68df16c77df

On Sat, Jun 21, 2014 at 12:24 AM, A. Walton awal...@gnome.org wrote:


 [Commercial Developer Hat - speaking on behalf of myself and not the
 company]

 My day job is maintaining an application called VMware Workstation. The
 application is among one of the oldest and largest Gtk+ codebases at 15
 years old, and has survived almost every major GNOME regime change from
 Gtk+ 1.3 to Bonobo to the D-Bus revolution to GIO to Gtk+ 3. As you might
 imagine, we're stuck using a few deprecated APIs (like, e.g., stock icons,
 of which we get thousands of warnings for alone while compiling).

 As such, we hit all kinds of these random issues through the ages, where
 subtle changes are made in Gtk+ and we spend our time tracking them down
 through Google and grepping hopefully through git logs. It's tiresome and
 it is rapidly turning my beard gray.

 The runtime warning would be incredibly helpful for tracking down these
 kinds of things in development - we build shipped versions of our
 application with these warnings suppressed anyways, and the GNOME team has
 already done(/undone ;) this in many other occasions:


 https://git.gnome.org/browse/glib/commit/?id=85e9455f68c6cc6093a1ede1c5f15587bba08b51

 https://git.gnome.org/browse/glib/commit/?id=f2f66bfe45f41d18e7437341e5ebf4c70d815958

 -Andrew Walton


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

Re: is shared memory hardcoded to zero in gnome-system-monitor?

[Jasper St. Pierre]

It seems 0 is the correct value. See this bug:

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

And while the filenames have changed from 2.4, it seems the behavior is
still the same:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/page_alloc.c#n2999


On Wed, Mar 5, 2014 at 7:54 PM, Giovanni Gherdovich
g.gherdov...@gmail.comwrote:

 Hello,

 I was reading libgtop code and noticed this snippet at sysdeps/linux/mem.c
 https://git.gnome.org/browse/libgtop/tree/sysdeps/linux/mem.c#n58

 --8---
 file_to_buffer(server, buffer, sizeof buffer, FILENAME);

 buf-total  = get_scaled(buffer, MemTotal:);
 buf-free   = get_scaled(buffer, MemFree:);
 buf-used   = buf-total - buf-free;
 buf-shared = 0;
 buf-buffer = get_scaled(buffer, Buffers:);
 buf-cached = get_scaled(buffer, Cached:);
 --8---

 where FILENAME is /proc/meminfo.

 Question:
 why is buf-shared hardcoded to zero?
 Is it intentional or a woops?

 man proc is pretty vague about the Shmem field
 of /proc/meminfo (it says to be documented),
 which seems to be the candidate for filling buf-shared,
 http://linux.die.net/man/5/proc

 but I was suprised to discover that gnome-system-monitor
 is wired to a flat constant zero (is it?) when it comes to show
 the amount of shared memory.

 Cheers,
 GGhh

 ___
 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

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

[Jasper St. Pierre]

Can we do that without breaking backwards compatibility? For instance, if I
have an old proxy config, and I upgrade to a new glib-networking / libsoup,
will I, as a user, have to re-set it for the new path layouts? Do we have a
migration tool to fix things like this?

(My local copy of glib actually has those deprecation warnings commented
out, because nobody has fixed them and they're difficult to fix without
breaking things, and warnings that nobody will ever fix is bad)


On Mon, Mar 3, 2014 at 9:59 AM, Dan Winship d...@gnome.org wrote:

 On 03/03/2014 09:40 AM, Colin Walters wrote:
  1) Split off some of the core settings like org.gnome.system.proxy into
  gsettings-core-settings or something

 The current proxy settings (and maybe some of the others in
 gsettings-desktop-schemas) cause warnings every time you install a new
 schema, because they still use an old GConf-style path
 (/system/network/proxy) rather than reverse-DNS-style.

 Also, the proxy settings have a ton of deprecated and/or unused keys,
 and it's not currently possible to configure proxies in certain ways.

 So... if we're going to do anything with the proxy schemas, we should
 move/rename and reorganize them at the same time.

 -- Dan

 ___
 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

Re: where i find a manual for write a wm in gtk3 ?

[Jasper St. Pierre]

Except you can't. GTK+ will deadlock your WM if you try to use it, unless
you do it very carefully (read: add 5000 lines of code, fake out GDK all
over the place, and implement an entire confusing state machine).

You can't use GTK+ to build a WM.


On Thu, Feb 27, 2014 at 2:18 AM, Andy Spencer andy753...@gmail.com wrote:

 On 2014-02-26 21:55Z, major_ghz wrote:
  i follow the begining of GTK-3 Reference Manual, but explan only for
  an application in gtk3
 
  not for write a litle wm.
 
  can you help me for begining this projet ?

 All the other people who told you not to do this are probably correct,
 but since you did ask a specific question, I'll at least try to answer.

 Before you write an WM in GTK you'll want to learn how to write a WM
 without GTK. Start with some existing simple window managers and learn
 how they works (e.g. what SubstructureRedirectMask does). xcb would be
 better, but xlib will be easier just because there's more examples. Then
 once you have something that runs and manages windows, you can think
 about adding GTK to it to do title bar drawing, or context menu's, or
 whatever it is that you want to use GTK for.
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

Re: where i find a manual for write a wm in gtk3 ?

[Jasper St. Pierre]

It does, but the code for that is quite complicated and we've ran into many
issues. They're some of the biggest issues holding up the Wayland port of
mutter right now.

See https://git.gnome.org/browse/mutter/tree/src/ui/ui.c#n90 for some of
the fun code you'll have to write to not deadlock GTK+.


On Thu, Feb 27, 2014 at 11:42 AM, Andy Spencer andy753...@gmail.com wrote:

 On 2014-02-27 12:40Z, Jasper St. Pierre wrote:
  Except you can't. GTK+ will deadlock your WM if you try to use it,
  unless you do it very carefully (read: add 5000 lines of code, fake
  out GDK all over the place, and implement an entire confusing state
  machine).
 
  You can't use GTK+ to build a WM.

 I thought metacity used GTK+ for things like right click menus at least,
 or is the issue a GTK+ 3 thing?

 Would it work better to use offscreen windows for the GTK stuff?




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

Re: where i find a manual for write a wm in gtk3 ?

[Jasper St. Pierre]

GTK+ is a toolkit for developing applications, not for developing WMs. In
fact, GTK+ will very often get in the way of building a WM, because you can
easily deadlock if you aren't careful.

You should really build a WM with raw XCB or XLib.


On Wed, Feb 26, 2014 at 4:55 PM, major_ghz major_...@electronique-libre.org
 wrote:

 hello,

 i follow the begining of GTK-3 Reference Manual, but explan only for an
 application in gtk3

 not for write a litle wm.

 can you help me for begining this projet ?
 best regard,
 major.
 ___
 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

Re: How to re-enable icons in menus?

[Jasper St. Pierre]

We add XSettings at will now, as it's really our only way to get platform
settings hooked into GTK+.

You can see all of the ones that GTK+ pays attention to here:

https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdksettings.c#n25


On Tue, Feb 4, 2014 at 7:16 AM, Chris Vine ch...@cvine.freeserve.co.ukwrote:

 On Tue, 04 Feb 2014 09:39:26 +0100
 Michael Lipp m...@mnl.de wrote:
  Am 04.02.2014 01:42, schrieb Matthias Clasen:
   Hey,
  
   you didn't say which environment this struggle is happening in, so
   I'm just going to assume it is GNOME, and gnome-settings-daemon is
   running. In that case,
  
   gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
   {'Gtk/MenuImages':1}
  
   will do what you are asking for. However, you might find that many
   menuitems just don't contain icons anymore - in that case, no
   setting will bring it back.
  
  
   Matthias
 
 [snip]
  Anyway, being a bit curious about these settings now, is there any
  kind of reference where those helpful secrets are documented
  (besides reading the code)?

 [top posting rearranged to be readable]
 [follow-ups not set, but should go to another list]

 The freedesktop.org Xsettings registry entries are here:

 http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/

 Chris
 ___
 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

Re: Regarding Maintainer of package gdk-pixbuf

[Jasper St. Pierre]

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

Re: symbolic icon fallback failure

[Jasper St. Pierre]

On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@cam.ac.uk wrote:

 Originally I thought that the lack of icons on my system in the post
 stock-icons age was because symbolic icons are SVGs:

   https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html

 (The request for documentation still stands.)

 It seems that the problem is somewhat different:

 1) scalable gnome icons (e.g. symbolic svg icons) are not searched for.
 2) the claim If a -symbolic icon is missing, the app will fall back to the
regular name. seems to be false.

 In reverse order, 2) looked as though it should be fixed by commit d25ee710
   https://bugzilla.gnome.org/show_bug.cgi?id=708163
 which was did appear in 3.10.2 despite the last comment in that bug.
 It seems that fallback is still broken.

 1) seems odd: when running e.g. evince --gtk-debug=icontheme (3.10.3), a
 gtk 3.10.3 system with gnome-icon-theme-symbolic 3.8.3, and gsetting:
org.gnome.desktop.interface icon-theme 'gnome'
 shows caches found in icons/hicolor and icons/gnome

 (gtk-update-icon-cache --validate returns 0 for those two directories
  so validates OK.
  Is there an easy way of dumping the contents of the cache?)

 Evince then looks for dialog-password in

  -? builtins?
 icons/hicolor/..x..  (why hicolor when gsettings says
 icon-theme=gnome?)
 evince/icons/..x..
 icons/hicolor/scalable
 evince/icon/scalable
 theme_lookup_icon found dialog-password in dir (null)
 ? builtin - it apparently didn't look in icons/gnome/..x.. which is where
 the
 PNGs live.

 Next is go-up-symbolic, which won't be found, and which lives in
 icons/gnome/scalable/actions

 It is looked for in
 
 icons/hicolor/..x..
 evince/icons/..x..
 icons/hicolor/scalable
 evince/icon/scalable
 (as before, and in addition)
 icons/hicolor/..x..  (again, interleaved with icons/gnome)
 icons/gnome/..x..(because of commit 90dee25e in 3.10.3?)
 
 icons/hicolor/..x..  (again, with evince/icons/hicolor)
 gtk_icon_theme_lookup_icon image-missing

 so icons/gnome/scalable is not searched, and fallback non-symbolic
 go-up is also not searched for.


hicolor is specified as a fallback icon theme in the icon theme
specification, so that apps can place their app icons there.


 Can you shed light on what is meant to happen?

 Cheers,

 Patrick


 BTW gtkicontheme.c:1658 choose_icon() seems odd: the first block
 checks for a -symbolic suffix, but appears to do the same as the
 second block. Was that intentional?


Look closer. In the case of symbolic, it searches all themes for
icon_names[0] (which is foo-bar-baz-symbolic). In the latter, it tries all
the icon names (foo-bar-baz-symbolic, foo-bar-baz, foo-bar, foo) for every
theme in order.


 Attached is a patch to 3.10.3 I used to spew more debugging output.

 ___
 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

Re: symbolic icon fallback failure

[Jasper St. Pierre]

On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote:

 On Thu, Nov 21, 2013 at 10:07:55AM -0500, Jasper St. Pierre wrote:
  On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@cam.ac.uk wrote:
 
   Originally I thought that the lack of icons on my system in the post
   stock-icons age was because symbolic icons are SVGs:
  
 https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html
  
   (The request for documentation still stands.)
  
   It seems that the problem is somewhat different:
  
   1) scalable gnome icons (e.g. symbolic svg icons) are not searched for.
   2) the claim If a -symbolic icon is missing, the app will fall back
 to the
  regular name. seems to be false.
  
   In reverse order, 2) looked as though it should be fixed by commit
 d25ee710
 https://bugzilla.gnome.org/show_bug.cgi?id=708163
   which was did appear in 3.10.2 despite the last comment in that bug.
   It seems that fallback is still broken.
  
   1) seems odd: when running e.g. evince --gtk-debug=icontheme (3.10.3),
 a
   gtk 3.10.3 system with gnome-icon-theme-symbolic 3.8.3, and gsetting:
  org.gnome.desktop.interface icon-theme 'gnome'
   shows caches found in icons/hicolor and icons/gnome
  
   (gtk-update-icon-cache --validate returns 0 for those two directories
so validates OK.
Is there an easy way of dumping the contents of the cache?)
  
   Evince then looks for dialog-password in
  
-? builtins?
   icons/hicolor/..x..  (why hicolor when gsettings says
   icon-theme=gnome?)
   evince/icons/..x..
   icons/hicolor/scalable
   evince/icon/scalable
   theme_lookup_icon found dialog-password in dir (null)
   ? builtin - it apparently didn't look in icons/gnome/..x.. which is
 where
   the
   PNGs live.
  
   Next is go-up-symbolic, which won't be found, and which lives in
   icons/gnome/scalable/actions
  
   It is looked for in
   
   icons/hicolor/..x..
   evince/icons/..x..
   icons/hicolor/scalable
   evince/icon/scalable
   (as before, and in addition)
   icons/hicolor/..x..  (again, interleaved with icons/gnome)
   icons/gnome/..x..(because of commit 90dee25e in 3.10.3?)
   
   icons/hicolor/..x..  (again, with evince/icons/hicolor)
   gtk_icon_theme_lookup_icon image-missing
  
   so icons/gnome/scalable is not searched, and fallback non-symbolic
   go-up is also not searched for.
  
 
  hicolor is specified as a fallback icon theme in the icon theme
  specification, so that apps can place their app icons there.


 I don't understand your comment. evince isn't providing go-up-symbolic.
 It is trying to use it.


You seemed confused why hicolor is searched. It's normal for it to be
searched as a fallback.

I'd put a print statement inside the for loop near that if statement that
prints the theme name, e.g.

g_print (searching theme %s\n, theme-name);

It sounds to me like the gnome icon theme isn't being properly added. Maybe
also put lots of print statements in insert_theme. Is that being called
with gnome as a theme name? Is it bailing out at some point before it's
supposed to?


 icons/gnome/16x16/actions/go-up.png
 icons/gnome/22x22/actions/go-up.png
 icons/gnome/24x24/actions/go-up.png
 icons/gnome/32x32/actions/go-up.png
 icons/gnome/48x48/actions/go-up.png
 icons/gnome/scalable/actions/go-up-symbolic.svg

 live on the system. go-up-symbolic.svg isn't found as for some reason
 icons/gnome/scalable isn't searched. non-symbolic fallback go-up.png
 isn't searched for. Is that clearer?

   BTW gtkicontheme.c:1658 choose_icon() seems odd: the first block
   checks for a -symbolic suffix, but appears to do the same as the
   second block. Was that intentional?
  
 
  Look closer. In the case of symbolic, it searches all themes for
  icon_names[0] (which is foo-bar-baz-symbolic). In the latter, it tries
 all
  the icon names (foo-bar-baz-symbolic, foo-bar-baz, foo-bar, foo) for
 every
  theme in order.

 Hmmm - so why isn't at least go-up found?

 Cheers,

 Patrick




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

Re: GObject Introspection Enum details

[Jasper St. Pierre]

You can try g_registered_type_info_get_type_name(), but mind asking why you
want to know?


On Sun, Nov 17, 2013 at 11:33 AM, Aleksey prolog.her...@gmail.com wrote:

  Hi guys



 I am trying to use GIRepository (version 1.38) to retrieve Enumeration
 details and I'm wondering how to retrieve C-name of Enum. For example, I
 have GIEnumInfo instance for GBookmarkFileError (
 https://developer.gnome.org/glib/2.38/glib-Bookmark-file-parser.html#GBookmarkFileError
 ).

 Calling g_base_info_get_name gives me BookmarkFileError, not
 GBookmarkFileError.

 After looking at *.gir file contents for GLib, I've found that required
 value is stored in c:type attribute:



 enumeration name=BookmarkFileError

 c:type=GBookmarkFileError

 glib:error-quark=g_bookmark_file_error_quark

 ...

 /enumeration



 so I expected to be able to get the name using g_base_info_get_attribute,
 however, checking available attributes with 
 g_base_info_iterate_attributesproduced no results. Code used to check 
 attributes (no attribute
 names/values are printed):



 // print available attributes, taken from GIRepository manual page

 void print_attributes(GIBaseInfo *info)

 {

 GIAttributeIter iter = { 0, };

 char * name;

 char * value;

 while (g_base_info_iterate_attributes (info, iter, name, value)) {

 g_print (attribute name: %s value: %s, name, value);

 }

 }



 int main(int argc, char ** argv)

 {

 GIRepository *repo = g_irepository_get_default();

 g_irepository_require(repo, GLib, NULL, 0, NULL);

  gint count = g_irepository_get_n_infos(repo, GLib);

  // find first enum

 int i;

 GIBaseInfo * info = NULL;

 for (i = 0; i  count; i++) {

 info = g_irepository_get_info(repo, GLib, i);

 GIInfoType type = g_base_info_get_type(info);

 if (type == GI_INFO_TYPE_ENUM) break;

 }



 const gchar * name = g_base_info_get_name(info);

  printf(Enum: %s\n, name);

 print_attributes(info);



 return 0;

 }

 Could you please advise on how is it possible to get C-type name for enum
 (e.g. GBookmarkFileError).

 ___
 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

Re: Building glib 2.28.7

[Jasper St. Pierre]

That's an error for glibc, not glib. You'd be better off talking to the
glibc people about that one...


On Mon, Nov 11, 2013 at 12:32 PM, Daniel Schultze king...@gmail.com wrote:

 Hey guys,

 I'm have a new error with my build. I did some searches which suggested to
 not use --enable-static-nss which I'm not doing. I did do an edit to one of
 the awk scripts, scripts/gen-sorted.awk, the build was reporting an error
 on lines containing /\/[^/]+$/ , so I added an extra backslash in the
 middle to /\/[^\/]+$/ . Hopefully this edit is unrelated.

 Here's the error log:
 isoc99_scanf.c: In function '__isoc99_scanf':
 isoc99_scanf.c:33: error: '_IO_acquire_lock_needs_exceptions_enabled'
 undeclared (first use in this function)
 isoc99_scanf.c:33: error: (Each undeclared identifier is reported only once
 isoc99_scanf.c:33: error: for each function it appears in.)
 isoc99_scanf.c: At top level:
 isoc99_scanf.c:40: error: expected identifier or '(' before 'while'
 isoc99_scanf.c:41: error: expected identifier or '(' before 'return'
 isoc99_scanf.c:42: error: expected identifier or '(' before '}' token
 make[2]: ***
 [/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7/build-glibc/stdio-common/isoc99_scanf.o]
 Error 1
 make[2]: *** Waiting for unfinished jobs
 isoc99_vscanf.c: In function '__isoc99_vscanf':
 isoc99_vscanf.c:29: error: '_IO_acquire_lock_needs_exceptions_enabled'
 undeclared (first use in this function)
 isoc99_vscanf.c:29: error: (Each undeclared identifier is reported only
 once
 isoc99_vscanf.c:29: error: for each function it appears in.)
 isoc99_vscanf.c: At top level:
 isoc99_vscanf.c:32: error: expected identifier or '(' before 'while'
 isoc99_vscanf.c:33: error: expected identifier or '(' before 'return'
 isoc99_vscanf.c:34: error: expected identifier or '(' before '}' token
 make[2]: ***
 [/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7/build-glibc/stdio-common/isoc99_vscanf.o]
 Error 1
 isoc99_fscanf.c: In function '__isoc99_fscanf':
 isoc99_fscanf.c:31: error: '_IO_acquire_lock_needs_exceptions_enabled'
 undeclared (first use in this function)
 isoc99_fscanf.c:31: error: (Each undeclared identifier is reported only
 once
 isoc99_fscanf.c:31: error: for each function it appears in.)
 isoc99_fscanf.c: At top level:
 isoc99_fscanf.c:38: error: expected identifier or '(' before 'while'
 isoc99_fscanf.c:39: error: expected identifier or '(' before 'return'
 isoc99_fscanf.c:40: error: expected identifier or '(' before '}' token
 make[2]: ***
 [/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7/build-glibc/stdio-common/isoc99_fscanf.o]
 Error 1
 isoc99_vfscanf.c: In function '__isoc99_vfscanf':
 isoc99_vfscanf.c:29: error: '_IO_acquire_lock_needs_exceptions_enabled'
 undeclared (first use in this function)
 isoc99_vfscanf.c:29: error: (Each undeclared identifier is reported only
 once
 isoc99_vfscanf.c:29: error: for each function it appears in.)
 isoc99_vfscanf.c: At top level:
 isoc99_vfscanf.c:32: error: expected identifier or '(' before 'while'
 isoc99_vfscanf.c:33: error: expected identifier or '(' before 'return'
 isoc99_vfscanf.c:34: error: expected identifier or '(' before '}' token
 make[2]: ***
 [/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7/build-glibc/stdio-common/isoc99_vfscanf.o]
 Error 1
 make[2]: Leaving directory
 `/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7/stdio-common'
 make[1]: *** [stdio-common/subdir_lib] Error 2
 make[1]: Leaving directory `/home/xxx/ltib_xx/rpm/BUILD/glibc-2.7'
 make: *** [all] Error 2
 error: Bad exit status from /home/xxx/ltib_xx/tmp/rpm-tmp.15860 (%build)


 -Dan


 On Fri, Nov 8, 2013 at 12:01 PM, Colin Walters walt...@verbum.org wrote:

 On Fri, 2013-11-08 at 10:28 -0800, Daniel Schultze wrote:


  The host is Ubuntu 12.04 x86_64, the target CPU is an arm926ejs on a
  Freescale board, using LTIB. It is an older system using glibc 2.5
  with glibc ports 2.5.

 From a quick look, this commit to glibc looks like it updated the splice
 prototype:

 commit 99ea5991a4957f7a21466a4b48c5020eb70db2b7
 Author: Ulrich Drepper drep...@redhat.com
 AuthorDate: Wed Aug 30 15:05:29 2006 +

 * sysdeps/unix/sysv/linux/alpha/bits/fcntl.h (splice): Add offin

 Which as you can see is really quite ancient.

  --- glib-2.28.7.orig/configure 2011-05-20 21:15:25.0 -0700
  +++ glib-2.28.7/configure 2013-11-08 10:15:51.380683520 -0800
  @@ -23107,7 +23107,6 @@
 ac_fn_c_check_func $LINENO splice ac_cv_func_splice
   if test x$ac_cv_func_splice = xyes; then :
 cat confdefs.h _ACEOF
  -#define HAVE_SPLICE 1
   _ACEOF

 That's probably fine as a fix for you for now, this issue will go away
 when you update to a version of glibc from this decade too =)





 ___
 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

Re: Can g_field_info_get_offset () provide same info as G_STRUCT_OFFSET?

[Jasper St. Pierre]

On Wed, Nov 6, 2013 at 9:05 AM, Andrés G. Aragoneses kno...@gmail.comwrote:


 Hello,

 According to GObjectIntrospection wiki page[1], this is the proper place
 to ask questions about GI.

 I'm wondering if the function g_field_info_get_offset() [2] could provide
 the same information at compile-time that the G_STRUCT_OFFSET macro [3]
 provides at run-time? Am I missing something obvious here?


You've got these backwards. G_STRUCT_OFFSET is a compile-time macro, while
g_field_info_get_offset() is a runtime method using the GIR/typelib data.
But yes, they should provide the same values. What's the issue here?


 Thanks

 [1] https://wiki.gnome.org/GObjectIntrospection
 [2] https://developer.gnome.org/gi/stable/gi-GIFieldInfo.html#
 g-field-info-get-offset
 [3] https://developer.gnome.org/glib/2.37/glib-Standard-
 Macros.html#G-STRUCT-OFFSET:CAPS

 ___
 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

Re: Can g_field_info_get_offset () provide same info as G_STRUCT_OFFSET?

[Jasper St. Pierre]

On Wed, Nov 6, 2013 at 10:48 AM, Andrés G. Aragoneses kno...@gmail.comwrote:

 On 06/11/13 16:45, Ross Burton wrote:

 On 6 November 2013 14:45, Andrés G. Aragoneses kno...@gmail.com
 mailto:kno...@gmail.com wrote:

 (unless glib upstream would accept a patch to wrap the
 G_STRUCT_OFFSET in a public function?).


 That would be a function for every member of every struct, as
 G_STRUCT_OFFSET is a macro (sounds unlikely to me).


 Oh, right! Thanks for the pointer.
 So then I'll go with the libgirepository route. BTW, does gnome provide
 Windows/Mac binaries for libgirepository library?


gobject-introspection is still in the process of being ported to Windows. I
think we'll ship Windows/Mac binaries when we support those platforms.

Thanks



 ___
 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

Re: Directional Images

[Jasper St. Pierre]

I think the thing that we'd want is to have a separate RTL icon theme that
inherits from the LTR icon theme, but overrides some icons with flipped
icons. This can be done with a few tweaks to the icon-theme specification,
and in GTK+.


On Wed, Oct 16, 2013 at 5:42 PM, fr33domlover fr33domlo...@mailoo.orgwrote:

 You're right, drop shadows don't work well when flipped.

 But I have three suggestions:

 1. When widgets do enable perfect clean flipping, use it

 2. When an app has two directional matching widgets, e.g. left and right
 arrows, simply switch between then instead of fliping. This will
 probably require an matching image object property

 3. Add guidance to the Gnome devel docs, which explains how to write
 just few extra simple lines which makes your app more RTL-ready, so that
 we won't need to hunt and fix the same bugs again and again in each
 new app/design/implementation/version

 On ד', 2013-10-16 at 23:25 +0200, Dov Grobgeld wrote:
  No, I don't think it is universally reasonable. Because in general an
  icon may have a style that is broken when the image is flipped.
  Imagine e.g. if the buttons in some style contains arrows that were
  drawn with an elliptical pen slanted at 45 degrees to the right. In
  such a case the left and the right arrow are not a mirror image of one
  another. Another example is if the style contains a drawing with
  dropshadow to the right. Horizontally flipping the image would put the
  drop shadow to the left, which would be inconsistent with the rest of
  the theme. You may claim that if this was done throughout the
  application then it wouldn't make any difference, but if e.g. have an
  embedded label with Latin name:  and an LTR widget then it would be
  inconsistant within the application. Even between applications that
  have either LTR or RTL directionality on the desktop would look
  inconsistent.
 
 
  Thus, imo there is no automatic solution, but you need to create
  dedicated RTL images to make things look good in a RTL environment.
 
  Regards,
  Dov
 
 
 
 
 
  On Wed, Oct 16, 2013 at 11:58 PM, fr33domlover
  fr33domlo...@mailoo.org wrote:
  Hello Gtk+ developers,
 
  My native language is an RTL language. I've been examining
  several RTL
  problems in GNOME software recently, and I noticed some
  recurring
  patterns.
 
  Some of them are related to text alignment and fonts, which I
  won't talk
  about this time because I haven't found a universal solutio.
  But I think
  I did find a solution for images.
 
  It is very common for images where the direction matters, such
  as
  prev/next arrows, to be in the wrong direction when apps run
  in RTL
  locales. So far, a volunteer has been fixing these problems by
  hand by
  sending patches to all GNOME software containing the problem.
  For
  example, the prev/next arrows in Epiphany and in Evolution's
  notification-bar bubble.
 
  Here are some related bugs:
 
 https://git.gnome.org/browse/rhythmbox/commit/?id=eb4641a127828a0fa567eb19c26c66ff7f3b2f52
 
 https://git.gnome.org/browse/totem/commit/?h=gnome-3-10id=9055f411d2332c43c725ccbb88f5f7c240885e91
 https://git.gnome.org/browse/totem/commit/?h=gnome-3-10id=3ff23cf41e0192860ee2ad5c70c99c3c4d024196
 
 
  Instead of doing it by hand, or trying to teach developers how
  to make
  their apps direction-aware, I found a universal solution which
  requires
  a bit of work once, and will work after that without any
  developer
  intervention.
 
  The idea is: Directional Images.
 
  Example: An arrow is a directional image. The direction of the
  arrow
  matters. When an arrow icon is rendered in RTL locales, it
  should be
  rendered horizontally flipped, so right becomes left and left
  becomes
  right.
 
  A folder image is a non-directional image. Changing its
  direction
  doesn't make any sense or different in any direction or
  locale. The same
  is true for people's faces, an image of the Earth, a map of a
  city, etc.
 
  The solution I suggest is to add a directional boolean
  property to
  GTK's image class used for icons. The property will be stored
  as image
  metadata, and set by the designer of the image. After that,
  the code
  which renders the menu/toolbar icons will just need to check
  if the
  image is directional and the locale is RTL. If both are true,
  draw the
  image horizontally flipped. Otherwise, draw as usual.
 
  I believe it shouldn't take extra resources, because the
  drawing loop
  will simply need to fill pixels from the other side. No extra
  processing
 

Re: Tutorials on writing bindings?

[Jasper St. Pierre]

You haven't been getting many responses simply because there's no easy
tutorial on writing a language binding. It's a hard and difficult process,
and requires a significant amount of effort.

Most significant language bindings also contribute to the
gobject-introspection project itself because they require things that it
doesn't have already.

Some projects have used GObject Introspection for static compilation, but
it's really meant for dynamic bindings.

I'd be more than welcome to answer any questions you have about
gobject-introspection, and how it fits into your project. Even if I do
think you're the slightest bit crazy for wanting to start new projects in
COBOL :)

Take any modern Linux system and stare at /usr/share/gir-1.0/. You'll find
a bunch of XML files in there describing the interfaces of GTK+.


On Thu, Oct 10, 2013 at 2:43 PM, Patrick patr...@spellingbeewinnars.orgwrote:

 Hi Everyone

 Sorry to answer my own post. I didn't get a response so I am guessing
 either there isn't a comprehensive tutorial on writing bindings or my post
 was poorly worded.

 If I could just get some guidance on where to focus my studying that would
 be so great.

 I didn't want to mention this because it could lead to a severe beating(or
 email version of it) but I really love Cobol.

 There have been some attempts to create bindings but they are not very far
 along.

 Open Cobol compiles to intermediate C and there are many data types that
 correspond to C. However we cannot define new data types so it is not easy
 to specify that a value is type gboolean, GtkWindowPosition etc.

 Should I try to learn about how GObject Introspection works? It sounds
 like this is for dynamically typed languages?

 Should I try to learn how other statically typed bindings work instead? Do
 they still use introspection or do they just try to recreate the data types
 within their own type systems?


 -Patrick
 __**_
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://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

Re: Removal of icons in buttons/menus

[Jasper St. Pierre]

I guess I'm curious: why would this break apps?

If your apps were relying on a specific user setting to show/hide icons,
wasn't it technically broken already? There was no guarantee of the value
of the setting.

It seems that reducing the amount of user configurations an app developer
would have to test in is a great idea for all.


On Wed, Oct 9, 2013 at 2:09 PM, Erick Pérez Castellanos
eric...@gnome.orgwrote:

 People keep raising this issue (both on list and on IRC) and I think
 there's a good reason for it.

 And people will keep doing it, until they get proper answers.

 As an application developer why I found troubling about this particular
 removal is:

 First: the fact that no-one has explained the reasons behind it. Certainly
 we can guess the thing has to do with Wayland port but yet there's no
 comment in those commits explaining the reasons behind it.

 Second: The workaround being settings the option in every widget of an
 application is not a friendly towards app developers.
 Right now, in a moment where new widgets come into Gtk+, the *Getting
 Started* section appeared in the docs and there's this new attention to the
 developer story with Gtk+ (and others), that doesn't seem very friendly at
 all.

 --
 Art is the most intense mode of individualism that the world has known
 Oscar Wilde


 ___
 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

Re: Removal of icons in buttons/menus

[Jasper St. Pierre]

Ah, you're saying if an app forces the setting to TRUE by calling
g_object_set. I just assume that we didn't imagine apps doing that when we
removed the code, since it is a bit silly.

Perhaps we can revert the GtkMenu/GtkButton changes and just remove the
XSettings hookup.


On Wed, Oct 9, 2013 at 2:19 PM, Erick Pérez Castellanos
eric...@gnome.orgwrote:

 On 9 October 2013 14:13, Jasper St. Pierre jstpie...@mecheye.net wrote:

 I guess I'm curious: why would this break apps?

 If your apps were relying on a specific user setting to show/hide icons,
 wasn't it technically broken already? There was no guarantee of the value
 of the setting.

 It seems that reducing the amount of user configurations an app developer
 would have to test in is a great idea for all.


 The point for an app developer would be:
 Before: I set on one place, every button will show images
 After: I have to go through all my code, looking for buttons to set the
 option, and worst, If I want to make it an option for my user, I have to
 recreate the settings scheme in my application.

 You certainly can see this when we are talking of huge application like
 Evolution right ?




-- 
  Jasper
___
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

[Jasper St. Pierre]

On Wed, Oct 9, 2013 at 2:57 PM, Ryan Lortie de...@desrt.ca wrote:

 hi

 On Wed, Oct 9, 2013, at 14:29, Jasper St. Pierre wrote:
  Perhaps we can revert the GtkMenu/GtkButton changes and just remove the
  XSettings hookup.

 Out of all of the available options, this would be the most pointless
 thing to do.

 If we're going to have the complexity in the widgets anyway, then we may
 as well actually have it exercised by something.


The idea here would be to keep apps that use g_object_set() to force icons
on/off working but not allow the environment to change it.


 Cheers




-- 
  Jasper
___
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

[Jasper St. Pierre]

On Wed, Oct 9, 2013 at 3:49 PM, Olivier Brunel j...@jjacky.com wrote:

 On 10/09/13 21:27, Matthias Clasen wrote:
  On Wed, Oct 9, 2013 at 2:09 PM, Erick Pérez Castellanos
  eric...@gnome.orgwrote:
 
  People keep raising this issue (both on list and on IRC) and I think
  there's a good reason for it.
 
  And people will keep doing it, until they get proper answers.
 
  As an application developer why I found troubling about this particular
  removal is:
 
 
  The setting does not do anything for you as an application developer. It
  was a user setting that lets users break the design of your application
 by
  making icons pop up in all sorts of places where you did not see them
  because you were not testing with that particular combination of user
  settings.

 Nope, not quite. It was an option that let users break the design of
 one's application (to reuse your wording) by making icons *disappear*
 in all sorts of places. Images were *shown* by default, and those
 settings allowed users to turn them off, not the other way around.

 IOW, what GTK 3.10 did was made sure to break the design of every GTK
 application and did so while removing the ability to fix it from users.
 As for application developers, they had no warning to prepare, and can't
 just fix things simply since (a) there's one way to get icons back, but
 it involves calling a function on every single widget concerned, and (b)
 that is only a temporary fix anyways, to unbreak things, since - for
 menus at least - said function, like the whole widget, is deprecated.

 (Which means, unless I missed something, there is no non-deprecated way
 in GTK to have images in menus (except packing a GtkImage ourself in a
 GtkMenuItem or similar). Whereas in GIO however, there's still
 g_menu_item_set_icon().)


In GNOME, we turned that setting off by default quite a long time ago.
Probably around 5-6 years at this point. So, if your application relied on
menus and buttons having icons, it would have broken in mid-GNOME2-era
GNOME.

-j

 
 
  First: the fact that no-one has explained the reasons behind it.
 Certainly
  we can guess the thing has to do with Wayland port but yet there's no
  comment in those commits explaining the reasons behind it.
 
 
  I just did.
 
 
 
 
  Second: The workaround being settings the option in every widget of an
  application is not a friendly towards app developers.
  Right now, in a moment where new widgets come into Gtk+, the *Getting
  Started* section appeared in the docs and there's this new attention to
 the
  developer story with Gtk+ (and others), that doesn't seem very friendly
 at
  all.
 
 
  Again, the GtkSettings that we are discussing here do nothing for
  application developers. On the contrary, by removing the settings, we
 have
  given you as application developer _more_ control over how your
 application
  appears to your users.
 
 
 
  ___
  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




-- 
  Jasper
___
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

[Jasper St. Pierre]

Sure, but both the user and the environment had options to override them,
and if your app broke in one of those environments of which it was
overridden by default (of which there are a lot), that's your bug.

Reducing the amount of environments an app has to be tested in is a very
good thing. I think that for GTK+ 3.10, we should add back the ability for
app authors to use the GtkSettings APIs to add back icons if that's how
they forced it on, but I don't think it should be hooked up to the
environment anymore.


On Wed, Oct 9, 2013 at 4:14 PM, Olivier Brunel j...@jjacky.com wrote:

 On 10/09/13 21:58, Jasper St. Pierre wrote:
  On Wed, Oct 9, 2013 at 3:49 PM, Olivier Brunel j...@jjacky.com wrote:
 
  On 10/09/13 21:27, Matthias Clasen wrote:
  On Wed, Oct 9, 2013 at 2:09 PM, Erick Pérez Castellanos
  eric...@gnome.orgwrote:
 
  People keep raising this issue (both on list and on IRC) and I think
  there's a good reason for it.
 
  And people will keep doing it, until they get proper answers.
 
  As an application developer why I found troubling about this
 particular
  removal is:
 
 
  The setting does not do anything for you as an application developer.
 It
  was a user setting that lets users break the design of your application
  by
  making icons pop up in all sorts of places where you did not see them
  because you were not testing with that particular combination of user
  settings.
 
  Nope, not quite. It was an option that let users break the design of
  one's application (to reuse your wording) by making icons *disappear*
  in all sorts of places. Images were *shown* by default, and those
  settings allowed users to turn them off, not the other way around.
 
  IOW, what GTK 3.10 did was made sure to break the design of every GTK
  application and did so while removing the ability to fix it from users.
  As for application developers, they had no warning to prepare, and can't
  just fix things simply since (a) there's one way to get icons back, but
  it involves calling a function on every single widget concerned, and (b)
  that is only a temporary fix anyways, to unbreak things, since - for
  menus at least - said function, like the whole widget, is deprecated.
 
  (Which means, unless I missed something, there is no non-deprecated way
  in GTK to have images in menus (except packing a GtkImage ourself in a
  GtkMenuItem or similar). Whereas in GIO however, there's still
  g_menu_item_set_icon().)
 
 
  In GNOME, we turned that setting off by default quite a long time ago.
  Probably around 5-6 years at this point. So, if your application relied
 on
  menus and buttons having icons, it would have broken in mid-GNOME2-era
  GNOME.

 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

 
  -j
 
 
 
  First: the fact that no-one has explained the reasons behind it.
  Certainly
  we can guess the thing has to do with Wayland port but yet there's no
  comment in those commits explaining the reasons behind it.
 
 
  I just did.
 
 
 
 
  Second: The workaround being settings the option in every widget of an
  application is not a friendly towards app developers.
  Right now, in a moment where new widgets come into Gtk+, the *Getting
  Started* section appeared in the docs and there's this new attention
 to
  the
  developer story with Gtk+ (and others), that doesn't seem very
 friendly
  at
  all.
 
 
  Again, the GtkSettings that we are discussing here do nothing for
  application developers. On the contrary, by removing the settings, we
  have
  given you as application developer _more_ control over how your
  application
  appears to your users.
 
 
 
  ___
  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
 
 
 
 




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

Re: Spell checking in GIO

[Jasper St. Pierre]

Of course, but do any of these need spell checking? I think it would be
more helpful to solidify an API for spell checking to see if it's viable to
do without UI concepts like cursor position or GTK+ concepts like
GtkTextBuffer before deciding where to put it.


On Wed, Oct 9, 2013 at 6:36 PM, Paul Davis p...@linuxaudiosystems.comwrote:




 On Wed, Oct 9, 2013 at 6:24 PM, Ross Burton r...@burtonini.com wrote:

 On 9 October 2013 23:15, Paul Davis p...@linuxaudiosystems.com wrote:

 And if an extension point is added, it's better to add it in GIO, so
 command line tools can use it.


 I'm just curious. What command line tools use GIO (or even glib)?


 A very rough list based on a grep of oe-core's metadata for glib-2.0 (so
 yes, this is GLib and not GIO):  avahi, connman, network manager, bluez,
  neard, ofono, telepathy, desktop-file-utils, pkgconfig, vala, blktool, mc,
 gconf, dconf, gstreamer.

 Non-GTK+ applications that use GLib do exist.


 thanks for the list. I was genuinely curious, not snarky. I should have
 remembered pkg-config myself.


 ___
 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

Re: Spell checking in GIO

[Jasper St. Pierre]

glib-networking exists for political reasons. I don't think we want to
repeat that with something we can just import in-tree.


On Tue, Oct 8, 2013 at 9:49 AM, Matthew Barnes mbar...@redhat.com wrote:

 On Tue, 2013-10-08 at 08:58 -0400, Dan Winship wrote:
  enchant depends on glib, so yes, a hard dependency on it from glib would
  be a problem. But enchant development has more or less stopped (last
  commit was two years ago), and if glib had equivalent functionality then
  enchant would be pretty much unnecessary. So it might make more sense to
  just absorb it into glib (which Dom seemed in favor of in that bug
 anyway).

 Or perhaps follow the glib-networking pattern where GIO just defines a
 spell checking interface and an extension point and the meaty parts with
 the extra dependencies are supplied by 3rd party module(s).

 glib-spell-checking anyone?  :)

 Matthew Barnes

 ___
 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

Re: Help Broadway Backend

[Jasper St. Pierre]

You need to update your version of glib.


On Sun, Feb 17, 2013 at 9:00 PM, Diego Felix (Bill) diegob...@gmail.comwrote:

 When I try to compile a older version of gtk+-3  (3.4.4), I have the same
 error:

 When I configure:

 bill@bill-laptop:~/Downloads/gtk+-3.4.4$ ./configure --prefix=/opt/gtk
 --enable-x11-backend --enable-broadway-backend

 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking how to create a ustar tar archive... gnutar
 checking whether to enable maintainer-specific portions of Makefiles...
 yes

 checking whether make supports nested variables... yes
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables...
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking for style of include used by make... GNU
 checking dependency style of gcc... gcc3
 checking whether gcc and cc understand -c and -o together... yes
 checking for gcc option to accept ISO C99... -std=gnu99
 checking for gcc -std=gnu99 option to accept ISO Standard C... (cached)
 -std=gnu99
 checking whether make sets $(MAKE)... (cached) yes

 checking build system type... i686-pc-linux-gnu
 checking host system type... i686-pc-linux-gnu
 checking for native Win32... no
 checking for c++... c++
 checking whether we are using the GNU C++ compiler... yes
 checking whether c++ accepts -g... yes
 checking dependency style of c++... gcc3
 checking how to print strings... printf
 checking for a sed that does not truncate output... /bin/sed
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for fgrep... /bin/grep -F
 checking for ld used by gcc -std=gnu99... /usr/bin/ld

 checking if the linker (/usr/bin/ld) is GNU ld... yes
 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... BSD nm
 checking whether ln -s works... yes
 checking the maximum length of command line arguments... 1572864
 checking whether the shell understands some XSI constructs... yes
 checking whether the shell understands +=... yes
 checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu
 format... func_convert_file_noop
 checking how to convert i686-pc-linux-gnu file names to toolchain
 format... func_convert_file_noop
 checking for /usr/bin/ld option to reload object files... -r
 checking for objdump... objdump
 checking how to recognize dependent libraries... pass_all
 checking for dlltool... no

 checking how to associate runtime and link libraries... printf %s\n
 checking for ar... ar
 checking for archiver @FILE support... @
 checking for strip... strip
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from gcc -std=gnu99
 object... ok

 checking for sysroot... no
 checking for mt... mt
 checking if mt is a manifest tool... no
 checking how to run the C preprocessor... gcc -std=gnu99 -E

 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking for dlfcn.h... yes
 checking for objdir... .libs
 checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
 checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
 checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
 checking if gcc -std=gnu99 static flag -static works... yes
 checking if gcc -std=gnu99 supports -c -o file.o... yes
 checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes
 checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared
 libraries... yes

 checking whether -lc should be explicitly linked in... no
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... no
 checking how to run the C++ preprocessor... c++ -E
 checking for ld used by c++... /usr/bin/ld
 checking if the linker (/usr/bin/ld) is GNU ld... yes
 checking whether the c++ linker (/usr/bin/ld) supports shared
 libraries... yes
 checking for c++ option to produce PIC... -fPIC -DPIC
 checking if c++ PIC flag -fPIC -DPIC works... yes
 checking if c++ static flag -static works... 

Re: Sharing CSS code between Gtk and the Shell

[Jasper St. Pierre]

I looked into this a while ago, and one big issue with this is that we
can't e.g. implement custom properties that we just fetch from JS. So we
couldn't implement any of our -st- properties or any others that we just
make up on the spot. I don't know if it would be possible or feasible to
add this to Gtk. In our current St implementation, the tokens that come out
of libcroco are especially hard to parse correctly, and we can't access
this from JS, so it might be possible to add some very simple custom
property system for colors and lengths, and that's it.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkTable is deprecated

[Jasper St. Pierre]

If GtkTable and GtkGrid were replaceable by a sed expression, I don't
think we would have bothered breaking API.

On Thu, Sep 29, 2011 at 1:11 PM, Johannes Schmid j...@jsschmid.de wrote:
 Hi!

 deprecated != gone.

 There is no super-urgent need to rid the world of GtkTables - unless
 you want your module to compile with disabled deprecations.

 Sure, but you know how picky some people are about deprecations...

 Regards,
 Johannes


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




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