Re: [gtk-osx-users] These mailing lists will be closed.

2022-09-29 Thread Emmanuele Bassi via gtk-osx-users-list 
I wished you contacted the Discourse mods, or the rest of the GTK
developers…

In any case:

- there is a macos tag on discourse.gnome.org already:
https://discourse.gnome.org/tag/macos
- you can subscribe to that tag if you are only interested on GTK on macos

In general, if you want to ask questions about GTK, and GTK on macOS, then
feel free to use Discourse.

I assume the gtk-osx-build discussion on GitHub will be useful for
questions related to using jhbuild with the gtk-osx moduleset.

As a side note: GTK4 gets built and tested on macOS using Meson and
subprojects—similarly to how we build GTK4 using MSVC on Windows. If you
are targeting GTK4, or you're planning to, the GTK team recommends using
the Meson build system, and adding GTK as a subproject.

Ciao,
 Emmanuele.


On Thu, 29 Sept 2022 at 18:18,  wrote:

> The Gnome foundation that hosts these mailing lists has decided that they
> are too low traffic to justify their continued existence or even to migrate
> to Gnome Discourse. Without specialization Discourse is way too noisy to be
> useful so I've enabled https://github.com/jralls/gtk-osx-build/discussions to
> replace these lists.
>
> Regards,
> John Ralls
>
> ___
> gtk-osx-users-list mailing list
> gtk-osx-users-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
>


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

Re: problem to install Gtk2

2021-11-04 Thread Emmanuele Bassi via gtk-perl-list 
On Thu, 4 Nov 2021 at 18:04, Jeremy Volkening via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> > *** can not find package cairo >= 1.0.0
>
> You need to have the underlying C libraries installed in order to use the
> Perl wrappers. Here is a good place to start:
>
> https://www.gtk.org/docs/installations/windows
>
> Note that if you really want/need to use Gtk2 rather than Gtk3, you need
> to change the corresponding lines in those instructions. For example:
>
> pacman -S mingw-w64-x86_64-gtk3
>
> becomes
>
> pacman -S mingw-w64-x86_64-gtk2
>
> Once you have installed Gtk itself, you should have more luck with the
> CPAN install.
>

As a side note: GTK2 is EOL since December 2020, and nobody should write
new code using it.

GTK3 is in maintenance mode (no new API, no new features), and the current
stable release of GTK is GTK 4.4.

Sadly, there are no Perl bindings for GTK 4 as of yet, though you can
easily use Glib::Object::Introspection to load the introspection data, just
like you'd do with GTK 3.

Ciao,
 Emmanuele.

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

Re: [gtk-osx-users] Annual Updates

2021-04-12 Thread Emmanuele Bassi via gtk-osx-users-list 
On Mon, 12 Apr 2021 at 17:03, Andrius Rinkevicius via gtk-osx-users-list <
gtk-osx-users-list@gnome.org> wrote:

> Want to make one small correction - it is true that Bluefish can use
> enchant 2.2, however, it will happily accept 1.6, 1.3, or even older. We
> support as wide as possible range of platforms, and try to do not break
> things that are working.
> Probably because of Gspell freeze there is some activity on gtk:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/3814 . Its for gtk4 only,
> though.
>

The exploratory work on spell checking for GTK4 was started long before the
recent GSpell developments, and have no relation to it.

We're currently trying to salvage some of the modules involved with the
GSpell maintainer, so please wait a bit before porting code or giving up on
it.

Ciao,
 Emmanuele.


> Andrius
>
> On Fri, Apr 9, 2021 at 10:07 PM John Ralls  wrote:
>
>>
>>
>> > On Apr 9, 2021, at 11:02 AM, John Ralls  wrote:
>> >
>> >
>> >
>> >> On Apr 7, 2021, at 7:31 AM, Andrius Rinkevicius 
>> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Apr 6, 2021 at 7:08 PM John Ralls  wrote:
>> >>
>> >>
>> >>> On Apr 6, 2021, at 1:25 AM, Andrius Rinkevicius 
>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Apr 6, 2021 at 4:13 AM John Ralls  wrote:
>> >>> I'm preparing the annual updates to the stable packages and in the
>> process I'm making some changes that could break build scripts and
>> jhbuildrc-custom:
>> >>>
>> >>> I haven't pushed any of this yet so if there are any objections now
>> is the time to raise them!
>> >>>
>> >>> Regards,
>> >>> John Ralls
>> >>>
>> >>>
>> >>> Hi John,
>> >>> I would like to suggest to change a bit enchant build module - to
>> build native Apple spellchecker instead of ispell and myspell it is
>> currently buiding. I do not have any objections to continue to build ispell
>> or myspell, however, in order to enable its functionality one has to add
>> external dictionaries somehow (I never tried), while applespell works out
>> of the box and uses native Apple spellchecker.
>> >>> Gedit is already doing this, and its enchant module is:
>> >>>
>> >>> 
>> >>>> repo="abisource/enchant">
>> >>>  
>> >>>  
>> >>>  
>> >>>
>> >>>
>> >>>  
>> >>>
>> >>>  
>> >>>
>> >>> There is one extra patch for applespell, and
>> enchant-relocatable.patch is a bit different to what is available on
>> gtk-osx repository. I have confirmed, gedit version works!
>> >>
>> >> Andrius,
>> >>
>> >> Sure, no problem. How about a PR on
>> https://github.com/jralls/gtk-osx-build or
>> https://gitlab.gnome.org/GNOME/gtk-osx?
>> >>
>> >> Regards,
>> >> John Ralls
>> >>
>> >>
>> >> Hi John,
>> >> made PR to Github repository.
>> >> Andrius
>> >
>> > I turns out that Andrius was a little off-base: GEdit uses GSpell which
>> in turn uses Enchant 2.2. Enchant 2.2 claims to support AppleSpell as-is.
>> Even Andrius's own project, Bluefish, uses Enchant 2.2.
>> >
>> > Enchant 2 is about 3 1/2 years old and Enchant 1 isn't maintained any
>> more, so it's obsolete. So, for that matter, is GtkSpell, which also hasn't
>> had any love for 3 years or so. Hunspell's last release was 2 1/2 years ago
>> and while there was a flurry of activity a year go the total is only 11
>> commits since and none in the last year.
>> >
>> > There's no module in Gtk-OSX for GSpell and nobody's ever asked for
>> one, so I'm inclined to declare that spelling infrastructure is
>> out-of-scope for Gtk-OSX; projects that need it are probably using their
>> own modules.
>> >
>> > Can anyone make a convincing case to the contrary?
>>
>> Update: It turns out that the GSpell maintainer abandoned ship earlier
>> this week, see
>> https://gitlab.gnome.org/GNOME/gspell/-/commit/9ee66534fcca2f971461fb8dfe709e55fc118f84
>>
>> Seems quite sudden. I could find no explanation.
>>
>> Regards,
>> John Ralls
>>
>> ___
>> gtk-osx-users-list mailing list
>> gtk-osx-users-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
>>
> ___
> gtk-osx-users-list mailing list
> gtk-osx-users-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
>


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

Re: Re: Re: Gtk3::MessageDialog - missing methods

2021-01-09 Thread Emmanuele Bassi via gtk-perl-list 
On Sat, 9 Jan 2021 at 17:16, Thomas Funk via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> Hi,
>
> On Sat, 9 Jan 2021 at 02:35, Emmanuele Bassi via gtk-perl-list <
> gtk-perl-list@gnome.org> wrote:
> > As Torsten wrote, those methods are not introspectable because of their
> use of variadic arguments in C; this means you cannot call them from Perl.
> >
> > You will need to re-implement them; luckily, they are easier to deal in
> Perl than the printf-style format of C:
> >
> > ```
> > sub Gtk3::MessageDialog::format_secondary_text {
> >   my ($dialog, $format, @args) = @_;
> >
> >   my $text = sprintf $format, @args;
> >   $dialog->set('secondary-text', $text, 'secondary-use-markup' => 0);
> > }
> >
> > sub Gtk3::MessageDialog::format_secondary_markup {
> >   my ($dialog, $format, @args) = @_;
> >
> >   my $text = sprintf $format, @args;
> >   $dialog->set('secondary-text' => $text, 'secondary-use-markup' => 1);
> > }
> > ```
> >
>
> Works like a charme ^^
> Thank you very much!
>
> What is the next step? Will you or Torsten push the code into gtk3-perl?
>

I've opened an MR:
https://gitlab.gnome.org/GNOME/perl-gtk3/-/merge_requests/5

Ciao,
 Emmanuele.

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

Re: Re: Gtk3::MessageDialog - missing methods

2021-01-08 Thread Emmanuele Bassi via gtk-perl-list 
Hi;

On Sat, 9 Jan 2021 at 01:13, Thomas Funk via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> Hi,
> > Gesendet: Freitag, 08. Januar 2021 um 19:08 Uhr
> > Von: "Torsten Schoenfeld via gtk-perl-list" 
> > An: gtk-perl-list@gnome.org
> > Betreff: Re: Gtk3::MessageDialog - missing methods
> >
> > On 08.01.21 02:15, Thomas Funk via gtk-perl-list wrote:
> > > ---|--|
> > > OK | GtkWidget *  | gtk_message_dialog_new ()
> > > FF | GtkWidget *  | gtk_message_dialog_new_with_markup ()
> > > OK | void | gtk_message_dialog_set_markup ()
> > > OK | void | gtk_message_dialog_set_image ()
> > > ?? | GtkWidget *  | gtk_message_dialog_get_image ()
> > > FF | void | gtk_message_dialog_format_secondary_text ()
> > > FF | void | gtk_message_dialog_format_secondary_markup ()
> > > ?? | GtkWidget *  | gtk_message_dialog_get_message_area ()
> >
>


> But for the methods ... I've tried several things but got every time:
>
> *** unhandled exception in callback:
> ***   Can't find information for method
> MessageDialog::format_secondary_text at /home/tf/workspace/Perl/Testem/
> messagedialog.pl line 52.
> ***  ignoring at /usr/share/perl5/Gtk3.pm line 572.
>

As Torsten wrote, those methods are not introspectable because of their use
of variadic arguments in C; this means you cannot call them from Perl.

You will need to re-implement them; luckily, they are easier to deal in
Perl than the printf-style format of C:

```
sub Gtk3::MessageDialog::format_secondary_text {
  my ($dialog, $format, @args) = @_;

  my $text = sprintf $format, @args;
  $dialog->set('secondary-text', $text, 'secondary-use-markup' => 0);
}

sub Gtk3::MessageDialog::format_secondary_markup {
  my ($dialog, $format, @args) = @_;

  my $text = sprintf $format, @args;
  $dialog->set('secondary-text' => $text, 'secondary-use-markup' => 1);
}
```

Ciao,
 Emmanuele.

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

Re: Using Gtk macros

2019-09-06 Thread Emmanuele Bassi via gtk-perl-list 
On Fri, 6 Sep 2019 at 16:57, Mike Martin via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> How do I use Gtk macros in perl-gtk?
> eg in c
> GTK_IS_CONTAINER(widget)
> What is the corresponding method in perl-gtk
>

I assume you're talking about Gtk3.

Macros are not introspected unless they evaluate to simple scalar values.
The "IS" type checking macros are replaces by normal Perl type checking
operations:

```
use v5.22;
use Gtk3 '-init';

my $x = Gtk3::Button->new_with_label('foo');
say "The type of x is: ", ref($x);
```

will print out:

```
The type of x is: Gtk3::Button
```

If you want to check if an instance is of a certain type, you can use
UNIVERSAL::isa:

```
use v5.22;
use Gtk3 '-init';

my $x = Gtk3::Button->new_with_label('Foo');

say "x is a button" if $x->isa('Gtk3::Button');
say "x is a container" if $x->isa('Gtk3::Container');
say "x is a widget" if $x->isa('Gtk3::Widget');
say "x is a window" if $x->isa('Gtk3::Window');
```

will print out:

```
x is a button
x is a container
x is a widget
```

Hope this helps.

Ciao,
 Emmanuele.

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

Re: [gtk-osx-users] New build system (continued).

2019-05-01 Thread Emmanuele Bassi via gtk-osx-users-list 
On Wed, 1 May 2019 at 10:23, Pascal  wrote:

> It's ok for me with that. I haven't tried with None.
>

Using `None` will enable source directory builds, which is not recommended.

Ciao,
 Emmanuele.

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

Re: gtk-fortran 19.04 released

2019-04-26 Thread Emmanuele Bassi via gtk-list 
On Fri, 26 Apr 2019 at 18:38, Stefan Salewski  wrote:

> On Fri, 2019-04-26 at 18:21 +0100, Emmanuele Bassi wrote:
> > It most definitely is not. The project is actively maintained, and it
> > recently got even a full description of the XML schema:
>
> That is interesting. Well 172 open issues
>
> https://gitlab.gnome.org/GNOME/gobject-introspection/issues
>
>
Open issues is not really an indicator. GTK has ~1100 issues open.


> >gtkmm is an old binding, and it's very much set it its ways. Newly
> written bindings should not go down the same route.
>
> Yes, but his fortran ones is from 2011. So switching to gobject-
> introspection is much work.
>

When I talk about "old" I literally mean 20+ years. Gtkmm is one of the
oldest language bindings for GTK. 2011 is after the creation of g-i, and
after Python and Perl got ported to it from their own ad hoc header parser
plus ancillary metadata.

Ciao,
 Emmanuele.

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

Re: gtk-fortran 19.04 released

2019-04-26 Thread Emmanuele Bassi via gtk-list 
On Fri, 26 Apr 2019 at 18:13, Stefan Salewski  wrote:

> On Fri, 2019-04-26 at 17:58 +0100, Emmanuele Bassi via gtk-list wrote:
> > Have you considered using the GObject introspection data that GTK
> > itself generates, instead of your custom parsing code?
>
> But a warning: GObject introspection is not that much fun, as it is in
> zombie state.


It most definitely is not. The project is actively maintained, and it
recently got even a full description of the XML schema:

https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/docs/gir-1.2.rnc

The documentation has also been updated:

https://gi.readthedocs.io/en/latest/

Starting with the API docs was really hard, took me some
> hundreds hours before useful code generation started.


libgirepository is mostly meant to be used by dynamic languages, not for
code generation. It's also heavily modelled on the requirements of existing
language bindings like pygobject for Python; Glib::Object::Introspection,
for Perl; and GJS for JavaScript. API can be added, but the on disk file
format is stable, so it cannot really be changed outside of the current
boundaries of its ABI.

Code generation typically starts from the GIR file format—for instance, the
Rust bindings use it to generate static bindings:

https://github.com/gtk-rs/gir

Note that Gtkmm does
> not use GObject introspection still.
>

gtkmm is an old binding, and it's very much set it its ways. Newly written
bindings should not go down the same route.

Ciao,
 Emmanuele.

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

Re: gtk-fortran 19.04 released

2019-04-26 Thread Emmanuele Bassi via gtk-list 
On Fri, 26 Apr 2019 at 17:46, vmagnin  wrote:


> I am one of the main authors and administrators, working on the python
> script used to parse the GTK .h header files and generate the Fortran
> interfaces.


Have you considered using the GObject introspection data that GTK itself
generates, instead of your custom parsing code?


> Concerning the "new discourse forum", I am not sure of what you mean. I do
> not see such a forum on this page:
> http://gtk.10911.n7.nabble.com/
> If the "Gtk+ - General" forum is not the good place to post my message, I
> apologize. It just seemed the less bad place for a Fortran thing...
>

Nabble is a web bridge to various mailing list; the "General" forum maps to
gtk-list@gnome.org, which is going to be de-activated on May 1st, 2019.

It seems Nabble does not respect cross-posting, so you probably haven't
seen the announcement:


http://gtk.10911.n7.nabble.com/REMINDER-List-moved-to-Discourse-archival-in-1-week-td95279.html

The tl;dr of it is: discussions about GTK (and language bindings) have been
moved to Discourse:

  https://discourse.gnome.org

and the existing mailing lists will be archived next Wednesday.

Ciao,
 Emmanuele.

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

Re: G_IS_OBJECT (object)' failed at /usr/share/perl5/vendor_perl/Gtk3.pm line 546 gtk-perl x

2019-04-24 Thread Emmanuele Bassi via gtk-perl-list 
On Wed, 24 Apr 2019 at 12:42, Mike Martin  wrote:

> When I tried running my program from gdb I got an error about program
> type, when I attached gdb to a running instance no widgets were responsive
>
>
Once you attached GDB to a running instance, the debugger will pause the
process to let you set up things like breakpoints and watchdogs. You need
to type `continue` in the GDB console to resume the program.

Ciao,
 Emmanuele.

On Wed, 17 Apr 2019 at 14:36, Emmanuele Bassi  wrote:
>
>> On Wed, 17 Apr 2019 at 14:11, Mike Martin via gtk-perl-list <
>> gtk-perl-list@gnome.org> wrote:
>>
>>> I've now got this dreaded message.
>>> Is there any way to find out which line is triggering it?
>>>
>>
>> Export `G_DEBUG=fatal-criticals` and then run under GDB to see which part
>> of the code is passing an invalid/finalised object around.
>>
>> Ciao,
>>  Emmanuele.
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>

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

REMINDER: List moved to Discourse; archival in 1 week

2019-04-24 Thread 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

2019-04-24 Thread Emmanuele Bassi via gtk-i18n-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-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

REMINDER: List moved to Discourse; archival in 1 week

2019-04-24 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

REMINDER: List moved to Discourse; archival in 1 week

2019-04-24 Thread 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: G_IS_OBJECT (object)' failed at /usr/share/perl5/vendor_perl/Gtk3.pm line 546 gtk-perl x

2019-04-17 Thread Emmanuele Bassi via gtk-perl-list 
On Wed, 17 Apr 2019 at 14:11, Mike Martin via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> I've now got this dreaded message.
> Is there any way to find out which line is triggering it?
>

Export `G_DEBUG=fatal-criticals` and then run under GDB to see which part
of the code is passing an invalid/finalised object around.

Ciao,
 Emmanuele.

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

Re: gtk3 drag and drop sample/demo

2019-04-15 Thread 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

2019-04-06 Thread 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

2019-04-06 Thread 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: Opening up Discourse for language bindings

2019-04-03 Thread Emmanuele Bassi via gtk-list 
Thanks for your patience; it took me a while to get around answering this
email.

On Thu, 28 Mar 2019 at 09:34, David Pirotte  wrote:

> Hello,
>
> > now that we've started migrating[0] GTK discussions from mailing lists
> over
> > to Discourse[1], we'd like to do the same for discussions on GTK language
> > bindings.
> >
> > For this reason we opened a new category:
> >
> >   https://discourse.gnome.org/c/platform/language-bindings
> >
> > There are a few language-specific tags already, but we're definitely open
> > to adding more.
> >
> > There's currently no deadline to phase the language-specific mailing
> lists,
> > but it would be great to get feedback from the current subscribers and
> > decide for one. Feel free to reach out to me at:
> >
> >   eba...@gnome.org
>
> I hope it will never ever be phased out:


I honestly cannot guarantee that; if most of the GNOME mailing lists owners
and users decide to move over to Discourse, keeping the infrastructure open
for a couple of lists is not going to happen. Maintaining a mail server,
and a listserv on top of that, is not "free", and it has become
increasingly more expensive in terms of effort over the years. That's the
whole reason why we wanted to find other platforms for discussions—and why
we opted to do a trial run of Discourse.

We're still figuring out *if* and when we might phase out the GNOME mailing
list infrastructure over to Discourse; GTK was the beta test, and we're
moving permanently at the end of April. We've also been experimenting with
moving more GTK-related infrastructure, like the meeting announcements and
minutes, and even straw man proposals for features, off from the (ageing)
wiki.gnome.org to Discourse.

It'd be great if more communities inside GNOME moved over alongside GTK,
because it's easier to move topics around, split them, or mark them as
resolved; but, again, there's no deadline.


> please keep it alive and make sure that
> all posted msg on discourse c/platform/language-bindings are automatically
> sent to
> this ML and vis-e-versa ...


We cannot really do that. Maintaining two separate infrastructure splits
the community, and doesn't solve the problem of having a mail and list
servers.

You can use email to interact with Discourse; you don't really need to use
the web interface.


> (I don't even want to create an account on discourse)
>

You don't have to: you can use an existing single-sign on service, like
Google or GitHub; or, if you have a GNOME LDAP account, you can use that.

We can look into adding more shared authentication services. We can even
migrate existing mailman accounts to Discourse, if needed.

Ciao,
 Emmanuele.

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

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

2019-03-21 Thread 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

2019-03-21 Thread 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

Opening up Discourse for language bindings

2019-03-20 Thread Emmanuele Bassi via gtk-list 
Hi all;

now that we've started migrating[0] GTK discussions from mailing lists over
to Discourse[1], we'd like to do the same for discussions on GTK language
bindings.

For this reason we opened a new category:

  https://discourse.gnome.org/c/platform/language-bindings

There are a few language-specific tags already, but we're definitely open
to adding more.

There's currently no deadline to phase the language-specific mailing lists,
but it would be great to get feedback from the current subscribers and
decide for one. Feel free to reach out to me at:

  eba...@gnome.org

Ciao,
 Emmanuele.

[0]: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html
[1]: https://discourse.gnome.org

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

ANNOUNCE: Phasing out GTK mailing lists and move to Discord

2019-03-18 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

ANNOUNCE: Phasing out GTK mailing lists and move to Discord

2019-03-18 Thread Emmanuele Bassi via gtk-i18n-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-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

ANNOUNCE: Phasing out GTK mailing lists and move to Discord

2019-03-18 Thread 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

2019-03-18 Thread 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: The Future?

2019-03-13 Thread Emmanuele Bassi via gtk-list 
On Wed, 13 Mar 2019 at 16:16, Igor Korot  wrote:


> >> How about porting recent GTK version to OpenVMS?
> >
> >
> > If you want to add a new platform to GTK, you will need to:
>
> Here is the problem - it is not a new port.
>
The last version of GTK+ on OpenVMS is GTK+1.x.
>

The last GTK 1.x release (1.2.10) was last released 18 years ago. Compared
to the existing GTK code base—both in the stable (3.24) and master
(4.0-pre) branches—is a completely different project.


> There was an effort to upgrade GTK+ for OpenVMS, but unfortunately it
> failed.
>

Not much we can do about that.


> Now out of curiosity - do you have access to OpenVMS?
>

No. Which is why I wrote:

>  - ensure that GTK master and gtk-3-24 build on it
> >  - open merge requests for every needed fix, if any
> >  - add a GitLab CI runner, so that we can test every commit and merge
> request on that platform, and ensure we don't regress
>

These are the *minimum* requirements for any support to exist. We'd also
need somebody knowledgeable with the OpenVMS platform to keep things
working when the build changes.

I assume OpenVMS still uses X11, so there's no need for a separate
windowing system, but of course every platform has its own quirks, so
everything that GTK depends upon will need to work on OpenVMS.

Ciao,
 Emmanuele.

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

Re: The Future?

2019-03-13 Thread Emmanuele Bassi via gtk-list 
On Wed, 13 Mar 2019 at 15:53, Igor Korot  wrote:

> Hi, Emmanuel et al,
>
> On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list
>  wrote:
> >
> > Meta: having this discussion on gtk-list is probably the best example as
> to why we need to move to Discourse. Nobody involved with the development
> of GTK even reads this list, except me, so you're never going to get more
> than my opinion about it.
>
> What is "Discourse"?
>

Announcement of the Discourse instance, sent to this list:
https://mail.gnome.org/archives/gtk-list/2019-March/msg0.html

Discourse: https://discourse.gnome.org


> How about porting recent GTK version to OpenVMS?
>

If you want to add a new platform to GTK, you will need to:

 - ensure that GTK master and gtk-3-24 build on it
 - open merge requests for every needed fix, if any
 - add a GitLab CI runner, so that we can test every commit and merge
request on that platform, and ensure we don't regress

If you want to support OpenVMS, you'll have to work on it, or pay somebody
to work on it.

Ciao,
 Emmanuele.

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

Re: The Future?

2019-03-13 Thread Emmanuele Bassi via gtk-list 
Thanks, very much appreciated!

Ciao,
 Emmanuele.

On Wed, 13 Mar 2019 at 13:56, Kasper Peeters 
wrote:

> > Care to file an issue:
> >
> >   https://gitlab.gnome.org/Infrastructure/gtk-web
> >
> > to update the wording?
>
> Done, see
>
>   https://gitlab.gnome.org/Infrastructure/gtk-web/merge_requests/5
>
> Thanks,
> Kasper
>


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

Re: The Future?

2019-03-10 Thread Emmanuele Bassi via gtk-list 
On Sun, 10 Mar 2019 at 11:02, Kasper Peeters 
wrote:

But for the 'big picture documentation', which includes up-to-date
> instructions on how to get it up and running on all platforms. Why
> gtk.org does not even seem to mention vpckg and Homebrew is a mystery
> to me, and seems easy to fix.
>

Care to file an issue:

  https://gitlab.gnome.org/Infrastructure/gtk-web

to update the wording?

We're in the process of updating the website because it's basically the
same as it was when we released GTK 3 (and it wasn't much different before
that either).

Ciao,
 Emmanuele.

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

Re: The Future?

2019-03-10 Thread Emmanuele Bassi via gtk-list 
Meta: having this discussion on gtk-list is probably the best example as to
why we need to move to Discourse. Nobody involved with the development of
GTK even reads this list, except me, so you're never going to get more than
my opinion about it.

Meta × 2: while I am employed by the GNOME Foundation to work in GTK, this
*my* opinion, and should not be construed as anything but my opinion.

On Sun, 10 Mar 2019 at 06:37, Miroslav Rajcic 
wrote:

> I think the question is a valid one and there is a plenty of evidence of
> people moving to Qt due to some issues of GTK.
>
> Some notable examples:
>
> - VLC (
> https://ubuntuforums.org/showthread.php?t=316155=54b259f2cb2d1a30ca8dc269d0561537)
>
>
- Wireshark  (https://blog.wireshark.org/2013/10/switching-to-qt/)
>
> - Subsurface by Linus (
> https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/)
> - GCompris educational software (
> https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html)
>

VLC, Wireshark, Subsurface, and GCompris switched to Qt mostly because of
its support for Android and mobile platforms, something that GTK doesn't
support. Well, Subsurface moved to Qt because the original developers
thought that asking on Google Plus was the proper way to ask for help with
writing GTK applications, and had no objections when somebody else showed
up and rewrote their application using Qt.

It's entirely justified to go through the ringer of a full rewrite if
you're thinking of expanding somewhere the GUI toolkit you use is not going
to be, and it's highly unlikely that an Android backend for GTK will ever
materialise—let alone an iOS one—so if you're thinking of targeting Android
and iOS, Qt is a perfectly valid choice. I personally would recommend using
Xamarin.Forms, and stop writing code in C/C++.

The LXDE case is a bit different: writing desktop environments is kind of
what GTK is known for. It seems that LXDE didn't have many contributors,
and the few that were there decided to join forces with a Qt-based project
in order to increase the contributors base. It's also telling that the Qt
port of LXDE is still very much in progress, and the GTK2 code base is
still being maintained. If porting to a new major version of a toolkit is a
lot of work, porting to a whole new infrastructure is even more work.

> All these people have valid complaints, so someone should think about it.
>
Everyone involved in GTK thought about them. We incorporated the feedback
we gleaned from the various ranting into a better stability and versioning
guarantees; better tooling, like the Inspector; a better build system, to
ensure ease of build on Windows and macOS. If the complaint is "it's not
written in C++" or "there is no paid support" then there isn't much we can
do.

1. GTK is not so cross-platform anymore: on Windows and macOS, you are
> supposed to build your own library binaries (gvsbuild for Windows and
> jhbuild for macOS exist, but are not foolproof).
>

There is a fundamental misconception at work, here. GTK was never a
cross-platform in the same sense as Qt is a cross-platform toolkit. GTK
began supporting Windows in the 2.0 release (2002) because GIMP first, and
then Evolution, needed to build and run on Windows. GTK is a *portable*
toolkit, but its goal has always been writing Linux (and GNOME-adjacent)
applications.

Of course it doesn't mean we shouldn't support people writing non-Linux
apps with GTK, but they are a smaller target audience.

Plus, you seem to imply that "binary builds for Windows" somehow means
"better cross-platform support", which is nonsensical at best. Windows
support in GTK has *never* been this good. There are multiple volunteers
working on building, testing, and developing GTK on Windows. It would be
great to have as many people working on macOS, even though things are
moving once again, there.

>   "Golden age" in this regards was when Tor Lillqvist was still doing the
> Windows builds regularly on each GTK release. GTK was easy to be used on
> Windows at that time.
>
Yes, things are always "easy" when somebody else is paid to do them for
you. Doesn't mean they are easy at all.

Given that Tor stopped working on these years ago, and that Windows hasn't
stayed still in the meantime, the only reasonable course of action for GTK
developers was to offload the build of GTK on Windows to the MSYS2 package
management system—mostly like we do on macOS, with brew and macports. Of
course, we would have loved it if somebody had showed up and did the work;
somebody did, from time to time, and we even gave access to a Windows build
machine hosted in the GNOME infrastructure, but keeping things building is
hard—I do that for GNOME, and it's not fun—and people simply tire of it.

The move to Meson for GTK4 (and possibly to GTK3, as a secondary build
system) should make building GTK and many of its dependencies easier to
deal with. Ideally, we'd like for people to be able to clone just GTK and
be ready to go; of course, that's

Re: Gtk::Widget::is_mapped ()

2019-03-03 Thread 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 ()

2019-03-03 Thread 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

2019-03-01 Thread 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

2019-03-01 Thread 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

2019-03-01 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Discourse instance

2019-03-01 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Discourse instance

2019-03-01 Thread 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

2019-03-01 Thread 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

2019-03-01 Thread 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

2019-03-01 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Discourse instance

2019-03-01 Thread 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: GtkStack, builder and hidden objects

2019-02-19 Thread Emmanuele Bassi via gtk-list 
Hi;

Are you calling gtk_widget_show_all() on the Stack or Notebook, at any
point?

If you call show_all() on a container, all children will be marked as
visible; you need to use gtk_widget_set_no_show_all() if you don't want
this behaviour.

Ciao,
 Emmanuele.

On Tue, 19 Feb 2019 at 12:14, Daniel Kasak via gtk-list 
wrote:

> Hi all.
>
> I'm using glade to lay out my UIs. I've just noticed after porting some
> things that used GtkNotebook to GtkStack that objects that I've set as
> *not* visible ( in glade, select the object, go to the 'common' page, go to
> 'widget flags' and de-select 'Visible' ) are in fact visible. It seems like
> GtkStack is calling 'show all' on the widget tree.
>
> Is this intended behaviour? I would expect my 'Visible' flag to be
> honoured, though I can see how this would be extra work.
>
> For now, I've hooked up some code to re-hide my hidden widgets when the
> GtkStack's 'set-focus-child' event fires.
>
> Dan
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: documentation pages broken

2019-02-14 Thread Emmanuele Bassi via gtk-list 
Thanks.

Sadly, there is just one person responsible for library-web, and he
maintains it on his spare time—which has gotten considerably smaller.

I'd be tempted to suggest the *mm bindings developers to use CI to generate
the documentation and publish it on the GitLab pages, like GTK does for its
master branch; at least it would be *something*.

Sadly, the automated publishing of documentation from release tarballs is
an unsolved problem: we kind of painted ourselves in the corner, here, by
having infrastructure in place that automated everything to the point of
not being maintained any more.

Ciao,
 Emmanuele.

On Thu, 14 Feb 2019 at 20:05, Kasper Peeters 
wrote:

> > > Full story: the API documentation for many of the C++ bindings at
> > >
> > >   https://developer.gnome.org/references
> > >
> > > is currently broken.
> > >
> > >
> > This is unexpected.
> >
> > Can you file an issue on the GitLab issue tracker for the libraries
> > without a reference?
>
> There is one already,
>
>   https://gitlab.gnome.org/Infrastructure/library-web/issues/12
>
> It's a year old... No-one with sufficient access rights seems to feel
> responsible enough to do something about it.
>
> Cheers,
> Kasper
>


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

Re: documentation pages broken

2019-02-14 Thread Emmanuele Bassi via gtk-list 
On Thu, 14 Feb 2019 at 18:41, Kasper Peeters 
wrote:

> TL;DR: can someone who is responsible or knows someone who is
> responsible for the developer API pages please read the text below,
> there is a serious issue with many GNOME libraries NOT having any API
> documentation online.
>
> Full story: the API documentation for many of the C++ bindings at
>
>   https://developer.gnome.org/references
>
> is currently broken.
>
>
This is unexpected.

Can you file an issue on the GitLab issue tracker for the libraries without
a reference?

Ciao,
 Emmanuele.

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

Re: Gtk3 text view anchored in text view cannot get cursor inside (Ok in Gtk2)

2019-02-13 Thread Emmanuele Bassi via gtk-list 
The list is not really dead, but nobody is required to give you an answer:
this is not a paid support channel.

If you're not getting answers it may be the case that you're doing
something that nobody else is doing.

Ciao,
 Emmanuele.

On Wed, 13 Feb 2019 at 08:38, Giuseppe Torelli via gtk-list <
gtk-list@gnome.org> wrote:

> Unfortunately this ML is dead. You rarely get any replies.
>
> Regards
> Giutor
>
> On Wed, 13 Feb 2019 at 08:35, Giuseppe Penone via gtk-list <
> gtk-list@gnome.org> wrote:
>
>> Please could somebody tell me where is the best place to report such
>> problem?  This is stopping the porting of my app cherrytree from pygtk2 to
>> gtkmm3.
>> I also raised a bug on https://gitlab.gnome.org/GNOME/gtk/issues/1663 but
>> got no feedback at all.
>> Regards,
>> Giuseppe.
>>
>>
>> On Thu, 7 Feb 2019, 07:42 Giuseppe Penone >
>>> The problem happens only building for GTK3; building the exact same code
>>> for GTK2 works fine.
>>>
>>> In the code, posted to
>>> https://stackoverflow.com/questions/54529359/gtkmm-3-text-view-anchored-in-text-view-cannot-get-cursor-inside
>>> , I'm having a text view anchored into another text view. The problem is
>>> that even if I mouse click, I cannot have the cursor move inside the nested
>>> text view to write text. The cursor can instead easily get into the
>>> anchored text entry just below.
>>>
>>> Please if there is a way to make it work help me, this is getting in the
>>> way of my app porting from pygtk2 to gtkmm3.
>>>
>>> Regards,
>>>
>>> giuspen.
>>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: Moving from mailing lists to Discourse

2019-02-08 Thread 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

2019-02-08 Thread 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: Moving from mailing lists to Discourse

2019-02-08 Thread Emmanuele Bassi via gtk-list 
On Thu, 7 Feb 2019 at 13:16, Eric Williams via gtk-list 
wrote:

> One benefit I find to mailing lists is that they are search engine
> indexed, meaning when I google a warning or assertion error I often get
> pointed to a mailing list thread that discusses the issue I am trying to
> fix.
>
> Being able to find such discussions and then follow them in thread
> format is very valuable and saves quite a bit of time. I haven't used
> Discourse so I don't know what the state of such a workflow is --
> apologies in advance if this use-case is a non-issue.
>
>
Discourse has fully searchable archives, and allows indexing on Google, so
you'd very likely get more relevant results with it than with generic
Google searches.

Ciao,
 Emmanuele.

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

Re: Migrating away from GtkStock stuff

2019-02-07 Thread 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

2019-02-07 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Moving from mailing lists to Discourse

2019-02-06 Thread 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

2019-02-06 Thread 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

2019-02-06 Thread Emmanuele Bassi via gtk-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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Moving from mailing lists to Discourse

2019-02-06 Thread 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"

2019-02-06 Thread 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: JSON-based UI Language

2019-01-16 Thread Emmanuele Bassi via gtk-list 
On Wed, 16 Jan 2019 at 10:34, Nandakumar Edamana via gtk-list <
gtk-list@gnome.org> wrote:


> Is there a JSON-based UI description language (like XUL based on XML)?
> If so, is it supported by GTK+?
>

No. GTK only supports GtkBuilder UI descriptions, which use an XML subset:

  https://developer.gnome.org/gtk3/stable/GtkBuilder.html

Ciao,
 Emmanuele.

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

Re: Searching for text in PDF files is wrong

2018-12-03 Thread 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: Gtk3 and subclassing

2018-11-30 Thread Emmanuele Bassi via gtk-perl-list 
On Fri, 30 Nov 2018 at 19:09, Jeff via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> Whilst working up a smallest working example for another bug, I've
> discovered that I cannot get subclassing working when the main package
> is in the same file as the module.
>
> Below is the Gtk2 subclassing example from Muppet which I have trivially
> converted to Gtk3.
>
>
Your GTK 3 port is wrong.


> I get the following error messages:
>
> Odd number of elements in anonymous hash at
> /usr/lib/x86_64-linux-gnu/perl5/5.28/Glib/Object/Introspection.pm line 267.
> *** unhandled exception in callback:
> ***   Can't locate object method "get_colormap" via package
> "Gtk3::EventBox" at ../gtk3-subclass.pl line 93.
> ***  ignoring at
> /usr/lib/x86_64-linux-gnu/perl5/5.28/Glib/Object/Introspection.pm line 67.
>
> What is going on?
>

You're calling the "get_colormap()" method on a GtkEventBox, which does not
have a "get_colormap()" method—and neither do all its parent classes.

In GTK 2.x, there is a `gtk_widget_get_colormap()` method, but it was
deprecated during the GTK 2.x API series, and thus removed once GTK 3.0 was
released.


> sub set_color {
> my $self = shift;
> my %params = @_;
> my $color = Gtk3::Gdk::Color->new ($params{red},
>$params{green},
>$params{blue});
> $self->{colorbox}->get_colormap->alloc_color ($color, 0, 1);
> $self->{colorbox}->modify_bg ('normal', $color);
> $self->{colorbox}->modify_bg ('active', $color);
> $self->{colorbox}->modify_bg ('prelight', $color);
> $self->{red} = $params{red};
> $self->{green} = $params{green};
> $self->{blue} = $params{blue};
> # emit the color-changed signal.  note again that the signal
> # name treats - and _ as equivalent.
> $self->signal_emit ('color-changed');
> }
>

Creating a colormap, allocating a color, and calling `modify_bg()` was
something used in GTK 2.x (and even there, it was questionable, as it broke
themes).

In GTK 3.x you're supposed load a CSS fragment, defining the
background-color CSS property for a specific class, e.g.

.foo { background-color: red; }
.foo:active { background-color: green; }
.foo:hover { background-color: blue; }

You load this using a GtkCSSProvider associated to the GdkScreen, and
loaded when you create your application instance.

If you're trying to set the color programmatically, overriding all user
theming, you can generate a CSS fragment programmatically and associate it
to the widget itself, instead of the global GdkScreen; or you can override
the GtkWidget::draw signal, and render the color yourself using Cairo.
Doing either of those is less than great, but it respects the original
example's intent.

Ciao,
 Emmanuele.

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

Re: Detect dark or light theme from an application

2018-11-06 Thread 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

2018-11-06 Thread 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

2018-10-23 Thread 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: Question about porting from gtk 2.x to 4.0

2018-10-02 Thread Emmanuele Bassi via gtk-list 
On Tue, 2 Oct 2018 at 20:02, Giuseppe Torelli via gtk-list <
gtk-list@gnome.org> wrote:

> Thank you. Any other clue? The question is not interesting?
>
>
It's more of a problem of scope: we have no idea what your application
does, or how it uses GTK.

Are you drawing using GDK API instead of Cairo? Are you implementing your
own widgets? Are you using GdkWindow API, or using things like foreign
surfaces?

You can start from the migration guide from 2.x to 3.x:

  https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

And if you want to look at what changes are necessary to go from 3.x to
4.0, you can look at the migration guide:

  https://gnome.pages.gitlab.gnome.org/gtk/gtk/gtk-migrating-3-to-4.html

Just a word of caution: GTK 4.0 is not out yet, and there are still some
changes that are in the pipeline, especially because GNOME applications are
now in the process of experimental ports to the 4.0 API, and we're
addressing the feedback.

My strong suggestion is to port to GTK 3.x, and use the 3.x-to-4.x
migration guide to ensure that you're using modern API that can ease the
transition toward 4.0 when it's released.

Ciao,
 Emmanuele.

Giutor
>
> On Sat, 29 Sep 2018 at 21:51, Allin Cottrell  wrote:
>
>> On Sat, 29 Sep 2018, Giuseppe Torelli via gtk-list wrote:
>>
>> > Hello,
>> >
>> > my application, Imagination, is written in GTK 2.x. After years of
>> > inactivity I finally started developing it again so I wanted to port it
>> to
>> > GTK 3 but I noticed GTK 4 is under development.
>> >
>> > What do you guys suggest to do? Port my app to 3.0 or wait until 4.0
>> stable
>> > is released?
>>
>> Just one simple observation: porting your app to 3.0 will probably
>> be trivial, if you're willing to use functions that are deprecated
>> in 3.0 (maybe less trivial if you use low-level drawing functions).
>> But porting to GTK 4.0 will likely be quite painful -- my
>> understanding is that everything that's deprecated in 3.0 (which is
>> quite a lot of bread-and-butter stuff in 2.x) will be gone in 4.0.
>>
>> --
>> Allin Cottrell
>> Department of Economics
>> Wake Forest University
>>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: Wayland Window Positioning

2018-10-02 Thread 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?

2018-09-17 Thread 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

2018-09-16 Thread 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: Deleting rows from a model

2018-09-13 Thread Emmanuele Bassi via gtk-perl-list 
On Thu, 13 Sep 2018 at 12:01, Daniel Kasak via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> Hi all. I've been looking at a long-standing bug in one of my libraries,
> triggered when I delete multiple rows from a tree model. After looking
> closer, my original bug appears to be caused by the fact that after going:
>
> $model->remove( $iter );
>
>  ... $iter is now pointing at the *next* row, without me having to go:
>
> $model->iter_next( $iter );
>
>
Just like the documentation[0] for gtk_list_store_remove() says.


> So this initially seemed to be easy to solve - just don't call iter_next()
> if I've deleted a row. But ... I was previously exiting the loop, based on
> the return of $model->iter_next( $iter ). If there are no more rows, this
> call returns false. Since I'm not calling it for deleted rows, and since
> $iter is still 'set' in this case, how do I know if I'm at the end of the
> model?
>

Use the return value of `Gtk::ListStore::remove()` to see if the iterator
is still valid or not.

Ciao,
 Emmanuele.

[0]:
https://developer.gnome.org/gtk3/stable/GtkListStore.html#gtk-list-store-remove

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

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

2018-09-07 Thread 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

2018-09-06 Thread 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

2018-09-06 Thread 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

2018-09-05 Thread 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

2018-09-03 Thread 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

2018-09-01 Thread 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

2018-09-01 Thread 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: Quick question about the GTK graphics stack

2018-08-20 Thread Emmanuele Bassi via gtk-list 
On Mon, 20 Aug 2018 at 22:11, Alexander Medvednikov via gtk-list <
gtk-list@gnome.org> wrote:


> GTK draws things with Cairo, and if the graphics driver is installed,
> Cairo uses the OpenGL backend. Otherwise it uses software rendering via
> xlib.
>
> Is this correct?
>

No.

GTK does not use the GL backend of Cairo, only the Xlib surfaces (on X11)
or the image surfaces (on Wayland), as the GL backend of Cairo is mostly
experimental.

If Glamor is enabled, then the X server will use GL as an acceleration
architecture, but that has no particular bearing on GTK, as Glamor
accelerates the X primitives, and GTK uses client side rendering.

This, of course applies to GTK+ 2.x and 3.x; in 4.0, GTK+ will be able to
use Vulkan or OpenGL as a rendering API, and only use Cairo as a fallback,
or if widgets explicitly decide to use Cairo surfaces to render their
contents.

Ciao,
 Emmanuele.

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

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

2018-08-14 Thread 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

2018-08-12 Thread 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

2018-08-02 Thread 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: Implementation of gtk_xxx_get_type

2018-07-25 Thread Emmanuele Bassi via gtk-list 
On Wed, 25 Jul 2018 at 12:44, Göran Hasse  wrote:

> Hello!
>
> I try to write my own widget. For this a study gtkswitch.c/.h
> ( http://ftp.gnome.org/pub/gnome/sources/gtk+/3.22/gtk+-3.22.30.tar.xz )
>
> There is a function gtk_switch_get_type - but there is no
> implementation?
>

See G_DEFINE_TYPE:


https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DEFINE-TYPE:CAPS

and the GObject tutorial:

  https://developer.gnome.org/gobject/stable/howto-gobject-code.html

Ciao,
 Emmanuele.

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

Re: XTestFakeKeyEvent GDK-equivalent

2018-07-07 Thread Emmanuele Bassi via gtk-list 
Hi;

virtual keyboards running outside of the windowing system platform as
clients do not use the XTest API — mostly because it's meant only for
testing X, and because it's only for X. Injecting synthetic events into the
windowing system is just not going to give you what you want, if what you
want is to write a input driver. Additionally, GDK won't let you do this
because GDK is a client toolkit, and it can only consume events coming from
the windowing system, not inject them for random clients to process.

You will need to write a device driver — either for X11, or for the Linux
kernel — that does this for you.

Ciao,
 Emmanuele.

On Fri, 6 Jul 2018 at 01:49, Anarchean via gtk-list 
wrote:

> Hi,
>
> I'm working into implementing a virtual remote keyboard/touch pad daemon
> for Linux, currently I'm dumping events into an uinput device, but that is
> giving me some trouble with my keyboard layout (which is brazillian,
> br-abnt2). I was looking for a way to this in X, found XTestFakeKeyEvent
> and was wondering if I could make it simpler and cross-platform using
> GDK3. I tried this attached code, but it doesn't do anything. I was
> wondering if someone has done this before and know what I'm doing wrong or
> if I should just give up doing with GDK.
>
> Also, this is an extra, if I can't just fake key events, what should I use
> to map unicode chars into linux/input.h event key codes based on my
> keyboard layout on X? What about Wayland?
>
> Thank you!
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: question about gtk_dialog (gtk2)

2018-06-21 Thread 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

2018-06-15 Thread 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

2018-06-04 Thread 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

2018-06-01 Thread 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()

2018-06-01 Thread 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?

2018-06-01 Thread 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++)

2018-05-30 Thread 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

2018-05-25 Thread 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

2018-05-15 Thread 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

2018-05-15 Thread 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

2018-05-03 Thread 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

2018-05-03 Thread 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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: ANNOUNCE: Completion of migration to GitLab for GTK

2018-05-03 Thread 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

Re: Gtk3->GET_VERSION_INFO

2018-05-02 Thread Emmanuele Bassi 
Hi;

thanks for your contribution.

Could you please open an issue on Bugzilla, here:

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

and attach your patch there? It would help making it easier for the
maintainers to review and apply your patch.

Ciao,
 Emmanuele.


On 2 May 2018 at 16:54, Jeffrey Ratcliffe  wrote:

> >> What is the Gtk3 equivalent of
> >>  Gtk2->GET_VERSION_INFO
> >>  and
> >>  Gtk2->get_version_info
> >> ?
>
> > It looks like these convenience functions never made it from Gtk2.pm
> > to Gtk3.pm. You can instead use Gtk3::get_major_version (),
> > Gtk3::get_micro_version () and Gtk3::get_minor_version () as well as
> > Gtk3::MAJOR_VERSION and friends. I'd also gladly accept a patch adding
> > ports of the old helpers to Gtk3.pm.
>
> Please find attached a patch to do add the above functionality, along
> with some tests.
>
> Regards
>
> Jeff
>
> ___
> gtk-perl-list mailing list
> gtk-perl-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-perl-list
>
>


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

ANNOUNCE: Completion of migration to GitLab for GTK

2018-05-01 Thread 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

ANNOUNCE: Completion of migration to GitLab for GTK

2018-05-01 Thread 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-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

  1   2   3   4   5   6   7   8   9   10   >