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,  wrote:

> On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre 
> wrote:
>
>> On Sat, Jul 9, 2016 at 12:06 PM,  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
 wrote:
> On Thu, Mar 17, 2016 at 2:26 PM, Jasper St. Pierre
>  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
 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
 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
 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
 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  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]

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
 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 
> 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
>>  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: 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
 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: 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  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]

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

On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro
 wrote:
>
>
> On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre 
> 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  wrote:
>> > Hi;
>> >
>> > On 11 June 2015 at 13:44, anatoly techtonik  wrote:
>> >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi 
>> >> 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?
&g

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  wrote:
> Hi;
>
> On 11 June 2015 at 13:44, anatoly techtonik  wrote:
>> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi  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: 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  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  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  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  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  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  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]

On Thu, Mar 5, 2015 at 1:21 PM, David Nečas  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: 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  wrote:

> Hi
>
> On 5 March 2015 at 20:09, Emmanuele Bassi  wrote:
> >>> On 5 March 2015 at 19:17, Florian Müllner  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  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  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  wrote:
> >> Hi;
> >>
> >> On 5 March 2015 at 17:51, Olivier Fourdan  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 t

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  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.
>
>  the question we're trying to answer is this: What CSS values
> does GtkStyleContext return?
>  this question is relevant because every time we change the CSS
> tree, we need to (potentially) update the value
>
>  3.0.0 used the approach of immediately updating everything once
> the css tree changed somehow
>  so if you did: context.add_class("a"); context.add_class("b");
> context.add_class("c");
>  it would recompute the CSS 3x
>  which gets real slow really fast
>
>  in 3.4 or so I changed that to always return a stale value
>  until we validated the style via gtk_container_idle_sizer()
> (when the frame clock runs)
>  so from that point on everything was fast, but the values were
> sometimes incorrect
>
>  wouldn't you want to mark the values as stale, and force a
> recompute when somebody asks for a value ?
>  ideally, you would
>  the reason I did not do that was the style-updated signal
>  when should that be emitted?
>  if we emit it once a context gets invalid, we go back to 3.0
> performance
>  because every widget queries values in the style-updated
> handler...
>
>  you could do some freeze/thaw to batch the 3 emissions from 3
> add_class calls
>  I don't want to add freeze/thaw calls though, everybody would
> get those wrong
>
>  who needs to listen to style-updated anyway ?
>  other than the gtk redraw machinery
>  mostly just that
>  GtkWidget needs to update the pango context
>  GtkImage needs to release the cached surface
>  things like that
>  and of course we need to queue_draw() or queue_resize()
>
>  here's another caveat: computing the CSS values requires
> computing the CSS values of the parent
>
>  is that on the person changing the style context, or do we do
> that automatically ?
>  GtkWidget::style-updated does that
>  based on the GtkCssAffects settings of the changed style
> properties
>
>  my mental model of this is that css values are used when drawing
> happens, so they need to be current at that point
>  and drawing happens when the frame clock comes around to tell us
>  yes
>  when the frame clock triggers, we (1) recompute styles, (2)
> size_allocate everything pending, (3) draw
>
>  whether css values are up-to-date at other points in the frame
> cycle should not be important
>  except for those 3rd party users who randomly poke at style
> contexts...
>  but it is important
>  otherwise you get shrinking gnome terminals and white firefox
> text
>  the gnome terminal case is actually rather complex to get right
> with the "should not be important" assumption
>  because it needs to compute a bunch of values based on multiple
> different widgets
>  and it needs to compute those before size allocation happens
>  in short: It needs to happen in style_updated() at the latest -
> but which style-updated, when it depends on multiple widgets?
>
>  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 ?
>  that's one thing we could do
>  there's many solutions to the problem(s)
>  I haven't reached the point yet where want to talk about
> solutions
>  so far I'm trying to list the problem(s) :)
>
>  'before size allocation' sounds like a global thing though ?
> like a point in the frame cycle
>  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 ?
>  at least, only the people doing the poking are paying the price
> of extra recomputations then
>
>  lemme do a short jsfiddle to show you how the web does it
>  http://jsfiddle.net/nbt2myzb/1/
>  I hope that example is simple enough
>  you wanna understand why uncommenting that 1 line of JS makes
> the animation restart
>  (disclaimer: I'm using firefox, no idea if webkit does things
> differently somehow)
>
>  does it ?
>  I seem to get blue when I click, which slowly fades to yellow
>  no restarts that I can observe
>  uncomment the line in the JS
>  then press the "run" button
>  ah, ok
>  now it restarts
>
>  you understand why it does that now?
>  no, 

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 
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 > > 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: 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 
wrote:

> On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre 
> 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]

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  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 
> 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"  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 
>>> wrote:
>>>
>>>> hi;
>>>>
>>>> On 25 January 2015 at 13:31, Philip Withnall 
>>>> 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]

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]

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?

If we're so opposed to requiring libwayland for this new widget, I could
write my own protocol, but it's simpler to use one that already exists.
On Jan 27, 2015 10:38 AM, "Cosimo Cecchi"  wrote:

> On Tue, Jan 27, 2015 at 2:59 PM, Paul Davis 
> wrote:
>
>> I understand the appeal of using "existing technology" (i.e. Wayland) to
>> accomplish something when it appears that it will make it much easier.
>>
>> But if GTK is still at least nominally cross-platform, then surely the
>> place to start is a higher level abstraction of the transport system, and
>> then later to bolt wayland onto that design "under the hood", rather than
>> starting with Wayland and then shrugging one's hands and saying "do
>> something like Wayland on other platforms"?
>>
>
> I don't see how anything I've said could be used to imply that GTK is,
> nominally or concretely, not cross-platform anymore.
>
> What is being discussed here is the possibility of using Wayland as the
> implementation to communicate privately between the preview plugin process
> and the main process, without a Wayland requirement for the session the
> processes live in.
> I'm arguing that as long as the Wayland libraries can be built on the
> platforms we care about and a suitable way of sharing a buffer exists, even
> if not extremely optimized, we can possibly get away without the
> abstraction you're talking about.
>
> Cosimo
>
___
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"  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  wrote:
>
>> hi;
>>
>> On 25 January 2015 at 13:31, Philip Withnall 
>> 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 Jan 23, 2015 12:06 PM, "Sébastien Wilmet"  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: GTK+ brochure for FOSDEM

[Jasper St. Pierre]

On Fri, Jan 23, 2015 at 3:37 AM, Sébastien Wilmet  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: 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  wrote:

> Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi 
> 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 
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]

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 
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  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
> && \
> m

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  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: 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  wrote:

> On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi  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  wrote:

> On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
> > On 16 August 2014 16:23, Sébastien Wilmet  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  wrote:

> Thanks for the explanation.
>
> On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
> > 
>
> > 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]

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 
wrote:

> 2014-06-24 3:02 GMT+02:00 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.
>
> 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]

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]

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]

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 
wrote:

> 2014-06-21 3:00 GMT+02:00 Jasper St. Pierre :
> > 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]

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]

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  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
>  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]

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 
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]

On Sat, Jun 21, 2014 at 11:42 AM, Paul Davis 
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 Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre 
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:18 AM, Jean Brefort 
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]

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 
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]

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 
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
> >  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]

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 
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]

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  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: 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 
wrote:

> On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre 
> 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]

On Fri, Jun 20, 2014 at 11:57 PM, A. Walton  wrote:

> On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre 
> 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

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

[Jasper St. Pierre]

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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk-Message: Failed to load module "canberra-gtk-module"

[Jasper St. Pierre]

No, actually. The issue is that the canberra GTK+ module uses an API which
we removed. It's been broken like this for quite a while. We patch it away
in Fedora, but libcanberra won't accept the patch upstream.

http://pkgs.fedoraproject.org/cgit/libcanberra.git/tree/libcanberra-quit-add.patch


On Tue, Mar 11, 2014 at 7:14 PM, Nicolas Dufresne <
nicolas.dufre...@collabora.com> wrote:

> Le dimanche 09 mars 2014 à 04:03 +, narcisse doudieu siewe a écrit :
> > Gtk-Message: Failed to load module "canberra-gtk-module"
>
> This is usually not fatal. Installing canberra-gtk would make it go
> away.
>
> Nicolas
>
>
> ___
> 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: 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
wrote:

> 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  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]

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  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]

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  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]

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  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 wrote:

> On Tue, 04 Feb 2014 09:39:26 +0100
> Michael Lipp  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,  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 10:35 AM, Patrick Welche  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  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: symbolic icon fallback failure

[Jasper St. Pierre]

On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche  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: 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  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:
>
>
>
> 
> c:type="GBookmarkFileError"
>
> glib:error-quark="g_bookmark_file_error_quark">
>
> ...
>
> 
>
>
>
> 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  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  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 
>> 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-d

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" wrote:

> On 06/11/13 16:45, Ross Burton wrote:
>
>> On 6 November 2013 14:45, "Andrés G. Aragoneses" > > 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: 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" wrote:

>
> 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: 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 wrote:

> 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
> >  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-10&id=9055f411d2332c43c725ccbb88f5f7c240885e91
> https://git.gnome.org/browse/totem/commit/?h=gnome-3-10&id=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.
> >
> >

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 wrote:

> 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-**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 wrote:

>
>
>
> On Wed, Oct 9, 2013 at 6:24 PM, Ross Burton  wrote:
>
>> On 9 October 2013 23:15, Paul Davis  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: 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  wrote:

> On 10/09/13 21:58, Jasper St. Pierre wrote:
> > On Wed, Oct 9, 2013 at 3:49 PM, Olivier Brunel  wrote:
> >
> >> On 10/09/13 21:27, Matthias Clasen wrote:
> >>> On Wed, Oct 9, 2013 at 2:09 PM, Erick Pérez Castellanos
> >>> wrote:
> >>>
> >>>> 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: Removal of icons in buttons/menus

[Jasper St. Pierre]

On Wed, Oct 9, 2013 at 3:49 PM, Olivier Brunel  wrote:

> On 10/09/13 21:27, Matthias Clasen wrote:
> > On Wed, Oct 9, 2013 at 2:09 PM, Erick Pérez Castellanos
> > wrote:
> >
> >> 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]

On Wed, Oct 9, 2013 at 2:57 PM, Ryan Lortie  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]

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
wrote:

> On 9 October 2013 14:13, Jasper St. Pierre  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]

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
wrote:

> 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: Hicolor icon theme

[Jasper St. Pierre]

Icon themes and GTK+ themes are separate. "hicolor" is defined as the
default fallback if an application can't find any other theme in the icon
theme specification:

http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#id3013799


On Wed, Oct 9, 2013 at 9:08 AM, John Emmas  wrote:

> Thanks for the advice, guys.  I should be able to try your suggestions
> either today or tomorrow.
>
> However, on a less obvious note  the product I'm working on (Ardour)
> does already use its own theme which (I think) gets handled by Clearlooks.
>  I hope it's not a dumb question - but if Ardour and Clearlooks are already
> handling theming, why would I also need a GTK+ theme, such as the "hicolor"
> theme which it can't find??
>
> I don't mind adding the hicolor theme like you suggested but I don't quite
> understand why it's needed.
>
> 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: 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  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: 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  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