Re: Development with GObjects

[Philip Chimento via gtk-devel-list]

Nice work, Pavlo! I wonder if you can work this into a patch for the
GObject documentation :-)

You might want to check out
https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/
as well.

In my personal style I would do three things differently, I don't know for
sure whether I'm correct about these or how widespread they are as best
practices:

- It's not necessary to override dispose or finalize if the only thing you
do is chain up.
- I would free self->name in finalize instead of dispose, along with any
other memory that is fully owned by the MyPoint instance. In dispose, I
would only drop any references to memory that had been passed in through
MyPoint's API.
- I think it's confusing to have my_point_free() that calls
g_clear_object(), since usually g_object_unref() is known as the standard
way to release a reference to a GObject, and it doesn't necessarily free
the object if there are other references.

Best regards,
Philip C

On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

> I am putting together a tutorial how to use GObject. It is my
> interpretation and I was trying to keep is as simple as possible and
> clear for new users.
>
> https://psunfun.blogspot.com/
>
> Thanks.
>
> --
> - Pavlo Solntsev
> -
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
> Sent from Evolution on GNU/Debian 
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[philip . chimento]

On Sat, Jun 9, 2018 at 8:02 AM Nirbheek Chauhan 
wrote:

> On Sun, Jun 3, 2018 at 1:13 AM  wrote:
> >
> > Before making the switch please be aware of
> https://github.com/mesonbuild/meson/issues/3077 and
> https://github.com/mesonbuild/meson/issues/2121 which make Meson-built
> libraries mostly broken on macOS, particularly with regard to g-ir-scanner.
> >
>
> I have a fix for this: https://github.com/mesonbuild/meson/pull/3691
>
> I'll wait till Monday or Tuesday for people to comment and then push
> it. It will be in the 0.47 release which is scheduled for 24th June.
>

That's fantastic news, thank you Nirbheek!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[philip . chimento]

Before making the switch please be aware of
https://github.com/mesonbuild/meson/issues/3077 and
https://github.com/mesonbuild/meson/issues/2121 which make Meson-built
libraries mostly broken on macOS, particularly with regard to g-ir-scanner.

Regards,
Philip C

On Sat, Jun 2, 2018 at 12:08 PM Ignacio Casal Quinteiro <
nacho.r...@gmail.com> wrote:

> On the gvsbuild side we are already building with meson for a while and
> things are ok. I just fear the case where we do not have python 3 on rhel 6
> and sles 11...
>
> On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi  wrote:
>
>> 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
>>
>>
>
>
> --
> Ignacio Casal Quinteiro
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GitLab CI runners for non-Linux systems

[philip . chimento]

On Fri, May 18, 2018 at 10:15 PM  wrote:

> Thanks for this call for help, it's our chance to finally be serious
> about supporting multiple platforms, instead of always fixing a
> posteriori. Thanks to gitlab that shouldn't be too hard to setup.
>
> Le vendredi 18 mai 2018 à 10:52 +0100, Philip Withnall a écrit :
> >  • macOS (ideally several versions, since we support from OS X 10.7
> > upwards[2])
>
> I did a quick test on a macmini (macOS 10.13.4) we have in Collabora
> office, and it's almost too easy to setup, not even a challenge!
>
> Well... except that glib fails to build with meson because libffi
> subproject does not support darwin. I'll try to investigate that.
>

I've been building
http://mirrors.kernel.org/sources.redhat.com/libffi/libffi-3.2.1.tar.gz on
macOS with no problems since at least 10.9. I think maybe just the meson
fork (https://github.com/centricular/libffi/commits/meson) of libffi has
this problem.

You could try pre-installing libffi from the tarball on the image, then it
wouldn't use the wrapped subproject, I think?

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

Re: GitLab CI runners for non-Linux systems

[philip . chimento]

On Fri, May 18, 2018 at 5:52 AM Philip Withnall 
wrote:

> Can anybody else provide and maintain CI runners for other platforms?
> I’d particularly like to see:
>  • *BSD (probably OpenBSD and NetBSD)
>  • macOS (ideally several versions, since we support from OS X 10.7
> upwards[2])
>  • Android (probably a cross-build)
>  • More Windows configurations (currently we have MSYS2 on Windows
> Server 2012; ideally we’d have a MinGW-w64 runner too)
>

I can help write the CI job configurations for macOS, but I don't know how
to host or set up a runner.

(For a shortcut solution, we could consider farming out the macOS builds to
Travis CI, which has macOS runners already available)

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

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

[philip . chimento]

On Wed, May 2, 2018, 11:32 Christoph Reiter, 
wrote:

> On Wed, May 2, 2018 at 7:57 PM, Morten Welinder  wrote:
> > It is just me, or is the migration mangling bugs?
> >
> > Compare https://bugzilla.gnome.org/show_bug.cgi?id=765921
> > to https://gitlab.gnome.org/GNOME/gtk/issues/621
> >
> > In bugzilla, the cut-and-paste compile commands with output are readable.
> > In gitlab, they're a mess.
>
> If you see a migrated bug that's hard to read please add some markdown
> formatting:
>
> https://docs.gitlab.com/ee/user/markdown.html#code-and-syntax-highlighting


Just wanted to add that cut-and-paste is pretty freeform on Bugzilla. It
wasn't possible to get all the cases right, and handling some would have
messed up others IIRC. So I picked some heuristics that mostly worked on my
test migrations of GJS. Even so, I had to edit some bugs and comments to
add markdown formatting, so I expect that maintainers will need to do that
in some cases for GTK as well.

I'd be happy to review any updates to the migration tool that improve its
ability to guess whether a particular paragraph should be enclosed in
triple-backticks or not.

Regards,
Philip C

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

Re: gobject-introspection Version 1 || GNOME

[philip . chimento]

Hi,

As is the standard in open-source software, you can find the license
information in the COPYING file in the root directory of the source
distribution or Git repository:
https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/COPYING

We do not have an ECCN number. Although I don't believe that
gobject-introspection uses encryption directly, it can be used to load
encryption libraries in client code, and there are no restrictions on the
purpose it could be used for.

I make no guarantees as to the accuracy of this information. We
unfortunately cannot provide any legally binding details, other than what
you can find yourself by inspecting the source code. Since many of our
contributors are individuals, not connected with any company, we cannot do
anything that might expose them to legal liability.

Best regards,
Philip C

On Wed, Mar 7, 2018 at 2:27 AM Chhabra, Komal /CS <
komal.chha...@exxonmobil.com> wrote:

> Hi Team,
>
>
>
> This is Komal Chhabra, a Team Lead from centralized license management
> team of ExxonMobil known as Software Asset Management[previously known as
> ITAM. The Software Asset Management group at ExxonMobil exists in large
> part to steward software license compliance
>
>
>
> We are contacting you to get *ECCN *details for product *gobject-introspection
> Version 1 *:
>
>
>
> Could you please provide us the ECCN number for this software
>
>
>
> *  If you do not have your software classified with an ECCN,
> please kindly answer the following questions* so that we may self-assess
> if there may be any prohibition or restriction for export or re-export of
> this product.
>
>
>
>  1, Does the Software perform any encryption or utilize any
> encryption processes?  Y/N
>
>  2. If the answer is YES to question 1, please indicate if the
> encryption is coded into the application or separately called (such as
> using SSL)
>
>  3. If the answer is YES to question 1, please indicate what
> function(s) the cryptography/encryption serves
>
>
>
> A, Copyright protection purposes (Includes using a license
> key/code)
>
> B, User authentication purposes
>
>C, A core part of the functionality such as to encrypt databases
>
>D, To encrypt communications between the software and a host
> system.
>
>
>
>  Background information:
>
>  An Export Control Classification Number (ECCN) is a specific
> alpha-numeric code that identifies the level of export control for items
> e.g. software that are exported from member states of the Wassenaar
> Arrangement, including the United States. After obtaining the ECCN, the
> exporter must determine  whether an export license is required
>
>
>
> Waiting for your kind acknowledgment.
>
>
>
> Regards,
>
>
>
> *Komal Chhabra*
>
> *New Products & Complex Team*
>
> *EMIT | IT OPS | Customer Infrastructure | WDS | SAM*
>
>
>
> *HCL Technologies Ltd. *
>
> *(CIN: L74140DL1991PLC046369)*
>
> *10th Floor, ODC-IV, Software Tower 6, Sector 126*
>
> *Noida SEZ, Uttar Pradesh – 201301, India*
>
> *Email : komal.chha...@em-msph.com *
>
>
>
> *for*
>
>
>
> *ExxonMobil Global Services Company*
>
> *22777 Springwoods Village Parkway*
>
> *Spring, TX 77389*
>
> *United States of America*
>
>
>
>
>
> *From:* Chhabra, Komal /CS
> *Sent:* Friday, February 23, 2018 2:46 PM
> *To:* 'gtk-devel-list@gnome.org' 
> *Subject:* RE: gobject-introspection Version 1 || GNOME
> *Importance:* High
>
>
>
> Hi Team,
>
>
>
> This is Komal Chhabra, a Team Lead from centralized license management
> team of ExxonMobil known as Software Asset Management[previously known as
> ITAM. The Software Asset Management group at ExxonMobil exists in large
> part to steward software license compliance
>
>
>
> We are contacting you to get *few* details for product *
> gobject-introspection Version 1 *:
>
>
>
> 1.   Under which agreement it falls under: MIT , GPL or LPGL ?
>
> 2.   Could you please provide us the ECCN number for this software
>
>
>
> *  If you do not have your software classified with an ECCN,
> please kindly answer the following questions* so that we may self-assess
> if there may be any prohibition or restriction for export or re-export of
> this product.
>
>
>
>  1, Does the Software perform any encryption or utilize any
> encryption processes?  Y/N
>
>  2. If the answer is YES to question 1, please indicate if the
> encryption is coded into the application or separately called (such as
> using SSL)
>
>  3. If the answer is YES to question 1, please indicate what
> function(s) the cryptography/encryption serves
>
>
>
> A, Copyright protection purposes (Includes using a license
> key/code)
>
> B, User authentication purposes
>
>C, A core part of the functionality such as to encrypt databases
>
>D, To encrypt communications 

Re: Contribution question

[philip . chimento]

On Thu, Jan 18, 2018 at 2:30 PM Pavlo Solntsev 
wrote:

> Hi,
>
> To better understand how some glib modules work, I write mini tests. I was
> thinking it would be beneficial for a lot of people if more examples will
> be included into the documentation to better explain how an object can be
> used. Similar to what QT has. I may contribute my examples. When I see
> a code on git hub I think about pull request. Do you use this approach? Or
> I should generate a patch and attach it to the bug report as described here
> https://github.com/GNOME/glib. I saw https://gitlab.gnome.org/ was
> created. Is it a common trend for ? Does glib also go there? Sorry for so
> many questions, just want to understand how dev process works.
>

Hi Pavlo,

The GNOME GitHub mirror is just a read-only mirror. Pull requests are
ignored for most repositories, although some maintainers will monitor them.
I'm not sure what's the case for GLib.

GNOME is in the process of migrating all their repositories to
gitlab.gnome.org, so GLib will go there eventually too, and accept merge
requests there. But until the migration is complete, you should follow the
old workflow: generate a patch and attach it to a bug report in Bugzilla.

Good luck with your contribution!

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

Re: gtk 3 stuck menu bug on Mac

[philip . chimento]

On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck <
schoeneb...@linuxsampler.org> wrote:

> On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote:
> > What I found out so far is that whenever this problem occurs, both of the
> > following two checks in function gtk_menu_motion_notify() (gtkmenu.c)
> return
> > false and the function is thus aborted at this point:
> >
> >   menu_item = gtk_get_event_widget ((GdkEvent*) event);
> >   ...
> >   if (!GTK_IS_MENU_ITEM (menu_item) ||
> >   !GTK_IS_MENU (parent))
> >   return false;
>
> Looking further at this issue, the problem is probably not a timing issue
> like
> I first considered in my previous email. Fact is that the wrong widget
> under
> the mouse pointer is resolved forever whenever this issue starts to occur:
>
> At this code location above, the gtk_menu_motion_notify() function expects
> menu_item to be a "GtkMenuItem" gobject class, however when this issue
> occurs,
> menu_item is pointing at its parent "GtkMenu" gobject instead.
>
> I would understand if this misbehavior just happens immediately after a new
> menu pops up. But whenever this stuck menu issue occurs, I can continue to
> move the mouse pointer over all the visible menu items for hours and the
> resolved toplevel widget under the mouse pointer (resolved by the Quartz
> implementation) is always the GtkMenu widget instead of the respective
> GtkMenuItem widget.
>
> Since this issue only seems to happen on Mac, and since it worked
> flawlessly on
> Mac before, and since I see the Quartz implementation hasn't really changed
> (significantly) in the last couple years, was there some kind of important
> change in gtk 3 that still would need to be applied to the Quartz driver?
>

No-one's really maintaining the Quartz backend at the moment, so if you
felt like investigating this it would be really appreciated. You could try
a 'git bisect' to see what change in GTK3 might have caused the regression
and that would probably make it easy to see what would need to be changed
in the Quartz backend.

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

Re: Stackexchange community for GNOME/GTK+

[philip . chimento]

On Wed, May 10, 2017 at 7:02 AM Tobias Mueller 
wrote:

> Hi.
>
> On Mi, 2017-05-10 at 08:04 -0500, Michael Catanzaro wrote:
> > Looks like if you want to do this, we'd have to host it
> Or use Stackoverflow.
> Sri's motivation was:
>
> > We need to have a search engine index-able library of knowledge on
> > our platform.  Modern programmers today frequently use stackexchange
> > and google to ask questions and to look for answers for questions.\
>
> I tend to think that Stackoverflow perfectly matches that.
>

Agreed, I'm a big fan of this but I don't see a reason why it ought to be a
separate community from the existing Stack Overflow site.

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

Re: [gtk-osx-devel] Native look and feel via GTK+ CSS

[philip . chimento]

On Mon, Jan 16, 2017 at 7:38 AM John Ralls  wrote:

>
> > On Jan 16, 2017, at 1:25 AM, Марко М. Костић 
> wrote:
> >
> > GTK+3 Python3 programs with headerbars  look out of place on macOS
> Sierra.
> >
> > I thought about using new GTK+ CSS system for styling them to look more
> like other
> > native macOS programs.
> >
> > Is this a good idea?
> > Anybody else did anything similar already?
>
> What do you mean by "headerbars"?
>

Something like this, I assume:
https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html

Yes, it's been done. Google for "gtk3 themes mac".
>

Even if GtkHeaderBar hasn't been styled yet in one of those themes, it's
likely that someone will since the CSS "API" has been declared stable in
3.20.

Regards,
Philip C
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: GLib.DIR_SEPARATOR_S problem on raspbian

[philip . chimento]

On Tue, Sep 13, 2016 at 3:36 AM narcisse doudieu siewe <
wambenarci...@yahoo.fr> wrote:

> Hello just to signal a problem.
>
> GLib.DIR_SEPARATOR_S on raspbian gives "\\" in place of "//".
> and GLib.DIR_SEPARATOR gives 92 number.
>

Several bugs are reported for this:
https://bugzilla.gnome.org/show_bug.cgi?id=696935
https://bugzilla.gnome.org/show_bug.cgi?id=749636
https://bugzilla.gnome.org/show_bug.cgi?id=757284

The short answer is, these constants are broken in introspected language
bindings so don't use them. For example, in Python use the os.path module
and in Javascript use GLib.build_filenamev() or Gio.File.

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

Re: Gtk+4.0

[philip . chimento]

On Mon, Sep 12, 2016 at 8:14 AM Davin McCall <dav...@davmac.org> wrote:

> Hi,
>
> I'm not a regular poster to this list and am not subscribed. I'm posting
> here now at the suggestion of Philip Chimento, who read a blog post I wrote
> recently [1] about the GTK+ lifecycle plans that have recently been
> discussed/announced. This blog post of mine received, for whatever reason,
> a lot more attention on anything than my blog normally does (just shy of
> 20,000 views in a day, when my average views per day of the whole blog is
> around 10) - which puts me in a position such that I feel I should address
> the concerns in a more head-on (and level-headed) fashion. I'll freely
> admit the tone in the blog posting is that of an indignant rant, though I
> hope no-one is personally offended by it since that certainly wasn't my
> intention.
>
> I'm concerned at the outset that this will be dismissed by people who are,
> after all, much more involved in GTK+ than I've ever been, so I ask that
> you read this with an open mind and with the understanding that I'm writing
> this out of genuine concern that's developed from the experience of dealing
> with API breakages in various packages over a long time-frame.
>
> My concern is that the new plan lays a foundation for breaking the API on
> a more regular basis, and formalises the notion that this is ok if it
> allows innovation in the design and development of GTK. While I am all for
> innovation, I am disturbed that casual API breakage in its name is being
> legitimised, especially because I do not believe that is necessary. From
> the proposal [2], statements such as:
>
> If new features conflict with existing ones, API might be removed, rather
> than being deprecated.
>
> ... are of particular concern. Further, I don't believe that this is
> consistent with the very next point in the same document:
>
> there will be an effort to limit breakage as much as possible.
>
> "As much as possible" is a *very* strong statement. If this was really
> the aim, there would be hardly any legitimate reason to break API at all,
> making the whole plan unnecessary. I'd suggest that the latter point is
> somewhat disingenuous (even if unintentionally so); putting it bluntly,
> only one of those two points can be correct, and from the tone of the
> document, I'm assuming that it's the first one and the second is a case of
> overly-strong wording. But on the other hand, removing API instead of
> deprecating is most definitely a breaking change that can often be *easily*
> avoided, let alone "as much as possible".
>
> Please do not assume I am basing my entire concern on that point alone.
> The general feeling from the proposal and the GTK development blog post
> that I initially responded to is that API stability is very much being
> pushed to a low priority compared to the need to push development ahead. I
> understand that API breakage does sometimes need to occur, but I think this
> attitude is not a good one. In particular I think the implied notion that
> API stability and good development progress cannot coexist is incorrect.
> I would be reassured perhaps if the plan discussed what software
> development methods were in place that would help to reduce the amount of
> API breakage needed. What is the procedure for API design in GTK - if there
> indeed is one? Are APIs reviewed before they are implemented? Are they made
> available for public review? Are there any guidelines? The Best Practices
> document [3] doesn't even mention API design; why not? Are the APIs even
> designed at all? I am left with the worrying impression (hopefully not
> correct) that the API simply emerges from the code. This would certainly
> explain why API breakage might be needed on a regular basis, but that's a
> symptom of an imperfect design practice; if it is being found that the
> resulting APIs are not extensible or flexible enough for ongoing
> development and future requirements, then I strongly suggest that the
> better solution is to improve the API design methodology, rather than
> simply to legitimise casual API breakage.
>
> I understand how open-source development often works in ways that don't
> suit more traditional rigourous approaches, but I would recommend
> establishing a set of guidelines for API development, and at a minimum have
> each commit/check-in that introduces new API be reviewed against those
> guidelines by a developer not otherwise involved. Since I can't claim to
> know how GTK development proceeds there's the possibility that something
> like this (or better) already happens - in which case, perhaps my concerns
> can be dismissed; if so, please consider publishing details and updating
> the Best Practices do

GTK-Next (was: Re: Gtk+4.0)

[philip . chimento]

On Tue, Jul 19, 2016 at 11:08 AM Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On 09/07/16 20:42, Jasper St. Pierre wrote:
> > In fact, this could be a new plan. If we double down on Flatpak, then we
> > could simply not bump soname / major version, leave it at 4, break ABI
> > every point release, and have the ".6-multiple" releases be LTS releases
> > which are "maintained more than most".
>
> Speaking as a distribution (Debian) developer: breaking the ABI without
> bumping the SONAME is really frustrating to deal with in distributions;
> so if there will be anything that uses Gtk and is ever distributed in
> ways other than Flatpak and similar things, please manage the Gtk SONAME
> correctly.
>
> gnome-shell, gnome-control-center and gnome-settings-daemon, together
> with their forks in GNOME derivatives like Cinnamon, are among prominent
> packages that depend on Gtk but should be part of the distribution's
> release process, even in a possible future where ordinary apps are
> exclusively distributed via Flatpak. (I don't think that future has
> arrived yet, in any case.)
>

Now for the comedy part of the discussion. I'd like to follow through on
the double-down-on-Flatpak proposal, even if Jasper didn't mean it
seriously. I don't mean it entirely seriously either, since it has some
serious flaws detailed below, but it does address some of the concerns I
summarized in my email from just now [1].

The stable series would be much as in the original GTK 4 proposal, but it
would just be called "GTK". That indicates to outsiders who don't care
about release schedules and just want a GUI toolkit, that this is the
toolkit to use. GTK would receive bugfixes, and possibly backports of new
features if maintainer time and inclination allows.

The unstable series would get a different name that isn't "GTK", e.g.
"GTK-Next", and become (imagine air quotes around this) "Flatpak-only".
Air quotes because it would of course still be released as a source
tarball, and if a distro wanted to package it of course no-one could stop
them; but we would discourage it from being available through distro
package managers. Air quotes also because it wouldn't be limited to Flatpak
on Linux; I would for example be able to build GTK-Next and bundle it
inside an application bundle on Mac OSX. That use would also be encouraged,
as well as its equivalent on Snappy, as well as whatever application
sandboxing solution arises on any other platform in the future.

But as far as GNOME is concerned, GTK-Next would be released first and
foremost as part of the org.gnome.Platform Flatpak runtime.

This does cut off system components such as gnome-control-center from using
GTK-Next, as Simon pointed out above.

This would also leave applications in somewhat of an awkward position if
they wanted to use GTK-Next but needed to use a library that depends on
GTK, such as GtkSourceView, VTE, or WebKitGTK. I see two possibilities here:
1) if the library maintainer is amenable to doing the work, the library
could have a GTK-Next branch with a separate pkg-config name, and this
would be released with the same intention and through the same channels as
GTK-Next.
2) if the library maintainer is not interested, the application author
would have to port the library to GTK-Next themselves and bundle it in
their application.

The worst part of this proposal is that it makes it very hard for app
maintainers to use GTK-Next if they want to keep releasing their app in the
traditional manner, not as a Flatpak or other bundle. They could decide to
maintain a separate GTK version alongside the GTK-Next version of their
app, but that's a really crappy story to sell to developers. Maybe we could
include some tooling which would make it easy for GTK-Next to be built as
an application's internal library in pkglibdir? It might mean that in
practice the only users of GTK-Next would be applications like GNOME
Documents and GNOME Music, which would be a shame. It would also feed the
perception that GTK is primarily there for the consumption of GNOME and
other consumers are an afterthought.

The pros of this proposal are that it's crystal clear that GTK-Next is
opt-in only, and the bulk of the extra work falls onto the people who
opt-in. It removes packagers and distros from the equation entirely and so
will not cause them more work. Put bluntly, the idea is to make it harder
for app maintainers to opt-in to the unstable series if they aren't serious
about keeping up with the porting work, as well as limiting the damage they
can do if they leave an app stuck on an old version of GTK-Next.

No version numbering schemes were harmed in the making of this email.

Happy hacking everyone,
Philip C

[1] https://mail.gnome.org/archives/gtk-devel-list/2016-August/msg00015.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 9:31 PM  wrote:

> On Sat, Jul 9, 2016 at 12:06 PM  wrote:
>
>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
>> wrote:
>>
>>>
>>> Here are some thoughts I have about all this, from a downstream
>>> maintainer POV.
>>>
>>
>> Thanks! It's good to get opinions from all over the place.
>>
>
> And, speaking of that, there was a blog post [1] on the GTK 4 subject that
> recently got a lot of attention on Hacker News. I reached out to the author
> and encouraged them to give their opinion here, but it seems the message is
> stalled in the moderator queue. Is there a moderator who can help?
>
> [1]
> https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/
>

Could a moderator please help with this? At this point, the blog post is
starting to attract comments insinuating that we're suppressing the
discussion on purpose [2].

Best,
Philip C

[2]
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/#comment-1050
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

I realized this thread had been sitting for quite a while. GUADEC is about
to start and I'd like to summarize what's been talked about. Some of the
concerns I read from this thread are:

1. Developers are concerned about there not being enough indication of
which APIs are more likely or less likely to be overhauled in the unstable
series.

2. Maintainers of non-core GNOME apps are concerned that they will be
sucked into the unstable series; in other words that it's not opt-out
enough.

3. App developers are concerned that the stable series will be ignored in
favor of the unstable series.

4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE,
WebKitGTK) are concerned about having to maintain essentially a separate
library for each unstable release.

5. Packagers are concerned about apps depending on a library that depends
on an unstable version of GTK, then ceasing development, leaving a
straggler package in the distro.

6. Users, maintainers, and packagers are concerned that it will be daunting
to keep up with stable GTK's 2-year API/ABI break cycle even if not
opting-in to the unstable series, and that maintainers will instead choose
to remain on GTK 3.x or GTK 2.x.

7. Distro maintainers are concerned about having to recompile the whole
world too often because of the unstable series necessitating frequent
soname changes.

Did I forget anything? Please help me summarize. I suggest phrasing it as
"$ROLE is concerned about $THING" as I believe that's conducive to thinking
about others' needs rather than a my-opinion-versus-your-opinion
discussion. (Not saying those are not good to have, but I think at this
particular stage, summarizing and understanding is more useful than hashing
it out.)

There are also the as-yet unanswered FAQs from the FAQ [1], copy-pasted
below, that I think we should try to answer by the end of GUADEC:

- Why can't the stable release cadence be longer than 2 years?
- Why can't the stable releases stay supported for longer than 2 years?
- Why release API-breaking major versions on a cadence? Can't you just do
it only when necessary?
- How about a GtkPrivate library and #define I_WANT_UNSTABLE_API?
- How can I support both the stable and unstable releases?
- How will this affect theme developers, since they don't get to choose
what version to target like app developers do?

By the way, Christian: Peter suggested turning this post of yours [2] into
a post on the GTK blog, would you be interested in doing that?

Best,
Philip C

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ
[2] https://mail.gnome.org/archives/gtk-devel-list/2016-June/msg00032.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sun, Jul 10, 2016 at 3:51 PM John Tall  wrote:

> On Sat, Jul 9, 2016 at 9:06 PM,  wrote:
> > I'm expecting this will become less and less of a problem as apps move
> to Flatpak as a means of distribution.
>
> As far as I know Flatpak only targets GNU/Linux, and at the moment
> only targets a handful of distros. I make software for not only
> GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries
> including GTK+. I don't know yet if or how these changes will impact
> me, all I know is that the way things are right now works just fine
> for me.
>

Let me state categorically:

Nothing in this proposal forces anyone to use Flatpak.

Though I am excited about Flatpak if that wasn't obvious by now, I myself
also make software for other platforms than Linux and contribute quite a
lot of my time towards keeping GTK and other libraries buildable on Mac OS
X.

I really don't want to turn this thread into a discussion of the merits of
Flatpak. What I did (more explanation here [1]) was try to answer a
question, essentially "What if some app developer does ?"
that I would previously, before Flatpak existed, have answered "Well, don't
do that then." Instead, I can now say "I hope fewer people will do  because of Flatpak."


> I'm worried that we're breaking things that already work for lots of
> us in order to fix inconveniences that some people have. I don't want
> to drastically change the way I make and distribute software just
> because one of the many libraries that I use has decided to do things
> differently. If things need to change then do whatever is necessary
> but please, let the old stuff also continue to work.
>

If you track the long-term supported releases of GTK with your software,
then you shouldn't need to change anything in the way you make and
distribute it.

Regards,
Philip C

[1] https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg9.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 1:14 PM Peter Weber  wrote:

> Hi!
>
> On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote:
>
> > I'm expecting this will become less and less of a problem as apps move
> > to Flatpak as a means of distribution.
>
> Uhuuu. I'm sorry, but this is bad.
>
> This mixes two completely different problems together, packaging and a
> toolkit. So enforcing Flatpak on distributions, developers and users
> should solve a problem with Gtk+?
>

No, nothing about any of this proposal forces people to use Flatpak.

The problem Emilio mentioned was,

> some third party apps pick a dependency on the vte for GTK+ 4.2 but don't
update it for GTK+ 4.4, as then distros would need to ship an increasing
number of versions that are unlikely to get any support upstream.

In my opinion, the expectation is that app developers who sign on to the
unstable series will see it through until the next long-term stable
release, and not abandon development while still targeting an unstable
release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2,
VTE-for-GTK-4.4, etc. because apps are all stuck at different versions.

Of course, nothing is stopping developers from doing that anyway. The same
way nothing is stopping me right now from putting this line in my app's
configure.ac:
PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20])
However, if I did that then any distros trying to package it would quite
rightly complain.

I'm saying that if an app developer feels the need to do that, then they
will be better off targeting a Flatpak runtime.

Having said all this, I'm thinking about sketching out a proposal that
doubles down on Flatpak like Jasper was suggesting. Paradoxically I think
it might seem more palatable to more people... more updates later.

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

Re: Gtk+4.0

[philip . chimento]

On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre 
wrote:

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

If an app was released as a Flatpak, it would target a Flatpak runtime.
There would not be a choice between targeting VTE-for-GTK-4.2 or
VTE-for-GTK-4.4, and so distributions would not need to ship a
VTE-for-GTK-4.2 straggler that some app was still targeting.

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

There are several different version numbering schemes proposed on this wiki
page [1]. I was referring to the term "unstable release" versus
"development branch".

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

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

> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
> wrote:
>
>> Hi,
>>
>> On 21/06/16 16:26, Peter Weber wrote:
>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> > write about my thoughts, in a careful way. In the first moment, I
>> thought
>> > this is a good idea and just the numbering is misleading. Stability is
>> what
>> > developers want, we need it, we love it. With a few days distance,
>> > numbering is just a small issue, I see this now entirely different and
>> > three major issues:
>>
>> Here are some thoughts I have about all this, from a downstream
>> maintainer POV.
>>
>
> Thanks! It's good to get opinions from all over the place.
>

And, speaking of that, there was a blog post [1] on the GTK 4 subject that
recently got a lot of attention on Hacker News. I reached out to the author
and encouraged them to give their opinion here, but it seems the message is
stalled in the moderator queue. Is there a moderator who can help?

[1]
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

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

Re: Gtk+4.0

[philip . chimento]

On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort 
wrote:

> Hi,
>
> On 21/06/16 16:26, Peter Weber wrote:
> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> > write about my thoughts, in a careful way. In the first moment, I thought
> > this is a good idea and just the numbering is misleading. Stability is
> what
> > developers want, we need it, we love it. With a few days distance,
> > numbering is just a small issue, I see this now entirely different and
> > three major issues:
>
> Here are some thoughts I have about all this, from a downstream maintainer
> POV.
>

Thanks! It's good to get opinions from all over the place.

My concern with this new scheme is that GTK+ libraries will have to bump the
> soname every 6 months (if they want to support the latest GTK+). That can
> be
> manageable for say vte or gnome-desktop, although it may be bad if some
> third
> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it
> for
> GTK+ 4.4, as then distros would need to ship an increasing number of
> versions
> that are unlikely to get any support upstream.
>

I'm expecting this will become less and less of a problem as apps move to
Flatpak as a means of distribution.

But do you expect WebKitGTK+ to bump the ABI every 6 months?
>

That does seem to point to a problem — if an app uses Library X which does
follow the unstable GTK series, and Library Y which doesn't, then the app
developer is forced to stick to the stable series of GTK and an old version
of Library X in order to accommodate Library Y.

Any thoughts?

I feel like the X.[024] releases are just snapshots of a development branch,
> with X.6 being the stable release, and I wonder if X.[024] shouldn't
> clearly be
> labelled as that, regardless of what version number is chosen (be it 4.0,
> 3.99.0, 4.0beta1 or whatever).
>

In my opinion the label "unstable release" communicates exactly that. I'm
not sure what "development branch" communicates that "unstable release"
doesn't?

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

Re: Gtk+4.0

[philip . chimento]

On Thu, Jun 23, 2016 at 9:29 AM Peter Weber 
wrote:

> On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie
>  wrote:
> > Ideally, we'd choose the trade-off such that projects that want to stick
> > to a stable-branch version are happy with its stability, while also not
> > feeling that they are missing out on too much new stuff by doing so. A
> > year is probably too fast? 5 years is probably too slow? I don't know
> > what the right middle ground between those two is, but 2 years sounds
> > like a good first guess.
>
> I started to think about it this. I tend to compare Gtk with Qt, but they
> are not the same. On the other hand, Gtk and Qt are only major
> platform-independent toolkits and largely used on GNU/Linux. The active
> phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016,
> which is a scary long time. Qt's cycle is much shorter, they moved from
> 2.x till 5.x in same time frame.
>
> The current proposal will split Gtk into stable branch, which will break
> in an insupportable* short-period of two years. Even if some major
> applications will move immediately to a stable release, they will already
> use the out-dated within two years. Furthermore GNOME will not use "Gtk",
> GNOME will use it's own Gtk which will likely look and feel different in
> several ways(HIG?). I'm afraid support for at least the development Gtk,
> the stable Gtk and the old-stable Gtk will be required also.
>
> * Thank you English language for this word!
>
> 10 Years are too long and 2 years are too short. Right? Is it better to
> break the API/ABI clearly once and keep it stable for some years, maybe a
> range between 4 to 6 years? In this area compatible (non-breaking)
> features
> can be added. I'm feeling far more comfortable with this idea. This sounds
> similiar to Qt and maybe it's a good approach:
>
> + all applications will largely use the same toolkit (good for users)
> + reliable planning (application developers)
> + necessary API/ABI break (library developers)
> + less maintenance burden (library developers)
> - not so many freedom through API/ABI break (library developers)
>
> I would prefer a faster and more firm cycle.
>

I've tried to capture some of the discussion that we've had so far, on-list
and off, in this FAQ [1]. I also added some points for further discussion,
such as the longer cycle length you mentioned above.

Regards,
Philip C

[1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[philip . chimento]

On Tue, Jun 21, 2016 at 7:34 AM Peter Weber 
wrote:

> Hello!
>
> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> write about my thoughts, in a careful way. In the first moment, I thought
> this is a good idea and just the numbering is misleading. Stability is what
> developers want, we need it, we love it. With a few days distance,
> numbering is just a small issue, I see this now entirely different and
> three major issues:
>
> 1. Separating official applications from GNOME, away from all other major
> applications
> 2. Very short stable-release-cycle, every two years an API/ABI-Break is
> really bad for all
> 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
> most important part for a toolkit
>
>
>
> I hope you don't hate me now.


Quite the opposite, thanks for starting the discussion. I think many people
who were at the hackfest are still recovering from travel and catching up
what they missed at work, so no-one started a thread on this.


> I'm trying to elaborate this:
> 1. Separating official applications from GNOME, away from all other major
> applications:
> Applications will be splitted in modern and outdated ones. Users will see
> modern applications from GNOME and a lot of old stuff, mainly well-known
> applications. As time of writing, neither Gimp, Inkscape, Geeqie, Pidgin
> nor Geany merged to Gtk3. After five years we see now Firefox and
> LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was
> released in 2011.


In my opinion, this is what the proposal tries to solve. I think a common
message is that outside applications don't want to risk porting to GTK 3
because it's not stable enough. I hope that once GTK 4 is released and
declared stable, then applications like Firefox and LibreOffice would be
confident enough to start porting right away. Especially if we can have
some decent porting guides in place when the new stable release rolls
around.

I'm not sure about this, but I suspect the jump between GTK 2 and 3 was
quite a lot larger than the jump between GTK 4 and the following stable
version will be. Since GTK 2 reigned for 10 years, there were a whole lot
of breaking changes that had to happen at once when the opportunity arose.


> From the developers side, we will forced to choose
> between to nasty options, an already outdated stable API/ABI or a shiny new
> API/ABI, which will break fast.
>

Even if the tradeoff is as bad as you describe, it's better than the one
that application developers get in the current situation: a 10-years
(instead of 1.5 years) outdated stable API/ABI or a shiny new API/ABI which
is not expected to break between releases but in practice it does anyway.

I'm hoping the tradeoff will not be as bad as you describe though :-) Two
years is a much shorter cycle and the stable version will not get as
outdated. As for tracking the unstable series, well, it's definitely opt-in
for a reason, and you shouldn't do it unless you are OK to deal with the
breakage. I expect though that given the option of a two-year stable
series, most developers outside of GNOME will use the stable series. I
certainly plan for my side projects to track the stable series.

If I can finish writing it, I'll add a FAQ page to the wiki today that will
try to illustrate better what the benefits and drawbacks are for
application developers.

2. Very short stable-release-cycle, every two years an API/ABI-Break is
> really bad for all:
> If the API/ABI becomes stable every fourth release or two years, this is
> to short for the developers to adapt. Constant breaking is bad for
> developers! We will see a lot of different stable API/ABIs used within
> years (or not, which isn't better). And the Gtk+-Team will have to support
> a lot of stable-branches: Gtk2, Gtk+3, Gtk4 (two years later), Gtk5(four
> years later) and so on.
> This sounds like very much work and is bad for the Gtk+-team. Currently
> the Gtk+-Team has to support Gtk2 and Gtk3, only.
>

I believe the idea is to support one stable and one unstable release at the
same time. In my opinion, if GTK 8 is the current stable version and you're
still on GTK 3, then that should be equivalent to if you're still using GTK
1 in 2016...

Furthermore the alignment to Debian/Ubuntu LTS sounds like a permanent
> delayed cycle building on top of each other. I don't expect many developers
> to catch up with unstable/upstream or even using "git clone://", in case of
> Ubuntu or Debian this could happen:
> -> LTS -> Stable API/ABI -> Developers start adapting
> -> Subsequent LTS -> Adapted applications available -> But already new
> stable API -> Developers start adapting again
>

This is a good point and it seems like the stable GTK should pick a
judicious time to release that fits with distros' release cycles.


> 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the
> most important part for a toolkit:
> Nobody named a reason, why it is 

Re: Does Gtk+ Still Support Application-Provided Widgets?

[philip . chimento]

Hi,

To a certain, lesser, extent this has always been the case: for example, I
filed [1] a long time ago because you can't write your own GtkContainer
subclass with an internal layout manager and have gtk_container_add() and
gtk_container_remove() still work on it, although GtkAssistant does this
and gets special privileges to allow it.

I'm not a core GTK developer so I don't know why things were set up this
way, but I assume it's because no-one (yet) wants to guarantee the
stability of the API in the private files, and once it's been declared
stable it'll be exposed. I hope that particularly the CSS gadget stuff is
eventually meant to be public, but if it were public before it was stable,
then people's custom widgets would just break on each new release anyway,
right?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=699756

Regards,
Philip C


On Sun, May 1, 2016 at 9:20 AM Morten Welinder  wrote:

> Gtk+ used to support custom widgets.  Whenever you were unhappy with
> the official
> set you would hack up your own.  More often than not, this would start
> by copying
> an official widget's code and do a mass rename of identifiers.
>
> No more.
>
> More and more of the api needed to created widgets is migrated into
> gtk*private.h
> headers rendering it inaccessible for applications.  Take GtkButton,
> for example.
> It includes the following private headers:
>
> #include "gtkbuttonprivate.h"
> Just a structure, but it is included also outside gtkbutton.c.  I.e.,
> widgets like GtkCheckButton
> are allowed special privileges that MyButton is not.
>
> #include "gtkwidgetprivate.h"
> Again, there really should not be any API that in-tree widgets are
> allowed to use, but
> out-of-tree widgets are not.  I can see a case for
> "gtkwidgetprotected.h" in the C++ sense,
> though.
>
> #include "gtkprivate.h"
> No idea.
>
> #include "gtkapplicationprivate.h"
> I don't think this one is actually used.
>
> #include "gtkcsscustomgadgetprivate.h"
> The whole gadget machinery is private.  Anyone who wants stateful css
> nodes gets to
> implement the whole css stack themselves.
>
> #include "gtkcontainerprivate.h"
> This is just silly.  Either something is useful for containers in
> general and it should be public, or
> else it is not useful and it should go into gtkcontainer.c
>
> Suggestion:  Only gtkbutton.c should be allowed to include
> gtkbuttonprivate.h and similarly
> with other private headers.  Create gtkbuttonprotected.h if needed and
> install it.  Add needed
> API for derivation either to gtkbutton.h or gtkbuttonprotected.h.
>
> Morten
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

[gtk-osx-devel] Linking on El Capitan

[philip . chimento]

I've run into a problem linking with ICU since upgrading to El Capitan.
I've pasted some example output from building webkit2gtk3 below, but I have
seen this as well on other modules that depend on icu.

This only happens when generating introspection data, not when linking the
actual libraries.

[ 99%] Generating ../../WebKit2-4.0.gir
dyld: Library not loaded: libicui18n.54.dylib
  Referenced from:
/my/jhbuild/checkout/webkitgtk-2.10.4/lib/libwebkit2gtk-4.0.37.dylib
  Reason: image not found
Command
'[u'/my/jhbuild/checkout/webkitgtk-2.10.4/Source/WebKit2/tmp-introspectilkK_K/WebKit2-4.0',
u'--introspect-dump=/my/jhbuild/checkout/webkitgtk-2.10.4/Source/WebKit2/tmp-introspectilkK_K/functions.txt,/my/jhbuild/checkout/webkitgtk-2.10.4/Source/WebKit2/tmp-introspectilkK_K/dump.xml']'
returned non-zero exit status -5
make[2]: *** [WebKit2-4.0.gir] Error 1

Looking at the library I see that other libraries are referenced by their
full path, but ICU is not:

$ otool -L lib/libwebkit2gtk-4.0.37.dylib
lib/libwebkit2gtk-4.0.37.dylib:
/my/jhbuild/checkout/webkitgtk-2.10.4/lib/libwebkit2gtk-4.0.37.dylib
(compatibility version 37.0.0, current version 37.11.7)
/my/jhbuild/install/lib/libgtk-3.0.dylib (compatibility version 1601.0.0,
current version 1601.7.0)
/my/jhbuild/install/lib/libgdk-3.0.dylib (compatibility version 1601.0.0,
current version 1601.7.0)
[...snip...]
libicui18n.54.dylib (compatibility version 54.0.0, current version 54.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1226.10.1)
libicuuc.54.dylib (compatibility version 54.0.0, current version 54.1.0)
[...snip...]

(local paths redacted to /my/jhbuild/checkout and /my/jhbuild/install)

So I wonder if DYLD_LIBRARY_PATH is getting clobbered by SIP somewhere on
the way to the g-ir-scanner tool. I am using a jhbuild-built bash in
jhbuild, not /bin/bash.

Regards,
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: Ülease get gtk3 css definition to be similar to gtk pixbuf!

[Philip Chimento]

On Sat, Jul 25, 2015 at 9:26 AM, Matthias Clasen matthias.cla...@gmail.com
wrote:

 We will be discussing how to document the evolving GTK+ css
 capabilities in a clearer way at Guadec in a few weeks.


I wanted to reply to this before GUADEC but it slipped my mind. Here's a
documentational Gist of supported CSS properties, as of GTK 3.8, that I put
together a couple of years ago by reading the GTK source at the time. It
may be useful to your discussion (if that discussion hasn't already
happened) as an example.

https://gist.github.com/ptomato/0fb634ef4098bb89026f

Another thing that I'd find useful in GTK CSS documentation is to document
exactly how the properties differ from their web counterparts, and indeed
which web properties are not supported. I'm not a web programmer but even
for me that would be useful, because the majority of CSS documentation and
examples out there are for the web.

Regards,
Philip

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

Re: GMemVTable broken

[Philip Chimento]

On Fri, Jun 26, 2015 at 8:50 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

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

 I think removing all the code is fine.

 On Fri, Jun 26, 2015 at 8:38 PM, Alexander Larsson al...@redhat.com
 wrote:
  So, I just tried to use the memory profiler in glib, and I crashes
  really early because the gobject constructor (gobject_init_ctor) calls
  g_malloc before main() is reached.
 
  This means g_mem_set_vtable() is impossible to use. I don't necessarily
  think this is all that bad. Honestly we should never have made it a
  vtable (one extra vfunc per malloc...) and instead do memory profiling
  etc the normal way, i.e. LD_PRELOAD something with malloc
  interceptors. Maybe we should just remove all this code and keep
  g_mem_set_vtable as a dummy function that prints a deprecation warning?


Would it be possible to write a how-to page on the Gnome wiki that the
documentation of the now-deprecated function would point to?

I'm afraid that new developers would be the ones hit hardest by this. I
certainly used g_mem_set_vtable to my benefit when I was first starting out
with the Gnome stack. I could now figure out how to do memory profiling the
normal way, as you say, on my own, but I certainly wouldn't have been
able to 8 years ago.

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

Re: [gtk-osx-devel] [PATCH 3/3] Moduleset-stable: fixing the repository link of cups module

[Philip Chimento]

On Mon, May 11, 2015 at 7:18 AM, John Ralls jra...@ceridwen.us wrote:


 On May 11, 2015, at 1:50 AM, Kirill Moizik kir...@daynix.com wrote:

 Hi John,
 I sent it here  https://github.com/GNOME/gtk-osx/pulls
 I am a little bit confused about all this different projects
 Kirill

 On Sun, May 10, 2015 at 6:59 PM, John Ralls jra...@ceridwen.us wrote:


 On May 10, 2015, at 1:43 AM, Kirill Moizik kir...@daynix.com wrote:

 Thanks for your reply John,
 i sent pull request with the fix,
 please review it
 Thanks in advance,


 Please remember to copy the list on all replies, using “reply all”.

 I don’t see any PRs on https://github.com/jralls/gtk-osx-build. Where
 did you send it?


 Please remember to CC the list on all replies.

 Huh, I’d forgotten about that repo. Not a good choice for PRs because I
 don’t get notifications about them, either by mail or on my dashboard.
 Better to use my repo.

 The structure is a bit weird because of the history of gtk-osx. When
 Richard Hult started it he created it separately from Gnome, and for a long
 time the Gnome folks were passively to aggressively hostile about building
 on anything other than Linux. That changed a few years ago when some of
 them discovered Macs, and I was invited to move the projects to Gnome and
 given push privs there. But git.gnome.org doesn’t have any way to handle
 PRs, so I kept my Github repos open and push everything to both Gnome and
 Github.

 The Gnome Github mirrors are just pushes from git.gnome.org, run by a
 commit hook. There’s a FAQ about them at
 https://wiki.gnome.org/Sysadmin/GitHub, the first of which says that PRs
 aren’t accepted. We’ll see if anyone notices yours and my comment on it.


There's a thread from just a few days ago on desktop-devel-list [1] about
changing to a system where it's the maintainer's choice whether to accept
pull requests or not; so I guess it's up to you, John.

If you want to get notified about pull requests in the Gnome mirror as
well, you can watch the repo with the button at the upper right.

[1]
https://mail.gnome.org/archives/desktop-devel-list/2015-May/msg4.html
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Libsoup Introspection (was Bison 3 and WebKit)

[Philip Chimento]

On Mon, Mar 2, 2015 at 7:27 AM, John Ralls jra...@ceridwen.us wrote:


 On Mar 1, 2015, at 11:12 PM, Philip Chimento philip.chime...@gmail.com
 wrote:

 On Tue, Feb 24, 2015 at 6:53 AM, John Ralls jra...@ceridwen.us wrote:


 On Feb 23, 2015, at 11:13 PM, Philip Chimento philip.chime...@gmail.com
 wrote:

 On Mon, Feb 23, 2015 at 11:52 AM, John Ralls jra...@ceridwen.us wrote:


  On Dec 27, 2014, at 9:55 AM, Philip Chimento 
 philip.chime...@gmail.com wrote:
 
  I still get an error building libsoup, only on modulesets-unstable. I
 worked around it by adding --disable-introspection to libsoup's autogenargs
 in my local configuration file, since I assume it's a temporary problem. I
 haven't yet had time to pinpoint where it came from, though. Have you seen
 this before at all?
 
GISCAN   Soup-2.4.gir
  Traceback (most recent call last):
File /Users/fliep/gtk/inst/bin/g-ir-scanner, line 55, in module
  sys.exit(scanner_main(sys.argv))
File
 /Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
 line 517, in scanner_main
  ss = create_source_scanner(options, args)
File
 /Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
 line 430, in create_source_scanner
  ss.parse_files(filenames)
File
 /Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
 line 256, in parse_files
  self._parse(headers)
File
 /Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
 line 302, in _parse
  proc.stdin.write('#ifndef %s\n' % (define, ))
  IOError: [Errno 32] Broken pipe
  make[3]: *** [Soup-2.4.gir] Error 1
  make[2]: *** [all] Error 2
  make[1]: *** [all-recursive] Error 1
  make: *** [all] Error 2

 Well, I finally needed to fix this, since we’re about to do a Gramps
 release. It was more involved than I thought, too: The broken pipe turned
 out to be from Popen getting a SIGSEGV; I’m not able to tell if it’s from
 the fork or the exec. Here’s the weird part, and the work-around. They’re
 the same:

 Select 4 to open a shell. cd to glib-networking. Run
   make uninstall  make install
 Quit the shell and select 1, rerun build. All will be well.

 How’s that for weird?


 Sure is. I'm completely stumped. The workaround might point at
 glib-networking doing something bad at shared-library load time, but it
 looks like the segfault occurs while still passing input to the compiler,
 before shared libraries are loaded.


 I tested by substituting `ls` for the gcc command line. That crashed too,
 leading me to conclude that something is interfering with Popen itself, but
 I haven’t yet figured out how to debug it.


 If there's a known configuration (Gnome 3.12?) where it worked, then
 perhaps git bisecting would be the most reliable method of finding out what
 broke. Probably the state of the modulesets before my update to 3.14 would
 be a good starting point. Potentially very tedious, since the problem could
 be in glib-networking, libsoup or gobject-introspection, or maybe somewhere
 else…


 We can rule out libsoup. giscanner is broken for everything after
 glib-networking is installed. Rolling back gobject-introspection didn’t fix
 the problem, so I’d start with glib-networking and if that failed to find
 the problem I’d look at its dependencies (libnettle, gnutls, gmp, etc.).
 One could start by just rolling each one back to what they were in the
 modulesets before your patches last December. Run giscanner on glib as a
 test.


I finally got some time to bisect this. The offending commit is this one:

https://git.gnome.org/browse/gtk-osx/commit/?id=302b4b32c81592cac6b8201a8edc986c2dfb6979
- Add p11-kit to gnutls

I rebuilt gnutls on master using --without-p11-kit, and sure enough -
giscanner works again. Still no clue why this is.

Here's a pull request on GitHub:
https://github.com/jralls/gtk-osx-build/pull/40

Regards,
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] configure: error: Python module libxml2 is needed to run this package

[Philip Chimento]

On Wed, Dec 24, 2014 at 8:11 PM, John Ralls jra...@ceridwen.us wrote:


 On Dec 24, 2014, at 2:13 PM, Jim Charlton char...@gmail.com wrote:

  On 14-12-23 12:23 PM, Philip Chimento wrote:

  On Tue, Dec 23, 2014 at 12:50 PM, Jim Charlton char...@gmail.com
 wrote:

 I am building gtk-osx on MAC Yosemite 10.10

 1. gtk-osx-build-setup.sh

 2. export PATH=$PATH:/Users/chartech/.local/bin

 3. Added lines

 checkoutroot =
 os.path.expanduser(/Applications/Drumroaster/gtk/Source/gtk)
 prefix = os.path.expanduser(/Applications/Drumroaster/gtk/inst)
 os.environ[ARCHFLAGS] = -arch x86_64

 to .jhbuildrc-custom as I want the installation in a non-standard
 location.

 4. jhbuild bootstrap
 5. alias jhbuild=PATH=/Applications/Drumroaster/gtk/inst/bin:$PATH
 jhbuild
 6. jhbuild build python
 7. jhbuild build meta-gtk-osx-bootstrap

 In step 7 I get a configure error while building itstool. configure:
 error: Python module libxml2 is needed to run this package

 I have run this sequence before on MAVERICKS (10.9.5) with no problem.
 Must be something about the way the python libs are being installed or used
 but I cannot figure it out.

 Any help would be appreciated.


  You may need to set the PYTHONPATH environment variable to include
 /Applications/Drumroaster/gtk/inst/lib/python2.7/site-packages (check that
 there is a libxml2.py file there.)

  Regards,
  --
 Philip


 A further comment... and perhaps a solution to my problem.

 I checked and the installed version of python on MAC 10.10 is 2.7.6.  I
 reasoned that the problem I was having was caused by having two
 installations of python.  So I started again as above but I left out the
 'jhbuild build python' step.  Now the next step 'jhbuild build
 meta-gtk-osx-bootstrap' completes successfully!

 Thanks for listening to my moaning! :-)


 I’ve had issues with that too. What happens is that the first build of
 python gets linked against /usr/lib/libpython instead of
 $PREFIX/lib/libpython, but libxml2.dylib gets linked against
 $PREFIX/lib/libpython and won’t import. Select 4, cd ../Python-2.7.6, rm
 python.exe, make  make install usually relinks python.exe correctly,
 after which iditools builds correctly.


I ran into this issue myself for the first time as well. I wasn't building
Python but using the system one instead. For me, starting a shell and doing

cd ../libxml/python
make install

was enough to get the libxml2 Python module installed in the right place.
Apparently, despite it finding Python at /usr/bin/python during configure,
it still didn't install the module the first time around. Still not sure
why this happens.
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: GL and libepoxy

[Philip Chimento]

On Fri, Mar 6, 2015 at 8:49 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

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


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

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

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

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


Jasper's correct; I tried this out  a while ago [1] and it currently does
the right thing in modulesets-unstable [2], although the repository I
specified there pointed to the libepoxy commit _before_ it was merged to
master.

This isn't yet in any release, I suppose we need to wait for libepoxy 1.3.

[1]
https://mail.gnome.org/archives/gtk-devel-list/2014-November/msg00012.html
[2]
https://git.gnome.org/browse/gtk-osx/tree/modulesets-unstable/gtk-osx.modules#n85

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

Re: RFC: GtkPreview library

[Philip Chimento]

On Thu, Jan 29, 2015 at 6:58 PM, Paul Davis p...@linuxaudiosystems.com
wrote:

 On Thu, Jan 29, 2015 at 7:34 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

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


 Its a fine point. But consider the perspective of a GTK developer who
 comes across GtkPreview and wants to write a cross-platform application
 using it. Embedding non-GTK widgets/views/thingdings inside GTK is still a
 bit of black art ... An almost identical argument can be made for the file
 browser and yet ...


Would it make sense instead to provide GtkPreviewer on all platforms, but
implement it in terms of each platform's native previewer? That's what app
developers would end up doing anyway if we considered it non-portable.
-- 
Philip
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: GtkPreview library

[Philip Chimento]

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

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

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

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

 I think you mean SCM_RIGHTS?

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

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

 S

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


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

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

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

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

Deprecated widgets on Stack Overflow [was: a new combo box]

[Philip Chimento]

On Tue, Dec 30, 2014 at 2:29 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 On Tue, Dec 30, 2014 at 2:26 AM, Philip Chimento 
 philip.chime...@gmail.com wrote:

 Assuming that questions on Stack Overflow are an approximate poll of what
 application authors do - many application authors go to the documentation
 and do exactly that. (And often don't bother to read any further - I've
 often enough seen questions about a deprecated widget such as GtkList which
 was selected purely based on its name.)


 We are getting a bit off the topic of the thread, but this is an
 interesting observation.

 Can you link to some examples of this? I would be curious why that is the
 case - i.e. which medium was used to consult the documentation, because on
 the website deprecated classes are quite clearly marked in a separate
 section at the bottom of the reference (
 https://developer.gnome.org/gtk3/unstable/).


Sure, I was curious about more substantiated data than just my own memory
:-)

I did searches on Stack Overflow for some widgets that were deprecated in
GTK 2, see some results below. It looks like in at least one case a
developer found an outdated GTK 1.x tutorial online and just ran with it.
In most other cases the widgets seem to have been picked for their names,
although it's hard to tell what the question askers were thinking exactly.
In one case someone asked why there were two widgets for the same thing,
having missed the deprecation warning completely.

 -
http://stackoverflow.com/questions/16159052/what-is-the-best-widget-with-gtk-for-chat-window-irc
 -
http://stackoverflow.com/questions/6801370/python-clist-widget-not-returning-expected-list-returns-only-the-first-characte
 -
http://stackoverflow.com/questions/27495030/rgtk2-gtkcombo-get-current-selected-text
 -
http://stackoverflow.com/questions/4404610/linux-and-gtk-gtkfileselection-vs-gtkfilechooserdialog
 - http://stackoverflow.com/questions/5012739/get-text-from-textbox-in-gtk
 - http://stackoverflow.com/questions/16586635/add-tooltip-to-gtkbutton
 - http://stackoverflow.com/questions/17390960/how-to-use-gtk-tree-error

Here are some more questions where the asker is aware the widget is
deprecated but wants to use it anyway or isn't sure what to use instead. Or
perhaps isn't sure why 'deprecated' is a bad thing, in the last link: I
know GtkList is deprecated and should be replaced with GtkTreeView +
GtkListStore. However, I do want to use GtkList in current situation since
GtkListStore is more complex.

 -
http://stackoverflow.com/questions/8162547/gtk-how-to-make-labels-as-buttons-sort-of-list
 -
http://stackoverflow.com/questions/1210602/how-to-make-a-multiple-select-list-box-in-ruby-glade-gtk-maybe-using-treeview
 -
http://stackoverflow.com/questions/18908756/use-what-instead-of-deprecated-gtk-clist
 -
http://stackoverflow.com/questions/2835693/multiple-selection-with-gtkcombo
 -
http://stackoverflow.com/questions/20122232/gtklistc-code-how-to-get-the-selection-of-a-gtklist

I would hazard a guess that most people don't load up the docs' index page,
but instead land on pages directly by googling - and so don't see the
Deprecated Widgets section. For example if I google gtk list widget a
GtkList tutorial page is the fourth result. [1] Although admittedly, that
doesn't explain why someone wouldn't click on one of the perfectly fine top
three results.

[1] http://www.pygtk.org/pygtktutorial/sec-gtklistexample.html

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

Re: a new combo box

[Philip Chimento]

On Sun, Dec 28, 2014 at 9:24 PM, Cosimo Cecchi cosi...@gnome.org wrote:

 On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
 stunned. Why should I use one instead of the other?


 I doubt application authors choose which widget to use by reading type
 names in API references;


Assuming that questions on Stack Overflow are an approximate poll of what
application authors do - many application authors go to the documentation
and do exactly that. (And often don't bother to read any further - I've
often enough seen questions about a deprecated widget such as GtkList which
was selected purely based on its name.)


 if you're following a style guide like the HIG, the recommendation will
 come from there.
 Other times you will want a widget that looks/works like one you've seen
 elsewhere, and the visual/behavioral difference will make it obvious why
 there are two different classes.


This also happens, though - people will post a screenshot and say What is
this widget? We could make the Widget Gallery page more discoverable in
the documentation in order to encourage this.

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

Re: [gtk-osx-devel] configure: error: Python module libxml2 is needed to run this package

[Philip Chimento]

On Tue, Dec 23, 2014 at 12:50 PM, Jim Charlton char...@gmail.com wrote:

 I am building gtk-osx on MAC Yosemite 10.10

 1. gtk-osx-build-setup.sh

 2. export PATH=$PATH:/Users/chartech/.local/bin

 3. Added lines

 checkoutroot = os.path.expanduser(/Applications/Drumroaster/gtk/
 Source/gtk)
 prefix = os.path.expanduser(/Applications/Drumroaster/gtk/inst)
 os.environ[ARCHFLAGS] = -arch x86_64

 to .jhbuildrc-custom as I want the installation in a non-standard location.

 4. jhbuild bootstrap
 5. alias jhbuild=PATH=/Applications/Drumroaster/gtk/inst/bin:$PATH
 jhbuild
 6. jhbuild build python
 7. jhbuild build meta-gtk-osx-bootstrap

 In step 7 I get a configure error while building itstool. configure:
 error: Python module libxml2 is needed to run this package

 I have run this sequence before on MAVERICKS (10.9.5) with no problem.
 Must be something about the way the python libs are being installed or used
 but I cannot figure it out.

 Any help would be appreciated.


You may need to set the PYTHONPATH environment variable to include
/Applications/Drumroaster/gtk/inst/lib/python2.7/site-packages (check that
there is a libxml2.py file there.)

Regards,
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Bison 3 and WebKit

[Philip Chimento]

On Mon, Dec 15, 2014 at 11:01 AM, John Ralls jra...@ceridwen.us wrote:


 On Dec 14, 2014, at 10:14 PM, Philip Chimento philip.chime...@gmail.com
 wrote:

 On Mon, Dec 8, 2014 at 8:15 PM, John Ralls jra...@ceridwen.us wrote:


  On Dec 8, 2014, at 3:37 PM, Philip Chimento philip.chime...@gmail.com
 wrote:
 
  On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us wrote:
  The upgrade of Bison to version 3 which you graciously provided breaks
 the WebKit build, which you also graciously provided. ISTR that you mumbled
 something about working on building a newer WebKit version. Are you?
 
  Yes! It's been a bit pre-empted by other stuff, but I am still working
 on building WebKit 2.4.7. What is it about Bison 3 that breaks the old
 build?

 [log]

 Moving ~/.local/bin/bison out of the way, so that it uses the one Apple
 ships (v.2.3), clears the problem.


 I've got something almost working for modulesets-stable on the
 update-webkit branch of ptomato/gtk-osx-build:
 https://github.com/ptomato/gtk-osx-build/tree/update-webkit

 There's one thing left I can't figure out. The build stalls while linking
 libWebCoreSVG.la. ranlib prints out reams of complaints about object files
 having no symbols, although, that seems to be normal in itself. Then it
 stalls at a point where the last two are repeats of the two before that:

 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o)
 has no symbols
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no
 symbols
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o)
 has no symbols
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no
 symbols

 And sits there for 25 minutes, maxing out one CPU - at that point I
 killed it. Restarting the build completed with no problem. If you wipe the
 source directory and build again from scratch, it stalls again. I'm curious
 if anyone else has this problem.

 Also, if you're waiting on this module to be buildable again, I can submit
 a pull request that only updates modulesets-stable while I work on the
 other two modulesets.


 Does using `make -j1` change anything?

 I’ll pull it and give it a try later today. If all else fails we can just
 disable SVG.

 I just deleted Bison 3 after bootstrapping, so it’s not holding anything
 up for me. That doesn’t help anyone who needs both gstreamer and WebKit,
 though. Maybe bison 2.7.1 would work for both.


-j1 did the trick - thank you for the suggestion!

I'd rather upgrade WebKit than downgrade Bison, although 2.7.1 would work
for gstreamer; it needs 2.4 or later.

Best,
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Bison 3 and WebKit

[Philip Chimento]

On Mon, Dec 8, 2014 at 8:15 PM, John Ralls jra...@ceridwen.us wrote:


  On Dec 8, 2014, at 3:37 PM, Philip Chimento philip.chime...@gmail.com
 wrote:
 
  On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us wrote:
  The upgrade of Bison to version 3 which you graciously provided breaks
 the WebKit build, which you also graciously provided. ISTR that you mumbled
 something about working on building a newer WebKit version. Are you?
 
  Yes! It's been a bit pre-empted by other stuff, but I am still working
 on building WebKit 2.4.7. What is it about Bison 3 that breaks the old
 build?

[log]

 Moving ~/.local/bin/bison out of the way, so that it uses the one Apple
 ships (v.2.3), clears the problem.


I've got something almost working for modulesets-stable on the
update-webkit branch of ptomato/gtk-osx-build:
https://github.com/ptomato/gtk-osx-build/tree/update-webkit

There's one thing left I can't figure out. The build stalls while linking
libWebCoreSVG.la. ranlib prints out reams of complaints about object files
having no symbols, although, that seems to be normal in itself. Then it
stalls at a point where the last two are repeats of the two before that:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o)
has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no
symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o)
has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no
symbols

And sits there for 25 minutes, maxing out one CPU - at that point I killed
it. Restarting the build completed with no problem. If you wipe the source
directory and build again from scratch, it stalls again. I'm curious if
anyone else has this problem.

Also, if you're waiting on this module to be buildable again, I can submit
a pull request that only updates modulesets-stable while I work on the
other two modulesets.

Best,
-- 
Philip
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Bison 3 and WebKit

[Philip Chimento]

On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us wrote:

 The upgrade of Bison to version 3 which you graciously provided breaks the
 WebKit build, which you also graciously provided. ISTR that you mumbled
 something about working on building a newer WebKit version. Are you?


Yes! It's been a bit pre-empted by other stuff, but I am still working on
building WebKit 2.4.7. What is it about Bison 3 that breaks the old build?

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

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

[Philip Chimento]

On Thu, Nov 20, 2014 at 3:31 AM, Emmanuele Bassi eba...@gmail.com wrote:

 hi;

 I'd like to point out that this is a build-time requirement for
 libepoxy only: if the app does not use GLX on the Apple X server, then
 the GLX code is never even loaded.

 it'd be nice to have a libepoxy build that does not require X11 on
 MacOS, but that would make it harder to have applications linking
 against libepoxy run on the X server on that platform. whether or not
 that is a long term strategy is a discussion worth having with Eric.


The officially supported way to build the GTK stack on OSX uses jhbuild,
and this is also how Gnome applications like Gedit build their app bundles
[1]. So building a stripped-down libepoxy shouldn't affect any other
applications who would want to use libepoxy's X11 capabilities outside of
the jhbuild environment.

I guess it's another story for those wanting to build GTK via Homebrew,
Macports, or other similar systems, though.

On 19 November 2014 08:10, Jasper St. Pierre jstpie...@mecheye.net wrote:
  Yeah, this is an unfortunate bug with libepoxy right now. There's a PR on
  GitHub if you want to see if that fixes it.
 
  https://github.com/anholt/libepoxy/pull/28


It did, thanks!


  All we can do is pressure Eric Anholt to merge it at this point.
 
  On Wed, Nov 19, 2014 at 12:03 AM, Philip Chimento
  philip.chime...@gmail.com wrote:
 
  On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi eba...@gmail.com
 wrote:
 
  hi all;
 
  I posted this on my blog, which is syndacated on Planet GNOME, but I
  thought about trying to reach out to more people by using the GTK+
  mailing list as well.
 
  GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and
  Wayland.
 
  if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're
  using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or
  3.x, then I'm asking you to help out with patches and testing the
  OpenGL support in the master branch of GTK+. we'd really like to have
  OpenGL support working on all the major backends in GDK by the time we
  release GTK+ 3.16.0, next February.
 
 
  I've started trying to build GTK master on OSX; looks like libepoxy is
 now
  a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that
  dependency? It seems to me that I shouldn't need X11 for the Quartz
 backend.


[1] http://blogs.gnome.org/jessevdk/2014/09/02/gedit-3-14-for-os-x-preview/

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

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

[Philip Chimento]

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

 hi all;

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

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

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


I've started trying to build GTK master on OSX; looks like libepoxy is now
a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that
dependency? It seems to me that I shouldn't need X11 for the Quartz backend.
-- 
Philip
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Intermediate children [was: Re: flow box]

[Philip Chimento]

On Mon, Sep 30, 2013 at 4:16 PM, Matthias Clasen
matthias.cla...@gmail.comwrote:

 On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom 
 trista...@openismus.com wrote:

   o gtk_flow_box_insert() or gtk_container_add() add an intermediate

 child, breaking the logical widget hierarchy.

 For most of the history of GTK+, one can rely on the logical
 hierarchy being preserved, i.e. adding a widget to a parent will
 always pass the 'gtk_widget_get_parent (child) == parent' check.

 Honestly I would be more comfortable with a policy where only a
 specific child type can be added to the flowbox. The GtkToolBar
 and GtkMenuShell apis are clearer by limiting what types of
 children can be added, without breaking the logical widget
 hierarchy.

 In any case, I think this is worth at least a mention in
 the gtk_container_add() documentation.


 This is following recent precedents - we are now automatically inserting
 viewports between a scrolled window and its child, and GtkListBox is
 automatically wrapping its children in GtkListBoxRow intermediaries.

 I agree that we should add some hints about this to the the
 gtk_container_add docs.


This may be a bit tangential to the flow box, but especially in light of
those recent precedents I think the requirement of
'gtk_widget_get_parent(child) == parent' should be relaxed... we had some
discussion about this a while ago in bug 699756 [1] but I never got around
to doing anything with it after that. I like Emmanuele's idea of a
has_child() vfunc in that bug's discussion though.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=699756

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

Re: win32-fixup.pl

[Philip Chimento]

On Sun, Feb 24, 2013 at 10:47 AM, John Emmas john...@tiscali.co.uk wrote:
 On 24/02/2013 08:34, John Emmas wrote:


 Can anyone tell me what the correct syntax is for running the script?  I
 tried perl win32-fixup.pl (without any command-line options) and although
 it did work, it only processed the first file in the list and then skipped
 the others.


 I realised what the problem was.  Here's the list of files to be processed:-


 process_file (config.h.win32);
 process_file (glibconfig.h.win32);
 process_file (glib/makefile.msc);
 process_file (glib/glib.rc);
 process_file (gmodule/makefile.msc);
 process_file (gmodule/gmodule.rc);
 process_file (gobject/makefile.msc);
 process_file (gobject/gobject.rc);
 process_file (gthread/makefile.msc);
 process_file (gthread/gthread.rc);
 process_file (tests/makefile.msc);

 The second one is wrong.  It should be:-

 process_file (glib/glibconfig.h.win32);

 After fixing that, it all works!  win32-fixup.pl is a useful little script.
 Congratulations to whoever thought of it.

Looks like it does the necessary substitutions that are usually done
by configure. I've never built GLib on win32, so the following is
just a wild guess -- but I'd guess this script is long out of date and
needs updating. For one thing, it sets the version number to 1.3.7,
from about 10 years ago -- neither current nor correct. That it is so
long out of date is an indication that you probably don't need to use
it, otherwise it would have been updated in the meantime.

In any case, look at the AC_SUBST and AC_CONFIG_FILES declarations in
configure.ac to make sure that the script performs the proper
substitutions with current values.

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

Re: runtime accel changes

[Philip Chimento]

On Thu, Sep 13, 2012 at 11:01 PM, Paul Davis p...@linuxaudiosystems.com wrote:

 On Thu, Sep 13, 2012 at 4:43 PM, Juan Pablo Ugarte
 juanpablouga...@gmail.com wrote:

 On Thu, 2012-09-13 at 06:22 +, Tristan Van Berkom wrote:
  From what I see... all one should *need* to do is specify the
  accelerator keys
  desired to trigger a given GtkAction and add that action to an action
  group
  (either with GtkBuilder constructs or with
  gtk_action_group_add_action_with_accel()).
 
  The fact that a GtkAccelGroup must be added to a GtkWindow... and that
  it must
  be referred to by the GtkActionGroup (need to set the
  property/relation somewhere)...
  is all a bit sub-par as an API (i.e. it's confusing, not obvious to
  figure out).
 
  So my basic question is... is there anything good about manually
  setting up these
  accel groups at all ? GIMP is an example of a multi-windowed application
  (and
  many apps can have a 'floating' editor for some purpose)... as it
  stands whenever
  you create an extra floating window that is not a temporal dialog, you
  must set
  the GtkAccelGroup manually also for those windows for accelerators to
  work
  while those windows have focus.
 
  GTK+ of course manages an internal list of the app's GtkWindows... I
  really dont
  see the reason why GtkAccelGroup couldnt just be completely automated...
  could we possibly just deprecate/eventually remove that from the
  (public) api ?

 I do not know about deprecating it, but we could definitely have a
 default accelerator group that gets set in every window and action group
 by default. This way actions will simply work and if for some reason you
 need a window with a different accel group you can always set it later.
 I like to keep common cases simple and special cases well special. :)


 fundamentally, what differs from window are the available actions. the fact
 the accels per window *might* be different is just a side-effect of this.
 therefore, action groups are the primary entity that needs to be attached to
 a window, not accel groups.

 since currently neither action nor accel groups permit sharing of actions or
 accels, both concepts are pretty useless in GTK right now. most applications
 end up with a single action group (semantically, anyway) and a single accel
 group. and if they don't they probably meant to :)

For accel groups I agree with you, but action groups are not useless.
For example you can have an action group that gets enabled/disabled
depending on whether something is on the clipboard (containing all
sorts of paste actions) or one that is only enabled when items are
selected (containing copy, cut, reformatting actions, etc.) I'm not
sure what you mean by semantically a single action group, but I don't
think that's it.
-- 
Philip
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ meetup at Guadec

[Philip Chimento]

On Sat, Jul 28, 2012 at 3:30 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 - We need to document how one extends GTK+ itself (eg how to create a
 new widget class), to make it easier for new people to get involved
 (I'll try to get this started)

I wrote a tutorial on extending GtkContainer in C
(http://ptomato.name/advanced-gtk-techniques/html/custom-container.html).
It's even current for 3.0. I wrote it for the advanced developer
rather than the new one, but perhaps you can recycle some of it.

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

Incorporating changes from bindings [was: Add GtkRadioGroup?]

[Philip Chimento]

On Sun, Oct 31, 2010 at 11:28, Alexander Larsson al...@redhat.com wrote:
 By the way, are there any other places where the java or C++ bindings do
 cleanup changes like this? Some may be interesting to push into the
 core now that we have the chance.

I'd propose adding gtk_builder_get_widget_derived(), based on a method
in gtkmm [1]. This would make it much easier to use Glade when
subclassing widgets.

[1] 
http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en
-- 
Philip Chimento
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Incorporating changes from bindings [was: Add GtkRadioGroup?]

[Philip Chimento]

On Wed, Nov 10, 2010 at 17:49, Tristan Van Berkom
trista...@openismus.com wrote:
 On Wed, 2010-11-10 at 17:16 +0100, Philip Chimento wrote:
 On Sun, Oct 31, 2010 at 11:28, Alexander Larsson al...@redhat.com wrote:
  By the way, are there any other places where the java or C++ bindings do
  cleanup changes like this? Some may be interesting to push into the
  core now that we have the chance.

 I'd propose adding gtk_builder_get_widget_derived(), based on a method
 in gtkmm [1]. This would make it much easier to use Glade when
 subclassing widgets.

 [1] 
 http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en

 I've been cooking up something that might be close to what that API
 describes (for some months actually a while back, I just need to dust
 off the code and possibly automate the creation of properties which
 refer to child widgets etc)

 The general idea is that GtkContainerClass itself allows one to define
 content using an assigned GtkBuilder xml at the class level,
 implementing classes are composite widgets and a project can be
 comprised of several or many composite widgets all defined by
 GtkBuilder xml, reusable, practical etc (i.e. the way IMO
 GtkBuilder should really be used ideally).

 I brought it up most recently here:
 http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00054.html

 And I would really like to land this stuff before 3.0 as well.

 Does that just about cover the use case ? or have I missed the point
 somehow ?

I think that covers it, although yours takes the concept much farther
than just porting that gtkmm function. I'm thinking of the common use
case of writing a MyAppMainWindow class that derives from GtkWindow.
The way it is now, in my_app_main_window_init() you open the ui file,
get the outermost non-toplevel widget from the builder (i.e. whatever
widget is contained by the window), gtk_container_add() that widget to
the window you're constructing, and then manually set all the
properties of the window that you would otherwise have set in Glade.

I'm not so fond of the gtkmm derived class having to have a certain
constructor either, but maybe this could be circumvented if the
derived class was required to implement GtkBuildable?
-- 
Philip Chimento
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Generic undo stack for GTK+

[Philip Chimento]

On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt bern...@gmx.de wrote:
 On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
 [...]
 Anyway, i don't see the value of adding it to GLib, as undo
 frameworks are only an abstraction, and users end-up doing the
 painfull job of implementing undo commands for every type of objects
 or actions they are putting in the stack or the tree.

 Aeh -- it's a container type. Of course no generic container type
 gets any application specialized functionality for free. Nobody claimed
 that.

 What it does get you is other things, for example

 [...]
 - You don't have to write the boring boiler-plate code yourself, which
  is likely to motivate application developers to actually offer undo
  in their applications.

I usually just lurk on this list, but the thought of not getting an
undo framework in GLib or GTK because of purity concerns is so
unbearable that I simply had to post. Yes, having an undo framework
would definitely motivate me to provide proper undo in my application.
Right now the undo that I offer is just what GtkSourceView provides,
so it only applies to typing text even though there are other actions
in the application that should be able to be undone.

What's more, I have been actively postponing writing a solution for
this because of the noises that I occasionally hear about adding an
undo framework. I don't want to implement it myself only to find out
later that GTK applications using the standard undo framework will
behave subtly differently.

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

GtkTextBuffer serialization/deserialization into Rich Text Format

[Philip Chimento]

Hi developers,

I've written a library that includes GtkTextBuffer
serialization/deserialization functions for Rich Text Format. I have
just released the first public version. I'd be willing to work with
somebody on converting the RTF functionality into a patch for GTK if
you're interested.

You can get the source code here: https://sourceforge.net/projects/osxcart/

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