DhCompletion, a GCompletion replacement

[Sébastien Wilmet]

Hi,

Just a small announce, I've implemented recently a replacement for
GCompletion in Devhelp. GCompletion is deprecated, but for some
applications it's still useful to have a string completion utility.

https://git.gnome.org/browse/devhelp/tree/src/dh-completion.h
https://git.gnome.org/browse/devhelp/tree/src/dh-completion.c

It's unit-tested and documented with gtk-doc. The API is a little
different, but better suits the needs of Devhelp. It uses a GSequence
internally (instead of a simple GList in GCompletion).

Feel free to copy the code in your project ;-)

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

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

[Sébastien Wilmet]

On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> I know this may sound harsh, but: If you want things to work differently,
> send patches.
> Patches to the migration guide are welcome too.
> 
> The bulk of the work done on GTK4 so far has been done by 3 or 4 people,
> only one of
> which gets payed to work fulltime on GTK+.
> 
> Maintaining compatibility layers costs and constantly gets in the way of
> large-scale
> refactorings like the ones that are happening in gtk 3.9x now.
> 
> Note that we haven't really asked application developers to port to the
> current 3.9x releases
> yet, because they are still in flux.

About the cost of compatibility layers, it reminds me an economics
principle with game theory and cooperation, for example with the
prisoner's dilemma:
https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner's_dilemma

With cooperation and compatibility layers in GTK, GTK would move forward
less quickly, but it would maybe yield a better outcome globally when
taking into account higher-level libraries and applications.

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

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

[Sébastien Wilmet]

On Thu, Dec 14, 2017 at 08:34:51PM +, Emmanuele Bassi wrote:
> On 14 December 2017 at 18:42, Sébastien Wilmet <swil...@gnome.org> wrote:
> > A recent example:
> > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> > "gtk: Remove GtkClipboard"
> >
> > The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> > in GTK+ 3.22, and the new API is not available in GDK 3.22.
> 
> The new API just landed; and, yes: it's hard to deprecate the API in
> this case, given that the new API has been moved down one level in the
> hierarchy.

GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard
still worked fine just before the commit that removed it, it would have
been possible to first deprecate GtkClipboard and then removing it in
3.9x+2 (see my comment below).

Of course if GtkClipboard didn't work anymore, then it needed to be
removed. Or maybe it was possible to port GtkClipboard to the new GDK
API, but this would have been more work for the GTK developers. It all
depends if you want to provide a smooth experience to port apps.

> Doing this work in 5 years, for GTK+ 5.0,
> would not have been any easier for anybody.

I don't understand why you say that. Each semi-stable 3.9x version can
be seen as a new major version, since it's possible to break the API. So
an API can be marked as deprecated in 3.92 and then removed in 3.94.
Instead of doing a direct API break. This would make it easier to port
applications.

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

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

[Sébastien Wilmet]

On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote:
> On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
> > 
> 
> > With "soft API breaks" (i.e. just removing an API that was deprecated
> > in
> > a previous major version), I think this would improve a lot the
> > situation and would avoid to repeat the same problem as GTK+ 2 -> 3.
> 
> It already exists. Look at the "DISABLE_DEPRECATED" macros in the
> current version of libraries, and which usually get removed in the +1
> version.

Yes, it's a nice feature, but it doesn't solve the problem that there
are a lot of direct API breaks during GTK+ 3.9x development.

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

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

[Sébastien Wilmet]

On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote:
> On 12/13/2017 04:05 AM, Sébastien Wilmet wrote:
> > Can I remind you that most of the biggest GTK+ apps are still using
> > GTK+ 2? MonoDevelop, GIMP, Ardour, …
> 
> MonoDevelop is still Gtk2 because Novell/Xamarin/Unity3d invested, quite
> literally, millions of dollars on consultants to work on the OS X port
> (without much interest in paying additional money to have that work
> upstream'd or ported to Gtk3). Add to that the necessity to write new
> bindings around G-I for Gtk♯ 3 and you can get the idea of how they see
> that as risk from a business standpoint.
> 
> Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
> and you cannot mix both into the same process space. DAW authors will
> often cite the necessity for plugins to be in process to allow for a
> large number of tracks/plugins due to context switching. (This is a
> contributing factor to why many DAWs write their own UI toolkits).

Thanks for that information, I was not aware of those problems.

> As for GIMP, I think the lesson I take away is that we need to recruit
> people to go do the ports for important projects rather than expect them to
> track us. Red Hat has shown that this strategy works in both Firefox and
> LibreOffice (which are arguably the two hardest applications to port).

The question is: why don't they do the port to GTK+ 3 "themselves"?
Because it's hard, you say it yourself in case of Firefox and
LibreOffice. With the GTK+ 2 -> 3 transition, there are a lot of "direct
API breaks". With GTK+ 3 -> 4, the same is happening. Lots of direct API
breaks at once, that's what makes it hard to port an application or a
higher-level library. For 10k lines of code, it's entirely feasible. For
100k lines, it's feasible by a full-time employee. For an application
the size of MonoDevelop, this is just unmanageable IMHO.

With "soft API breaks" (i.e. just removing an API that was deprecated in
a previous major version), I think this would improve a lot the
situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

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

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

[Sébastien Wilmet]

On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote:
> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

No, that's not true.

A recent example:
https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
"gtk: Remove GtkClipboard"

The clipboard is now implemented in GDK. GtkClipboard is not deprecated
in GTK+ 3.22, and the new API is not available in GDK 3.22.

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

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

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

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

[Sébastien Wilmet]

Hi,

I'm a bit worried about how GTK+ 4 is developed. It seems that there
will be a lot of API breaks that will require to adapt the code at once.

Ideally, a new major version of a library should only remove deprecated
APIs. It's how a library should be developed, in case the developers
want to get rid of old APIs: 1. New APIs are added. 2. Old APIs are
marked as deprecated (but still work). 3. In the next major version,
deprecated APIs are removed.

Why is it a good practice to follow that approach? Because developers
using the library can port their code to the new APIs *incrementally*.
The deprecated APIs still work, so the code can be ported to the new
APIs, one step at a time, by writing small and testable commits (for
each commit, the code can be compiled, running the unit tests, testing
the GUI, etc). Not with one huge commit/branch, untestable until all the
code is ported.

It is more work for the library developers to keep the deprecated APIs
still working, but it provides a much smoother experience for all the
developers using the library (and in case of GTK+, there are a lot of
users). Can I remind you that most of the biggest GTK+ apps are still
using GTK+ 2? MonoDevelop, GIMP, Ardour, …

With the new model of GTK+ development, each stable GTK+ 3.9x version
can be seen as a new major version, so that developers can port their
code to 3.90, then 3.92, etc (if those versions are in a sufficiently
usable state). But currently, with how those versions are developed,
it'll be quite hard to port the code, the same as the GTK+ 2 -> 3
transition, because there are direct API breaks instead of just removing
deprecated APIs.

So, that's it, I think when GTK+ 4.0 will be released, if it is still
developed in the same way, developers will have a really bad surprise
when trying to port their code. At least 2 years worth of direct API
breaks… GTK+ 4 will probably be awesome for writing new applications,
but it'll probably be a different story for developers wanting to port
their code from GTK+ 3.

GTK+ 3 was criticized for being a bit unstable. But that was not the
root of the problem IMHO, the root of the problem is that there are
direct API breaks (and for GTK+ 3, the CSS was not sufficiently
advertised as having an unstable API; it's fine to have unstable APIs in
a library, but there must be big warnings in the documentation).

My 2 cents,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_object_ref() now propagates types

[Sébastien Wilmet]

On Fri, Dec 08, 2017 at 11:26:31AM +, Philip Withnall wrote:
> Note that the new behaviour requires GCC, and is only enabled if you
> have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56.

If GLIB_VERSION_MAX_ALLOWED is not defined, does it take by default the
value of the last GLib version?

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

Re: Gtk+4.x and broadway ( and other remote options )

[Sébastien Wilmet]

On Thu, Dec 07, 2017 at 08:57:46AM +0100, Alexander Larsson wrote:
> Maybe someone else is interested in consulting work on it though?

There is a list of consultancy partners here:
https://www.gtk.org/support.php
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GApplication process uniqueness, saving config files and multi-seat support

[Sébastien Wilmet]

On Mon, Sep 11, 2017 at 02:25:43PM +0200, Bastien Nocera wrote:
> As a general rule, we don't support being logged in to the same account
> on 2 different seats, whether they share the same physical machine, or
> just the backing storage.
> 
> On physical machines, this is enforced by gdm, and a shared user D-Bus, 
> which mimicks the old session bus.
> 
> In short, not something to worry about.

OK, thanks for the info.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Catalog of GObject-specific design patterns?

[Sébastien Wilmet]

On Sun, Aug 13, 2017 at 01:20:14PM +0200, Joël Krähemann wrote:
> The AgsApplicationContext acts as a base entry point to your
> application. It is an extensible singleton
> where functions are added by interfaces.
> 
> In order to use libags-thread.so.0 you have to implement
> AgsConcurrencyProvider provider in your application context.
> 
> Likewise for libags-audio.so.0 you have to implement
> AgsConcurrencyProvider provider and AgsSoundProvider because
> it depends on thread routines.
> 
> Both library use the very same base class but you can use
> libags-thread.so.0 without ever knowing about audio. Here are
> some implementations:
> 
> * AgsXorgApplicationContext
> * AgsAudioApplicationContext
> * AgsServerApplicationContext
> 
> The advantage of having a application context is you can provide your
> very own extensions and you just have to derivate
> AgsApplicationContext and implement wished interfaces.
> 
> There is another interface in development AgsServiceProvider if you do
> J2EE you might have seen such as using
> Spring.
> 
> AgsRecallFactory is an advanced factory pattern as you put in a string
> you get a list of objects back. It does instantiate
> AgsRecall sub-types you can view it as a kind of effect processor.
> 
> Managers are singletons, too. They usually keep track of objects. In
> general you can add, remove and lookup objects of it.
> It is really common to use hashmaps in its implementation.

Now I better understand, thanks for the explanations.

--
Sébastien

> On Sun, Aug 13, 2017 at 12:33 PM, Sébastien Wilmet <swil...@gnome.org> wrote:
> > On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
> >> I use some patterns like:
> >>
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
> >> ...
> >>
> >> Or having an application context:
> >>
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
> >> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h
> >
> > Can you describe a little those patterns? What are the intents?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Catalog of GObject-specific design patterns?

[Sébastien Wilmet]

On Thu, Aug 10, 2017 at 02:39:12PM +0200, Joël Krähemann wrote:
> I use some patterns like:
> 
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_recall_factory.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/plugin/ags_lv2_manager.h
> ...
> 
> Or having an application context:
> 
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/ags_xorg_application_context.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_concurrency_provider.h
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_sound_provider.h

Can you describe a little those patterns? What are the intents?

> But what GObject makes really special are it's properties and events.

Yes for example the Observer design pattern is implemented in a simpler
way with GObject signals. But the intent remains the same.

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

Re: Building glib-genmarshal (while building glib)

[Sébastien Wilmet]

On Sat, Aug 12, 2017 at 01:54:29PM +0100, John Emmas wrote:
> What's happened to 'glib-genmarshal.c'?  It seems to have been removed from
> git master - although (AFAICT) it doesn't get auto-generated.  A new file
> does get generated (gobject/glib-genmarshal) but i can't see how that gets
> used to generate glib-genmarshal.c..  What am I missing??  (I'm building on
> Windows BTW).

>From the news file for version 2.53.4:

https://git.gnome.org/browse/glib/tree/NEWS

* glib-genmarshal and glib-mkenums have been rewritten in python.
  Every effort has been made to keep compatibility. Please report
  problems related to these tools

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

Re: Catalog of GObject-specific design patterns?

[Sébastien Wilmet]

On Fri, Aug 11, 2017 at 09:16:32AM +0700, Arnaud wrote:
> As for using the `g_object_set_data()` like you do, it's something I
> always tried to stay away from, because it seems to me that everything
> becomes possible with that, and there's probably plenty of mistakes to
> be made ;) On the other hand, there must be some situations where it's
> the only solution. I'd be curious to know what the old-timers think
> about it, when to use it and when to avoid it.

A bad example in Devhelp:
https://git.gnome.org/browse/devhelp/tree/src/dh-window.c?h=3.25.2#n1357

The function creates a new tab and appends it to the GtkNotebook. vbox
is the content of the tab, which contains web_view and info_bar. In
other DhWindow functions, we have access to the GtkNotebook, but from
the GtkNotebook we have access only to the vbox. So with the vbox we can
call g_object_get_data() to get the web_view and info_bar.

This is a typical example where it is better to create a new class:
called for example DhTab, a subclass of GtkBox or GtkGrid. The web_view
and info_bar are simply stored as instance variables in DhTab. This
would also have the nice benefit to have less code in DhWindow, because
DhWindow would delegate some of its work to DhTab.

For other use-cases, creating a subclass is a too heavy solution, or
sometimes creating a subclass is even not possible/desirable as I
explained in my blog post.

An example where creating a subclass would be a too heavy solution: to
implement a context/right-click menu, attaching some information to menu
items, so when the ::activate signal is called we have the required info
to implement the action. For instance for spell-checking: the context
menu to choose another word:
https://git.gnome.org/browse/gspell/tree/gspell/gspell-context-menu.c?h=1.5.3#n258

> At last, I take this opportunity to share my bookmark post on GObject. I
> collected all the interesting bits I found on the Net while learning
> from zero, plus added some personal thoughts, and in the end it's just a
> mess, but learners might find interesting bits there, who knows.
> 
> https://github.com/elboulangero/goodvibes/wiki/GObject-Introduction

I've written also a small intro to GObject here:
https://people.gnome.org/~swilmet/glib-gtk-book/

But not how to subclass GObject, just how to *use* an existing GObject
class.

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

Catalog of GObject-specific design patterns?

[Sébastien Wilmet]

Hi,

I've documented my first GObject design pattern:
https://blogs.gnome.org/swilmet/2017/08/09/gobject-design-pattern-attached-class-extension/

Question to the old-timers: do you know any other GObject-specific
design pattern? Not applying the classic design patterns with GObject,
I'm talking here about new design patterns that use GObject features
that are not necessarily present in other object systems.

Or am I the first to write about a GObject-specific design pattern?

Thanks,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Amtk - Actions, Menus and Toolbars Kit for GTK+

[Sébastien Wilmet]

Hi,

You're maybe not aware of the problem, but the GtkUIManager deprecation
is really painful for developers who want to keep a traditional UI for
their application.

See all the work that I've done recently in the Amtk library (3000 lines
of code, and some features are still missing):
https://blogs.gnome.org/swilmet/2017/07/20/amtk-actions-menus-and-toolbars-kit-for-gtk/

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

Re: GTK+ 4: knowing the action/event at the origin of a text insertion/deletion?

[Sébastien Wilmet]

On Sat, Jul 08, 2017 at 10:08:56AM +0200, Timm Bäder wrote:
> On 07.07, Sébastien Wilmet wrote:
> > But heuristics are not ideal of course. Will the input handling rework
> > in GTK+ 4 support that use-case?
> 
> As far as I know, the input rework so far only touches pointer input and
> has nothing to do with keyboard input at all. I'm not sure what Carlos
> and/or Christian have planned and what they will actually implement
> though.

OK, thanks for your reply.

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

GTK+ 4: knowing the action/event at the origin of a text insertion/deletion?

[Sébastien Wilmet]

Hi,

With the plans for GTK+ 4, I wonder if it'll solve the following
use-case.

Knowing where does a text insertion/deletion come from. In GtkTextView
and GtkEntry. Is it a key press? Is it a cut/paste/…? Is it done
programmatically? Etc.

Because currently with GTK+ 3 there are heuristics in GtkSourceView (for
the undo/redo) and gspell (to not underline the word currently typed) to
know whether a text insertion/deletion is a simple key press. If the
inserted/deleted text is only one character at the cursor position, it
assumes that it was a key press.

For example in GtkSourceView for the undo/redo:
https://git.gnome.org/browse/gtksourceview/tree/gtksourceview/gtksourceundomanagerdefault.c?h=3.24.3#n42

But heuristics are not ideal of course. Will the input handling rework
in GTK+ 4 support that use-case?

Thanks,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Licensing

[Sébastien Wilmet]

On Sun, May 28, 2017 at 05:38:26PM +0100, John Emmas via gtk-devel-list wrote:
> On 28/05/2017 14:41, Sébastien Wilmet wrote:
> > On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list 
> > wrote:
> > > the following 11 header files stipulate GPL:-
> > > 
> > >gbase64.h
> > >gbookmarkfile.h
> > >gchecksum.h
> > >ghmac.h
> > >glib-private.h
> > >glib-unix.h
> > >gmain.h
> > >gmain-internal.h
> > >gmessages-private.h
> > >goption.h
> > >gpoll.h
> > > 
> > > Just thought I'd flag it up in case it's unintentional,
> > I've checked the 3 first files that you list, and they are correctly
> > licensed under the LGPL (up until recently it was the "GNU Library
> > General Public License", it's now the "GNU Lesser General Public
> > License").
> > 
> > Please double check the list.
> 
> I updated from git master just now and the above files are all okay now.
> However, in the latest stable branch (glib-2-52 ?) they're still showing the
> older licenses.

gbase64.h on glib-2-52 has the LGPLv2+ license, there is nothing wrong
with that.

See: https://www.gnu.org/licenses/old-licenses/old-licenses.html#LGPL

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

Re: Licensing

[Sébastien Wilmet]

On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list wrote:
> Hi guys - whilst checking something else this morning I came across an
> anomaly in the licensing mechanism for glib / gtk+ etc.
> 
> The vast majority of the header files state that it's LGPL.  But
> occasionally there are GPL headers here and there.  For example in glib-2,
> the following 11 header files stipulate GPL:-
> 
>   gbase64.h
>   gbookmarkfile.h
>   gchecksum.h
>   ghmac.h
>   glib-private.h
>   glib-unix.h
>   gmain.h
>   gmain-internal.h
>   gmessages-private.h
>   goption.h
>   gpoll.h
> 
> Just thought I'd flag it up in case it's unintentional,

I've checked the 3 first files that you list, and they are correctly
licensed under the LGPL (up until recently it was the "GNU Library
General Public License", it's now the "GNU Lesser General Public
License").

Please double check the list.

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

Re: What does "(skip)" mean ???

[Sébastien Wilmet]

Hi,

Replying only to the mail subject:

It's a GObject Introspection annotation !!!

https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations

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

Re: gio enhancement.

[Sébastien Wilmet]

Hi,

On Thu, Apr 13, 2017 at 10:14:08AM +0200, Bruggemann Eddie wrote:
> Or For multimedia files (Video, Music, Image) providing a way to access the
> meta-data:
> 
> in a type like this:
> 
> GMediaFileInfo
> 
> ---
> 
> Else because Gtk has a library for the font (pango) for drawing (cairo) for
> images (gdk_pixbuf), and so on...
> 
> Why not get a library for playing sounds ?

GStreamer [1] can be used for media files metadata and for playing
sounds. For image metadata, I don't know, but you can look at the code
of eog [2] for example to see how it retrieves the image properties.

[1] https://gstreamer.freedesktop.org/
[2] https://wiki.gnome.org/Apps/EyeOfGnome

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

Re: Migrating from GTK+ 2.x to GTK+ 3

[Sébastien Wilmet]

Hi,

On Tue, Feb 14, 2017 at 12:25:32PM +, Rúben Rodrigues wrote:
> i'm new on Linux and gtk+. I'm trying to migrate an application make
> with gtk+2.0, and i'm following this tutorial
> https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

There is also this guide that may be useful:
https://developer.gnome.org/Gnome3PortingGuide/

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

Re: Moving to glade and GtkInspector

[Sébastien Wilmet]

Hi,

On Mon, Apr 03, 2017 at 01:29:01AM -0400, Martin Owens wrote:
> I'm brining this up in devel mailing list because it might not be
> possible to do well enough, but I'm interested in raising the question
> of moving projects from widget code to glade ui files.
> 
> I work on Inkscape. The next version of Inkscape (0.93) will be Gtk3
> and Gtk2 is now removed from our codebase. But we're still generating
> all of our widget trees in-code and is kinda hurts redesigning our
> dialogs.
> 
> Is it worth moving to glade for parts of a large gtk3 app, does it help
> with css adjustments at all and would it be an acceptable patch to make
> the gtkinspector dump out our existing widget trees (it would be really
> nice to have it generate glade xml, but that's just silly right). At
> least getting the data out of the inspector and into a python script
> for generating the xml would be a start.
> 
> Any ideas, or thoughts?

Glade is not well maintained, some developers prefer to edit the XML
files directly, which is not really convenient.

At least by writing C/C++ code, you have compilation warnings when using
deprecated functions. Personally I prefer writing code instead of using
GtkBuilder, but that's just my preference. With code it's easy to write
re-usable functions, in XML files it is not possible.

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

Re: Versioning and long term stability promise in GTK+

[Sébastien Wilmet]

On Mon, Jan 30, 2017 at 11:17:55AM +, Emmanuele Bassi wrote:
> On 29 January 2017 at 10:00, Sébastien Wilmet <swil...@gnome.org> wrote:
> > On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote:
> >> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
> >
> > In the above announcement, you've written:
> 
> I didn't write it, but since I reviewed it, let's assume I did.

(By "you" I was using the plural form, the GTK+ team, not you
specifically, I know it was written/reviewed by several people ;)

> > More details about these plans, including specifics for library
> > developers and distribution packagers, will follow in subsequent
> > blog posts.
> >
> > Those subsequent blog posts have not yet been posted. If you've written
> > that, it probably means that you wanted to explain more things.
> 
> Not really. That paragraph means: "other libraries will explain their
> own plans once they decide them, and if the maintainers of those
> libraries wish to share them through the GTK development blog, we will
> publish them here". Since no other library has published their
> intentions, or contacted the GTK team about those, we're still
> waiting. I know that you sent your plans for GtkSourceView to
> desktop-devel-list and to your blog, for instance.

Mmh I might have read the sentence wrong. "for library developers", I
understand it as "for developers like me who develop GtkSourceView", not
"for application developers who use higher-level libraries".

> > For a higher-level library based on GTK+, a GTK+ API break can force an
> > API break in the higher-level library. So during the GTK+ 3.9x versions,
> > the higher-level library cannot really guarantee API stability.
> 
> They can guarantee API stability in the same way GTK+ does — with API
> that changes throughout the .9x minor releases, but not between micro
> releases, and bump the soname every time the ABI changes.
> 
> > Normally, each time there is an API break, the Libtool version must be
> > bumped (increment CURRENT, set REVISION to 0 and set AGE to 0). Is that
> > all there is to know about handling API instability in higher-level
> > libraries? Maybe you have other things in mind.
> 
> That's the idea behind the soname bump that we are using in GTK+ x.9y cycles"
> 
> | Each of these minor versions will bump the soname of the shared library,
> | to ensure that automated tools can pick up the eventual changes and notify
> | distributors and maintainers.
> 
> We're going to reset the soname every time we do a new .9x minor
> release; this is enough to cause any application and library that
> depends on GTK+ to be rebuilt, and allows distributions to change the
> package name.

Maybe another thing to explain to higher-level library developers, even
if it looks obvious: using the same minor versions: 89 (unstable), 90
(semi-stable), 91, etc. So that there is some kind of consistency
between libraries, even if the major version is not the same.

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

Re: Versioning and long term stability promise in GTK+

[Sébastien Wilmet]

On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote:
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

In the above announcement, you've written:

More details about these plans, including specifics for library
developers and distribution packagers, will follow in subsequent
blog posts.

Those subsequent blog posts have not yet been posted. If you've written
that, it probably means that you wanted to explain more things.

For a higher-level library based on GTK+, a GTK+ API break can force an
API break in the higher-level library. So during the GTK+ 3.9x versions,
the higher-level library cannot really guarantee API stability.
Normally, each time there is an API break, the Libtool version must be
bumped (increment CURRENT, set REVISION to 0 and set AGE to 0). Is that
all there is to know about handling API instability in higher-level
libraries? Maybe you have other things in mind.

Thanks,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_text_iter_forward_search() comparison

[Sébastien Wilmet]

On Sat, Jan 28, 2017 at 07:16:04PM -0500, Eric Cashon via gtk-devel-list wrote:
> I have been working on a little search experimentation. Gave writing a
> case in-sensitive gtk_text_iter_forward_search() a try. The code is
> shorter than what is in gtktextiter.c and it works a little faster. If
> a word is searched that isn't very frequent the time is about the
> same. If you just look for single chars or words that are frequent it
> looks to be quicker.

Is the performance of gtk_text_iter_forward_search() a problem for your
application? Or you just wanted to play a little with the code?

(Side note: GtkSourceView has a higher-level API for the search and
replace, with regex support. If you're working on the search and replace
for an application, this is worth a look.)

> Not sure if this a suitable method though. I know
> little of the textbuffer internals. UTF-8 gives me some trouble also.

This doesn't give us confidence in your code. Bug-free code is more
important than better performance at the cost of UTF-8-related bugs.

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

Re: Contributing

[Sébastien Wilmet]

On Tue, Jan 03, 2017 at 09:19:00PM +0200, Panagiotis Follas wrote:
> Have you already written an application in GTK+? No. Yes I would like.
> Have you already written a library based on GLib/GTK+? No. But I would like.
> 
> I have half read the book "Foundations of GTK+ Development" and I tried to
> start my very first steps by compiling gtk on windows with vs2013. Wall.
> No clear instruction and some are not updated or are very old. I would like
>  to help and update those instructions for a start. I am a quick learner.
> But I need some help with someone that has compiled gtk with visual studio.
> 
> I have worked with a lot of open source libraries (Ogre3d, wxWidgets) or
> use a lot of open source programs and I would like to start giving back.

OK. I've started to write a new "book" (but we cannot call that a book
yet):
https://people.gnome.org/~swilmet/glib-gtk-book/

For Windows, some links:
https://www.gtk.org/download/windows.php
https://blogs.gnome.org/nacho/

The gtk.org website is developed in this git repository:
https://git.gnome.org//browse/gtk-web/

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

Re: Contributing

[Sébastien Wilmet]

On Tue, Jan 03, 2017 at 08:19:49PM +0200, Panagiotis Follas wrote:
> I am developer, and I would like to contribute to gtk development. But
> first I would like some guidance.
> I can code on windows 7 platform. Like where to start and how.

See:
http://ometer.com/hacking.html

Have you already written an application in GTK+? Have you already
written a library based on GLib/GTK+?

Just find a bug that annoys you, see if it's already filed in bugzilla,
and try to fix it.

As a general rule of thumb for free software, look at the HACKING file
to see how to contribute (there is usually also a README file which
refers to the HACKING file, so… read the docs!).

If you attach a patch to the bugzilla, sometimes it takes a while before
getting a response. If you don't have any feedback, a solution is to ask
on IRC.

Happy hacking,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Sébastien Wilmet]

On Thu, Dec 29, 2016 at 11:55:35PM +0100, Stefan Sauer wrote:
> Sorry for reviving the thread. What if upstream lib ship a suppression
> file and add a pkg-config variable pointing to it? Then apps can use
> $PKG_CONFIG --variable=valgrind_suppressions gtk+-3.0
> to collect those and e.g. export them into a valgrind wrapper or use
> them in the test runners.

Things are moving, see this recent glib commit:
https://git.gnome.org/browse/glib/commit/?id=a24f57b071758b01500e2b4b9c05d2a60f8280bf

"glib: Add installed Valgrind suppressions file for GLib and GIO"

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

Re: Gtk+4.x and broadway ( and other remote options )

[Sébastien Wilmet]

On Wed, Dec 07, 2016 at 02:18:24PM +1100, Daniel Kasak wrote:
> Another option, if the task is too large or difficult for me, is to
> either offer a bounty here, or to post a project on something like
> freelancer. I also realise that work done via freelancer would
> possibly be of questionable quality, and would quite possibly break
> with later gtk+ versions again. Any comments on this option?

See https://www.gtk.org/support.php

IMHO Igalia would be a good choice, since they have a lot of expertise
on web browser technologies (WebKitGTK+ and Epiphany among other
things).

> Another option would be another remote-desktop / remote-app
> capability. I've read a little on wayland / weston and RDP. I think
> RDP would be a reasonable option, though haven't managed to get it
> working yet.

There is also Waltham, a generic Wayland-style IPC over network, still
in development:
https://lists.freedesktop.org/archives/wayland-devel/2016-October/031413.html

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

Re: [RFC] Renaming the GtkSourceView namespace from GtkSource to Gsv

[Sébastien Wilmet]

On 10/20/2016 08:05 AM, Georges Basile Stavracas Neto wrote:
> My personal opinion is that it's a good move, even though it'll create
> some pain. Since the API itself won't change behavior-wise, adapting the
> code to the new change will be simple enough (a Search and Replace
> throughout the codebase will be enough, I think).

A script will be provided for C code, based on:
https://github.com/swilmet/gnome-c-utils

(to keep a good indentation/alignment of the code, assuming the code
aligns function parameters on the opening parenthesis).

For other languages, a sed s/GtkSource/Gsv/ should be enough.

In Vala it's different because Vala has changed GtkSource.[...] to
Gtk.Source[...]. So for example in Vala, GtkSourceView becomes
Gtk.SourceView. And if there is "using Gtk;" at the top of a file, then
what needs to be searched/replaced is "Source", which can result to more
false positives.

Anyway, an intermediary release/tarball will be provided, with the only
change being the namespace change (and maybe also removing the
deprecated API). Still using GTK+ 3. So that app developers can adapt
their code to the new Gsv namespace, and be able to compile/test the
code before porting to GTK+ 4 and GtkSourceView 4.

On Thu, Oct 20, 2016 at 12:12:54PM -0700, Christian Hergert wrote:
> It will certainly make it easier for me to stay within my ideal line width
> for some of the longer named functions. I don't mind a change to Gsv, that's
> what I think/type already when talking about the project.

Yes having shorter code is another advantage, though not the most
important to my eyes. When using GObject-based APIs, it is not rare to
end up with lines of 120 columns, even if there is only one indentation
level, with only one function parameter at the end of the line. This
happens e.g. when chaining-up to the parent vfunc. But 120 columns is
still OK IMHO. Of course 200 columns would be more problematic.

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

[RFC] Renaming the GtkSourceView namespace from GtkSource to Gsv

[Sébastien Wilmet]

Hi,

For GtkSourceView 3.90, there is a plan to rename the namespace from
GtkSource to Gsv:
https://bugzilla.gnome.org/show_bug.cgi?id=755752

Because the current namespace (GtkSource, or gtk_source in lowercase)
conflicts with the GTK+ one.

But I have never heard complaints from GTK+ developers.

So the question is: does it worth the big API churn? Or do you think it
is OK to continue using the GtkSource namespace?

Another element to take into account: GtkSourceView doesn't show the
good example, although it is a widespread library, so external
developers might create other libraries that also conflict with the Gtk
namespace. Example: GtkSpell.

PS: it is not me who created GtkSourceView, I started contributing much
later, so the namespace conflict isn't my fault, I prefer to clarify.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Sat, Sep 03, 2016 at 02:19:11PM +0100, Emmanuele Bassi wrote:
> On 3 September 2016 at 10:27, Sébastien Wilmet <swil...@gnome.org> wrote:
> 
> > The versioning looks much better. Small detail, during the next
> > development cycle, the alpha/beta/rc versions will be 3.89.x, with the
> > 3.90.0 version released in March 2017, right?
> 
> Starting at ".90" has a good round number feeling to it, and it makes
> it easier to spot the pattern — but we're still debating which minor
> version number will be assigned to the first development release of
> the cycle. We are reluctant to drop the invariant that the odd release
> numbers signal instability, so the first release in a development
> cycle would be .91, and the first "island of stability" following it 6
> months later would be .92, followed by the development cycle starting
> with .93, etc.:
> 
>   [ Development starts here ]
>   .91.0 → .91.n — development, dropping deprecated API
>   .92.0 → .92.n — partially stable
>   .93.0 → .93.n — development, with no strict blanket backward
> compatibility guarantee


Starting at .91/.92 permits a maximum of 2.5 years to reach 4.0, if the
numbers are kept in the 90's (otherwise it gets ugly with 3.100, 3.102,
etc).

Starting at .89/.90 would allow 3 years (2-3 years is what the
announcement says).

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

Re: Gtk+4.0

[Sébastien Wilmet]

To people who might have missed it:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

Some comments:

“While the GTK+ team reserves the right to change API during development
series, this does not mean that the whole GTK+ API will constantly break
each release; only specific, and hopefully rarely used parts of the API
may change, and if the changes are too extensive they will very likely
be delayed to the next major development cycle. We’ll ensure that these
changes are well-communicated in advance.”

As a maintainer of several GNOME libraries (doing it during my free
time), this reassures me.



The versioning looks much better. Small detail, during the next
development cycle, the alpha/beta/rc versions will be 3.89.x, with the
3.90.0 version released in March 2017, right?

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Wed, Aug 17, 2016 at 03:06:43PM +, Philipp A. wrote:
> Peter Weber  schrieb am Mo., 15. Aug. 2016 um
> 14:20 Uhr:
> 
> > Gtk is the GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work
> > inside Gtk it
> > could also named the GNU-Toolkit.
> >
> 
> is this a joke? GTK means “GIMP toolkit”. always has.


Don't read "Gtk is the GNOME-Toolkit" literally. It was meant to say
that GTK+ is developed mostly by GNOME developers, for the GNOME
desktop.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Mon, Aug 15, 2016 at 02:20:25PM +0200, Peter Weber wrote:
> I think breaking the API/ABI because of required changes, is right,
> breaking API/ABI because a fixed number of months has passed doesn't make
> much sense.

>From time to time, it is nice to get rid of deprecated APIs, to have
less code to maintain. GTK+ 3 has quite a lot of deprecated classes. So
getting rid of those, that alone is a good reason to release GTK+ 4, in
my opinion.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:
> On Sun, 14 Aug 2016 13:40:55 +0200
> Sébastien Wilmet <swil...@gnome.org> wrote:
> > When GTK+ breaks the API, it doesn't mean that a higher-level library
> > needs to break API too. For example, GtkTextView has a quite stable
> > API, so I think GtkSourceView will still have a stable API too, to
> > keep backward compatibility during GtkSourceView 4.
> 
> However, if your application depends on two GTK-based libraries, the
> developers for one of which proceed to adopt a development path using
> unstable GTK versions and one where they stick to stable, surely you
> are doomed?  Likewise if the two libraries decide to adopt different
> stable versions (not impossible with a two-year cycle for stable
> releases).

Yes, that's why it's more important for libraries to follow unstable
GTK. For apps, it's less important.

GtkSourceView will probably follow unstable GTK, while still trying to
keep the GtkSourceView 4 API stable.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote:
> 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.

Actually, I do not fully understand this. Can you extend a bit?

For example, imagine that GTK+ 4.0 and GtkSourceView 4.0 are released.
During the 4.1 development cycle, GTK+ breaks the API in a way that
forces GtkSourceView to also break its API. For the 4.2 release, both
GTK+ and GtkSourceView bump their SONAME.

Then in GtkSourceView, some bugfixes can be backported to the 4.0
version and new micro versions can be released, 4.0.3 etc. Exactly as it
is done now. GtkSourceView 4.0 and 4.2 are not separate libraries, it's
the same as 3.18 and 3.20, except that there is an API break between 4.0
and 4.2.

Another practical difference is that this might need several jhbuild
installations (the 4.0 installed in a certain prefix, the 4.2 in another
prefix), and switching between different jhbuildrc. I already do this
sometimes, for older versions.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 09:03:23AM -0400, Morten Welinder wrote:
> > When GTK+ breaks the API, it doesn't mean that a higher-level library
> > needs to break API too.
> 
> That depends.
> 
> You are right that a lot of API changes can be hidden.
> 
> But if the higher-level library has an API  that includes a type
> which is being removed, then the API will have to be
> changed.
> 
> And if your library depends on a feature that is being removed
> then your library probably cannot be saved with an API break.

Higher-level libraries can do their best to keep backward compatibility,
but when it is not possible, the higher-level library will also need to
bump the SONAME (without full parallel-installability for the headers
etc).

As long as the higher-level libraries communicate this clearly to their
users, I don't see it as a problem.

Of course a higher-level library developer can decide *not* to follow
GTK+ unstable, which forces some applications to also stay at GTK+
stable. Which can be a problem (the same problem with Python libraries
that are not yet ported to Python 3, so some programs are stuck at
Python 2).

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Sun, Aug 14, 2016 at 01:05:08PM +, Philipp A. wrote:
> I tried just to read and not ask anything but no amount of reading has
> resulted in any enlightenment, so:
> 
> Why not do what almost everyone does and have 4.X mean “stable” while
> anything with alpha/beta/pre/rc means unstable?
> 
> KDE made the same mistake with the exact same version number, i.e having
> the number look stable to everyone while the software was (as they clearly
> said everywhere!) a pre-release. People used it, distros shipped it, it was
> buggy and incomplete and everybody was confused and angry as a consequence.
> Was it simply lack of historic knowledge that led to the GTK-4.0 decision?
> 
> Besides, there's no gain in specifying some arbitrary minor version to be
> suddenly stable (as it was said GTK 4, “somewhere around 4.6” would
> become). There's exclusively a disadvantage, i.e. that you can't rely on
> common sense, convention, or any other kind of rule to know if that's a
> stable version. You have to know our look it up.
> 
> Just use http://semver.org and you have something that follows the
> principle of least surprise.

See:
https://wiki.gnome.org/Projects/GTK%2B/Lifecycle

Nothing is decided yet.

There is another proposal with even/odd major versions to distinguish
between stable/unstable.

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

Re: Gtk+4.0

[Sébastien Wilmet]

On Fri, Aug 12, 2016 at 04:19:30AM +, philip.chime...@gmail.com wrote:
> 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.

When GTK+ breaks the API, it doesn't mean that a higher-level library
needs to break API too. For example, GtkTextView has a quite stable API,
so I think GtkSourceView will still have a stable API too, to keep
backward compatibility during GtkSourceView 4.

> Did I forget anything?

It is expected that GNOME apps will follow the unstable GTK+ versions.
But some GNOME apps (or other libraries, for that matter) are developed
almost entirely by people contributing during their spare time. And the
amount of spare time/energy/willingness to maintain code can vary widely
between development cycles. This includes gedit. I'm not sure it is a
good idea for gedit to follow the unstable versions of GTK+.

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

Re: Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet]

On Tue, Aug 02, 2016 at 04:48:03PM -0700, Jasper St. Pierre wrote:
> What you miss is that GtkWidget already has container-like behaviors with
> gtk_widget_set_parent. In fact, the whole API has been awkward. GtkWidgets
> themselves can have children. GtkContainer is a "convention" interface for
> a way of manipulating an object that can have children. Not every widget
> that has children has to implement GtkContainer (though there *are* some
> features that won't work automatically, like drawing of children, since
> gtkwidget.c often has checks for GTK_IS_CONTAINER).
> 
> It makes sense to me to merge these two APIs so we don't have this
> impedance mismatch.

You should at least be aware that GtkWidget violates several OOP
best-practices, namely [1] :

1. A class must know what it contains, but it should never know who
contains it.

2. Derived classes must have knowledge of their base class by
definition, but base classes should not know anything about their
derived classes.

3. Classes should not contain more objects than a developer can fit in
his or her short-term memory. A favorite value for this number is six.

Those OOP best-practices are not there just to bother developers,
following them makes a code easier to understand, more maintainable,
etc.

But I think you, the GTK+ maintainers, know what you're doing, of
course.

--
Sébastien

[1] 
https://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet]

On Tue, Aug 02, 2016 at 07:57:04PM +0200, Sébastien Wilmet wrote:
> I see at:
> https://wiki.gnome.org/Hackfests/GTK2016/Day1
> 
> That there is maybe a plan to merge GtkContainer into GtkWidget.

More precisely, "Next step after that would be to make gadgets real
widgets and add them to their parent widget directly."

So the goal is: gadget == GtkWidget. Why would it be wrong to have
gadget == GtkContainer? I suppose that the problem at the source is this
one: how to implement a GtkWidget that (1) composes several other
widgets and (2) is a direct subclass of GtkWidget, to not expose that
the widget is implemented internally with a GtkGrid, for example.

If my supposition is correct, there is a clearer solution: have a
protected function gtk_widget_set_delegate (GtkWidget *delegate);
If priv->delegate != NULL, GtkWidget would delegate everything to
priv->delegate. A way to achieve this is with a macro like:

GET_PRIV(widget) (widget->priv->delegate != NULL
  ? widget->priv->delegate->priv : widget->priv)

So each time the widget accesses one of its instance variables, it
accesses the instance variable of the delegated widget if non NULL.

That way, it would be possible to use e.g. GtkGrid internally, without
exposing to the user which container is used (it's an implementation
detail).

And the various utility classes (gadgets) could be composed exactly how
we add e.g. a GtkScrolledWindow.

Or do I have a wrong idea of what would be a "gadget == GtkWidget"?

PS: sorry for my ramblings, but out of curiosity, I'm interested to know
more details about that gadgets plans.

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

Alternative to swallow GtkContainer into GtkWidget

[Sébastien Wilmet]

Hi,

I see at:
https://wiki.gnome.org/Hackfests/GTK2016/Day1

That there is maybe a plan to merge GtkContainer into GtkWidget.

>From a software engineering point of view, this looks like a bit scary
to me.

$ wc -l gtkwidget.c
17510 gtkwidget.c
$ wc -l gtkcontainer.c
3880 gtkcontainer.c

GtkWidget can already be considered a God Class.

GTK+ is not without bugs. It is already a challenge to maintain a good
stability for a project as big as GTK+. So IMHO the trend should be to
extract some code into new, smaller classes. When there are too many
instance variables, it is more complicated to work on the code and
ensure that what we change is correct. With small classes, we can be
more confident that the code is correct.

But I think you know well all of this.

So, instead of inheritance, the alternative is of course composition. A
GtkWidget could use internally a reference to a GtkContainer-like
utility object. And the real GtkContainer subclass could use the same
utility class internally. But using the GtkContainer utility by
composition would require a fair amount of boilerplate, when overriding
the GtkWidget vfuncs. But I'm sure there is a solution to have less
boilerplace. E.g. another utility class that is setup in class_init()
that handles the proxy to the internal container object.

Just my 2 cents, maybe it's a crack idea. But at least I've shared my
thoughts. I think it's possible to split out more classes, writing more
utilities to share code between widgets, and being able to implement new
widgets more easily. GtkEventController is a good example.

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

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Sébastien Wilmet]

On Tue, Aug 02, 2016 at 01:47:41PM +0100, Philip Withnall wrote:
> On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote:
> > So, is there an up-to-date Valgrind suppression file somewhere? Or is
> > GNOME.supp the most up-to-date?
> 
> The one I’ve been using is here:
> 
> https://github.com/pwithnall/walbottle/blob/master/libwalbottle/tests/w
> albottle.supp
> 
> It covers most of the GLib and GIO functionality which I’ve been using
> recently. Enough to get the Walbottle tests Valgrind-clean, at least.
> 
> I do not claim it’s anything like perfect though.

I already get much better results with walbottle.supp, at least for the
tests depending only on GLib/GObject. Thanks a lot!

> This has been discussed before, and I failed to do anything about it:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=666114#c28
> 
> Installing a suppression file with GLib won’t fix everything, because
> Valgrind only has one default suppression file, which we can’t modify
> or add to. So even if GLib installed a suppression file, you’d have to
> pass it as a --suppressions argument to Valgrind manually. However,
> that is better than having to write your own suppressions file //and//
> pass it in.
> 
> See here for information about default.supp:
> 
> https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto#Valgrind_and
> _suppression_files
> 
> Valgrind has a couple of bugs open about improving its support for
> default suppressions. None of them have seen activity recently:
> 
> https://bugs.kde.org/show_bug.cgi?id=93376
> https://bugs.kde.org/show_bug.cgi?id=160905 (basically a duplicate)

And thanks for the links. I also think that it would be useful to have a
suppression file upstream, even if it is incomplete.

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

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote:
> If there is a compelling advantage to splitting up libraries, of course,
> by all means do so.

I have an example: gspell:
https://wiki.gnome.org/Projects/gspell

The non-GUI parts could be implemented in GIO, with an extension point
to not hard-depend on Enchant. And the GUI parts could be implemented in
GTK+.

I created gspell as a separate library for a few reasons:

With a GIO extension point, a new library would anyway need to be
created. And I thought that dlopening a library was as bad for startup
time as a hard dependency. Now I know that a GIO extension point would
actually be slightly better.

Be able to iterate on the API more freely, and have something working
(and used in several apps) in less time. Now gspell-1 has a stable API,
but nothing prevents me from bumping to gspell-2 to break the API,
making the new major version parallel-installable. In GIO, it is not
possible.

Be the maintainer. If I wanted to integrate spell checking in GIO and
GTK+, I would still be busy with that project. With a separate library,
it was done in 6 months, working on and off on it (and part-time).

Having the code self-contained. Having all the spell-checking related
code in one repository. The biggest *.c file contains 1400 lines. Mixing
all that code in GtkTextView would make the code less clear, in my
opinion.

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

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 08:47:02PM +0200, Bastien Nocera wrote:
> Link it against gtk-3.0-wayland instead of both the x11 and wayland
> versions, and try again? My nautilus links against 25 X libraries, both
> the old-school versions and the xcb async versions. And to wayland libs
> as well as Wayland.

Yes by looking at the ldd output in more details, there is not a lot of
GNOME or GTK+ libraries.

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

Re: Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Wed, Jun 22, 2016 at 05:19:19PM +0100, Simon McVittie wrote:
> On 22/06/16 13:14, Sébastien Wilmet wrote:
> > Time for another Project Ridley?
> 
> Maybe; or maybe the benefit of those 30 extra libraries outweighs their
> cost (CPUs are faster now than in the GNOME 2 days after all), but we
> still shouldn't introduce more without good reasons.
> 
> If there is a compelling advantage to splitting up libraries, of course,
> by all means do so.
> 
> > And it doesn't count the dlopen'ed libraries, like for the GIO extension
> > points.
> 
> The application potentially has an opportunity to provide feedback to
> the user before it loads all of those, at least.
> 
> "Properly linked" hard dependencies seem likely to be a bigger issue for
> GUI responsiveness than dlopen'd modules and *their* dependencies,
> because we can't display anything (not even an empty window) until ld.so
> has finished thinking about the relocations for hard dependencies, and
> handed over control to main().

So, if someone wants to optimize application startup time, the features
that rely on a GIO extension point can be initialized later, after the
window is shown.

Or maybe some extension points could be replaced by swallowing the lib
into GIO.

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

Number of dynamically linked libraries (Was: Re: Gtk+4.0)

[Sébastien Wilmet]

On Tue, Jun 21, 2016 at 05:07:46PM +0100, Simon McVittie wrote:
> > 2. Add experimental features through external libraries (libsexy and so
> > on?)



> and linking a large number of tiny libraries has a measurable startup
> cost for applications.

https://blogs.gnome.org/alexl/2008/10/07/towards-a-ridley-based-platform/

"""
Before:

ldd `which nautilus` | wc -l
91

After:

ldd `which nautilus` | wc -l
60
"""

Now:

ldd `which nautilus` | wc -l
98

Time for another Project Ridley?

And it doesn't count the dlopen'ed libraries, like for the GIO extension
points.

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

Re: Developing a new text editor widget?

[Sébastien Wilmet]

On Wed, Jun 15, 2016 at 08:13:54AM -0400, Simon McVittie wrote:
> Monospace environments like terminals traditionally display æ, œ, … as
> a single character-cell: it isn't typographically correct, but neither
> is having m the same width as i, and we tolerate that in monospace.
> 
> The one use I'm aware of for characters that occupy more than one cell
> in monospace is that CJK writing systems have the concept of "fullwidth"
> character forms. which take up 2 adjacent cells.
> 
> 
> For instance, if you read this mail in monospace, these lines should
> line up exactly, even though in a proportional font they'd be very
> different lengths:
> 
> |Ｆｕｌｌｗｉｄｔｈ|
> |halfwidthhalfwidth|
> |朅—∴mw朅—∴mw朅—|
> |ll|
> 
> (It works as described in gnome-terminal, xterm and gvim, but not in
> gedit, where the full-width letters are about 1.5 character cells.)

Ok, thanks for the information.

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

Re: Developing a new text editor widget?

[Sébastien Wilmet]

On Sun, Jun 05, 2016 at 12:33:20PM -0700, Christian Hergert wrote:
> You wouldn't want to mmap() the whole file, because that would still
> limit how large of a file you can open on 32-bit systems. You would want
> mapping windows with a page replacement strategy. Once you get this far,
> mmap() is simply an optimization over a page/extent read.
> 
> You need to iconv/etc the whole thing sequentially and therefore must
> read in the whole file upfront. However, you can do this and then
> proceed as normal with the alternate file afterwards (using O_TMPFILE or
> tmpfs backed fd).

/tmp is mounted in RAM on some distros, AFAIK. Maybe a better place is
~/.cache/, so opening a 8GB file is feasible (not sure it is useful
though, but people coming from Windows expect to be able to use a GUI
tool for everything).

> Are there situations where the character is larger than a single cell?

Yes I think.

In French there is æ and œ, those should ideally be displayed as 1.5x
the size of a char. Or there is also "…". But those are still entirely
readable in monospace. But I think in other languages, there are
characters that should take 2x the size of a cell.

> > For source code, GtkTextView is really not that bad IMHO. Normally
> > source code doesn't trigger the very long line problem (and even, this
> > problem in GtkTextView is fixable by internal refactorings, although
> > nobody tried recently AFAIK). And source code is contained only in very
> > small files, it is not a problem to load e.g. 20k lines in memory.
> 
> There are a few things that it is really bad at.
> 
> You have to scan linearly from O..n to determine line height. There are
> all sorts of hacks to do this upfront in high-priority idles. It's why I
> still can't open a file, and scroll to a line number like 1000 correctly
> without retrying a bunch of times.

When loading a large file (e.g. 20 MB), we indeed see GtkTextView busy
computing its size. But for a file of 10k lines, there is absolutely no
problem.

In gedit-tab.c, scroll_to_cursor() is an idle function.

> The main thing I'd like to learn at the hackfest is what constraints
> must we take on to do fast text scrolling with GSK+(GL/Vulkan/etc). This
> pixelcache copying on every frame is really hard to optimize.

When I was a heavy user of gedit a few years ago (for developing in
Vala), I've never seen the scrolling performances as a problem.

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

Re: Developing a new text editor widget?

[Sébastien Wilmet]

On Sun, Jun 05, 2016 at 03:15:30PM -0400, Rena wrote:
> As an application developer, my main gripes with GtkTextView have been:
> 
> 1. The view/buffer model. I expected that the view just asks the buffer for
> text, and I could supply a custom buffer object that generates text on the
> fly. In reality it seems I have to use a GtkTextBuffer and fill it with the
> text I want to display, and manually respond to cursor movements by
> modifying the buffer. It rather defeats the purpose of having a view/buffer
> model at all.

The view is not the only user of a buffer. There can be scanners that
scan the buffer, to do various things such as highlighting the syntax.
The buffer/view split permits in theory to have several views for the
same buffer. Lazy loading of the buffer content is something separate.

> 2. Difficult to compute how much text will actually fit in the view, when
> varying character sizes (especially heights) are involved. This relates to
> #1, since I'm not putting text into a view, I'm putting it into a buffer
> which doesn't know much about how the view is going to render it. This
> makes it difficult to know how much text I need to supply. (I can usually
> get away with over-estimating and supplying more than enough, but then when
> the cursor is moved down at the bottom of the view, it wants to scroll, so
> I have to handle that... also I hadn't even thought until now about what
> "select all, copy" will do in this case.)

I don't think GtkTextBuffer was meant to be used like that, despite its
name.

> 3. No way to control the positioning of text and/or movement of the cursor.
> When implementing a hex editor widget, I wanted to display data in a format
> like "__00_00_00_00__00..." (where _ is a space), but have the
> cursor skip over the spaces. I could find no way to achieve this except by
> (again) manually handling all cursor movement events, trying to figure out
> what the best valid position is for where it's trying to go, and putting it
> there. I had hoped I could either tag the spaces to say "have the cursor
> skip over this", or add a "margin-right" attribute to the digits like I
> would in a web page, so that spaces would be added without using an actual
> space character. (Although in the latter case I'd have to have a custom
> "copy" handler that renders the text *with* spaces for the clipboard, so
> that might not be so good either.)

I think it's possible to implement virtual spaces with a utility class.
It's probably not straightforward, but it should be feasible. I also
need virtual spaces in gCSVedit:
https://sourceforge.net/projects/gcsvedit/

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

Developing a new text editor widget?

[Sébastien Wilmet]

Hi,

I'm not going to the GTK+ hackfest, but there is one subject listed on
the wiki page that I want to talk about: textview/sourceview
replacements.

Christian talked a bit about it here:
https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html

Which is inspired by this paper:
https://www.cs.unm.edu/~crowley/papers/sds.pdf
"Data Structures for Text Sequences"

It would indeed be really nice to have such an implementation, to
support very large files and very long lines (GtkTextView currently
doesn't support well very long lines, there is a performance issue). But
writing a new text widget is a major undertaking. For example, just for
the mmap idea, is it possible to mmap a remote file? (that's a real
question, I actually have never tried). And what about encoding
conversion if the file isn't UTF-8?

There was also some talks about a monospace-only textview. But even in
source code, a string or comment can contain text in any language. So
having good i18n support as an option can be a big advantage when
choosing a text widget or toolkit.

For source code, GtkTextView is really not that bad IMHO. Normally
source code doesn't trigger the very long line problem (and even, this
problem in GtkTextView is fixable by internal refactorings, although
nobody tried recently AFAIK). And source code is contained only in very
small files, it is not a problem to load e.g. 20k lines in memory.

And if a new text widget is written, there is the question about the
API. If the API is different, porting all the applications to it would
also be a huge amount of work. The GtkTextView API is not that bad, I
find it convenient to use, even if it could be modernized or improved
here and there (leverage CSS, better support multiple views, and a few
smaller things). So, if one day a new text widget is written, I think it
would be a good idea to not diverge too much from the GtkTextView API.

That's all, I wanted to share my thoughts.

Cheers,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk/quartz ... a tale of nested incompatible event loops

[Sébastien Wilmet]

On Mon, May 23, 2016 at 01:29:44PM -0400, Paul Davis wrote:

> I'm emailing it
> just in case anybody else decides to wade into a complete overhaul of the
> design of the glib event loop on Quartz.


Looks somewhat obscure and low-level.

I think on bugzilla it would have more chances to be read by someone
interested to improve the quartz support in the future. When doing a
complete overhaul, looking at the existing reported bugs seems a good
thing to do.

Best regards,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_error_free() warning on null pointer

[Sébastien Wilmet]

On Mon, Aug 31, 2015 at 11:03:40PM -0400, Michael McConville wrote:
>  1) print an annoying warning

Not always, as Simon explained already, the g_return_if_fail()/...
functions can be disabled, in which case the program continues its
execution and will usually crash.

See the --enable-debug configure option of GLib:
https://developer.gnome.org/glib/unstable/glib-building.html

In the docs, if it is not mentioned whether NULL is accepted or not, it
means that it is not supported. Except when the documentation needs to
be fixed, of course, which can happen from time to time.

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

Re: Custom TextBuffer

[Sébastien Wilmet]

Hi,

On Sun, Aug 30, 2015 at 12:22:36AM -0400, Rena wrote:
 I want to use a TextView to display information as marked-up text.
 This information is generated on the fly and would span millions of
 lines that the user can page through. It seems like the idea would
 just be to subclass GtkTextBuffer to provide my own methods for get
 text in a particular range, but I can't find any information about
 how. I tried providing my own get_text and get_slice methods but
 they're never called. I'm using Python btw.

See this tutorial for GtkTextView:
http://www.bravegnu.org/gtktext/

And see the introduction of GObject:
https://developer.gnome.org/gobject/stable/

For Python and PyGI, there is normally also some documentation.

Cheers,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_error_free() warning on null pointer

[Sébastien Wilmet]

On Sat, Aug 15, 2015 at 01:52:02PM -0700, Jasper St. Pierre wrote:
 Lots of things in GLib fail when passed a NULL pointer, like g_object_unref.
 
 The idea is that passing a NULL pointer is probably a sign of a bug
 somewhere, so you shouldn't do it.

No, accepting a NULL pointer for free functions is for convenience. At
the beginning of the block, you initialize your variables at NULL, and
at the end of the block (maybe after a goto label) you free the
variables that need to be freed. It's not a sign of a bug…

Consistency is important for a library. It's much simpler to remember
all free/unref functions accept NULL instead of free/g_free accept
NULL, g_object_unref not, g_clear_object yes, etc etc.

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

Re: g_error_free() warning on null pointer

[Sébastien Wilmet]

On Sun, Aug 16, 2015 at 10:49:56AM +0100, Emmanuele Bassi wrote:
  Consistency is important for a library. It's much simpler to remember
  all free/unref functions accept NULL instead of free/g_free accept
  NULL, g_object_unref not, g_clear_object yes, etc etc.
 
 unref() is not a free function, so there goes the consistency
 argument for it.

A free function can be seen as a special case of unref where the pointed
memory can have at most one reference. free and unref are used for the
same purpose, to release memory. Consistency between the two makes
sense. If you need to remember different rules for two similar cases,
then you have an inconsistency.

 All the reference counting functions must *not*
 accept NULL; if you're unreffing a NULL value then there is reference
 counting bug in your code, because it means something is holding a
 pointer to an object, nullifying it, and still trying to access it; if
 that happens, your code should keep an actual reference. Silently
 discarding NULL is going to mask this bug.

If you have a NULL pointer and you unref it, it can mean:
- that the object was never initialized
- that unref has already been called

For the first case, I've given a typical use case: at the end of a
function you release the variables that you don't need anymore; some of
them are maybe not initialized, e.g. if you have an early error and goto
directly to the end of the function.

For the second case, if some code is still trying to access the object,
you'll get warnings when using other public functions, that is, other
functions that do some actual work on the object. The job of unref() is
just to release the reference, if the pointer is NULL it means that the
job is already done. Lots of public functions do a NOP when the job is
already done. Being able to do several times the same operation, to be
sure that it's done, can simplify the code. You don't need to add some
logic to know if the operation is already done or not, you just call the
function.

 As a side note: the g_clear_* family of functions is meant to be used
 to nullify a pointer variable after freeing its contents; these
 functions are NULL-safe because they have to, since they need to
 nullify the variable at the given address.

Calling g_object_unref() also generally implies to nullify the pointer,
except if the variable goes out of scope.

What we see nowadays is to call g_clear_*() at the end of a function,
just for convenience to avoid the if(foo != NULL). Even if nullifying
the pointer is useless. It's sort of a small hack. It would work equally
fine if we can do in dispose():

g_object_unref (foo);
foo = NULL;

In C the latter is more natural imo. Setting a variable to NULL after
freeing it is a common pattern.

(it's just one more line, but it would already be more convenient than
having conditions)

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

Re: g_error_free() warning on null pointer

[Sébastien Wilmet]

On Sun, Aug 16, 2015 at 11:53:16AM +0200, Nicolas George wrote:
 Consistency is good, but it is not the only aspect of convenience. Catching
 common bugs is another aspect, pulling in the other direction.
 
 When freeing something, there is always the question If I am freeing NULL
 here, is it a bug in my program?. If the answer is more frequently no
 then the free function should accept NULL silently; if the answer is more
 frequently yes, then the free function should complain about NULL. The
 answer is not the same for all free functions.

So if you design a library like that, your users will need to read the
documentation everytime they use as simple functions as free/unref.

Consistency is important for a programming language or for a library to
save time to the programmer (and not turning crazy).

To take another example, I always use bitfields to add booleans in a
struct. So, instead of:

struct
{
gboolean blah;
};

I always write:

struct
{
guint blah : 1;
};

A bitfield of 1 bit can only be used for a boolean, so the code is
almost as clear as using the more precise type.

Since gboolean is a typedef to a gint, for heavily-used structs it's
better to pack booleans at the end of the struct with bitfields, to
save some memory. For less-heavily used structs (the extreme case being
a singleton), other people prefer to use gboolean because it's slightly
clearer, and fields can be grouped more logically instead of being
forced to put booleans at the end. But in that case, you always need to
think is my struct heavily used or not?. The answer may be different
over time, after adding a new feature for example. And what does
heavily-used mean exactly? It also depends on how many booleans you
have in the struct.

It's far simpler and quicker to always apply the same convention.

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

Re: TextView background color: bug or misunderstanding?

[Sébastien Wilmet]

Hi,

On Sat, Jul 04, 2015 at 01:04:08PM +0200, Kasper Peeters wrote:
 I am trying to make the background colour of all TextViews white, using
 
   gtk_widget_override_background_color()
 
 This does make the background white, but it also makes the color used
 for selection highlight white. As a result, I can't see anymore what I
 am selecting.

You can have a look at how the GtkSourceView styling works, you'll
probably find the answer there.

Note that gtk_widget_override_background_color() has been deprecated
since version 3.16.

With the hope that helps,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Sat, Jan 24, 2015 at 10:07:56AM -0500, Paul Davis wrote:
 GTK3's CSS styling feature is a huge draw for many developers. Being able
 to take an understanding of themeing based on web development and apply it
 to native applications is really a very very nice feature. I would have
 talked at greater length about that rather than GObject, since many
 developers using any language binding stand to benefit from CSS themeing,
 versus the few who might one day use a little bit of GObject.

I personally use more often GObject features than CSS. CSS is more for
theme authors, not application authors. A small GTK+ app doesn't really
need CSS, the available GTK+ widgets are sufficient and have a decent
theme with Adwaita.

 I would cite some of the more unique widgets in GTK also, especially the
 newer ones that might not be known by people familiar only with GTK1 and
 GTK2.

To better understand widgets, screenshots are needed, and a flyer is too
small for screenshots (at least the three-folded A4 page).

As you said, two A4 pages are not enough for describing every
interesting features. Nothing prevents us from writing a brochure about
GTK+ only, and another brochure about lower-level libraries, but it'd
become maybe a bit too much content (that said, the FreeBSD stand has
almost 10 different flyers! And in different languages).


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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 10:42:28PM +, Chris Vine wrote:
 On Fri, 23 Jan 2015 23:24:18 +0100
 Sébastien Wilmet swil...@gnome.org wrote:
  I said object oriented style, not GObject. You can write C code with
  an OO style without using GObject.
 
 What you actually said was:
 snip

If you jump several replies backward, the discussion will be more
difficult…

In the meantime, I agreed that what you describe is another (valid)
approach. I just added that GObject is more powerful (wrt OO style in
plain C) and that if the C language is chosen, then it's advised to
follow an OO style, i.e. the object is a struct and the self parameter
is a pointer to an instance of the struct, and you keep that in a
single file if possible (the class). Otherwise, if you don't follow this
(in C), you'll end up with global variables, which is not great.


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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 12:29:12PM -0800, Jasper St. Pierre wrote:
 That seems like an extremely bizarre and specific use case to optimize for

Hey, it was just a random example, to give another possible viewpoint.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 09:27:37AM -0800, Jasper St. Pierre wrote:
  The learning path for writing a GTK+ application should be: GLib -
  GObject (at least the basis) - a bit of GIO - and finally GTK+. All
  GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's
  important to explain what it is, at least briefly.
 
 I disagree. The learning path for writing a GTK+ app should start with GTK+
 and let them venture into the utility libraries of GLib and Gio when they
 need to. No need to start with here's the library that seemingly reinvents
 all of C99 because people sometimes still use SunCC in TYOOL 2015.

It's all the debate between the bottom-up and top-down approaches. Maybe
a good compromise is a mix between the two, because it's more fun to
show a window with three buttons than learning how to create a signal.
But sooner or later a developer needs to know GLib and GObject.

For a potential book about GTK+, there can be a short chapter on GLib to
learn the basis, then an introduction to GTK+ with some basic
explanations on how to _use_ a GObject class, then a chapter to know how
to _write_ GObject classes. For what it's worth it was roughly the path
chosen in GGAD.

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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 10:39:17AM -0500, Paul Davis wrote:
 Event loop programming is simultaneously completely fundamental to all
 user-interactive software, and as such ought to require no introduction at
 all, but as you note it is (pathetically) lacking from the education
 experienced by many in the field. If you're going to draw an event loop
 then I think you want to capture something a bit less abstract than what
 you have.
 
  Events (keyboard,mouse,touch,network,serial,other data sources) =
 application response (computation, communication, request drawing changes)
 = redraw = REPEAT
 
 That's the actual useful event loop.

Yeah, the GMainContext state diagram is a bit abstract without more
explanation. So I've replaced it by another schema, which is really
straightforward to understand now.

The redraw part is specific to GTK+ or a graphical application, so
it's better to not mention it in the GLib section. I explain a bit later
that it can be used to write daemons.

Thanks for your feedback,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

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

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

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

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

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

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

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

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

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


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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 01:38:05PM -0500, Paul Davis wrote:
 Writing GObject classes is not typically something that application
 developers will do.

There are many apps in GNOME, written in C, full of GObject classes.
Look at gedit for instance.

By reading the answers of this thread, it seems that GObject should be
something we should hide to newcomers because it's a bit painful to use.
It's indeed a bit painful, but I hope that some better tools will exist
in the near future (Builder) to create, rename, refactor GObjects while
still keeping a good indentation, to format the function prototypes and
headers automatically, completion of signal and property names,
static-analysis tools to detect if a signal callback has a wrong
prototype, less boilerplate code (GProperty, signals? syntactic sugar?),
and I probably forget other things.

It's a bit off-topic, but maybe if GObject was created with only the C
language in mind, everybody would be happy with C/GObject. But since
GObject was created with bindings in mind, it's a bit more painful in C.
But it has the advantage that if one day there exists a wonderful
high-level language, someone just needs to write good GObject
introspection support, and suddenly millions of lines of GObject code
can be used in the high-level language. Supposing that the binding
support is really stable and that API documentation targetting the
high-level language is available, there is still a potential problem:
the exposed API can be weird to use in the high-level language because
it doesn't use all the features of that language. So ideally you need to
write a wrapper for each library (a bit like the *-glib wrappers to
GObjectify some libraries). This last thing really happens, for example
one reason why the MonoDevelop developers have written another text
widget in C# is because GtkTextView had a weird API in C# (but some can
argue that it's also the case in C :-).


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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 09:00:53PM +, Chris Vine wrote:
 You are looking at it from the perspective of a GTK+ developer and not
 an application developer.

(I'm not a GTK+ developer, I just contribute a little)

 Application developers not providing applications specifically for
 the gnome stack almost never need to sub-class the library-provided GTK+
 widgets.  For example, contrary to what you think, they do not sub-class
 GtkWindow for their main window.  Instead they use the (generally)
 perfectly adequate GTK+ container system to put things in GtkWindow
 objects, or in library-provided sub-classes of GtkWindow.  If they want
 to be particularly rigorous, they may provide a convenience factory
 function for the purpose.  If that doesn't work they probably use
 another toolkit, because OO with GObject is a pain for the application
 developer writing in C (and as I say, normally completely unnecessary).
 Nor for that matter would they normally sub-class GtkApplication: they
 just connect to GApplication signals to customize behaviour.
 
 Only in very specialized circumstances is derivation necessary in the
 average application.

Yes, for a small application it's another possible code architecture.
But I would still recommend to write C code in object oriented style (if
the C language has been chosen).

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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Fri, Jan 23, 2015 at 09:40:56PM +, Chris Vine wrote:
 On Fri, 23 Jan 2015 22:29:02 +0100
 Sébastien Wilmet swil...@gnome.org wrote:
  Yes, for a small application it's another possible code architecture.
  But I would still recommend to write C code in object oriented style
  (if the C language has been chosen).
 
 Just to be clear, I completely disagree.  Whether to use GObject-style
 OO has almost nothing to do with application size.  The GTK+ library is
 generally well enough designed to render the derivation of custom
 widgets unnecessary in almost all cases.  The unnecessary use of GObject
 derivation is as much an affectation as anything else.

I said object oriented style, not GObject. You can write C code with an
OO style without using GObject.

 The OO fad of the 1990s is now well over.  We now have the functional
 fad (and as it happens GTK+ has bindings for most functional languages).
 The truth, as always, lies somewhere in between.

GTK+ is object-oriented, so it makes sense to me to write the
application in the same style.

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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

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

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

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

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

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

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

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

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Thu, Jan 22, 2015 at 10:01:55PM +0100, Sébastien Wilmet wrote:
 https://github.com/swilmet/gtk-brochure
 https://people.gnome.org/~swilmet/gtk-brochure.pdf

I've pushed an update. I've simplified the GObject section, and added a
state diagram of the GLib event loop. An event loop and event-driven
programming is not often taught at the university, so with a diagram
readers will better memorize what it is.

I've tried to add a screenshot of gnome-clocks, but the headerbar is
barely visible, the image is too small. The flyer is more about
presenting the lower-level stack. I think by explaining that GTK+ is to
create applications with a graphical user interface, readers will
understand what that means… If not, there is a GNOME flyer for users, as
well as a demo computer on the stand to try GNOME 3.

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

Re: cl-cffi-gtk: A Common Lisp binding for GTK+ 3

[Sébastien Wilmet]

Hi Sian,

On Wed, Jan 21, 2015 at 02:27:27PM +, Sian Mountbatten wrote:
 I'd like to bring to your attention the Common Lisp binding for GTK+ 3
 written by Dr Dieter Kaiser kai...@crategus.com. The binding is
 thorough and well documented.
 
 Please update your list of language bindings of GTK+ 3.

With an URL it'd be better.

I suppose you want the binding to appear here:
http://www.gtk.org/language-bindings.php

Cheers,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet]

On Thu, Jan 22, 2015 at 09:33:18PM +, Alberto Ruiz wrote:
 First of all thanks a lot for working on this!
 
 However, for a brochure about a graphical toolkit, I find it interesting
 that there are no GTK+ apps' screenshots.
 
 Perhaps I would suggest something less verbose and more to the point with
 captures of GNOME 3 apps'.

My gut feeling is that most people of the target audience already know
what a GTK+ app looks like. But having at least one screenshot would be
nice, indeed. I can try to shorten the GObject section so a screenshot
can be added in the GTK+ section.

I think a good application is gnome-clocks. It'll probably look nice
even in a small size.

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

GTK+ brochure for FOSDEM

[Sébastien Wilmet]

Hi,

Just a quick note to announce that I've written a brochure about
GLib/GTK+:
https://github.com/swilmet/gtk-brochure
https://people.gnome.org/~swilmet/gtk-brochure.pdf

Nothing revolutionary here, some chunks of text come from the gtk.org
website or from the API references [1]. But for a technical conference
like FOSDEM it was something missing.

I've already posted this on the engagement-list, where there has been
some reviews (thanks!). So if you have other comments, don't hesitate!

If everything goes well, the flyer will be available on the GNOME stand
this year at FOSDEM. Of course I hope the document will be useful for
other technical conferences.

Cheers,
Sébastien

[1] For a small text like this, copyright and license information
shouldn't be a problem IMHO, normally the people who have written the
original text on gtk.org or the API references implicitly agree that the
text is sometimes copied (it's for the own good of GTK+).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Sébastien Wilmet]

On Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote:
 From a quick look at gtkcombobox.h, the only really problematic part
 is the tabular menu nonsense (set_wrap_width(), set_row_span_column(),
 set_column_span_column()). Is there any way we could get around that ?
 perhaps just an additional GtkComboBox subclass which explicitly does
 not support those tabular menu things and thus would not be an API
 break ?

Overriding a function with a NOP is generally not a good idea, it breaks
the logic of inheritance. A derived type should be a specialization of
its base class. The derived type *is* also (a kind of) the base class.
If the base class supports operations A and B but a derived class
doesn't, then the derived class is *not* a kind of the base class,
logically. The inheritance hierarchy should be reversed in that case, so
that only the derived class supports operations A and B. Or create a
common base class or interface with two subclasses.

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

Re: a new combo box

[Sébastien Wilmet]

On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
 In any case, I think this misses the point I was trying to make, I think
 someone had to raise the obvious question: is it justified to bring in a
 whole new combo API ? Or can we / should we get the most out of the API
 we have ?

Yes, it was more a side note.

As a comment says at the top of gtkcombobox.c:
/* WELCOME, to THE house of evil code */

If it's the reason why new APIs are created instead of cleaning
internally the code, then the risk is to repeat the history every 10
years, deprecating endlessly APIs. Every code base evolves. At the
beginning a new class is (almost) always clean, but years after years
when more features are added the code becomes harder to understand, and
the risk is that it becomes evil code that nobody wants to modify, if
no refactorings is done regularly.

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

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Sat, Oct 04, 2014 at 08:54:03PM +0200, Sébastien Wilmet wrote:
 On Sat, Oct 04, 2014 at 02:10:02PM -0400, Matthias Clasen wrote:
  My main motiviation is that 'we follow TR29' is much better in terms
  of documenting it, testing it and diagnosing bugs in than 'do what vim
  does'.
 
 That would work if TR29 specifies clearly the different word boundaries
 to use for the different features. But it is not the case. Instead, TR29
 specifies generic word boundaries that should be tailored for the
 different features, and the tailoring is left as an exercise for the
 reader.

For what it's worth, LibreOffice Writer also takes into account the
punctuation for word movements and word selection.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Fri, Oct 03, 2014 at 10:25:36PM -0400, Matthias Clasen wrote:
 I think I want the default in GtkTextView/Pango to stay basically
 Unicode. So the vfunc may be needed sooner if you want to have
 vim-like behaviour in GtkSourceView.

What do you mean by basically Unicode?

The problems in GTK+:
- the behavior is not consistent between GtkEntry and GtkTextView (and
  possibly GtkLabel too for word selection).
- the current behaviors don't work well, since it uses only
  natural-language word boundaries.

So I want to fix both points.

When playing with GtkEntry and GtkTextView, we can clearly see some
differences, and we can also see that the behavior is sometimes strange.
For example with this line:

  g_assert_cmpint (pos - str, ==, 5);

In GtkEntry, double click on the 's' of str. Then double click on the
't' of str. In the first case,  - str is selected; in the second
case str is selected. With GtkTextView only str is selected for both
cases.

Double click on ==, it will select , ==, .

In GtkTextView, place the cursor just before g_assert (with the two
spaces before). Ctrl+left doesn't go to the start of the line. GtkEntry
does.

And of course g_assert_cmpint is not one word.

A more realistic example for GtkEntry:

foobar -- blah

Place the cursor at the start. Press Ctrl+right several times. -- is
skipped.

Do I continue?

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

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Sat, Oct 04, 2014 at 12:30:43PM -0400, Matthias Clasen wrote:
 I mean that it is the right default behavior to follow Unicode TR 29.

If we want to follow Unicode TR 29, then we should use the
is_word_boundary PangoLogAttr attribute, see:
https://bugzilla.gnome.org/show_bug.cgi?id=530405

As I explained there, I've done some experiments with is_word_boundary,
and it is not convenient to use directly. Using is_word_boundary gives
probably better results for the whole-word search. But for word
selection and word movements, it's not convenient, another algorithm
on top of is_word_boundary would be needed to achieve good results (at
least as good as the current behaviors in GTK+ that use is_word_start
and is_word_end).

With is_word_start and is_word_end, we have two word boundary types. It
is needed for word movements: ctrl+right goes to the next word _end_,
ctrl+left goes to the previous word _start_. With is_word_boundary, we
don't know if a word boundary is at the start or end of a word.

For word selection (double click), one word boundary type is needed. It
is easy to go from two word boundary types to one, utilities functions
can be written. Doing the contrary is more difficult. So, since
is_word_boundary doesn't give good results for the word selection, using
is_word_start and is_word_end is easier (through the utilities
functions).

But, is_word_start and is_word_end are only for natural-language words.
It doesn't take into account the punctuation, that can also occur for
normal text. If we want to follow Unicode TR 29, we can see here:
http://www.unicode.org/reports/tr29/#Word_Boundaries

that there are word boundaries for punctuation too. It is explained that
word boundaries can be tailored for some features. For example the
whole-word search can have different word boundaries than word
selection.

And I think the Vim word boundaries as used by the 'e' and 'b' commands
are suitable both for normal text and code. It would be a consistent
behavior across all GTK+ text widgets, including GtkSourceView for the
code.

 Fixing internal inconsistencies is a good idea, of course. Patches for
 that would be most welcome.
 
 For tayloring the text segmentation behavior for special situations,
 such as code instead of natural language, a vfunc is the right
 approach.
 
 Does that make clear what I would like to see ?

But the Vim word boundaries improve the behavior also for normal text,
not just code. Vim can be used to write mails and documents.

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

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Sat, Oct 04, 2014 at 02:10:02PM -0400, Matthias Clasen wrote:
 My main motiviation is that 'we follow TR29' is much better in terms
 of documenting it, testing it and diagnosing bugs in than 'do what vim
 does'.

That would work if TR29 specifies clearly the different word boundaries
to use for the different features. But it is not the case. Instead, TR29
specifies generic word boundaries that should be tailored for the
different features, and the tailoring is left as an exercise for the
reader.

For the documentation, no need to mention Vim, the Vim word boundaries
can be summarized easily. A word is either:
- a natural-language word that can include the underscore character;
- a contiguous group of non-blank characters.

But anyway, this is an implementation detail.

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

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Sat, Sep 27, 2014 at 12:47:31AM -0400, Matthias Clasen wrote:
 I agree that we probably need a vfunc - there's different use cases
 that need different variants: natural language, code, xml, etc. For
 best results, we may even want a way to use different word breaking
 rules in different regions of the buffer. As an example, you might
 have comments embedded in code.

So having better defaults in GTK+ would be a first step, I think it's
more important. The vfunc can be added later.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve word boundaries for text widgets

[Sébastien Wilmet]

On Fri, Sep 26, 2014 at 04:37:52PM -0700, Christian Hergert wrote:
 I'm doing exactly this in Builder today for VIM style `w` and `b`.

Ctrl+right is the same as 'e' in Vim: go to the next word end.
Ctrl+left is the same as 'b' in Vim: go to the previous word start.

Is there a good reason to choose 'w' instead of 'e'? I think 'e' and 'b'
are better for word selection with Ctrl+Shift+arrow.

 Additionally, I'd like double-click and triple-click to be different
 things. Imagine triple-click selecting the whole scope in some C code
 for example.

Currently triple-click selects the line, it's not that bad. But being
able to change the behavior can be useful, I'll keep that in mind for
the vfunc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Improve word boundaries for text widgets

[Sébastien Wilmet]

Hi,

Several months ago I started working on improving the word boundaries,
I've written some patches, written some comments on bugzilla in various
bugs. Here is a summary, I hope it'll get more attention than in
bugzilla.

I would like to improve the word boundaries for the text widgets:
GtkTextView, GtkEntry and GtkLabel (anything else?). More precisely the
word boundaries used for word movements (Ctrl+arrow) and word selection
(double click). Currently the behavior is not consistent across the text
widgets in GTK+ (and other applications), and the current word
boundaries don't work well with spaces, punctuations,
variables_with_underscores, etc.

The word boundaries currently used are those returned by Pango for
natural-language words. Those word boundaries are suitable for a spell
checker, since the spell checking should be run only on natural-language
words. But for word movements and word selection this doesn't work well
directly.

By seeing how Vim handles word movements, I think it's a much better
behavior. Deriving the Vim word boundaries from the Pango word
boundaries is quite straightforward (I have a workable patch): it uses
only the is_word_start and is_word_end PangoLogAttr attributes,
g_unichar_isspace() and compare if a character is an underscore.

Another idea for GtkTextView is to add a vfunc to let GtkSourceView
define custom word boundaries for word movements and selection. But
all what GtkSourceView would do is to define the Vim word boundaries,
which are generic. The Vim word boundaries are good enough, we don't
need more flexibility. So I prefer to implement directly the Vim word
boundaries in GTK+, and have a consistent behavior with other widgets.

Longer-term, we can maybe think about moving the Vim word boundaries
algorithm in Pango, so other applications like Firefox can also have the
same behavior. But in the meantime we can have internal utilities
functions in GTK+ that would be used by all text widgets, so the code
would have the time to maturate before going to Pango.

Do you think it's a good plan?

Thanks,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ scene graph, API deprecations

[Sébastien Wilmet]

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

Ok I see.

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

But GtkTreeView has the advantage that it already works and is mostly
feature complete (to display trees too), and is used in lots of
libraries and applications, with custom models etc. It seems easier to
me to do code refactorings in GtkTreeView than creating a completely new
widget from scratch. And if GSK can potentially simplify a lot the
GtkTreeView implementation in the future, and with the API break for GTK
+ 4, another solution is to simplify both the API and implementation of
GtkTreeView for GTK+ 4.

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

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

--
Sébastien

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

Re: GTK+ scene graph, API deprecations

[Sébastien Wilmet]

On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
 Because every time we try to clean up GtkTreeView, we break some random
 application. It's a widget that has twenty three gazillion use cases, and
 so we have to keep it a mess, because removing the mess means removing one
 use case, and we can't do that.

So the problem is because GtkTreeView was developed as policy-free as
possible. Now the new widgets are written with more policy, which makes
the API easier to use, with a simpler implementation.

So if I understand correctly, with the new widgets, small applications
are easier to write, but applications with more complex needs are more
complicated to write, because even more custom widgets are needed (while
before it was possible to use all the bells and whistles of the generic
widgets).

--
Sébastien

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

Re: GTK+ scene graph

[Sébastien Wilmet]

Hi,

Another question.

With GskLayerContent, will it be possible to unify cell renderer and
widget drawing models? To simplify significantly the GtkTreeView
implementation, for example, and be able to insert a GtkWidget in a
GtkTreeView.

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

Regards,
Sébastien

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

Re: A Gtk's build system ?

[Sébastien Wilmet]

On Tue, 2014-08-05 at 10:35 -0300, Victor Aurélio Santos wrote:
 Is there a plan to write a new build system or use another existing
 build system for Gtk instead of Autotools ?

For what it's worth, I've written a blog post some time ago:
http://blogs.gnome.org/swilmet/2012/09/05/switch-from-cmake-to-autotools/

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

Re: GTK+ scene graph

[Sébastien Wilmet]

Thanks for the explanation.

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

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

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

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

GTK+ scene graph

[Sébastien Wilmet]

Hi,

Some questions about the GTK+ scene graph ([1]).

Why not reusing the height-for-width and width-for-height sizing
requisition type? Will it Just Work with the constraint-based layouts?

For functions like gsk_layer_set_z_position() having 'z' in the name,
have you considered naming them with depth or another more meaningful
name than a single letter? I know everybody use x/y/z, but personally
when I read some math code with lots of single-letter variables, I
find it more complicated to understand. Maybe the API should be free of
such single-letter math stuff, or if a convention is followed, document
it clearly somewhere (but there should not be too many conventions for
single letters, since it's harder to memorize).

Best regards,
Sébastien

[1] http://www.bassi.io/articles/2014/07/29/guadec-2014-gsk/

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

Re: Tutorial on writing widgets?

[Sébastien Wilmet]

Hi,

On Thu, 2014-07-17 at 16:54 -0400, Rena wrote:
 Is there any tutorial on how to make a library that provides a GTK widget,
 like GtkGlExt or GtkSourceView, but for GTK+ 3? I want to write such a
 library, but I can't find a guide on how to do it, and existing libraries
 are proving too complex for me to learn from with no other references.

For writing a library, the C language is more or less recommended, but
Vala can be used too. You should be familiar with GObject, GTK-Doc,
GObject introspection annotations, and the Autotools for the build
system. For the Autotools if you don't want to proceed by trials and
errors, a good and recent book is Autotools by John Calcote:
http://www.nostarch.com/autotools.htm

For library development, read David Zeuthen's articles:
http://davidz25.blogspot.be/2011/07/writing-c-library-intro-conclusion-and.html

And also Ulrich Drepper's articles How to Write Shared Libraries and
Good Practices in Library Design, Implementation, and Maintenance:
http://akkadia.org/drepper/

For widget implementation, a good introduction is in the GGAD book, but
it is unfortunately mostly obsolete. But the main principles remain
valid. GtkObject has been replaced mainly by GObject, Cairo is now used
for drawing, Pango is used for text rendering, the size requisition is
more powerful with height-for-width and width-for-height, and many other
things have changed too.

http://www.e-booksdirectory.com/details.php?ebook=1811

See the GtkWidget documentation for an up-to-date reference. The GTK+
documentation contains also sections on the drawing model, migrating
from GTK+ 2 to GTK+ 3, and so on.

I recommend that you first write your GtkWidget in an application code,
since writing a library is more complicated (you must pay more attention
to not break the API/ABI).

--
Sébastien

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

Re: Glade crashing

[Sébastien Wilmet]

Hi,

On Sat, May 17, 2014 at 12:05:13PM +0200, Lanoxx wrote:
 I am using Ubuntu 13.10 with Glade 3.14.2. I just noticed that Glade
 crashes when I try to open the following glade file:

A mailing list is not a good place for a bug report. Please file a bug 
on bugzilla, after searching if a similar bug is not already present 
(and fixed).

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

Re: Scrolling: be able to disable the zoom mode

[Sébastien Wilmet]

On Sun, Mar 23, 2014 at 02:06:32PM +0100, Sébastien Wilmet wrote:
 I've filed a bug about the scrolling zoom mode:
 https://bugzilla.gnome.org/show_bug.cgi?id=722438

More information about the scrolling zoom mode:
http://blogs.gnome.org/mclasen/2013/08/05/scrolling-in-gtk/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Scrolling: be able to disable the zoom mode

[Sébastien Wilmet]

Hello,

I've filed a bug about the scrolling zoom mode:
https://bugzilla.gnome.org/show_bug.cgi?id=722438

Without any response. So I try here on the mailing list. I still use 
GTK+ 3.8 on my desktop because of that.

For me the zoom mode is useful only for taking a precise screenshot...

I copy/paste my comment from bugzilla:

I don't like the scrolling zoom mode, it is not how I use the scrollbar.

When I want to skim through the content to find quickly what I'm searching, I
do that in several steps:

1. click on the scrollbar, and hold the button pressed.
2. look at the content, perhaps reading the section titles.
3. scroll to find the section I want to read.

The problem: during step 2, the scrollbar often goes into zoom mode, so step 3
doesn't work.

The workaround is to directly move the scrollbar just after we click on it, so
the zoom mode is disabled. But this is not convenient.

And for me the zoom mode is useless, if I need to scroll a small distance, I
use the mouse scroll wheel.

I think the zoom mode is not a good idea. It should at least be possible to
disable it.

Best regards,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: deactivate enter signal on GtkButton

[Sébastien Wilmet]

Hi,

On Thu, Nov 07, 2013 at 08:10:50PM +0800, Mahesh Chaudhari wrote:
 which one to use if I wants my button should not glow on hovering mouse 
 pointer over the button 

It comes from the theme. It's a bad idea to stop a signal because you 
don't want the :hover effect.

Regards,
Sébastien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Spell checking in GIO

[Sébastien Wilmet]

On Mon, Oct 07, 2013 at 10:38:01PM +0200, Sébastien Wilmet wrote:
 The first step is to wrap enchant in GIO.

More precisely, here are the two classes from gtkhtml that can go in 
GIO:

https://git.gnome.org/browse/gtkhtml/tree/components/editor/gtkhtml-spell-language.h
https://git.gnome.org/browse/gtkhtml/tree/components/editor/gtkhtml-spell-checker.h

Some API tweaks may be needed, but I think these features belong to GIO, 
not GTK+. We can also hide these features and adapt the GTK+ widgets 
directly, and add some widgets for the spell checking (a menu or a 
dialog window with the list of available languages, and a dialog window 
for the spell checking of a GtkTextView). But this would be less 
flexible, and custom widgets would need to use Enchant.

Anyway, what can be extracted from GtkhtmlSpellLanguage is the decoding 
of language codes, fr_BE - French (Belgium). I proposed last year to 
add functions in glib for doing that (it reads the iso-codes data). Even 
if this is not added to the public API, it can be useful to have this 
feature separately, so other projects can copy the code. The bug:

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

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

Re: Spell checking in GIO

[Sébastien Wilmet]

On Wed, Oct 09, 2013 at 09:31:19AM +1100, Andrew Cowie wrote:
 Speaking of which, do we really need to have so many different
 back-ends? We made a hard decision about the input method framework
 requirement, maybe we should just pick a dictionary provider and go with
 it?

The perfect dictionary provider for every language doesn't exist.

Enchant explains this in the Enchant and multiple backends section:
http://www.abisource.com/projects/enchant/

Enchant is used by a lot of projects, inside and outside GNOME. It is a 
good thing that it is a small library. In my opinion, Enchant should not 
be deprecated in favor of GIO (if we want to absord Enchant).

Enchant is already a good abstraction. The sole reason to wrap it in GIO 
is to GObjectify Enchant, and to decode language codes (fr_BE - French 
(Belgium)) with the iso-codes.

For a command line application, Enchant is still available. So it's 
maybe a better idea to implement the spell checking directly in GTK+.  
I'll think about the possible API additions.

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

Re: Spell checking in GIO

[Sébastien Wilmet]

On Wed, Oct 09, 2013 at 10:53:50PM +0200, Bastien Nocera wrote:
 I wouldn't want to use 2 different APIs when creating
 command-line/curses APIs or GTK+ though. Otherwise, whatever syntactic
 sugar the GObject bindings would add would be lost.

And if we add the spell checking directly in GTK+, an extension point 
would anyway be needed to avoid a direct dependency, since the Enchant 
types would not be exposed in GTK+.

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

So it makes sense to have the GObjectification in a separate library. Or 
the other possibility is to add the GObjects directly to Enchant (and 
keep the current API available). By doing so, we have one less DSO to 
load. But Enchant would have one more dependency, that perhaps some 
projects don't want to have.

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

Re: API break in GtkAction?

[Sébastien Wilmet]

On Mon, Oct 07, 2013 at 06:39:41PM -0400, Matthias Clasen wrote:
 I've just pushed a testcase (
 https://git.gnome.org/browse/gtk+/tree/tests/teststockbuttonmenu.c) that
 shows things related to stock icons, buttons, menuitems and actions working
 as I would expect them to, including gtk_action_set_always_show_image.

Thanks. With a little more investigation, what worked with GTK+ 3.8 and 
doesn't work anymore is to call gtk_action_set_always_show_image() after 
the widgets are added to their containers.

Sébastien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

API break in GtkAction?

[Sébastien Wilmet]

Send to gtk-devel-list too.

GtkAction, GtkStock, GtkUIManager etc have been deprecated. But it 
should still be possible to use them.

On Thu, Oct 03, 2013 at 10:13:51PM +0200, Sébastien Wilmet wrote:
 Hello,
 
 Since the deprecation of GtkUIManager, GtkAction, GtkStock etc, it seems 
 that gtk_action_set_always_show_image() doesn't work anymore.
 
 I don't have the time to port my application to GMenu (and I think some 
 features are missing, that I use with GtkUIManager). And I need icons in 
 menus. For example some menu items permit to insert international 
 accents. The image is really useful to know which accent it is.
 
 To enable icons in menus, I use this code (in Vala):
 
 foreach (Gtk.ActionGroup action_group in ui_manager.get_action_groups ())
 {
 foreach (Gtk.Action action in action_group.list_actions ())
 {
 action.set_always_show_image (true);
 }
 }
 
 It works fine with GTK+ 3.8, but not with GTK+ 3.10.
 
 I openened this bug:
 https://bugzilla.gnome.org/show_bug.cgi?id=708651
 
 I hope this is not intentional (which means it is an API break, without 
 .so version bump…).
 
 And, if it is intentional, is there another easy way to force to show 
 icons in menus? (Without lots of manual code, I mean, because the menu 
 is big).
 
 Thanks in advance,
 Sébastien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list