REMINDER: List moved to Discourse; archival in 1 week

[Emmanuele Bassi via gtk-app-devel-list]

Hi all;

next week, on May 1st, this list will be archived[0]. This means no new
subscriptions, and no new email.

If you have questions about GTK, GLib, and the rest of the core GNOME
development platform, you can use the Discourse[1] instance hosted on GNOME
infrastructure; we have a Platform/Core category, and we can use
appropriate tags that you can watch[2] and filter on.

You can use existing single-sign on systems, like Google and Github, to
authenticate yourself; if you have a GNOME LDAP account already, you're
strongly encouraged to use that method of authentication.

You can still use email to interact with Discourse, and a guide is
available[3] to configure your account.

If you have any questions or feedback on Discourse, please use the
appropriate category[4].

Ciao,
 Emmanuele.

[0]: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html
[1]: https://discourse.gnome.org
[2]: https://discourse.gnome.org/t/tags-and-watching/94
[3]: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
[4]: https://discourse.gnome.org/c/site-feedback

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

REMINDER: List moved to Discourse; archival in 1 week

[Emmanuele Bassi via gtk-devel-list]

Hi all;

next week, on May 1st, this list will be archived[0]. This means no new
subscriptions, and no new email.

If you have questions about GTK, GLib, and the rest of the core GNOME
development platform, you can use the Discourse[1] instance hosted on GNOME
infrastructure; we have a Platform/Core category, and we can use
appropriate tags that you can watch[2] and filter on.

You can use existing single-sign on systems, like Google and Github, to
authenticate yourself; if you have a GNOME LDAP account already, you're
strongly encouraged to use that method of authentication.

You can still use email to interact with Discourse, and a guide is
available[3] to configure your account.

If you have any questions or feedback on Discourse, please use the
appropriate category[4].

Ciao,
 Emmanuele.

[0]: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html
[1]: https://discourse.gnome.org
[2]: https://discourse.gnome.org/t/tags-and-watching/94
[3]: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
[4]: https://discourse.gnome.org/c/site-feedback

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

Re: gtk3 drag and drop sample/demo

[Emmanuele Bassi via gtk-app-devel-list]

On Mon, 15 Apr 2019 at 12:45, Pankaj Bansal via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:


> I am working with OpenJDK JavaFX dev group and we are facing some problems
> with drag and drop functionality with gtk3.20 or later. You can have a look
> at the bug for more information
> https://bugs.openjdk.java.net/browse/JDK-8211302. It will be great if
> someone can point out any big change done with respect to drag and drop
> from gtk3.20.
>

First of all, it's kind of rude to ask people to go to a random bug tracker
and ask for a code review without stating what the issue is.

Can you explain what issues are you experiencing?


> I am looking for a sample/demo for drag and drop functionality using gtk3.
> I can see that there is one demo at [1], but it is not compatible with gtk3
> as it is using gtk4 specific structs and functions. I am not able to find
> any other working demo/sample working with gtk3. It would be great if
> anyone can point to me to something useful.
>

The drag and drop code in GTK 3 hasn't really changed from the 2.x days,
and has been substantially reworked for GTK 4.

The old drag and drop tutorial may be of help:
https://wiki.gnome.org/Newcomers/DragNDropTutorial

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Emmanuele Bassi via gtk-app-devel-list]

On Sat, 6 Apr 2019 at 20:15,  wrote:


> The second cairo_t is used so that the rectangle can be lined up to the
> cell. If I use the cairo_t in the "draw" callback then the rectangle
> doesn't line up.
>

You're still using:

 1. the wrong window to draw on
 2. deprecated API
 3. a slow rendering path

In general, though drawing *on top* of widgets is not encouraged; you're
either going to break things inside GTK, or your own code will break
because GTK may change something in how widgets are drawn.

If you want to change how a cell is rendered, you can subclass the cell
renderer into your own class and override its own draw function; this way,
you're guaranteed you'll be rendering at the right position.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Emmanuele Bassi via gtk-app-devel-list]

On Sat, 6 Apr 2019 at 19:05, Eric Cashon via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:



> static gboolean draw_rectangle(GtkWidget *tree_view, cairo_t *cr, gpointer
> data)
>   {
> GtkTreePath *path=gtk_tree_path_new_from_indices(row_g, -1);
>
> g_print("Draw Rectangle %i %i\n", row_g, column_g);
> GdkWindow *win=gtk_tree_view_get_bin_window(GTK_TREE_VIEW(tree_view));
> cairo_t *cr2=gdk_cairo_create(win);
>

Don't ever do this.

There's a reason why you're getting a deprecation warning: you're already
getting a Cairo context from the "draw" signal; use that to draw. There's
no reason whatsoever to create a new Cairo context for a GdkWindow in GTK3.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 21 Mar 2019 at 02:28, Matthew A. Postiff via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:


> Is it easy in discourse to turn on email, either daily digests or
> "live"? Is there an rss feed that I can subscribe to? A quick howto
> would be great.
>

There is a link on how to use email with Discourse in the original email.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord

[Emmanuele Bassi via gtk-app-devel-list]

On Wed, 20 Mar 2019 at 23:59, David C. Rankin <
drankina...@suddenlinkmail.com> wrote:

> On 03/18/2019 12:02 PM, Emmanuele Bassi via gtk-app-devel-list wrote:
> > Hi all;
> >
> > as announced in:
> >
> >
> https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html
> >
> > we have created a Discourse instance available at:
> >
> >   https://discourse.gnome.org



> What is the technological hold-up to doing both? Listserves are no cost
> simple
> implementations that should be able to mirror posts from discourse to the
> existing list and vice-versa.


This is an increasingly out of date position. Maintaining email servers and
mailing lists is getting more and more complicated with every passing year.

Sending thousands of emails to thousands of people every single day, and
rewriting the envelope to make sure that the email comes from gnome.org, is
becoming undistinguishable from spam. While we managed to carve out some
exception using the established mechanisms, large ISPs are not really happy
about all this stuff.


> That would seem to be the way to go until you
> have some assurance that discourse will preserve community involvement
> instead
> of just doing it on hope.
>

Splitting the community is not a great plan, so it's not going to happen.

You can interact with Discourse via email, which is the main reason why we
chose it as the platform to replace Mailman.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

ANNOUNCE: Phasing out GTK mailing lists and move to Discord

[Emmanuele Bassi via gtk-app-devel-list]

Hi all;

as announced in:

  https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html

we have created a Discourse instance available at:

  https://discourse.gnome.org

After testing it for the past couple of weeks, we're very satisfied with
how the platform behaves, so we are going to officially migrate all
GTK-related discussion lists over to Discourse. This means the following
mailing lists:

 - gtk-devel-list
 - gtk-app-devel-list
 - gtk-list

Will be closed and archived on May 1st, 2019. The archives will remain
public, but you won't be able to subscribe or send emails to the list.

If you're subscribed to any of those lists you will receive a link to
Discourse where you'll be able to create an account on that platform; you
can also use other single sign-on systems, like Google or GitHub; and if
you have an LDAP account on gnome.org, you're strongly encouraged to use
that account.

For further information on Discourse, please see the following topics:

 - https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
 - https://discourse.gnome.org/t/tags-and-watching/94

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

ANNOUNCE: Phasing out GTK mailing lists and move to Discord

[Emmanuele Bassi via gtk-devel-list]

Hi all;

as announced in:

  https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html

we have created a Discourse instance available at:

  https://discourse.gnome.org

After testing it for the past couple of weeks, we're very satisfied with
how the platform behaves, so we are going to officially migrate all
GTK-related discussion lists over to Discourse. This means the following
mailing lists:

 - gtk-devel-list
 - gtk-app-devel-list
 - gtk-list

Will be closed and archived on May 1st, 2019. The archives will remain
public, but you won't be able to subscribe or send emails to the list.

If you're subscribed to any of those lists you will receive a link to
Discourse where you'll be able to create an account on that platform; you
can also use other single sign-on systems, like Google or GitHub; and if
you have an LDAP account on gnome.org, you're strongly encouraged to use
that account.

For further information on Discourse, please see the following topics:

 - https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
 - https://discourse.gnome.org/t/tags-and-watching/94

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

Re: Gtk::Widget::is_mapped ()

[Emmanuele Bassi via gtk-devel-list]

No, it's not. The issue is not GTK: it's the windowing system.

With the advent of compositing, all windows are "visible" all the time,
from a toolkit perspective. The compositor is responsible for building
what's presented to the user. For example: are windows fully visible when
doing an "exposé"-like view? Are they not? If the compositor is ultimately
responsible of creating the final result of what's on the screen, it could
put each window on separate planets as far as the toolkit is concerned
(assuming latency and coordinate space size aren't a problem).

On Wayland is even "worse", because each window surface is completely
separate from every other window surface by design; each window has its own
coordinate system, that has an origin in the top-left corner of the window.
A window *cannot* be obscured by another window, as far as the toolkit is
concerned.

If you're targeting an X11 system from the late '90s/early '00s, then
visibility notifications *may* be emitted (though they are never
guaranteed). On anything more modern than that, or on
Wayland/Windows/macOS, visibility notification events are either
non-sensical, not emitted, or not possible by design.

This is why I said: "there is no way to know".

Ciao,
 Emmanuele.

On Sun, 3 Mar 2019 at 16:10, Paul Davis  wrote:

>
>
>
> On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
> gtk-devel-list@gnome.org> wrote:
>
>> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>>
>>>
>> For example... let's say the widget is a top-level window.  If it's
>>> currently displayed on screen but there's some other window hiding it
>>> (maybe from a totally different app) would 'is_visible()' return true or
>>> false?
>>>
>>
>> That's entirely different, and you should have said so at the very
>> beginning of the thread. Yes, both "visible" and "mapped" would be set to
>> true because you called show() on the window, and a window has no parents,
>> so once it's visible and realized, it'll be mapped as well; there is no way
>> to know, from a toolkit perspective, if a top level is being partially, or
>> totally, covered by some other window, either in the same process or from a
>> different process. That information is only available to the window manager.
>>
>
> John should really know that there's code to do this (to the best extent
> possible) within the Ardour source code at
> libs/gtkmm2ext/visibility_tracker.cc :)))
>
> It works (to whatever extent it does work) by handling GtkEventVisibility
> notifications. Hopefully this is still possible in GTK3 ?
>
>

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

Re: Gtk::Widget::is_mapped ()

[Emmanuele Bassi via gtk-devel-list]

On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:

> On 03/03/2019 11:22, Emmanuele Bassi wrote:
>
> On Sun, 3 Mar 2019 at 11:09, John Emmas  wrote:
>
>> Sorry to ask a dumb question...
>>
>> What does it mean if a widget is "mapped" ?
>>
>
> It means that:
>
>  - the widget is visible
>  - the widget is realized
>  - all its ancestors up to the top level window are mapped
>
> Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean
> 'literally visible' or 'capable of being visible'?
>

If it were enough, why would we have two flags? :-)

The "visible" property means "you, or something else, called
gtk_widget_show()" on the widget. A widget can be visible and not have any
parent, for instance.

If you want to know that a widget is going to be drawn, and respond to
events, then you have to check the "mapped" state.

For example... let's say the widget is a top-level window.  If it's
> currently displayed on screen but there's some other window hiding it
> (maybe from a totally different app) would 'is_visible()' return true or
> false?
>

That's entirely different, and you should have said so at the very
beginning of the thread. Yes, both "visible" and "mapped" would be set to
true because you called show() on the window, and a window has no parents,
so once it's visible and realized, it'll be mapped as well; there is no way
to know, from a toolkit perspective, if a top level is being partially, or
totally, covered by some other window, either in the same process or from a
different process. That information is only available to the window manager.

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

Re: Discourse instance

[Emmanuele Bassi via gtk-app-devel-list]

Note: for those who prefer email, we've written down a handy guide on how
to use email with Discourse:

  https://discourse.gnome.org/t/interacting-with-discourse-via-email/46

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:50, Emmanuele Bassi  wrote:

> And, of course, I forgot the link: https://discourse.gnome.org
>
> Embarrassing.
>
> Ciao,
>  Emmanuele.
>
> On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:
>
>> Hi all;
>>
>> after the discussion[1] last month, and the feedback received (both on
>> list and off), we decided to trial a Discourse instance on the GNOME
>> infrastructure.
>>
>> The Platform/Core sub-category is meant to be used for all discussions
>> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
>> stack.
>>
>> Email is still allowed for both posting and replying, though I strongly
>> encourage people to give the web UI a try; it's really nice.
>>
>> Feedback is very much appreciated.
>>
>> Ciao,
>>  Emmanuele.
>>
>> [1]:
>> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Emmanuele Bassi via gtk-devel-list]

Note: for those who prefer email, we've written down a handy guide on how
to use email with Discourse:

  https://discourse.gnome.org/t/interacting-with-discourse-via-email/46

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:50, Emmanuele Bassi  wrote:

> And, of course, I forgot the link: https://discourse.gnome.org
>
> Embarrassing.
>
> Ciao,
>  Emmanuele.
>
> On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:
>
>> Hi all;
>>
>> after the discussion[1] last month, and the feedback received (both on
>> list and off), we decided to trial a Discourse instance on the GNOME
>> infrastructure.
>>
>> The Platform/Core sub-category is meant to be used for all discussions
>> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
>> stack.
>>
>> Email is still allowed for both posting and replying, though I strongly
>> encourage people to give the web UI a try; it's really nice.
>>
>> Feedback is very much appreciated.
>>
>> Ciao,
>>  Emmanuele.
>>
>> [1]:
>> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


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

Re: Discourse instance

[Emmanuele Bassi via gtk-app-devel-list]

And, of course, I forgot the link: https://discourse.gnome.org

Embarrassing.

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:

> Hi all;
>
> after the discussion[1] last month, and the feedback received (both on
> list and off), we decided to trial a Discourse instance on the GNOME
> infrastructure.
>
> The Platform/Core sub-category is meant to be used for all discussions
> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
> stack.
>
> Email is still allowed for both posting and replying, though I strongly
> encourage people to give the web UI a try; it's really nice.
>
> Feedback is very much appreciated.
>
> Ciao,
>  Emmanuele.
>
> [1]:
> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Emmanuele Bassi via gtk-devel-list]

And, of course, I forgot the link: https://discourse.gnome.org

Embarrassing.

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:

> Hi all;
>
> after the discussion[1] last month, and the feedback received (both on
> list and off), we decided to trial a Discourse instance on the GNOME
> infrastructure.
>
> The Platform/Core sub-category is meant to be used for all discussions
> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
> stack.
>
> Email is still allowed for both posting and replying, though I strongly
> encourage people to give the web UI a try; it's really nice.
>
> Feedback is very much appreciated.
>
> Ciao,
>  Emmanuele.
>
> [1]:
> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


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

Discourse instance

[Emmanuele Bassi via gtk-app-devel-list]

Hi all;

after the discussion[1] last month, and the feedback received (both on list
and off), we decided to trial a Discourse instance on the GNOME
infrastructure.

The Platform/Core sub-category is meant to be used for all discussions
about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
stack.

Email is still allowed for both posting and replying, though I strongly
encourage people to give the web UI a try; it's really nice.

Feedback is very much appreciated.

Ciao,
 Emmanuele.

[1]:
https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Discourse instance

[Emmanuele Bassi via gtk-devel-list]

Hi all;

after the discussion[1] last month, and the feedback received (both on list
and off), we decided to trial a Discourse instance on the GNOME
infrastructure.

The Platform/Core sub-category is meant to be used for all discussions
about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
stack.

Email is still allowed for both posting and replying, though I strongly
encourage people to give the web UI a try; it's really nice.

Feedback is very much appreciated.

Ciao,
 Emmanuele.

[1]:
https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html

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

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-devel-list]

On Wed, 6 Feb 2019 at 12:19, Emmanuele Bassi  wrote:

>
> The main differences are that you’d need a different subscription account
> than the existing one, and that you wouldn’t have the weekly digests, as
> far as I can see.
>

It turns out I was wrong: Discourse has "weekly summaries" as well.

As for the subscription: Discourse supports multiple identity
providers—Google, Facebook, Instagram, Twitter, Yahoo, and GitHub are all
supported, and there's a plugin available for GitLab authentication as
well, so we might be able to automatically authenticate existing GTK
contributors with an account on gitlab.gnome.org.

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

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-devel-list]

On Thu, 7 Feb 2019 at 00:54,  wrote:

> > We already looked at Hyperkitty, and found it fairly limited in
> > functionality. Avoiding Hyperkitty is what led us to Discourse in the
> > first place.
> Can you link that discussion please?


It was on IRC and in person discussions, and private emails between various
people.


> I'm interested what newcomers want
> to do such that Hyperkitty doesn't let. Negatives of Discourse: loads
> slower, broken without evergreen CSS and JS, huge blank margins. Fedora
> uses Hyperkitty on its other, non-Silverblue lists.
>

We asked Fedora developers for their experiences, and they weren't overly
impressed with it.

Off the top of my head (and after using Hyperkitty to browse Fedora desktop
and devel mailing lists for the last couple of years):

 - Hyperkitty's UX is confusing, cluttered to the point of being unhelpful
 - navigating through recent discussions never makes it clear which emails
are newer, and the fake threading makes it visually harder to scan
 - searching is a disaster, with results returned without any sense of
what's relevant or not
 - mobile access is pretty much not supported
 - it's all just a front to a mailman, instead of being a whole packaged
software; this means:
  - harder to set up and upgrade
  - no moderation tools
  - no categories, sub-categories, or tagging to organise email
  - no integration with services or additional plugins

In general, mailman3 + hyperkitty is a somewhat good upgrade on mailman2
(even though I still prefer the old archive pages compared to hyperkitty;
I've been going through those *a lot* for my "History of GNOME" project),
but it does not compare to other platforms like Discourse.

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

Re: Migrating away from GtkStock stuff

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 7 Feb 2019 at 13:30, Gabriele Greco 
wrote:


> (test:77229): Gtk-WARNING **: 14:28:49.162: Could not find the icon
> 'help-about'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
> You can get a copy from:
> http://icon-theme.freedesktop.org/releases
>
> (test:77229): Gtk-WARNING **: 14:28:49.162: Error loading theme icon
> 'help-about' for stock: Icon 'help-about' not present in theme Adwaita
>

GTK uses `help-about` internally, because it doesn't use stock icons.

You need an icon theme for the icons GTK uses, currently, though we're
thinking of shipping a cut down version of Adwaita inside GTK for that
reason: https://gitlab.gnome.org/GNOME/gtk/issues/1235

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Migrating away from GtkStock stuff

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 7 Feb 2019 at 11:52, Gabriele Greco via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi guys,
>
> I'm in the process of migrating a big code base from GTK 2.x to GTK 3.x,
> I've done most of the work, but I'm facing now some problems with GTK stock
> stuff.
>
> I used stock stuff a lot to reduce the localizable strings needed in my
> code and to reduce the number of images to ship.
>
> From what I've seen there are no more stock items in GTK 3 (3.24.2 at the
> moment), since they have been deprecated in 3.10.
>
>
That's not correct: GTK still ships the stock icons. You can find them in
the tree as `gtk/icons///`. The icons themselves are built
into the GTK shared library as GResources.

The labels are still there, but you're strongly encouraged to ship your own
strings, with your own mnemonics; GTK cannot know which mnemonics you or
your translators use, so there will inevitably be conflicts, which will
make your application look bad, or behave worse.


> It's more a removal than a deprecation since my code compiles but the
> program seems to fail to find at least the icons pointed by the stock item:
>
> (:75970): Gtk-WARNING **: 12:47:16.541: Error loading theme icon
> 'document-new' for stock: Icon 'document-new' not present in theme Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.598: Error loading theme icon
> 'document-open' for stock: Icon 'document-open' not present in theme
> Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon
> 'document-save' for stock: Icon 'document-save' not present in theme
> Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon
> 'edit-find' for stock: Icon 'edit-find' not present in theme Adwaita
>
>
If you're using `edit-find` or `document-save` then you're using a named
icon from the icon theme, not the stock identifier.

For those, you'll have to ship an icon theme like Adwaita.

There is a stack overflow post that suggests how to handle the migration
> from a GtkStock item to a "named icon" or a "gtk localized label":
>
>
> https://stackoverflow.com/questions/36805505/gtk-stock-is-deprecated-whats-the-alternative
>
> ... but what about toolbar or buttons that given the theme may have icons,
> labels or both?
>

You are strongly encouraged to reduce the number of icons in your UI to
begin with; icons need to be extremely recognisable if you want to reduce
the mental load on users, and if you're showing both text and icons, users
will use the text, not the icon, to know what ai UI element does—if they
don't memorise the spatial location of the UI element, in which case
they'll use spatial memory instead of icon/text memory:

https://uxmyths.com/post/715009009/myth-icons-enhance-usability

In any case, if you wish to move away from stock elements, the
recommendation is to move to icon theme names (GTK deprecation notes will
tell you what to use instead, if there is a replacement). If you don't want
to ship a whole icon theme, because of disk/download size constraints, or
build a list of icon assets you know you are using, and then you can either
take the Adwaita icon theme and remove everything you don't use, or create
the same file system layout as the icon theme but under your own
application's data directory:

https://wiki.gnome.org/DraftSpecs/ThemableAppSpecificIcons

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-app-devel-list]

More information on Discourse:

  - About: https://www.discourse.org/about
  - Features: https://www.discourse.org/features

Discourse is a forum software that has multiple ways to access it: web,
native apps, and email. It's not a mailing list software with a web
frontend.

The interesting (to me) parts are:

 - 2FA instead of Mailman's plaintext password
 - real moderation tools, that can scale with the community and encourage
civility and code of conduct compliant behaviour
 - anti-spam measures
 - open source software (kind of a pre-requisite)
 - good UI for reading and replying to topics

The Fedora (Silverblue) and Ubuntu communities already use Discourse, for
instance; the SDL community also does.

Ciao,
 Emmanuele.


On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi  wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> Are there any objections? Did somebody already try out Discourse and has
> opinions about it that they want to share with the community?
>
> Ciao,
>  Emmanuele.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-devel-list]

More information on Discourse:

  - About: https://www.discourse.org/about
  - Features: https://www.discourse.org/features

Discourse is a forum software that has multiple ways to access it: web,
native apps, and email. It's not a mailing list software with a web
frontend.

The interesting (to me) parts are:

 - 2FA instead of Mailman's plaintext password
 - real moderation tools, that can scale with the community and encourage
civility and code of conduct compliant behaviour
 - anti-spam measures
 - open source software (kind of a pre-requisite)
 - good UI for reading and replying to topics

The Fedora (Silverblue) and Ubuntu communities already use Discourse, for
instance; the SDL community also does.

Ciao,
 Emmanuele.


On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi  wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> Are there any objections? Did somebody already try out Discourse and has
> opinions about it that they want to share with the community?
>
> Ciao,
>  Emmanuele.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


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

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-devel-list]

On Wed, 6 Feb 2019 at 15:11, Charles Lindsey  wrote:

>
>
> On 06/02/2019 11:46, Emmanuele Bassi via gtk-devel-list wrote:
> > [Cross-posted to various relevant mailing lists; please, reply to
> > gtk-devel-list]
> >
> > As part of an attempt at making GTK more friendly to newcomers, I and
> other
> > core developers were thinking of moving the mailing lists from the
> current
> > mailman installation to Discourse:
> >
> >https://discourse.org/
> >
> > Possibly still hosted on GNOME infrastructure, depending on the
> > requirements for our sysadmins.
>
> > Are there any objections? Did somebody already try out Discourse and has
> > opinions about it that they want to share with the community?
>
> Does that mean I have to log in to Discourse every day just to check
> whether
> some new message has arrived? If so, then no thank you.


No, you could still get email notifications for messages, and you could
still send email replies; that's supported on Discourse, as you could
easily check on their website.


> This is a low volume
> list, often with two or more weeks between messages.
>

Yes, the *gtk-devel-list* mailing list is low volume, compared to
gtk-app-devel-list and gtk-list. Did you ever wonder why it is? Mostly
because mailing lists are kind of terrible. The idea behind switching to
Discourse is to improve the communication channels available to GTK
developers and users to something more useful than email.

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

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-devel-list]

Hi;

On Wed, 6 Feb 2019 at 13:10, Reuben Rissler  wrote:

>
> To introduce myself, I only am using Gtk for 3 years, but really like
> the infrastructure / people / open source surrounding Gtk. I am
> sometimes seen as 'theGtknerd'.
>
>
> On 02/06/2019 06:46 AM, Emmanuele Bassi via gtk-devel-list wrote:
> >
> > The GTK project would have various sub-topics, mostly around
> > development with and of GTK. Having a better archive search, a better
> > moderation system, and a decent web UI are the major selling points
> > for switching to Discourse. The fact that the project is also open
> > source is neatly aligned with our values.
> Let me ask a poignant question, was moderation ever a problem with
> mailing lists?


As the person that moderates two out of the three GTK mailing lists, yes:
it’s somewhat annoying the amount of spam going on every day. Not terrible,
but it’d be nice not to have to deal with it. Additionally, Discourse would
allow us to deal with code of conduct violations in a much better way than
mailman currently lets us.



> >
> > Are there any objections? Did somebody already try out Discourse and
> > has opinions about it that they want to share with the community?
> I have a computer that is email only for work (no web browser for
> several personal reasons). I could no longer be a part of the Gtk
> responders as far as I can see.


That’s not accurate: Discourse also works with email, so you’d receive
email messages and you’d be able to reply to email messages.

The main differences are that you’d need a different subscription account
than the existing one, and that you wouldn’t have the weekly digests, as
far as I can see.

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

Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-app-devel-list]

[Cross-posted to various relevant mailing lists; please, reply to
gtk-devel-list]

As part of an attempt at making GTK more friendly to newcomers, I and other
core developers were thinking of moving the mailing lists from the current
mailman installation to Discourse:

  https://discourse.org/

Possibly still hosted on GNOME infrastructure, depending on the
requirements for our sysadmins.

The GTK project would have various sub-topics, mostly around development
with and of GTK. Having a better archive search, a better moderation
system, and a decent web UI are the major selling points for switching to
Discourse. The fact that the project is also open source is neatly aligned
with our values.

Are there any objections? Did somebody already try out Discourse and has
opinions about it that they want to share with the community?

Ciao,
 Emmanuele.
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Project rename to "GTK"

[Emmanuele Bassi via gtk-devel-list]

Hi all;

tl;dr: GTK is GTK, not GTK+. The documentation has been updated, and the
pkg-config file for the future 4.0 major release is now called "gtk4"

over the years, we had discussions about removing the "+" from the project
name. The "plus" was added to "GTK" once it was moved out of the GIMP
sources tree and the project gained utilities like GLib and the GTK type
system, in order to distinguish it from the previous, in-tree version. Very
few people are aware of this history, and it's kind of confusing from the
perspective of both newcomers and even expert users; people join the wrong
IRC channel, the URLs on wikis are fairly ugly, etc.

With the move to Git, years ago, we had to add a couple of hacks to allow
for the "plus" to stay in the repository browsing UI; those hacks were
dropped once we moved to GitLab. We discussed again during IRC meetings and
hackfests whether to drop the "plus", and we finally decided to do so.

With the work in the master branch towards the 4.0 release, it's finally
time to say goodbye to the "plus" in "GTK+".

The documentation is updated so that the project in named consistently.

The removal of the plus has a side effect on the name of the pkg-config
file for GTK 4; additionally, since we don't break API across the same
major version, having a fully qualified major.minor version in the
pkg-config file is redundant. This means that the pkg-config file for GTK 4
is going to be called "gtk4".

Incidentally, the IRC channel on irc.gnome.org is now called "#gtk";
there's a re-direct in place, so if you join "#gtk+" you'll end up in the
right place.

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

Re: Searching for text in PDF files is wrong

[Emmanuele Bassi via gtk-app-devel-list]

Hi;

this list is for the development of applications with GTK; your question
relates to Poppler, so you should ask on a Poppler-related mailing list or
developers forum, e.g.
https://lists.freedesktop.org/mailman/listinfo/poppler

Ciao,
 Emmanuele.

On Fri, 30 Nov 2018 at 20:56, Радомир Хаџић via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi.
>
> I use poppler_page_find_text() to find text in PDF files. This returns
> GList of pointers to PopplerRectangles. Then I use
> poppler_page_render_selection() to mark the found text.
>
> What is wrong is that PopplerRectangles returned by
> poppler_page_find_text() are incompatible with those that
> poppler_page_render_selection() requests, which is why the wrong text
> is selected.
>
> I have found that to make those two compatible, I have to do the
> following to PopplerRectangles returned by poppler_page_find_text():
> 1) SWAP(rectangle.x1, rectangle.x2);
> 2) SWAP(rectangle.y1, rectangle.y2);
> 3) rectangle.y1 = page_height - rectangle.y1;
> 4) rectangle.y2 = page_height - rectangle.y2;
> But this does not solve the problem because the marked text cycles
> between right and wrong again while resizing the window.
>
> I have created a small program that illustrates the problem. Here it
> is: https://pastebin.com/h3F56Yv7 (I've also sent an attachment but
> last time you didn't get it so this paste is a fallback in case you
> don't get it again.)
> You ought to supply two arguments when running the program: the
> absolute path to a PDF file and the text you want to search for,
> respectively. Pay attention to the selected text with and without
> lines 54-57.
>
> How can I make the found text to be marked properly? This "workaround"
> does not work very well and it is an ugly solution anyway.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Detect dark or light theme from an application

[Emmanuele Bassi via gtk-app-devel-list]

On Wed, 7 Nov 2018 at 00:48, Yuri Khan via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hello everybody,
>
> I know in the GTK+3 theming engine a theme can define a light variant
> and a dark variant. Is it possible, in an application, to know which
> variant is currently used, and/or specify which widget in the
> application uses which variant?
>

No.

"Variants" are really only used by applications themselves, i.e. your
application explicitly says that it prefers a dark variant of the current
theme, if it's available. This is opt-in from the application perspective,
though of course themes may not have a dark variant.

User options do not change the theme variant: they change the theme; in
other words, if a user decides to enable a dark theme globally, they will
enable a dark theme, not the dark variant of the current theme.

The only way to respect the GTK theme is to use GTK to render UI elements
according to that theme—using the `gtk_render_*` API. Anything else is, by
and large, impossible unless you literally parse the CSS with your own CSS
parser, determine the colours of every UI element you care about, and then
detect whether those colours are "light" or "dark".

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Segmentation fault when passing Poppler objects

[Emmanuele Bassi via gtk-app-devel-list]

On Tue, 6 Nov 2018 at 09:55, Радомир Хаџић via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi. I get segmentation fault if I try to access a Poppler object whose
> pointer is passed through g_signal_connect. There is no such problem
> with normal pointers, though.


This:


> void draw_cb(GtkWidget *drawing_area, struct Colors *colors)
>

Is *not* the signature for a GtkWidget::draw signal callback.

The signature is:

  gboolean (* draw) (GtkWidget *widget, cairo_t *context, gpointer
user_data);


0x5571faa9c6e0

> 0x5571fac68200
> current colors are:
> red 0.00
> green 0.00
> blue 0.00
> As we can see, colors in main and colors in draw_cb have different
> values, but this doesn't stop us from accessing the object (I wonder
> how this works, though it's not important in this case).
>

It "works" because you're getting passed a pointer to a memory area, and
you're trying to access it by 3 `sizeof(double)` offsets; the cairo_t
structure is large enough to accommodate those accesses without generating
a segmentation fault, but of course cairo_t does not contain 3 doubles at
the very beginning of its structure, so you're getting garbage that C
helpfully translates to a double representation. I also assume that you're
running on a 64 bit architecture, because if you tried the same of 32 bits
archs, you'd very much get a segmentation fault.

Of course, this will never work for a PopplerDocument instance, because
you're not trying to access the first `3 * sizeof(double)` bytes of it:
you're calling a Poppler function, which expects a PopplerDocument
instance, instead of a cairo_t one:

void doc_cb(GtkWidget *drawing_area, PopplerDocument *doc)
> {
> g_print("%p\n", doc);
> g_print("%d\n", poppler_document_get_n_pages(doc));
> }
>
>
Which is why you're getting a segmentation fault.

I strongly encourage you to read the GTK API reference:

https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw

In general, you should *always* read the documentation for each signal
you're using, to know the signature of the callback associated to the
signal. The signal machinery disables a lot of the type safety at compile
time in order to allow generic functions to be invoked without ad hoc
emitters.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK+ 2.0/3.0 Windows runtimes

[Emmanuele Bassi via gtk-app-devel-list]

Hi;

On Tue, 23 Oct 2018 at 08:26, John Mills  wrote:

> Hello list
>
> If this question should be raised on another list, please let me know.
>
> I have been developing a C-language GTK+ 2.0 application for MS Windows 10
> using mingw
> cross-compilation on Linux, and deploying it by installing the Windows
> GTK+ 2.0 runtime
> bundle on the Windows machine.
> http://ftp.gnome.org/pub/gnome/binaries/win32/
>
> The procedure was: on Linux development machine, unzip the gtk Windows
> bundle in a directory
> with the C source, set up a Makefile with the appropriate CFLAGS and
> LDFLAGS, 'make mingw'
> and deploy the EXE. This procedure suited my development style.
>
> Do I now need to port to GTK+ 3?
>

Considering that GTK 2.x is now in deep maintenance mode, you're strongly
encouraged to migrate to GTK 3.24 — if and only if you're interested and
have enough design and maintenance effort for the migration, and if you
need functionality that is just never going to happen in the GTK 2.x branch.

If you don't have any particular requirement, and you don't have enough
bandwidth to migrate, then you can keep using GTK 2.24; it's not going to
go away.

Is MSYS2 now the best/only way to deploy the dependencies to Windows?
>

MSYS2 is the recommended way to *develop* an application using GTK 3.24 on
Windows, natively. GTK developers are not going to ship binary builds for
you, as we don't have the resources to do so—on any platform, in any case,
not just on Windows.

In order to ship GTK applications on Windows to your users you're strongly
encouraged to take the builds you made and put them into an installer
binary; your users do not need MSYS2.


> Using the binaries available through MSYS2/pacman, can I still develop on
> Linux and deploy
> mingw executables to Windows?
>

You can still cross-compile on Linux for Windows; many Linux distributions
have mingw packages to accomplish just that. The recommendation is still to
package up your binary builds into an installer, and ship the installer to
your users.


> Can anyone point me to a guide for doing that?
>

There are various GTK applications that have build and release scripts for
Windows; gedit and hexchat come to mind:

  - https://gitlab.gnome.org/GNOME/gedit/tree/master/win32
  - https://github.com/hexchat/hexchat/tree/master/win32

For Linux/Windows cross-compilation there are distro-specific tutorials:

  - Fedora: https://fedoraproject.org/wiki/MinGW/Tutorial
  - Debian: https://wiki.debian.org/Mingw-W64

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Wayland Window Positioning

[Emmanuele Bassi via gtk-app-devel-list]

You probably want to ask on gtk-devel-list and gnome-shell-list.

Wayland interfaces need to be implemented by the compositor, and typically
not piecemeal. That KDE interface seems to be a private interface shared
between Plasma and kwin, like the gtk_shell interface is a private
interface between GTK and GNOME Shell; typically what happens is that
toolkit and compositor developers iterate over their requirements and then
propose the addition of functionality to the xdg_shell shared interface.

You could ask the gnome-shell developers to expose a similar functionality
in the gtk_shell interface, and then GTK would be able to consume it; but
that requires coordination between GNOME Shell and GTK releases.

Ciao,
 Emmanuele.

On Tue, 2 Oct 2018 at 11:13, Gerald Nunn via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> With respect to window positioning in Wayland, I was wondering if mutter
> supports a Wayland extension to position windows similar to what
> PlasmaShell does. Keep in mind I'm not very familiar with Wayland, however
> looking at the Wayland protocol definition for PlasmaShell it looks like
> they have this here:
>
>
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/plasma-shell.xml#L170
>
> Looking at the similar file for gtk-shell I don't see anything similar:
>
>
> https://github.com/GNOME/mutter/blob/master/src/wayland/protocol/gtk-shell.xml
>
> I have a lot of people asking me for Wayland support of quake mode in Tilix
> where the terminal emulator sticks at the top or bottom of the screen.
> Without being able to explicitly position the window this isn't possible.
> Someone pointed me to Yuakake which seems to do it by integrating with the
> PlasmaShell Wayland extension from what I can tell.
>
> Thanks,
>
> Gerald
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Any way to access treeview in GtkFileChooser?

[Emmanuele Bassi via gtk-app-devel-list]

Do you have an example of how you want to modify the style?

Changing the style does not require access to the widget: it requires
loading a CSS fragment in your application's startup code, and applying the
appropriate selector to match the treeview inside the file chooser dialog.

Ciao,
 Emmanuele.

On Mon, 17 Sep 2018 at 16:15, Marco Ricci  wrote:

> I want to modify the column headers to be consistent with the style/theme
> of the rest of the application I am working on.
>
> Thanks,
> marco
>
> ----
> On Mon, 9/17/18, Emmanuele Bassi  wrote:
>
>  Subject: Re: Any way to access treeview in GtkFileChooser?
>  To: marcoricci2...@yahoo.com
>  Cc: "gtk-app-devel-list list" 
>  Date: Monday, September 17, 2018, 9:31 AM
>
>  No, and it's never a good idea
>  to do so.
>
>  Care to
>  tell use what are you trying to achieve?
>
>  Ciao,
>   Emmanuele.
>
>
>  On Mon, 17
>  Sep 2018 at 15:25, Marco Ricci via gtk-app-devel-list <
> gtk-app-devel-list@gnome.org>
>  wrote:
>  I want to
>  get a handle to the GtkTreeView object that lists the files
>  in GtkFileChooser and customize it. Is there any way I can
>  access this object directly?
>
>  ___
>
>  gtk-app-devel-list mailing list
>
>  gtk-app-devel-list@gnome.org
>
>  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
>
>  --
>
>  https://www.bassi.io
>  [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: An alternative to gdk-pixbuf

[Emmanuele Bassi via gtk-devel-list]

On Sun, 16 Sep 2018 at 10:47, John Emmas  wrote:

> On 15/09/2018 18:48, John Emmas wrote:
> >
> > Do you happen to know if the tiff library has its own mailing list? I
> > haven't had much success in finding one
> >
>
> In fact I'll need the mailing list for gdk-pixbuf now - except that I
> can't find that one either!! (or is this the correct place for reporting
> gdk-pixbuf issues?)
>
>
The correct way to report issues for gdk-pixbuf:

1. use the issue tracker:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/new
2. do not attach to an existing, unrelated thread on a mailing list; create
a new topic instead

For discussions, you can use this mailing list—but issues should strictly
be reported on the issue tracker.

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

Re: Introspection data generation error in evince (autotools vs meson)

[Emmanuele Bassi via gtk-app-devel-list]

Just as a follow up to this for the archives, since it has been fixed in
Evince[0]:

 - the issue is caused by a double declaration of `GType
ev_document_model_get_type (void)`—one by the G_DECLARE_FINAL_TYPE at line
33, and one explicit at line 57. This confuses the g-ir-scanner parser, and
would be nice to track it down a bit further
 - next time, you probably want to use gir-devel-list for this kind of
issues, not gtk-app-devel-list

Ciao,
 Emmanuele.

[0]: https://gitlab.gnome.org/GNOME/evince/merge_requests/82

On Fri, 7 Sep 2018 at 07:35, Iñigo Martínez via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hello,
>
> I have recently started porting evince to meson. The port is almost
> complete but I have an issue with the generation of introspection data of
> one of its libraries, `libevview3`, which I haven't been able to figure out
> due to my limited introspection knowledge.
>
> The introspection build parameters are as follows in the autotools'
> Makefile[0]:
>
> ```
> INTROSPECTION_COMPILER_ARGS = --includedir=$(top_builddir)/libdocument
>
> EvinceView-$(EV_API_VERSION).gir: libevview3.la
> EvinceView_@EV_API_VERSION_U@_gir_FILES = \
> $(INST_H_SRC_FILES) \
> $(INST_H_BUILT_FILES)   \
>  $(filter %.c,$(libevview3_la_SOURCES))
> EvinceView_@EV_API_VERSION_U@_gir_INCLUDES = GLib-2.0 GObject-2.0 Gio-2.0
> Gdk-3.0 GdkPixbuf-2.0 Gtk-3.0
> EvinceView_@EV_API_VERSION_U@_gir_LIBS = libevview3.la
> $(top_builddir)/libdocument/libevdocument3.la
> EvinceView_@EV_API_VERSION_U@_gir_CFLAGS = \
> -I$(top_srcdir) \
> -I$(top_builddir)   \
> -I$(top_srcdir)/libdocument \
> -I$(top_builddir)/libdocument   \
> -DEVINCE_COMPILATION
> EvinceView_@EV_API_VERSION_U@_gir_EXPORT_PACKAGES =
> evince-view-$(EV_API_VERSION)
> EvinceView_@EV_API_VERSION_U@_gir_SCANNERFLAGS = \
> --add-include-path=$(top_builddir)/libdocument  \
>
>
> --include-uninstalled=$(top_builddir)/libdocument/EvinceDocument-$(EV_API_VERSION).gir
> \
> --identifier-prefix=Ev  \
> --symbol-prefix=ev
> INTROSPECTION_GIRS = EvinceView-$(EV_API_VERSION).gir
>
> girdir = $(datadir)/gir-1.0
> gir_DATA = EvinceView-$(EV_API_VERSION).gir
>
> typelibsdir = $(libdir)/girepository-1.0
> typelibs_DATA = EvinceView-$(EV_API_VERSION).typelib
> ```
>
> These produces the following command lines:
>
> ```
> CPPFLAGS="" CFLAGS="-g -O2" LDFLAGS="-L/home/imartinez/jhbuild/install/lib
> " CC="gcc" PKG_CONFIG="/usr/bin/pkg-config" GI_HOST_OS="" DLLTOOL="false"
> /usr/bin/g-ir-scanner   --namespace=EvinceView --nsversion=3.0
> --libtool="/bin/bash ../libtool"  --include=GLib-2.0 --include=GObject-2.0
> --include=Gio-2.0 --include=Gdk-3.0 --include=GdkPixbuf-2.0
> --include=Gtk-3.0 --pkg-export=evince-view-3.0   --library=libevview3.la
> --library=../libdocument/libevdocument3.la
> --add-include-path=../libdocument
> --include-uninstalled=../libdocument/EvinceDocument-3.0.gir
> --identifier-prefix=Ev --symbol-prefix=ev --cflags-begin -I.. -I..
> -I../libdocument -I../libdocument -DEVINCE_COMPILATION --cflags-end
> ev-document-model.h ev-jobs.h ev-job-scheduler.h ev-print-operation.h
> ev-stock-icons.h ev-view.h ev-view-presentation.h ev-view-type-builtins.h
> ev-annotation-window.c ev-document-model.c ev-form-field-accessible.c
> ev-image-accessible.c ev-jobs.c ev-job-scheduler.c ev-link-accessible.c
> ev-page-accessible.c ev-page-cache.c ev-pixbuf-cache.c ev-print-operation.c
> ev-stock-icons.c ev-timeline.c ev-transition-animation.c ev-view.c
> ev-view-accessible.c ev-view-cursor.c ev-view-presentation.c
> ev-media-player.c libevview3.la --output EvinceView-3.0.gir
> g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC gcc -o
>
> /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0
> -export-dynamic -g -O2
>
> /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o
> -L. libevview3.la ../libdocument/libevdocument3.la
> -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0
> -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0
> -L/home/imartinez/jhbuild/install/lib
> libtool: link: gcc -o
>
> /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/.libs/EvinceView-3.0
> -g -O2
>
> /home/imartinez/Development/gnome/evince-at/libview/tmp-introspectfyj_c9fn/EvinceView-3.0.o
> -Wl,--export-dynamic -pthread -Wl,--export-dynamic  -L.
> ./.libs/libevview3.so ../libdocument/.libs/libevdocument3.so
> -L/home/imartinez/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0
> -lglib-2.0 -pthread -Wl,-rpath -Wl,/tmp/evince/lib
> g-ir-scanner: EvinceView: warning: 2 warnings suppressed (use --warn-all to
> see them)
> ```
>
> This command creates the `EvinceView-3.0.gir` file properly. I tried to
> replicate this on meson by using the same parameters[1]:
>
> ```
>   incs = [
> 'Gdk-3.0',
> 'GdkPixbuf-2.0',
> 'Gio-2.0',
> 'GLib-2.0',
> 'GObject-2.0',
> 'Gtk-3.0',
> 

Re: Problems with git.gnome.org

[Emmanuele Bassi via gtk-devel-list]

Are you trying to access a repository using a `git://` URL? That has been
deprecated a long time ago, for security reasons, and with GitLab it was
removed altogether.

Ciao,
 Emmanuele.

On Thu, 6 Sep 2018 at 14:09, John Emmas  wrote:

> Hi guys - sorry for posting this here but I've tried gnome's
> 'gitlab-issues' mailing list and couldn't get any response.  Maybe
> someone here can help..?
>
> For the past few weeks I've been seeing errors if I try to update (i.e.
> pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc).
> Here's what I see...
>
>  Looking up git.gnome.org ... done.
>  Connecting to git.gnome.org (port 9418) ... fatal: unable to
> connect to git.gnome.org
>  git.gnome.org[0: 209.132.180.168]: errno=No error
>  git.gnome.org[1: 209.132.180.180]: errno=No error
>
> At first I assumed the repos were down temporarily but it's not getting
> any better so I'm guessing the libraries have been moved somewhere
> else?  So do I maybe need to change something at my end?
>
> It doesn't seem to be affecting all my gtk support libs BTW - just some
> of them... Thanks,
>
> John
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>


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

Re: An alternative to gdk-pixbuf

[Emmanuele Bassi via gtk-devel-list]

On Wed, 5 Sep 2018 at 19:25, Magnus Bergman 
wrote:

> On Wed, 5 Sep 2018 17:28:22 +0100
> Emmanuele Bassi  wrote:
>
> > We're phasing out Cairo in favour of the CSS rendering model,
> > implemented on top of OpenGL and Vulkan, as it's the API that most
> > closely matches the requirements of GTK.
>
> I'm not sure I quite understand what you are saying. What does this
> mean for image loading if terms of actual implementation? What would
> ideally happen then GTK+ needs to load an image (because the
> application called gtk_image_new_from_file() for example)?
>
>
We're still using GdkPixbuf, and for the 4.0 API series we still have
GdkPixbuf types exposed in the GTK API.

For future API series (5.x, 6.x, …) we may revisit this, with the option of
moving icon loading into GTK itself.


> > Cairo is still used as a fallback mechanism — both when running on
> > platforms without support for OpenGL or Vulkan, and in the interim
> > period while the GL/Vulkan rendering pipelines inside GTK don't
> > support a CSS feature. Additionally, you may still use Cairo for 2D
> > high quality rendering, for printing and for custom drawing.
>
> But then it comes to printing and custom drawing I'm on my own then it
> comes to loading the images? Which is okey of course since gdk-pixbuf
> is kind of a separate library already. But isn't it a good thing to
> share common image loading code?
>

Not really; icons—especially ones that are identified via icon theme
names—are a very narrow subset of "all the possible images and formats in
human history".

Gegl is great for image editing. But not as much for simple viewing.


This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi display
I'm already pushing gdk-pixbuf and cairo to their limits because of the
scaling factor applied to the window — not only the buffer gets loaded
uncompressed to allow for zooming, but the image viewer needs to render a
CPU-scaled down copy of the image.

Sure, for viewing a 500x400px image macro for a meme we're fine; but we're
fine with gdk-pixbuf as well, so there's really no need to change to a
different image loading library.


> It doesn't do animation


Animated formats are a dying breed, and they have all but killed by VP9 and
new, web-friendly video formats. Social platforms will take a GIF and turn
it into a video transparently.

Additionally, GTK 4.x already has new API to render videos and other
frame-based media sources through GStreamer.

> From the perspective of a consumer of GdkPixbuf, the only thing that
> > an image loading library should do is, pretty literally, load images.
> > No scaling, no compositing, no rendering. Saving to a file may be
> > interesting — but that opens the whole transcoding can of worms, so
> > maybe it should just be a debugging feature. Ideally, I/O operations
> > should happen in a separate thread, and possible use multi-threading
> > to chunk out the work on multiple cores; it definitely needs to
> > integrate with GIO, as it's a modern API that well maps to GUIs.
>
> Yes, I very much agree with this. Except I think it has to do rendering
> of some sort. If an image contains a triangle, it has to be converted to
> a function call that renders it (using OpenGL/Vulcan/cairo) somehow.
>

That's up to the toolkit, as it's going to be the one deciding how to
render the rest of the UI. There's no way for you to know, from the
outside, how to efficiently render anything.

That's why it's much, much better to get a memory buffer with the contents
of the image, and let the toolkit pass it to the GPU.

Vector formats are different, but that's why we have API like Cairo or
Skia; I'm also waiting for web browsers to implement SVG rendering on the
GPU where possible, with the help of new primitives from the GL/Vulkan
implementation.

> In the near future, I'll very likely deprecate most of GdkPixbuf's
> > API, except for the I/O operations; I'd also be happy to seal off
> > most of its internals, within the ABI stability promise, to avoid
> > leakage of internal state.
>
> Will the loader plugin API go away, you think?
>

No API will ever go away: there are no plans for a gdk-pixbuf-3.0. The
deprecations would mostly apply to API that is either long since been
replaced by Cairo (scale/composite), or that is weirdly ad hoc, like
saturate_and_pixelate(). Ideally, I'd like to deprecate the option to build
gdk-pixbuf without depending on GIO to do MIME type sniffing, as GIO has
been fixed to work on Windows and macOS, and it is a required dependency
anyway. The animation API is pretty much a garbage fire, so it may go on
the chopping block as well. Of course, deprecated API will keep working as
well—or as badly—as it works today, so people can still use it. Moving
pixbuf loaders to separate processes, and 

Re: An alternative to gdk-pixbuf

[Emmanuele Bassi via gtk-devel-list]

Hi;

On Tue, 4 Sep 2018 at 23:19, Magnus Bergman 
wrote:

> Over the years it has been discussed from time to time to replace
> gdk-pixbuf with something else[1][2]. Something was even in the making
> (I guess over ten years ago) but it never replaced gdk-pixbuf
> apparently. Now I don't even remember what it was called. And something
> else called pig was proposed more recently.
>
> One major reason to replace gdk-pixbuf has been the long term goal to
> phase out GDK in favour of cairo. And some people (including me) has
> been displeased with the gdk-pixbuf API for more subtle reasons. It has
> also been brough up that it lacks some features (which I guess are hard
> to implement as an afterthought). I finally took some time to design an
> image loading library on top of cairo called abydos, which at least
> suits my needs. And also some needs mentioned in this list over the
> years. First I thought it could suit the needs of GTK+ as well. But I
> just learned that even cairo is now considered "legacy technology" by
> the GTK+ developers[3], so I guess cairo is also being phased out now.
> But in favour of what?


We're phasing out Cairo in favour of the CSS rendering model, implemented
on top of OpenGL and Vulkan, as it's the API that most closely matches the
requirements of GTK.

Cairo is still used as a fallback mechanism — both when running on
platforms without support for OpenGL or Vulkan, and in the interim period
while the GL/Vulkan rendering pipelines inside GTK don't support a CSS
feature. Additionally, you may still use Cairo for 2D high quality
rendering, for printing and for custom drawing.

Internally, GTK only cares about GdkPixbuf in as much as it provides us
with a way to load graphic assets like icons, which are typically in a very
limited amount of formats. As far as we're concerned, image data coming
from GdkPixbuf and Cairo gets loaded into memory buffers that get submitted
to the GPU almost immediately, and all transformations and rendering happen
using shaders, on the GPU.

Anything bigger than an icon should probably be loaded and displayed
through Gegl, the same library used by the GIMP; this is especially true if
you're planning to process the image using filters. Images, these days, are
pretty big buffers — and so are displays; using a simple linear buffer like
GdkPixbuf's does not scale.

>From the perspective of a consumer of GdkPixbuf, the only thing that an
image loading library should do is, pretty literally, load images. No
scaling, no compositing, no rendering. Saving to a file may be interesting
— but that opens the whole transcoding can of worms, so maybe it should
just be a debugging feature. Ideally, I/O operations should happen in a
separate thread, and possible use multi-threading to chunk out the work on
multiple cores; it definitely needs to integrate with GIO, as it's a modern
API that well maps to GUIs.

In the near future, I'll very likely deprecate most of GdkPixbuf's API,
except for the I/O operations; I'd also be happy to seal off most of its
internals, within the ABI stability promise, to avoid leakage of internal
state.

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

Re: "draw" icon with string

[Emmanuele Bassi via gtk-app-devel-list]

On Tue, 4 Sep 2018 at 00:09, c.buhtz--- via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Dear Emmanuele,
>
> you describe how to set a drag icon. I know how to do this.
> https://stackoverflow.com/q/51975256/4865723
>
> But the question is how do I create my icon?
>

That's what I wrote in my email:

> If you want to override that, you should call
> gtk_drag_set_icon_surface(), using a Cairo surface you created:
>
>
https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface
>
> The GtkTreeView uses the default handler of the GtkWidget::drag-begin
> signal to set the drag icon; you want your own handler to be called
> after that, so you can override the drag icon with your own.

Icons are Cairo surfaces; this means you need to create a Cairo surface and
render on it using the Cairo API.


> e.g. TreeView create it's own one, too. It is based on the row content.
> I can I do the same? e.g. I only want the content of the second
> column/cell and not the complete row?
>

You can get the contents of the model and render them as you wish, using
the gtk_render_* API.

Ciao,
 Emmanuele.

 On 2018-09-02 02:33 Emmanuele Bassi
>  wrote:
> > On Sat, 1 Sep 2018 at 22:20, c.buhtz--- via gtk-app-devel-list <
> > gtk-app-devel-list@gnome.org> wrote:
> >
> > > I want to use my own drag-icon in a Gtk.TreeView where this is set
> > > as an instance of GdkPixbuf.Pixbuf.
> > >
> > > I can I create/draw a pixbuf and create Text, background and border
> > > color in it?
> > >
> >
> > Typically, GtkTreeView will call gtk_tree_view_create_row_drag_icon()
> > for the default drag surface — a box with the contents of the row.
> >
> >
> https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-create-row-drag-icon
> >
> > If you want to override that, you should call
> > gtk_drag_set_icon_surface(), using a Cairo surface you created:
> >
> >
> https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface
> >
> > The GtkTreeView uses the default handler of the GtkWidget::drag-begin
> > signal to set the drag icon; you want your own handler to be called
> > after that, so you can override the drag icon with your own. To do
> > that, you can:
> >
> >  - call gtk_tree_view_unset_model_drag_source() or
> > gtk_tree_view_unset_model_drag_dest() and implement your own drag and
> > drop handling
> >  - call g_signal_stop_emission_by_name() in your drag-begin callback
> > to stop the signal emission chain, and prevent the default handler
> > from running
> >  - use g_signal_connect_after() to connect your callback, and have
> > your handler run after the default one
> >  - subclass GtkTreeView and override the drag_begin() virtual function
> > without chaining up, to implement your own handler
> >
> > Ciao,
> >  Emmanuele.
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: "draw" icon with string

[Emmanuele Bassi via gtk-app-devel-list]

On Sun, 2 Sep 2018 at 02:02, Chris Moller  wrote:

> You probably can't do that--GTK has gotten just about impossible to
> customise--but if you can do it at all, you'll probably have to use CSS.
>

Please, avoid this kind of unhelpful reply in the future.

Ciao,
 Emmanuele.

On 01/09/18 17:20, c.buhtz--- via gtk-app-devel-list wrote:
> > I want to use my own drag-icon in a Gtk.TreeView where this is set as
> > an instance of GdkPixbuf.Pixbuf.
> >
> > I can I create/draw a pixbuf and create Text, background and border
> > color in it?
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: "draw" icon with string

[Emmanuele Bassi via gtk-app-devel-list]

On Sat, 1 Sep 2018 at 22:20, c.buhtz--- via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> I want to use my own drag-icon in a Gtk.TreeView where this is set as
> an instance of GdkPixbuf.Pixbuf.
>
> I can I create/draw a pixbuf and create Text, background and border
> color in it?
>

Typically, GtkTreeView will call gtk_tree_view_create_row_drag_icon() for
the default drag surface — a box with the contents of the row.

https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-create-row-drag-icon

If you want to override that, you should call gtk_drag_set_icon_surface(),
using a Cairo surface you created:

https://developer.gnome.org/gtk3/stable/gtk3-Drag-and-Drop.html#gtk-drag-set-icon-surface

The GtkTreeView uses the default handler of the GtkWidget::drag-begin
signal to set the drag icon; you want your own handler to be called after
that, so you can override the drag icon with your own. To do that, you can:

 - call gtk_tree_view_unset_model_drag_source() or
gtk_tree_view_unset_model_drag_dest() and implement your own drag and drop
handling
 - call g_signal_stop_emission_by_name() in your drag-begin callback to
stop the signal emission chain, and prevent the default handler from running
 - use g_signal_connect_after() to connect your callback, and have your
handler run after the default one
 - subclass GtkTreeView and override the drag_begin() virtual function
without chaining up, to implement your own handler

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: return value from expose event / draw signal of GtkDrawingArea

[Emmanuele Bassi via gtk-app-devel-list]

Hi;

On Tue, 14 Aug 2018 at 17:30, Luca Bacci via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi, does anyone know what meaning has the return value from expose event
> handler (for gtk2) and draw signal (for gtk3) of GtkDrawingArea?
>
> When one should return TRUE, and when FALSE?
>
> I can't find any information in the reference manual
>

The "expose-event" signal in GTK+ 2.x comes from GtkWidget:


https://developer.gnome.org/gtk2/stable/GtkWidget.html#GtkWidget-expose-event

The "draw" signal in GTK+ 3.x comes from GtkWidget:

  https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw

They have similar semantics as other signals in GTK+, like the
input-related ones: returning TRUE means "I handled this signal emission,
so do not propagate it further to other signal handlers"; returning FALSE
means "I did not handle this signal emission, so propagate it further to
other signal handlers".

What "handling" means it depends on what you want to achieve.

When using GTK+ 3.x, you're strongly encouraged to use the symbolic
constants "GDK_EVENT_PROPAGATE" and "GDK_EVENT_STOP", instead, as they make
the code easier to read.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: PyGObject: FileChooserDialog and transient parent

[Emmanuele Bassi via gtk-app-devel-list]

Hi;

On Sun, 12 Aug 2018 at 12:33, c.buhtz--- via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Below you see a minimal working example using Gtk.FileChooserNative as
> a file-open dialog. While running with Python 3.6.6 I recieve
> this warning message
>
> "GtkDialog mapped without a transient parent. This is discouraged."
>
> I understand the logic behind it but can not find a solution BECAUSE
> the docu is IMO inusfficient. Please see
>
> <
> https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/FileChooserDialog.html#Gtk.FileChooserDialog
> >
>
> This docu is about PyGObject which is Python, isn't it!? But there is C
> code in the example. Also with my C experience this doesn't help.
>

The documentation for Python/GObject bindings is generated from the
introspection data, which is in turn generated from comments and
annotations inside the C code.

The C code comes with C examples, because writing examples in Python, Perl,
JavaScript, whatever inside the C documentation would be odd, and could not
be validated in any way by the C developers.

Yes, it would be nice if we had a translation layer for introspected
languages using the documentation inside the generated data; it's been a
request for a long time, but nobody has shown up to do the work.

What IMO is missing in that documentation and what would help me to
> understand and solve the problem by myself without contacting the list
> or issue tracker is
>  - Description of the Constructor or new()
>  - all possible parameters accepted by this constructor (I have no idea
>where and how to put a parent to it)
>

The properties are inherited from the GtkFileChooserDialog class, so you'll
have to look at the hierarchy of the type, namely:

 - GtkWidget
 - GtkWindow
 - GtkDialog

The transient parent is provided by the transient-for property on GtkWindow:


https://developer.gnome.org/gtk3/stable/GtkWindow.html#GtkWindow--transient-for

or:


http://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Window.html#Gtk.Window.props.transient_for

In any case, it would be good to file this as an issue against pygobject:

  https://gitlab.gnome.org/GNOME/pygobject/issues/new

Documentation doesn't magically improve by itself, and issues are how
projects can work on improving it, as long as they provide actionable items
and goals.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gdk_screen_get_width/height

[Emmanuele Bassi via gtk-app-devel-list]

Use the GdkMonitor API; GdkScreen is an X11-ism, and a single screen can
cover multiple outputs.

  https://developer.gnome.org/gdk3/stable/GdkMonitor.html

Ciao,
 Emmanuele.


On Thu, 2 Aug 2018 at 14:58, Wojciech Puchar 
wrote:

>
>
> On 2018.08.02 15:55, Wojciech Puchar wrote:
> > how to get width/height of smallest available display - in case of
> > multiple monitors are attached?
> >
> or to be more exact - how to enumerate screens.
>
> all i need is to get resolution of smallest attached monitor.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: question about gtk_dialog (gtk2)

[Emmanuele Bassi via gtk-app-devel-list]

You haven't specified which windowing system you're using.

If it's X11, then the position of a window is always the remit of the
window manager; the position set is a hint, which is taken into account by
the window manager itself, alongside the "this is a dialog" hint that
GtkDialog sets.

There's no toolkit-available way to say "set this window to be at the
center of the screen", unless you create a GTK_WINDOW_POPUP and thus ask
the window manager to *not* manage your window.

Ciao,
 Emmanuele.


On Fri, 15 Jun 2018 at 12:44, Wojciech Puchar 
wrote:

> how to make dialogs appear on center of screen not on left corner. tried
> multiple things no results. For normal windows gtk_window_set_position
> works
>
> for dialog it doesn't
>
> below is example routine to ask a yes/no question from my program.
>
>
> i've tried
> gtk_window_set_position(GTK_WINDOW(dialog),GTK_WIN_POS_CENTER_ALWAYS);
>
> but it doesn't work
>
>
> nt pytanie(const char *txt) {
>   GtkWidget *dialog,*lab;
>   int odpowiedz;
>
> dialog=gtk_dialog_new_with_buttons(TEXT_QUESTION,NULL,GTK_DIALOG_DESTROY_WITH_PARENT,
>   TEXT_TAK,GTK_RESPONSE_ACCEPT,TEXT_NIE,GTK_RESPONSE_NONE,NULL);
>   lab=new_label(txt);
>   gtk_container_add (GTK_CONTAINER (gtk_dialog_get_content_area
> (GTK_DIALOG (dialog))), lab);
>   odpowiedz=gtk_dialog_run(GTK_DIALOG(dialog));
>   gtk_widget_destroy(dialog);
>   return (odpowiedz==GTK_RESPONSE_ACCEPT);
> }
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Emmanuele Bassi]

On Fri, 15 Jun 2018 at 16:34,  wrote:

> Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> > Just to make sure everyone is aware of this, this also means distros
> > will always need to always build the documentation with gtk-doc,
> > since
> > "ninja dist" won't include generated html files in the tarball. It
> > just
> > includes whatever is checked into git (they could be checked into git
> > of course if that was a deal-breaker for some reason).
>
> Note that the doc is built and uploaded as part of glib's CI for each
> tag, so it can be taken from artifacts. I don't know if it gets
> published from there, but we could do something. Emmanuele Bassi
> probably knows more about this mechanism.
>

It doesn't get published, only built and stored as artefacts – though it's
mostly a demonstration of what could be done.

The main issue with using GitLab pages is that publishing wipes out the
deployment every time, so we cannot have things like "publish the API
reference for master under unstable/ and the API reference for for each
branch under branchname/ and then publish the test suite coverage under
coverage/".

The only way to achieve this would be to build the API reference then push
it to some other repository, and have a CI hook that deploys everything.
This would allow building different versions of the API reference, and
additionally have things like coverage (per branch) and a simple website.
I've started looking into this, but it's kind of complicated, as it
requires creating a new `glib-docs` user and repo; generate SSH keys for
it; and then have the CI infrastructure store the SSH keys as secrets and
use them during the CI build.

Alternatively, we'd need a place accessible from the CI infra to copy our
files into, that would get published automatically on our web servers.

Ideally, this would also serve as the replacement for developer.gnome.org.

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

Re: How to get a directory from the user

[Emmanuele Bassi]

On 4 June 2018 at 13:06, Richard Shann  wrote:

> Hi,
>
> I have seen GtkFileChooser for getting a file from the user, but how to
> get a directory (folder)?
>
>
You can use GtkFileChooser with GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER as
the action:

 -
https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#GtkFileChooserAction
 -
https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-action

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Emmanuele Bassi]

With Python 2.x getting EOL in less than 2 years, I suspect that commercial
distros will need to provide Python 3 pretty quickly.

Ciao,
 Emmanuele.

On Fri, 1 Jun 2018 at 21:10, Christian Hergert  wrote:

> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
> > Disclaimer: I'm not a GLib maintainer so this email is only about
> > opening the discussion. There is no decision made yet.
> >
> > Opinions?
>
> I think the risk area is python3 support on some commercially supported
> distributions. Although, that is probably in better shape now than it
> was a year ago.
>
> Also not a maintainer, but +1 for the switch.
>
> -- Christian
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
-- 
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

Re: Undefined reference to g_file_load_bytes()

[Emmanuele Bassi]

Hi;

g_file_load_bytes() is available since GLib 2.56:

  https://developer.gnome.org/gio/stable/GFile.html#g-file-load-bytes

so you'll need to make sure that the version of GLib provided by MSYS2 is
new enough if you want to use that method.

Ciao,
 Emmanuele.


On 1 June 2018 at 01:21, PC Buddies  wrote:

>  During my application programming, I had to use the GIO function
> g_file_load_bytes().
>
> I have my GTK+ installation installed from MSYS (the new method)
> so I obviously have GIO. I previously even used g_file_load_contents()
> without problems, but now, it weirdly doesn't find definition for
> `g_file_load_bytes()` in the libraries..
>
> I checked the headers and not surprisingly I could not find declarations
> for this function either. I have had similar problem with other glib
> functions before too, most of the functions from the man page work, but
> some not.
>
> What should I do?
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: guchar * sometimes a utf8, sometimes utf16?

[Emmanuele Bassi]

Hi;

this mailing list is not for the GTK port of WebKit; you should ask on:

  https://lists.webkit.org/mailman/listinfo/webkit-gtk

Ciao,
 Emmanuele.

On 31 May 2018 at 23:04, Leo Ufimtsev  wrote:

> Hello guys,
>
> The following method:
> guchar * webkit_web_resource_get_data_finish(..)
>
> Sometimes returns utf8 and sometimes utf16. Is there a way to tell them
> apart?
>
> Thank you.
>
> --
> Leo Ufimtsev, Software Engineer, Red Hat
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Why is it impossible to move a window programmatically in GTK+ (C/C++)

[Emmanuele Bassi]

On 30 May 2018 at 18:33, Tarie Nosworthy via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> I am writing an app in GTK+, and I wanted to center a splash screen.
> Coming from a Windows background, where SetWindowPos does the job, I found
> out the X Window Manager always ignores requests to move a window,
> therefore eventually denying any attempt to manipulative the position of a
> window.  I can resize it, even dynamically, and I can move it with the
> mouse, but never in code.  Why?  It seems very strange that GTK would just
> disallow it.  You have gravity properties, but not matter what gravity I
> set, the position NEVER changes.  Why have the APIs if GTK is free to
> ignore them.  I'm baffled by it.
>

Hi;

some of the GtkWindow API work on a "best effort" basis; on X11, window
managers are wholly in charge of managing windows according to their own
rules and constraints, and they can ignore the hints set by an application.
Additionally, you can have other client apps that manage the window for you
— see, for instance, Devil's Pie[0], which gives you the ability to match
windows and execute scripts for them.

Additionally, if there is no window manager present — for instance, because
you're running a single window kiosk-style appliance — some functionality
like fullscreen won't simply be available, as it's part of a IPC protocol
with the window manager.

If you want, you can manage the window yourself — use a GTK_WINDOW_POPUP as
the window type, and then use your own decorations; you'll be in charge of
reimplementing window repositioning and resizing, but you're guaranteed
that the window manager won't interfere with your application.

As a side note: when using Wayland as a display server, you won't really be
able to deal with global coordinates and positioning, given that every
client surface operates in isolation.

Ciao,
 Emmanuele.

[0]: http://www.nongnu.org/devilspie2/


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: The best way to draw a GL texture from a different process

[Emmanuele Bassi]

On 25 May 2018 at 10:23, Jiří Janoušek  wrote:

> Hello,
>
> My app consists of the main process, where the GTK+ main loop and widgetry
> live, and the GPU process, which does OpenGL kung-fu and provides GL
> texture and dirty/invalidated rectangles as a result. I have little control
> over the GPU process - I can patch it a bit, but I cannot merge the main
> and GPU process, for example.
>
> If I understand it correctly, I cannot simply share GL textures between the
> processes and use e.g. gdk_cairo_draw_from_gl(). I can transfer the pixel
> buffer via IPC, store it in the main process, call
> gtk_widget_queue_draw_area(), and finally paint it in the draw signal
> handler, but that is slow and involves a lot of copying.
>
> Do you have any suggestions what could be a better way to draw the GL
> texture from a different process? With GTK 3.22 and under Xorg.
>

You can store the texture data as an X11 Pixmap object, and use the
GLX_EXT_texture_from_pixmap extension to get a GL texture object out of a
Pixmap XID.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: PyGObject Maybe bug with alternate row colors in a Gt.TreeView

[Emmanuele Bassi]

On Tue, 15 May 2018 at 21:19, <c.bu...@posteo.jp> wrote:

> Thank you for the link.
>
> On 2018-05-15 15:01 Emmanuele Bassi <eba...@gmail.com> wrote:
> >  - the CSS "regions" were problematic for the whole theming system,
> > so they were removed before we made the CSS selectors stable
> >  - GtkTreeView does not use widgets, so CSS selectors do not
> > typically work properly (that's why "regions" had to be introduced in
> > the first place)
>
> I have no idea what you are talking about. ;)
>
> What does it mean? I can do stripping or not?


As I said in my reply: no, you can’t.

Ciao,
 Emmanuele.
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: PyGObject Maybe bug with alternate row colors in a Gt.TreeView

[Emmanuele Bassi]

Hi;

On 11 May 2018 at 21:57,  wrote:

> Please see this StackOverflow question.
> https://stackoverflow.com/q/50281987/4865723
>
> Is there an official bug about setup alternate (even & odd) row colors
> with CSS in a Gtk.TreeView?
>

No, not any more.


> Can someone give a link to the bug ticket?
>

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

To summarise:

 - zebra striping has not been demonstrably more effective on displays as
opposed to paper
 - the CSS "regions" were problematic for the whole theming system, so they
were removed before we made the CSS selectors stable
 - GtkTreeView does not use widgets, so CSS selectors do not typically work
properly (that's why "regions" had to be introduced in the first place)

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Migration to GitLab, turn your notif off to avoid mail flood

[Emmanuele Bassi]

The migration is complete.

Ciao,
 Emmanuele.

On 1 May 2018 at 09:02, Carlos Soriano  wrote:

> Hello,
>
> Tomorrow Wednesday 2nd we're going to do the bug migration of gtk+. Since
> gtk+ has been for some time in GitLab, probably most of you are subscribed
> to notifications.
>
> This is a call to turn them off if you want to avoid your mail client
> flooded. To do so, in the project overview click the bell and select none.
>
> I'll send an email here when migration is completed so you can turn it on
> again.
>
> Best,
> Carlos Soriano
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>


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

Re: ANNOUNCE: Completion of migration to GitLab for GTK

[Emmanuele Bassi]

Hi all;

the migration is now complete, and you should find all the open issues on
GitLab:

  https://gitlab.gnome.org/GNOME/gtk/issues

Thanks for your patience.

Ciao,
 Emmanuele.


On 1 May 2018 at 09:24, Emmanuele Bassi <eba...@gmail.com> wrote:

> Hi all;
>
> in the past few months we've taken various steps to migrate GTK to the
> GNOME GitLab instance in advance of the rest of the projects hosted on
> git.gnome.org, as migrations of old projects usually unearth various
> issues; we approached this piecemeal, breaking down the move into various
> steps:
>
>  - moved the repository to https://gitlab.gnome.org/GNOME/gtk.git
>  - redirected the cgit URL to gitlab
>  - redirected https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B to
> https://gitlab.gnome.org/GNOME/gtk/issues/new
>  - closed all NEEDINFO bugs with no interaction over the last 5 years
>  - asked for feedback on NEEDINFO bugs with no interaction over the past 1
> year
>
> We're finally ready to take the last step: migrating all the open bugs
> over to GitLab.
>
> The migration will take place on Wednesday, 2nd of May, and it'll take
> about 4 to 5 hours. During that time you should avoid leaving comments on
> existing bugs. The migration consists of opening a new issue on GitLab and
> copying all comments and attachments over from Bugzilla, so that nothing is
> lost.
>
> After the migration is successful:
>
>  - the GTK+ product on Bugzilla will be closed for new bugs
>  - all closed bugs will stay on Bugzilla
>  - all migrated bugs on Bugzilla will be closed and a comment left
> pointing to the GitLab issue
>
> I'll make sure to notify the lists when the migration is complete.
>
> We haven't migrated the GLib issues from Bugzilla, yet, but that will also
> happen in the near future; again, I'll make sure to notify the list when
> that happens.
>
> If you have any question, feel free to contact me on the list, on
> gtk-devel-list, or privately.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

ANNOUNCE: Completion of migration to GitLab for GTK

[Emmanuele Bassi]

Hi all;

in the past few months we've taken various steps to migrate GTK to the
GNOME GitLab instance in advance of the rest of the projects hosted on
git.gnome.org, as migrations of old projects usually unearth various
issues; we approached this piecemeal, breaking down the move into various
steps:

 - moved the repository to https://gitlab.gnome.org/GNOME/gtk.git
 - redirected the cgit URL to gitlab
 - redirected https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B to
https://gitlab.gnome.org/GNOME/gtk/issues/new
 - closed all NEEDINFO bugs with no interaction over the last 5 years
 - asked for feedback on NEEDINFO bugs with no interaction over the past 1
year

We're finally ready to take the last step: migrating all the open bugs over
to GitLab.

The migration will take place on Wednesday, 2nd of May, and it'll take
about 4 to 5 hours. During that time you should avoid leaving comments on
existing bugs. The migration consists of opening a new issue on GitLab and
copying all comments and attachments over from Bugzilla, so that nothing is
lost.

After the migration is successful:

 - the GTK+ product on Bugzilla will be closed for new bugs
 - all closed bugs will stay on Bugzilla
 - all migrated bugs on Bugzilla will be closed and a comment left pointing
to the GitLab issue

I'll make sure to notify the lists when the migration is complete.

We haven't migrated the GLib issues from Bugzilla, yet, but that will also
happen in the near future; again, I'll make sure to notify the list when
that happens.

If you have any question, feel free to contact me on the list, on
gtk-devel-list, or privately.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: migrating gtk

[Emmanuele Bassi]

On 16 April 2018 at 19:32, Emmanuele Bassi <eba...@gmail.com> wrote:

>
>   * Migrate what's left at the end
>>
>
> We're in the process of migrating: https://gitlab.gnome.org/
> Infrastructure/GitLab/issues/228
>
> This will take a while once it starts; I'll send another email to the list
> to notify when the process starts and ends.
>

Quick addendum: do **not** migrate open bugs manually from Bugzilla to
GitLab.

If a bug is still open, it will be automatically migrated, with all
comments and attachments, to GitLab, and the old issue in Bugzilla will be
closed with a link to the new location.

If a bug has been closed already as part of the Bugzilla clean up, you can
open a new issue in GitLab manually, linking to the old issue in Bugzilla.

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

Re: migrating gtk

[Emmanuele Bassi]

Hi all;

it's time for an update.

On 2 February 2018 at 14:04, Matthias Clasen 
wrote:

> Hey Carlos,
>
> we discussed gitlab migration for gtk here at the hackfest. Our
> conclusions were as follows:
>
> * We want to migrate the git repository as soon as possible
>

The repository was migrated successfully, and we've been using it for the
past two months. There is a redirect in place for git.gnome.org URLs that
will automatically take you to gitlab.gnome.org for GTK; the only thing
that changed is the Git push URL for people that have the commit bit set
and a GNOME Git account.

Switching to GitLab allowed us to benefit from things like automated CI
(build and tests) for branches and merge requests; we're also building
Flatpak versions of gtk-demo and gtk-widget-factory on master, so you can
ask other people to immediately test your changes without having to rebuild
GTK and deal with its dependencies. Also on the CI side, we have a Windows
CI runner, which means that master is currently build tested using MSYS2.
It would be stellar if we could get a MSVC and a macOS runners as well.

* For bugs:
>   * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
>

This has been done.


>   * Wait a few weeks, then close the needinfoed bugs that didn't get a
> response
>
  * Triage the rest
>

We waited 2 months, and now all the bugs left in NEEDINFO state have been
closed.

Additionally, we've set up redirections so that going to Bugzilla to file a
new issue will automatically send you to the Issues page on GitLab.

  * Migrate what's left at the end
>

We're in the process of migrating:
https://gitlab.gnome.org/Infrastructure/GitLab/issues/228

This will take a while once it starts; I'll send another email to the list
to notify when the process starts and ends.

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

Re: double_buffered and scrolled_window

[Emmanuele Bassi]

On 16 April 2018 at 10:19, Dov Grobgeld  wrote:

> Hi all,
>
> After lots of years I finally got around to porting my widget
> GtkImageViewer to gtk3. After doing lots of reading of man pages, did I
> realize that i can turn off double buffering.
>

I wonder what kind of man pages did you read, considering that the API
reference of gtk_widget_set_double_buffered() clearly states that it's
deprecated and doesn't do anything remotely useful:

https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-double-buffered

You should *never* disable double buffering — and you should never need it.
Double buffering is an intrinsic characteristic of the windowing system; if
you disable it, it means you're literally owning the rendering pipeline —
which is why it's still used by applications that render their own UI
inside a GTK top level, like Firefox or LibreOffice. Given their user base,
we try to avoid breaking their use cases, but we do not really recommend
other people try doing that.

GTK widgets should always use the rendering pipeline provided by GTK, not
work around it; we do not make any guarantees if you decide to eschew that.

I honestly couldn't read your code because it's using Gob — something that
has long since been deprecated and it's not even remotely up to date with
the GObject and GTK best practices. From what I could glean:

 - it seems you started from the GtkDrawingArea code, which has some
backward-compatibility functionality, like a custom window and the need to
send configure events; those are not needed in newly written code
 - you're not using the GTK 3.22 API; for instance, you should be calling
gtk_widget_register_window() when creating a new GdkWindow inside the
realize() function
 - you're still using GdkPixbuf to do scaling and compositing, instead of
using Cairo
 - you're using a client input/output GdkWindow for rendering, instead of
rendering directly on the parent's surface
 - you're using a background color and compositing it, instead of using the
style system to render the background and border
 - you should be using the Gesture API, instead of connecting to each event
in order to do zoom and scroll

There is a wiki page on how to write widgets:
https://wiki.gnome.org/HowDoI/CustomWidgets

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

Re: Get the default font in Gtk3

[Emmanuele Bassi]

On 29 March 2018 at 15:12, rastersoft  wrote:

>
> [get the Gtk font type and size]
>>>
>>> Ops, sorry: I'm reworking a backup utility that I wrote (cronopete), and
>>> I added a timeline with the backups (you can see an screenshot at
>>> http://www.rastersoft.com/cronopete_screenshot.png ). As you can see, at
>>> the left is the timeline and it has the days, months and years. I think
>>> those should use the same typography than the standard Gtk widgets, but
>>> reducing the size to 2/3. The same for the titles in each "pseudowindow"
>>> (they have a visual effect: they go forward and backwards when you move
>>> through the timeline).
>>>
>>> ...I must be missing something here...
>> You can change font size in a layout. The scrolling might be tricky, but
>> just eyeballing it, sounds like something that can be done by showing
>> the layout twice at different coords in different clips
>> (cairo_save/cairo_restore brackets).
>>
>> So...?
>>
>> (Only thing I'm not quite sure about right now is if gtk fully initializes
>> font description in a layout, cause I vaguely recall that it might
>> not... though maybe that was just wrt. theming API...)
>>
>>
> Mainly the problem is that I'm using cairo_show_text...


That's the Cairo toy text API; you should only use it for tests or small
examples; it's basically useless for anything user-facing.


> I presume that what you say is that I should replace all that with
> Pango... Now I have some problems: first, I'm using vala and I can't find
> the "get_pango_layout" from a widget. It exists "create_pango_layout", so I
> suppose that this is the call I need to create a layout.


Yes, the function is `gtk_widget_create_pango_layout()`:
https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-create-pango-layout


> Now the big question is: does ANY widget return the right layout, or I
> must use a widget designed to contain text (like a Gtk.Label) to get that
> layout, paint into it, and paste it in the final Cairo canvas (which won't
> be the same canvas than the Gtk.Label from which I created the layout)?
>

All widgets that need to render text call gtk_widget_create_pango_layout()
internally, including GtkLabel.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Problem accessing gtk-2-24

[Emmanuele Bassi]

On Fri, 23 Mar 2018 at 09:07, John Emmas  wrote:

> On 23/03/2018 08:53, LRN wrote:
> > On 23.03.2018 11:08, John Emmas wrote:
> >> has the gtk repo moved recently (or has the gtk-2-24 branch
> >> been deleted somehow?)
> >>
> >> [...]
> >>
> >> Is it no longer hosted at git.gnome.org maybe?
> > Correct, it's on gnome gitlab instance[0] now.
> >
> >
> > [0] https://gitlab.gnome.org/GNOME/gtk
> >
>
> Thanks LRN - are any other repos affected (glib etc?)  If this got
> announced somewhere, I must have missed it  :-(
>

It’s part of a mass migration of GNOME to GitLab, so it’s been announced on
various GNOME-related venues as well as Bugzilla, since we’re migrating all
open bugs as well - but, indeed, we did not announce it here. Sorry for the
miscommunication.

In practice, though, we set up a redirection so the old URL should still
work for read only access (the push URL is different); it seems TortoiseGit
is not working correctly with a redirect in place.

Currently, both GLib and GTK have been moved, but by August the mass
migration will be complete, and all modules on git.gnome.org will be
available on gitlab.gnome.org. I’ll make sure to send an announcement when
that happens.

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

Re: A simple GtkSpinner is very costly in CPU cycles

[Emmanuele Bassi]

On 20 March 2018 at 14:06, Kian Karas  wrote:

> Hi smart people
>
> I just introduced animation, in the form of a GtkSpinner, to my application
> for the first time. When the spinner is animating, the application takes up
> 45 % of the CPU resources (the application is otherwise idle at 0-2,6 %).
> The CPU is a single core ARM Cortex-A7 running at 528 MHz (maximum).
>
> This seems like a lot of MIPS for rotating an image of approximately 20x20
> px.
>
>
The rotation is performed through CSS, in order to be stylable by themes;
this means that the CSS state has to be invalidated in order to recompute
the next frame, and this is there the cost lies.

Of course, 45% is a pretty big chunk of a core, so it's indeed problematic
on single core, low performance devices. It's going to be the case for
every animation involving CSS, though, so you may elect to either disable
animations on your platform, or use a static placeholder image. There's
also the option of using a theme that does not have as many states for the
spinner animation, thus causing fewer invalidations.

We are actively working to fix the issue on GTK 4, but changing the CSS
subsystem has the potential of breaking GTK 3 applications, so it's not on
the roadmap, outside of low impact optimizations.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Emmanuele Bassi]

On Fri, 2 Mar 2018 at 00:03, Alex ARNAUD <a...@arnaud.link> wrote:

> Le 01/03/2018 à 16:32, Emmanuele Bassi a écrit :
> > that the current GNOME Shell already has logic for zoom, color
> > inversion, and other effects, it’s perfectly capable of dealing with
> > these requirements.
>
> You can enable the GNOME Shell zoom feature, zoom to the factor 10 and
> tell me if it works without blurry effects. I'm visual-impaired with a
> vision of 1/10 and I see embarrassing blurry effect. You can try the
> ZoomText magnifier on Windows, it provides trial version and you'll see
> a real perfect zoom.


Thanks.

I was not claiming that the Shell’s zoom is perfect; I’m saying that the
Shell is where things need to be fixed, as it’s where things are
implemented already. The shell does not currently ask the toolkit to render
an area at a different scaling factor, but it could. The shell can also
change the rendering pipeline to apply an effect like color inversion.

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

Re: No module anymore & perfect zoom feature

[Emmanuele Bassi]

On Thu, 1 Mar 2018 at 20:48, Samuel Thibault <samuel.thiba...@ens-lyon.org>
wrote:

> Hello,
>
> Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote:
> > On 26 February 2018 at 17:49, Samuel Thibault
> > <samuel.thiba...@ens-lyon.org> wrote:
> > > Hello,
> > >
> > > So, I also saw the removal of generic modules.
> > >
> > > Unfortunately we currently need it for implementing perfect zoom
> feature
> > > :)
> >
> > I don't know what a "perfect zoom feature" is —
>
> Please compare the two attached examples :)
>
> zoom-gimp.png is the kind of zoom you can get with state-of-the-art
> zooming heuristics. zoom-perfect.png is simply obtained by getting gtk
> to redraw the window into a bigger pixmap.
>
> > but zooming on a window should be part of the display server.
>
> The display server can not invent information, at best it could
> achieve the zoom-gimp.png result, which is really not enough for
> visually-impaired people. Here I have only magnified a couple of times,
> people quite often request for 10x-30x magnification.
>

The compositor can say to the toolkit to render with a different scaling
factor - we do that for hidpi so toolkits already know how to deal with it.
No need to do vector rendering; after all, things are rendered to pixmaps
anyway, not using vector based API.


> Also, the control on zooming should really not implemented in the
> server. Usually you'll also want color inversion or mangling, adding
> position hints etc. I don't think freedesktop people will be happy to
> see that added to the display server, so an external solution is needed,
> currently implemented in Compiz (but lacking access to re-rendering on a
> bigger pixmap).
>

Don’t really agree at all. Considering that Compiz is mostly dead, and that
the current GNOME Shell already has logic for zoom, color inversion, and
other effects, it’s perfectly capable of dealing with these requirements.
Targeting an obsolete graphics stack is not going to get you anywhere -
especially for a new major version of the toolkit, where we don’t have
legacy code.

Ciao,
 Emmanuele.


> > Having said that, we do have a magnifier inside GTK, used by the
> > Inspector. We could make that feature public, and improve it.
>
> Interesting.  Having mentioned adding the feature to AT-SPI, I'm
> however interested in putting the interface there, so that not only GTK
> application can benefit from it, but also Qt, etc. and GTK can just plug
> its support into AT-SPI.
>
> > We definitely do not want to let people inject code into running
> applications.
>
> Ok :)
>
> Samuel
>
-- 
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

Re: No module anymore & perfect zoom feature

[Emmanuele Bassi]

On 26 February 2018 at 17:49, Samuel Thibault
 wrote:
> Hello,
>
> So, I also saw the removal of generic modules.
>
> Unfortunately we currently need it for implementing perfect zoom feature
> :)

I don't know what a "perfect zoom feature" is — but zooming on a
window should be part of the display server.

Having said that, we do have a magnifier inside GTK, used by the
Inspector. We could make that feature public, and improve it.

We definitely do not want to let people inject code into running applications.

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

Re: GTK_MODULES removal and the future of existing modules

[Emmanuele Bassi]

On 26 February 2018 at 13:17, Philipp Emanuel Weidmann
<p...@worldwidemann.com> wrote:
> Thank you for the quick response!
>
> I'm not sure anything short of direct access to the widget tree would
> suffice for a GTK4 version of Plotinus to provide the functionality it
> does today on GTK3.

Which is kind of why we don't want people to write this kind of
modules any more. ;-)

Accessing the hierarchy from outside of the application is a great way
to lead to crashes. See also why we removed theme engines.

From our perspective, the only way to know about menus and actions
should be through the GAction API, and the mechanisms that we already
have in place to export the menus on the session bus.

> Of course, I don't expect LibreOffice to move to GTK4 in the short or
> even medium term. The major cross-platform applications like Firefox,
> LibreOffice, GIMP, and Inkscape have been very reluctant in their
> adoption of even GTK3, and likely don't fancy another bumpy upgrade
> anytime soon. Still, eventually they might switch, and it makes sense
> to anticipate that.

If LibreOffice and Firefox will ever move to GTK4, we're going to
strongly suggest they expose their menus on the session bus, either
through the GMenu API directly, or by implementing the same DBus API
exposed by GTK.

Ciao,
 Emmanuele.

> On Sun, 2018-02-25 at 09:54 +, Emmanuele Bassi wrote:
>> Hi;
>>
>> On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann <pew@worldwide
>> mann.com> wrote:
>> > Greetings,
>> >
>> > I am the author of Plotinus[1], a GTK+ module that provides a
>> > searchable command palette to GTK+ applications. Recently, it was
>> > brought to my attention[2] that module loading has been removed[3]
>> > on
>> > GTK+ master.
>> >
>> > It appears that this change could mean the end for Plotinus and
>> > other
>> > modules like it. I would be interested to learn:
>> >
>> > 1. What is the rationale behind the removal of module loading?
>> >
>>
>> The module code was fairly ancient, and was hand rolling things for
>> which we have better API down the stack, like GIO extension points,
>> which support things like priorities and prerequisites.
>> > 2. What will be the first stable release of GTK+ that does not
>> > support
>> >modules anymore? Is this GTK+ 4.0+ only, or will support also be
>> >dropped in a 3.0 series release?
>> >
>>
>> The GTK 3.x series is frozen, so it won’t be touched. This change is
>> for 4.x only.
>>
>> > 3. What, if any, alternatives are available/planned for software
>> >like Plotinus that needs to inspect the widget hierarchy of
>> > running
>> >applications in order to work?
>> >
>>
>> We could be amenable to add an extension point for this, if you
>> present a case for it, and explain what kind of requirements you need
>> from the toolkit; granting blanket access to the internals of the
>> toolkit is not something we’d be happy to provide, but if you have a
>> specific domain it should be possible to accommodate your extension.
>>
>> Alternatively, we could ensure that all our menus and actions are
>> introspectable from the outside, and give you a proper API for
>> writing Plotinus in GTK 4.0. We’d probably prefer that.
>>
>> Ciao,
>>  Emmanuele.
>>
>> > Any insight is appreciated!
>> >
>> > Warm regards
>> > Philipp
>> >
>> >
>> > [1]: https://github.com/p-e-w/plotinus
>> > [2]: https://github.com/p-e-w/plotinus/issues/35
>> > [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196
>> > b910
>> > dce40e1617
>> >
>> > ___
>> > gtk-devel-list mailing list
>> > gtk-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]



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

Re: GTK_MODULES removal and the future of existing modules

[Emmanuele Bassi]

Hi;

On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann <
p...@worldwidemann.com> wrote:

> Greetings,
>
> I am the author of Plotinus[1], a GTK+ module that provides a
> searchable command palette to GTK+ applications. Recently, it was
> brought to my attention[2] that module loading has been removed[3] on
> GTK+ master.
>
> It appears that this change could mean the end for Plotinus and other
> modules like it. I would be interested to learn:
>
> 1. What is the rationale behind the removal of module loading?
>

The module code was fairly ancient, and was hand rolling things for which
we have better API down the stack, like GIO extension points, which support
things like priorities and prerequisites.

>
> 2. What will be the first stable release of GTK+ that does not support
>modules anymore? Is this GTK+ 4.0+ only, or will support also be
>dropped in a 3.0 series release?
>

The GTK 3.x series is frozen, so it won’t be touched. This change is for
4.x only.


> 3. What, if any, alternatives are available/planned for software
>like Plotinus that needs to inspect the widget hierarchy of running
>applications in order to work?
>

We could be amenable to add an extension point for this, if you present a
case for it, and explain what kind of requirements you need from the
toolkit; granting blanket access to the internals of the toolkit is not
something we’d be happy to provide, but if you have a specific domain it
should be possible to accommodate your extension.

Alternatively, we could ensure that all our menus and actions are
introspectable from the outside, and give you a proper API for writing
Plotinus in GTK 4.0. We’d probably prefer that.

Ciao,
 Emmanuele.

Any insight is appreciated!
>
> Warm regards
> Philipp
>
>
> [1]: https://github.com/p-e-w/plotinus
> [2]: https://github.com/p-e-w/plotinus/issues/35
> [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196b910
> dce40e1617
> 
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
-- 
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

Re: migrating gtk

[Emmanuele Bassi]

On 10 February 2018 at 21:26, Kristian Rietveld <k...@loopnest.org> wrote:
>
>> On 05 Feb 2018, at 11:37, Emmanuele Bassi <eba...@gmail.com> wrote:
>>
>> Of course if we get a positive response that the bug is still there
>> we're going to migrate it and keep track of it.
>>
>>> With that in mind, I believe it is much nicer to just leave the old bugs 
>>> there.
>>
>> The old bugs will be left there, but closed, so we don't need to check
>> two bug lists, and split the maintenance resources even more.
>
>
> What about old bugs that will not receive a response right now / in the very 
> near future? Can these still be migrated at a later point? I gather there’s a 
> script to do this on a case-by-case basis?

The script only moves open bugs; moving closed bugs for GTK would be
quite a move, and would not really preserve the history anyway,
because the bug numbers would be different, and because the
projects/products would not match.

If a bug does not receive any feedback in the allotted time, then
it'll stay on Bugzilla.

> And I assume all data in bugzilla.gnome.org will remain accessible for quite 
> some time to come? This is an important archive of information.

Yes, Bugzilla will remain available for existing bug for the
foreseeable future. Even in case we closed down Bugzilla for good, we
have plans to turn it into a static website, for archival purposes.

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

Re: migrating gtk

[Emmanuele Bassi]

On 5 February 2018 at 13:19, Morten Welinder <mort...@gnome.org> wrote:
>> Considering that you usually stop short of the first step I have to
>> ask you: what kind of "busywork" have you ever experienced?
>
> Here's a sample:
> https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7
>
> Yes, that was you.  What did you really gain from asking that
> question, other than verifying that I read my email?

I gained the fact that you read your email and if you're still
experiencing the issue, or if it was accidentally fixed in the ~4
years between your original report and me going through the open bugs
of gobject-introspection. That's why it was marked as NEEDINFO.

As soon as you replied, the bug was reinstated as NEW and will be
migrated to the gobject-introspection repository on gitlab.gnome.org.

> The more typical sample -- not recently practiced by gtk+ -- is mass
> moving of bugs into NEEDINFO with a note saying something like
> "This bug was reported for version x.y. Please test if it still applies.  If
> we get no response, this bug will be closed in 30 days."

Which is what Matthias has said we're going to do in the email you
replied to — and it's also implied in the NEEDINFO state as it's used
by GNOME projects.

> The reason I call that busywork is that you can actually do as asked
> only to repeat the whole thing in a year when no-one has looked at
> in the meantime.  And repeat it a year after that.  And multiply all that
> by the number of open bugs you have.

Oh, I'm sorry you're *so* inconvenienced by volunteers trying to get
the bug count under control, and cannot replicate every single set up
from 5 years ago.

> Quite frankly, the rational response to such periodic requests is to
> simply answer "the bug is still there" without going through the work
> of checking.

So, you're basically just making shit up?

That's *really* great to know, because now I won't feel compelled at
all to act on bug reports coming from you.

Next time, either don't bother, or just be a decent human being, and
answer "I don't know".

>  That's rational for the bug reporter because it preserves
> the investment of time that was put into reporting the bug without
> spending more maintaining an large portfolio of open bugs.

That's the "rational" thing to do if you're just abusing the ecosystem
you're taking advantage of.

Again, that's a great thing to know.

>> Of course it is, that's why we generally don't do that — except,
>> maybe, for rude bug reporters.
>
> You really don't like to be called out, do you?  (And, yes, I know I am
> occasionally and deliberately rude.  The email you responded to was
> not rude; it's just that you don't take criticism well, if at all.)

Your behaviour on this mailing list, and on Bugzilla, has been
consistently rude, inconsiderate, and plain abusive of the patience
and effort that volunteers put in the platform you're consuming.

You've been called out before, multiple times, about this.

Of course, you can now spin it the way you want it, and say it's me
that doesn't like being called out. I'll just remember it for the next
time you open a bug, explaining what *I* have to do, without even
bothering to attach a patch. Or reply "this bug still exists" without
testing it, because you're too busy with your own stuff.

Ciao,
 Emmanuele.

> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
>> On 4 February 2018 at 20:52, Morten Welinder <mort...@gnome.org> wrote:
>>> As a general principle, you should only ask bug reporters to do work if you
>>> intend to do something with the answer.  Or, with other words, it really is
>>> not nice to keep asking "is that bug still there?" until they get tired of 
>>> the
>>> busywork and leave in disgust.
>>
>> The busywork meaning "attaching a patch and iterating over it"?
>> Considering that you usually stop short of the first step I have to
>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Of course if we get a positive response that the bug is still there
>> we're going to migrate it and keep track of it.
>>
>>> With that in mind, I believe it is much nicer to just leave the old bugs 
>>> there.
>>
>> The old bugs will be left there, but closed, so we don't need to check
>> two bug lists, and split the maintenance resources even more.
>>
>>> We never got around to solving the reporter's problem, but at least we did
>>> not add to the pain by asking them to do work and report back, only to
>>> ignore the result of that.  Doing that is quite rude.
>>
>> Of course it is, that's why we generally don't do that — except,
>> maybe, for rude bug reporters.
>>
>> 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

Re: Does GTK+ do automated/nightly performance regression testing?

[Emmanuele Bassi]

On 5 February 2018 at 10:40, Timm Bäder  wrote:
> On 05.02, Clemens Eisserer wrote:
>> So back to the original question: How does the GTK+ project make sure
>> to spot performance regressions when they are introduced?
>> And if there is nothing automated, would there be interest in such a
>> project -  Would it be useful and used by the developers doing feature
>> work?
>
> Aside from what Emmanuele already said: yes, that would be very useful.
> However, the performance problems in gtk4 are not that much related to
> rendering (mostly...), but the much bigger problem is CSS
> (in)validations. GTK4 does a lot more CSS state changes due to automatic
> focus and :hover tracking with CSS pseudo classes. While the number of
> CSS nodes should not have significantly increased, the fact that we e.g.
> set :hover on a listbox node with many children is new in gtk4. But then
> again, this is already known to be slower and what we need is a fix for
> that.

Yep; this is also why comparing GTK 2/3 performance with GTK4 is
wildly misleading: GTK4 does *so much more* than GTK3 or GTK2 ever
did, and mostly does it to ensure that the toolkit behaves
consistently, instead of having behaviour depend on each class.

> Still, I think even if you can't automate it, a performance testsuite
> for certain things (or just a bunch of executables in tests/, really)
> would be good in any case.

Indeed, and we should probably provide some internal feature to add
profiling probes to the toolkit itself, so we could expose them via
the inspector and via a CLI tool that could be used in the CI
pipeline.

I've recently done some work in that regard, with nearly-zero cost
profile probes for the Endless SDK:
https://github.com/endlessm/eos-sdk/blob/master/endless/eosprofile.c#L18

GSK has a prototype of a profiling object that should be improved;
Christian Hergert has worked on performance counters for sysprof and
gnome-builder, so we should also look at that.

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

Re: migrating gtk

[Emmanuele Bassi]

On 4 February 2018 at 20:52, Morten Welinder  wrote:
> As a general principle, you should only ask bug reporters to do work if you
> intend to do something with the answer.  Or, with other words, it really is
> not nice to keep asking "is that bug still there?" until they get tired of the
> busywork and leave in disgust.

The busywork meaning "attaching a patch and iterating over it"?
Considering that you usually stop short of the first step I have to
ask you: what kind of "busywork" have you ever experienced?

Of course if we get a positive response that the bug is still there
we're going to migrate it and keep track of it.

> With that in mind, I believe it is much nicer to just leave the old bugs 
> there.

The old bugs will be left there, but closed, so we don't need to check
two bug lists, and split the maintenance resources even more.

> We never got around to solving the reporter's problem, but at least we did
> not add to the pain by asking them to do work and report back, only to
> ignore the result of that.  Doing that is quite rude.

Of course it is, that's why we generally don't do that — except,
maybe, for rude bug reporters.

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

Re: Does GTK+ do automated/nightly performance regression testing?

[Emmanuele Bassi]

On 5 February 2018 at 09:35, Clemens Eisserer  wrote:
> Hi there,
>
> I wonder - is there any automatic / nightly performance regression
> testing done against GTK+ development snapshots, like it is done by
> other performance-sensitive open-source projects (e.g. mozilla
> firefox)?

No.

Ideally, we'd be using Continuous for this — but the VM generation
broke last year, and while I'm still working to replace it with a new
build system, it's not finished. Performance regression testing is
also not entirely reliable when running on a VM.

Mozilla has a fairly big build and test farm, and a huge test suite,
something GNOME has no access to. This allows Mozilla to test changes
on real hardware, most of the time, and thus have a better picture of
what kind of performance trade-offs should be considered.

> The reason I ask is, from a subjective point of view, several times
> during GTK+'s development I had the impression of performance
> regressions introduced by new feature work:
> * During the GTK2-8 days, when GTK was migrated to use cairo instead
> of GDK's abstraction for drawing widgets

There was no "GDK abstraction": you either rendered using Xlib, or you
rendered using a reimplementation of Xlib primitives because you were
running GTK on Windows.

The introduction of Cairo added a new rendering abstraction API, but
the porting from GDK primitives to Cairo took definitely more time
than just the 2.8 release.

> * When GTK-3 was released: Eclipse's SWT is almost twice as slow when
> running on top of GTK3 compared to GTK2:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=493714

Eclipse does really weird things to maintain compatibility with
plugins written for older releases and different platforms; those
plugins are also often out of tree and non-free, so they cannot be
easily ported.

Such is the life when writing an abstraction over a toolkit.

> Now GTK4 is almost ready to be released, and watching the
> presentations about the new drawing model, all the CSS properties etc.
> I am worried again of performance regressions for real world code.

"Real world code", as of this moment, does not exist.

Porting custom widgets to GTK 4.0 will require some work, depending on
what the custom widget does; for custom rendering, using Cairo should
not come at any additional cost, whereas rendering using the
GtkSnapshot API and the CSS drawing model (boxes, borders, shadows,
text) should come with a significant performance improvement compared
to the equivalent Cairo-based rendering in GTK 3.x.

> And if there is nothing automated, would there be interest in such a
> project -  Would it be useful and used by the developers doing feature
> work?

Of course, if you want to work on performance testing you're
absolutely free to do so; we can discuss methodology, but comparison
with GTK 2 and GTK 3 is kind of moot: the rendering pipeline is wildly
different, and the cost is allocated in different places.

I'm much more interested in incremental performance regression testing
over the same code base; if we plug it into the CI pipeline, we'd at
least be able to spot eventual regressions during the development
phase.

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

Re: migrating gtk

[Emmanuele Bassi]

On 2 February 2018 at 15:04, Matthias Clasen  wrote:
> Hey Carlos,
>
> we discussed gitlab migration for gtk here at the hackfest. Our conclusions
> were as follows:
>
> * We want to migrate the git repository as soon as possible
> * For bugs:
>   * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
>   * Wait a few weeks, then close the needinfoed bugs that didn't get a
> response
>   * Triage the rest
>   * Migrate what's left at the end
>
> Does this sound plausible to you ?

Additionally, it would be great if we could set up the GTK+ issue
tracker on GitLab with all the tags coming from Bugzilla before we
start migrating issues — i.e. run the bztogl script to create all the
tags, and bail out right before it starts migrating the issues.

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

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

[Emmanuele Bassi]

Hi;

On 24 January 2018 at 13:20, John Emmas  wrote:

> In my November 2017 version, the most recent commit for
> 'gobject/glib-genmarshal.in' is:- is #100b83a7fa ("genmarshal Only wrap body
> prototypes in C++ guards").  But a couple of further commits got added since
> then.  I'm pretty certain one of those new commits has introduced this
> problem.. :-(

This is possibly a case that was solved with this commit:

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

i.e. the older version of the Python port you used generated too many
symbols that aliased the ones provided by GLib.

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

Re: GnomeDesktopThumbnail API replacement

[Emmanuele Bassi]

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

We could add a GThumbnail interface, like we did for GIcon,
GThemeIcon, and friends.

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

Re: Script to build templates for H and C files

[Emmanuele Bassi]

Hi;

creating GObject classes with modern best practices is matter of calling:

  G_DECLARE_FINAL_TYPE

or:

  G_DECLARE_DERIVABLE_TYPE

in your header file, and:

  G_DEFINE_TYPE

in your source file. Anything else is usually dependent on what your
class is going to contain; properties? Signals? A custom constructor?
Private data? A singleton pattern for g_object_new()?

Templating will get you only as far as you're going to make the
template flexible enough.

On 8 January 2018 at 19:07, Pavlo Solntsev  wrote:

> I am open to comments and critics. Any suggestions are very welcome. I am
> more than willing to see a tool like that as part of the glib library.

You probably want to look at GNOME Builder's snippet functionality, if
you want to generate code.

Additionally, we had a UI tool ages ago called "Turbine", which was
fairly flexible:

https://git.gnome.org//browse/turbine

You could fork it and update its templates. to follow best practices

In general, though, I don't think we're going to have this tool
shipped as part of GLib; after all, we have never landed an interface
definition language to generate code either.

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

Re: GLIB Port on QNX

[Emmanuele Bassi]

Hi;

On 8 January 2018 at 13:20, Nitin Jain  wrote:

> Is there any QNX port available for glib .

We don't manage packaging of GLib ourselves, if that's what you're
asking. We usually defer to whatever downstreams exist for any given
platform.

> Any pointers will be very helpful if we want to port GLIB on  QNX 6.6 .  As
> per understanding , QNX is posix compliant  and most of the functionality
> .of glibc shall be available on QNX.

These are our toolchain requirements:

https://wiki.gnome.org/Projects/GLib/CompilerRequirements

and these are our supported platforms, as well as our support policy:

https://wiki.gnome.org/Projects/GLib/SupportedPlatforms

We currently do not build, nor test, GLib on QNX. If you're willing to
set up and maintain an automatic CI system that verifies we won't
unintentionally regress on that platform, we'd be very happy to help.
Additionally, if you're willing to help us out on ensuring that GLib
works appropriately on QNX, by fixing regressions and implementing
functionality that is platform-specific, then it would be great.

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

Re: Why these settings are deprecated?

[Emmanuele Bassi]

On 26 December 2017 at 20:06, Tomasz Gąsior  wrote:
> I would like to ask question directly to main GTK developers. Why these
> Xsettings are deprecated?

XSettings are an X11-only concept that does not translate to any other
windowing system platform supported by GDK.

You're probably thinking of GtkSettings properties - which can always
be set using the settings.ini file; some of the ones you're referring
to, though, have been deprecated and the handling code removed.

> * gtk-icon-sizes

Custom icon sizes are part of the stock items system, and went away
alongside the stock items.

> * gtk-enable-mnemonics

Mnemonics are hidden by default, and made visible when pressing "Alt",
so this setting is pointless.

> * gtk-menu-bar-accel

The key used to toggle the menu bar is either part of the toolkit, and
thus shared by all applications and documented as part of the global
documentation; or it's defined by the application, in case of
conflicting key binding (though application developers are *strongly*
encouraged not to mess around with global key bindings).

> * gtk-menu-bar-popup-delay
> * gtk-menu-popdown-delay
> * gtk-menu-popup-delay

These are internal details of the toolkit, and at most should be part
of the accessibility layer.

> * gtk-show-input-method-menu
> * gtk-show-unicode-menu

These two menu items are always visible in GTK+ 3.x and future major
versions; it's a toolkit feature, not something that comes under the
purview of application authors or users. Application developers can
intercept the context menu and use their own, if they really want to
have a different looking menu.

> * gtk-button-images
> * gtk-menu-images
> * gtk-toolbar-icon-size
> * gtk-toolbar-style

Application developers are the ones that ought to decide how their
application looks and behaves; if they wish to provide a setting for
users, it's entirely possible for them to do so.

> * gtk-visible-focus

Focus rectangles are always visible, because otherwise it makes for
very poor UX.

> * gtk-alternative-button-order

This is not marked as deprecated, but it ought to be.

The alternative button order was a remnant of GTK 1.2 carried over
into 2.0, but it's really a decision that is made by the platform's
human interface guidelines.

> What is the reason of limiting GTK customization?

Not all customisation is good, warranted, or future-proof.

> Why only application
> programmer should have ability to change these settings (as g-object
> properties etc.) and why user shouldn't?

Because application developers are the one deciding how their
applications should look like, and how it should behave. A toolkit
should not give out setting that radically modify an application, as
it's the wrong layer for that to work. If an application developer
wishes to provide settings to alter the UX of their project they can
do so.

> And second question. Why you are forcing removing icons from images and menu
> items instead just disabling it by default in GNOME?

Because icons alongside text in menus and buttons do not provide any
additional value:

http://uxmyths.com/post/715009009/myth-icons-enhance-usability

On the other hand, lots of icons in the UI increase the cognitive load
on the user, who now has to interpret what an icon means in the
context of each application and then commit it to memory; and they
increase the load on the graphic artists, who now have to create
unique assets to represent complex concepts, often in 16x16 pixel
icons, which is utterly ridiculous.

We have this thing called "text" that is used to convey meaning;
pictographs do not really scale as well.

> Maintaining code of
> GtkImageMenuItem or images in buttons is too time-consuming?

Yes, it is. Mostly, because it's not "just maintaining code" in a
widget: you have to maintain the internal hierarchy of widgets; the
logic to switch between themes; the logic to swap between text, and
icons and text; the logic to change the setting depending on the
platform; the logic to change the setting depending on the desktop
environment on the same platform (remember: there is no "Linux"). On
top of that, every time we have to refactor the asset loading code, or
the rendering code, or the input layer, we have to deal with the
potential fallout of any change breaking this automagic code.

> (I know that programmer can pack image to button or menu item manually, but
> it is not the same. It isn't convenient and user have not ability to disable
> images added this way.)

"It isn't convenient" may be an argument for application developers,
not for users; and it's not really a major argument, considering that
icons can be added using a template GtkBuilder file, or abstracted
into a separate function.

Users being unable to change a setting at the toolkit level is just a
fact of life; it's not like the toolkit is mandated to offer settings
for everything, and there's plenty of stuff that you cannot really
change in GTK already. Application developers 

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

[Emmanuele Bassi]

On 23 December 2017 at 13:47, Salvatore De Paolis  wrote:
> On Wed, 13 Dec 2017 15:08:46 -0800
> Christian Hergert  wrote:
>
>> Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
>> and you cannot mix both into the same process space. DAW authors will
>> often cite the necessity for plugins to be in process to allow for a
>> large number of tracks/plugins due to context switching. (This is a
>> contributing factor to why many DAWs write their own UI toolkits).
>>
>> As for GIMP, I think the lesson I take away is that we need to recruit
>> people to go do the ports for important projects rather than expect them
>> to track us. Red Hat has shown that this strategy works in both Firefox
>> and LibreOffice (which are arguably the two hardest applications to port).
>
>
> http://libremusicproduction.com/news/20171221-lsp-plugins-version-110-released-farewall-gtk

Unsurprisingly, considering that the whole UI is completely custom and
using a generic desktop toolkit would have made their lives miserable.

> I wonder why GTK+ has not been forked yet.

I wonder why you don't keep this kind of statements for yourself; in
any case, feel free to fork GTK and figure how why nobody does that.

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

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

[Emmanuele Bassi]

On 17 December 2017 at 23:14, Daniel Kasak  wrote:

>> Just one example, gtk3 (yes 3, not even 4) is currently completely
>> unusable on
>> Mac, so I sent a patch to fix this:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=791174
>>
>> I know my patch is suboptimal, but to make this clear: it does not address
>> a
>> minor bug, this bug is a real show stopper on Mac, and this change is
>> purely
>> gtk internal. Of course it is not a clean solution, but there is no reason
>> to
>> simply apply this patch (at a bare minimum at least to the gtk3/stable
>> branch)
>> with a FIXME comment for now so that people on Mac can finally start using
>> gtk3
>> at all.
>
>
> I really have to agree. One of my bugs I raised in 2004 - which involves
> data loss - is still open. I submitted a patch ( which was difficult at the
> time - I only dabble in C when I absolutely have to ) which received very
> little feedback, and the bug has rotted since.

Yes, everyone has their own pet bug where they submitted a patch and
waited for feedback, as if GTK doesn't have ~3000 issues open at any
given time, and a constant stream of bugmail.

It would be *great* if we could review all incoming patches; sadly, we
either do that, or we spend time actually developing the toolkit.

Plus, if you have a patch lying in bugzilla for *13* years and you
never bothered to actually poke people about it, then I don't think
it'll ever get bumped up in terms of priority on the list of things to
do.

> "Send a patch" only goes so far. If patches don't get reviewed, or don't get
> sufficient feedback, and never get accepted, what's the point in sending
> patches?

Your role doesn't terminate at sending a patch.

It's your bug, your patch, and your responsibility for bringing it up
to the people *volunteering* to work on GTK. If you have a patch that
is languishing in Bugzilla, join the #gtk+ IRC channel on
irc.gnome.org, or send an email to gtk-devel-list.

Otherwise, you get exactly what you paid for.

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

Re: Build GTK3 without ATK

[Emmanuele Bassi]

On 17 December 2017 at 23:28, Tomasz Gąsior  wrote:

> It is possible to build GTK3 without Accessibility Toolkit dependency? How
> can I do it?

You can't: ATK types are exposed in the GTK API.

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

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

[Emmanuele Bassi]

On 14 December 2017 at 18:42, Sébastien Wilmet <swil...@gnome.org> wrote:
> On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote:
>> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.
>
> No, that's not true.
>
> A recent example:
> https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> "gtk: Remove GtkClipboard"
>
> The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> in GTK+ 3.22, and the new API is not available in GDK 3.22.

The new API just landed; and, yes: it's hard to deprecate the API in
this case, given that the new API has been moved down one level in the
hierarchy.

This is also why we could not do this during the 3.x API cycle,
without incurring into a lot of regressions or potential breakage.

> I think Benjamin has done a great work with the new implementation. Just
> a little problem: it's what I call a "direct API break", applications or
> higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
> with a big API delta, so it will result in one huge commit/branch
> untestable until all the code is ported [1].

That's what we said would happen during the 9x development cycle: no
API stability between 9x and 9x+2. We were very much upfront about the
API stability.

> It's of course much worse
> if porting directly from 3.22 to 4.0.

And we understand that. Doing this work in 5 years, for GTK+ 5.0,
would not have been any easier for anybody.

> [1] What I would recommend is to copy custom widgets/containers (if they
> are self-contained) out-of-tree, and port them individually, with a
> small GUI test program for each, so that they can be tested outside the
> whole application.

That would not help at all for the GtkClipboard case, and that would
not help with the new rendering API.

I'm sorry about the pain in porting, but this is what 2.5 years of
development are for.

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

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

[Emmanuele Bassi]

On 13 December 2017 at 16:34, Christian Schoenebeck
<schoeneb...@linuxsampler.org> wrote:
> On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote:
>> On 13 December 2017 at 12:05, Sébastien Wilmet <swil...@gnome.org> wrote:
>> > Ideally, a new major version of a library should only remove deprecated
>> > APIs.
>> The short answer is: that's not how library development works, unless
>> you have a small enough library whose API is inconsequential, or it's
>> used only by a handful of projects. GTK is neither.
>
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
> etc. are actually all handling it as expected by application developers; that
> is they usually deprecate old APIs and retain them for many years before they
> eventually (if at all) remove them one day. It is rare that they remove APIs
> without deprecating them first, and in such rare cases there are "usually"
> profound reasons like security aspects (or -cough- "product policies").

In short:

 - GTK supports parallel installation of different major API versions
 - symbols, types, properties, and signals deprecated in a major API
version continue to exist forever (and possibly work as well)
 - new major versions remove the deprecated API from the previous
major API version
 - application developers port their projects between major versions
at their own leisure

The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

We are not talking about remove API inside the same major version.

Porting applications between major versions is its own effort, just
like porting an application from Windows Vista to Windows 10, or from
macOS 10.6 to 10.12.

>> If we just removed deprecated API without adding any new feature,
>> there would be no incentive whatsoever to port applications to a new
>> major version, which will result in an untested API that we cannot
>> change until the next major release cycle.
>
> Personally I feel with him, although I can live with APIs being removed, even
> without a deprecation phase. A much bigger problem that I see is when
> replacement APIs are introduced which are missing features from their
> predecessors. That happened with at least every major release of Gtk, and I
> see this to happen with Gtk 4 again. I hope some of my patches will be
> accepted to fix a couple of those issues before Gtk 4 will be officially
> released.

Not every new feature or replacement will be 1:1 with deprecated API.
We did not deprecate something because we were tired of how it's
named: we deprecated it because some things should not be done any
more, or because they won't work in a new environment, or because they
exposed some toolkit internals that make changing the toolkit without
breaking applications impossible.

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

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

[Emmanuele Bassi]

On 13 December 2017 at 12:05, Sébastien Wilmet  wrote:

> Ideally, a new major version of a library should only remove deprecated APIs.

I'm having major flashbacks from the same discussions we had at Gran
Canaria, when we planned 3.0 — with people asking for releasing 3.0
only with sealed data structures and without deprecated API.

The short answer is: that's not how library development works, unless
you have a small enough library whose API is inconsequential, or it's
used only by a handful of projects. GTK is neither.

If we just removed deprecated API without adding any new feature,
there would be no incentive whatsoever to port applications to a new
major version, which will result in an untested API that we cannot
change until the next major release cycle.

That's why we released the 9x snapshots; to give us, and application
developers, time to iterate over the API.

The problem is that we're trying to fix almost two decaded of hacks
and cruft piled on top of each other, and any new feature comes with
its own set of removals.

> So, that's it, I think when GTK+ 4.0 will be released, if it is still
> developed in the same way, developers will have a really bad surprise
> when trying to port their code.

The reason why we're doing the 9x snapshots — the reason we change the
whole release management process and model — is because we will *not*
be developing 4.x (and 5.x, and 6.x) the same way we developed 3.x.

The 9x snapshots are the first cycles of 3.x, writ large. We give up
API compatibility during that period in order to have a firmer n.0
release, and later minor cycles, until we open the tree for the n+1
development.

Yes: the delta between 3.x and 4.x is going to be large — at least, if
you're implementing widgets. It's not something we expect this to
happen with every major release; we don't really expect to change the
way we render everything, or to change the input subsystem, every
major cycle.

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

Re: g_object_ref() now propagates types

[Emmanuele Bassi]

On 8 December 2017 at 11:26, Philip Withnall  wrote:


> If anybody encounters any problems with this, please comment on the bug
> report:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=790697

As a side note: I've started a full Continuous rebuild, so if there
are projects that indeed break with this change, we should be notified
pretty quickly.

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

Re: Window icon is not shown in gnome shell dash under wayland

[Emmanuele Bassi]

Hi;

On 2 December 2017 at 22:34, rastersoft  wrote:

> I created several applications that make use of Gtk.window, and set a window
> icon. But recently I discovered that, under wayland, the icon is not shown
> in the dash, but under X it is shown fine. It fails both in python3 and Vala
> applications.
>
> In both cases I used Glade to generate the window, and set the icon name
> there.
>
> What can I do to have again the right icon in the dash?

Window icons are set using X11 properties, which means there is no
corresponding concept under Wayland (and other windowing systems).

GNOME Shell uses the desktop file for retrieving metadata like icon,
names, and actions; you need to provide a desktop file with the same
name as your application's binary, or your GtkApplication application
id, and put it under /usr/share/applications or
$HOME/.local/share/applications. The icon specified in the desktop
file is going to be the one used by the shell.

For more information:

 - https://standards.freedesktop.org/desktop-entry-spec/latest/
 - https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Static library with Gtk 3

[Emmanuele Bassi]

While we don't actively disable static builds, we're also not really
using them, or testing them. This typically means that doing static
builds of GTK (and its dependencies) is discouraged, or at least that
you're basically on your own.

To be fair, there's literally no reason whatsoever to do a static
build; this is not 1983. You're going to waste more resources (loading
time, storage space) doing a static build of everything, these days.

My strong suggestion is to simply ship your application in a bundled
archive that replicates the file system layout that GTK expects,
alongside a launcher that sets up the execution environment by
modifying PATH, linker paths, and environment variables such as
XDG_DATA_DIRS and friends; then, distribute your application that way.
If you're using Linux, I strongly recommend you look at Flatpak:
https://flatpak.org

Ciao,
 Emmanuele.


On 29 November 2017 at 21:57, Мариано Гаудикс
 wrote:
> Hi . I need a example for compiling a static library with Gtk3 libraries
> together .
>
> Cordial greetings
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Set CSS properties programmatically

[Emmanuele Bassi]

Hi Felipe;

You probably wanted to send this email to gtk-devel-list, not
gtk-app-devel-list.

On Sat, 25 Nov 2017 at 12:41, Felipe Borges 
wrote:

> Hi,
>
> I have been looking for a clean way of updating my widget's css
> properties programmatically at runtime.
>
> Basically I have a css animation which gets its properties from
> variables in my C code.
>
> The current (working) approach I came up with is to benefit from the
> cascade and generate a whole new css definition for the animation
> every time my variable changes and use GtkStyleProvider.load_from_css
> (my_new_animation_css_spec). For this to work I need to set the
> "animation-name" to have a new and unique value, overwriting the
> previous one. This doesn't sound efficient at all.
>
> My desire is to get the "animation" property of my class, and be able
> to update only what changes in it. It can already be done for some
> properties via GtkStyleContext.get_property.
>

How would you even do this? You would need to read the current style state
and then resubmit it as a whole, because you cannot know how changing your
style for your animation will end up in your computed style.

All in all, is there a better way of doing this? Will there ever be?
>

Not for gtk3, and I’m pretty sure even for gtk4 it would be kind of weird.

Ciao,
 Emmanuele.
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Set CSS properties programmatically

[Emmanuele Bassi]

Hi Felipe;

You probably wanted to send this email to gtk-devel-list, not
gtk-app-devel-list.

On Sat, 25 Nov 2017 at 12:41, Felipe Borges 
wrote:

> Hi,
>
> I have been looking for a clean way of updating my widget's css
> properties programmatically at runtime.
>
> Basically I have a css animation which gets its properties from
> variables in my C code.
>
> The current (working) approach I came up with is to benefit from the
> cascade and generate a whole new css definition for the animation
> every time my variable changes and use GtkStyleProvider.load_from_css
> (my_new_animation_css_spec). For this to work I need to set the
> "animation-name" to have a new and unique value, overwriting the
> previous one. This doesn't sound efficient at all.
>
> My desire is to get the "animation" property of my class, and be able
> to update only what changes in it. It can already be done for some
> properties via GtkStyleContext.get_property.
>

How would you even do this? You would need to read the current style state
and then resubmit it as a whole, because you cannot know how changing your
style for your animation will end up in your computed style.

All in all, is there a better way of doing this? Will there ever be?
>

Not for gtk3, and I’m pretty sure even for gtk4 it would be kind of weird.

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

Re: webassembly

[Emmanuele Bassi]

On 20 November 2017 at 17:34, Andrea Zagli <aza...@libero.it> wrote:
> Il giorno lun 20 nov 2017 16:02:11 CET, Emmanuele Bassi ha scritto:
>
>> Hi;
>>
>> On 20 November 2017 at 14:52, Andrea Zagli via gtk-devel-list
>> <gtk-devel-list@gnome.org> wrote:
>>>
>>> do you plan to port (i don't know if "port" is the right word) glib/gtk
>>> to
>>> webassembly?
>>
>>
>> There are no plans that I'm aware of, nor use cases that have
>> materialised that would require such a port.
>>
>
>
>
> for example it could replace broadway

Considering that the Broadway backend is mostly a toy, and it hasn't
seen much development at all in master, I'm not sure replacing it is
going to work.

Writing new GDK backends, and ensuring that they keep working, is not
a trivial matter.

> since i hate other languages than c, i wrote a little library with glib to
> easy develop cgi; and i use other libraries (libgda, libsoup, libxml, etc
> etc) to make my web apps
>
> the base code for that web apps is always a library that i use also for the
> gui backend of the web app
>
> with webassembly i could write backend and frontend in glib/gtk

If you are volunteering to write a new GDK backend, and maintain it,
then by all means: feel free to work on it and submit your code for
review!

I strongly advise you work on the master branch, as the rendering
model has drastically changed from the gtk-2-24 and gtk-3-22 stable
branches.

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

Re: webassembly

[Emmanuele Bassi]

Hi;

On 20 November 2017 at 14:52, Andrea Zagli via gtk-devel-list
 wrote:
> do you plan to port (i don't know if "port" is the right word) glib/gtk to
> webassembly?

There are no plans that I'm aware of, nor use cases that have
materialised that would require such a port.

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

Re: Gtk Builder and item id

[Emmanuele Bassi]

Hi;

thanks for your patch; GTK uses Bugzilla to track issues,
contributions, and requests for enhancements.

Please, file a bug at:
https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B and attach
your patch, so it won't get lost and will be properly reviewed.

It would be stellar if you created a patch against the current Git
repository, either using `git format-patch` or, better, the `git-bz`
command; this allows us to track ownership and to easily review the
code contributions. For more information, see:
https://wiki.gnome.org/Git/WorkingWithPatches

Thanks again for your contribution!

Ciao,
 Emmanuele.


On 7 November 2017 at 20:23, Christian Schoenebeck
 wrote:
> Hi,
>
> I noticed that the current Gtk Builder XML parser does not accept an id for
> "item" elements. Please consider the attached patch to address this.
>
> Background: it should be possible to query menu items at runtime to change
> their labels (text) at any time.
>
> CU
> Christian
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



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

Re: No protocol specified error

[Emmanuele Bassi]

On 4 November 2017 at 06:08, Lokesh Chakka
 wrote:
> Dear Felipe,
>
> I have refereed the link. As the application I am writing needs root
> privileges, I must use sudo ./a.out. No other option.

Of *course* there are other options for you: this is software
development, not surgery.

The appropriate course of action, as Felipe outlined, is:

 - split the business logic that requires administrator privileges of
your application from the GUI bits
 - move that business into a daemon listening on the system bus and
exposing a DBus interface
 - use polkit to deal with the privilege escalation, and write a small
policy file
 - have the GUI call into the DBus interface on the system bus

Alternatively:

 - do not write a GUI application
 - require running under X instead of Wayland, and assume
responsibility for the potential security side effects; not that
running applications under X as root is recommended, either

Running GUI applications as administrator means that your exposing
yours and your users' data to a massive, unaudited code base, that may
or may not open random shared modules — like input methods, image
loaders — and parse multiple files from random locations.

It's more secure to start from a completely sandboxed environment and
gradually opening it up on demand, than running a completely open
environment and then closing it down.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with Gcolor3

[Emmanuele Bassi]

On 25 October 2017 at 12:50, Listings - www.majors-welt.net
 wrote:

 You probably want to start with a compositor-specific API, like the
 way screenshot and screen recording is performed in GNOME; if you want
 more Wayland compositors to follow the same protocol, you will have to
 draft the specification and discuss it on wayland-devel in order to
 get buy in from all the developers of Wayland compositors out there.
>>>
>>> Where is a documentation about it?
>>
>> Sorry, I'm not sure I understand. Documentation about what, precisely?
>
> I'm also not sure as a user... something about "a compositor-specific API,
> like the way screenshot and screen recording is performed in GNOME"

You can look at the DBus API provided by GNOME for taking screenshots:

  
https://git.gnome.org/browse/gnome-shell/tree/data/org.gnome.Shell.Screenshot.xml

and for taking screencasts:

  
https://git.gnome.org/browse/gnome-shell/tree/data/org.gnome.Shell.Screencast.xml

A "pick a color" interface would probably look something like this:

  org.gnome.Shell.ColorPicker
  - pick() → (success: boolean, color: ai)

where the `pick()` method would tell the compositor to initiate the
selection of the color. The `color` return value would contain an
array of 3 integers, with the values of the RGB channels. As you can
see, there is no leakage of information on the application or content,
and since the compositor is responsible for the user interaction, the
application would never be able to call this method multiple times
behind the user's back.

You would need to talk to the GNOME Shell developers for implementing
this functionality; you'd have to start by opening a bug:

  https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-shell

Then, once it's available, you'd have to call it from GColor3.

Alternatively, you'd have to talk to the Wayland developers and
various compositor developers, and describe a Wayland protocol to
achieve the same result.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with Gcolor3

[Emmanuele Bassi]

On 25 October 2017 at 11:19, Listings - www.majors-welt.net
 wrote:
>>> I am a user of a color-picker tool - previously Gcolor2 - that has now
>>> been
>>> adopted to Gnome3 -> Gcolor3 -> https://github.com/Hjdskes/gcolor3/
>>>
>>> Now while lots of linux distributions are switching to wayland as default
>>> session the color picking just dont work any more (which breaks the
>>> workflow
>>> of web and other developers) - even not in gimp afaik.
>>
>> Correct; the idea is that only privileged components can access the
>> contents of the screen, and that applications need an appropriate
>> privilege escalation mechanism, usually by talking to those components
>> through a well-defined IPC mechanism, like DBus or a Wayland protocol
>> extension. Starting from a sandboxed environment and opening it up
>> appropriately is safer and more secure than having an open system and
>> closing it down.
>
> Yes, i know why this happens and i agree with that.
>
> But thinking from my position as user, its is it going to be -> pick color,
> enter password, -> pick color, enter password, -> pick color, enter
> password, and so on?
>
> this will be 4 times more time consuming at working with colors.

No, that would of course be ridiculous and would just make people
angry at their computer. :-)

"Privilege escalation" does not imply "asking for a password"; it
means that there's a user-noticeable, or a user-initiated step in the
middle of the operation, and that the operation can be cancelled by
the user at any time, without leaking information to the application.

For instance, right now, an X application can literally pick any pixel
from the screen without the user knowing it ever happened, through the
existing client API. What we want is, instead, to have a (simple) IPC
mechanism to ask the compositor to start the selection of a pixel on
the screen; the compositor would now be able to change the cursor and
deal with the user side of things, tracking the position of the
pointer, and then pick the pixel at those coordinate. Essentially, to
enter into a state where it would be clear to the user that there's a
color selection in progress. It's the same way you take screenshots of
the desktop: an application asks the compositor to take a screenshot,
and the compositor deals with the whole user interaction; all that an
application gets at the end is a file in a specific location.

>>> The developer of Gcolor3 has no straight idea how to fix this (and maybe
>>> some "wayland-api" is neccessary?)
>>
>> You probably want to start with a compositor-specific API, like the
>> way screenshot and screen recording is performed in GNOME; if you want
>> more Wayland compositors to follow the same protocol, you will have to
>> draft the specification and discuss it on wayland-devel in order to
>> get buy in from all the developers of Wayland compositors out there.
>
> Where is a documentation about it?

Sorry, I'm not sure I understand. Documentation about what, precisely?

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with Gcolor3

[Emmanuele Bassi]

On 25 October 2017 at 09:40, Listings - www.majors-welt.net
 wrote:
> Hi folks,
>
> i write here, because i dont know where it may fit.

You probably want to start a discussion on wayland-devel:
  https://lists.freedesktop.org/mailman/listinfo/wayland-devel

This list is for developing GTK applications.

> I am a user of a color-picker tool - previously Gcolor2 - that has now been
> adopted to Gnome3 -> Gcolor3 -> https://github.com/Hjdskes/gcolor3/
>
> Now while lots of linux distributions are switching to wayland as default
> session the color picking just dont work any more (which breaks the workflow
> of web and other developers) - even not in gimp afaik.

Correct; the idea is that only privileged components can access the
contents of the screen, and that applications need an appropriate
privilege escalation mechanism, usually by talking to those components
through a well-defined IPC mechanism, like DBus or a Wayland protocol
extension. Starting from a sandboxed environment and opening it up
appropriately is safer and more secure than having an open system and
closing it down.

> The developer of Gcolor3 has no straight idea how to fix this (and maybe
> some "wayland-api" is neccessary?)

You probably want to start with a compositor-specific API, like the
way screenshot and screen recording is performed in GNOME; if you want
more Wayland compositors to follow the same protocol, you will have to
draft the specification and discuss it on wayland-devel in order to
get buy in from all the developers of Wayland compositors out there.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtkdialog maximum size

[Emmanuele Bassi]

On 12 September 2017 at 18:06, Rúben Rodrigues  wrote:

> Someone knows how to limite the maximum size of gtkdialog? My problem is
> that as the dialog does resize itself, sometimes it gets bigger that the
> screen.

Why are you using a GtkDialog? You should be using a GtkWindow for a complex UI.

Additionally, the size of a top-level is given by its contents, unless
you specify a size yourself. If your UI is too big, you'll have to
arrange it differently.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Generating glib-genmarshal

[Emmanuele Bassi]

On 7 September 2017 at 16:35, John Emmas  wrote:

> gdk-pixbuf and gdk+2 both built fine for me.  The only odd thing I noticed
> was when building gtk (from gtk-2-24) I saw quite a few warning messages
> looking like this:-
>
>   WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
>   WARNING: The token "NONE" is deprecated; use "VOID" instead
>
> They're probably nothing to worry about (I think they might be coming from
> 'gtk/gtkmarshal.list').  In fact it's possible they've always been there but
> I don't remember noticing them before...

No, the deprecation warnings are new, and were added with the rewrite to Python.

The `BOOL` and `NONE` keywords have been deprecated for 17 years —
they were deprecated when glib-genmarshal was added to the GLib
repository. Older versions of GTK+ still use those keywords because
they haven't been touched in years, and people cargo-culted their way
out of these things.

The deprecation warnings are there to let people know that
copy-pasting from old projects does not imply that things will never
change. :-)

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

Re: Generating glib-genmarshal

[Emmanuele Bassi]

In GLib 2.52, glib-genmarshal is a C program. In GLib master, which
will become GLib 2.54 soon, glib-genmarshal is a Python program.

The change from C to Python will *not* be backported to GLib 2.52.

Ciao,
 Emmanuele.


On 6 September 2017 at 16:41, John Emmas  wrote:
> Hi guys...
>
>   python  win32/gen_util_scripts.py --type=glib-genmarshal
> --version=
>
> If I'm building glib from git master, the above command works fine (if I
> issue it from a DOS window or from my MSVC project file). However... it
> produces an error if I try to build from the 'glib-2-52' branch.  Is that to
> be expected?
>
> In case it helps, the error message that I see is:-
>
> File "win32/gen_util_scripts.py", line 30, in main
>raise ValueError('Type must be glib-mkenums or gdbus-codegen')
>
> It's probably something that's been changed in 2-52 but not merged into
> master yet.  Anyway... just flagging it up,
>
> Thanks, John
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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