Re: GNOME GitLab instance slow?

[Tristan Van Berkom via gtk-devel-list]

This is probably better on another list, maybe d-d-l, since this would effect 
everyone.

I can say that since 2 weeks ago, the gitlab.com instance seems to have 
deployed a huge and sluggish JS payload which brings my browser to a crawl, i 
dont know if we've opted into that update on the GNOME instance, though.

Cheers,
-Tristan

> On Jul 27, 2018, at 8:17 PM, Luca Bacci via gtk-devel-list 
>  wrote:
> 
> Hi, do you experience too general slowness in GNOME's GitLab?
> 
> In general the workflow is too sluggish and this gets a bit in the way.
> 
> But the real problem is that I'm not able to create a Merge Request. It waits 
> for about 30 seconds and fails with: "502 Whoops, GitLab is taking too much 
> time to respond."
> 
> Also I get errors in many places like "Error loading viewer", even though 
> everything seems to work fine!
> 
> I don't know if the problem is related to GitLab or the GNOME instance / 
> installation
> 
> Is it me or do you encounter these problems too?
> Just to ask..
> 
> Thank You!
> Luca
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

Re: Functional programming with GLib

[Tristan Van Berkom]

On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
> 
> 
> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi 
> wrote:
> > For command line parsing I'd actually favour a slightly bolder
> > approach of deprecating GOptionContext, and having something
> > slightly
> > more modern — in terms of being bindable in other languages, and
> > well-integrated with API like GApplication.
> > 
> 
> What is lacking in the current incarnation of commandline option
> support in GApplication? 

Since this was raised here and I've currently been working with
python's click library and trying to make some enhancements there, just
thought I'd throw some things out there.

Some things that I'm finding important for CLI apps:

A.) Automatic generation of man pages and similar documentation,
    especially generating separate man pages for each separate sub
    command.

    I'm not even sure, do we have this already ?

B.) Built-in support for bash completions, allowing optional overrides
    for the application to implement custom completion suggestions
    for selected options/arguments.


This is all probably possible without completely replacing the API with
a new one, though.

Cheers,
    -Tristan

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

Re: Need help in debugging glib crash

[Tristan Van Berkom]

On Mon, 2015-05-25 at 16:42 +0300, Alexander Pyhalov wrote:
> On 05/25/2015 15:33, Alexander Pyhalov wrote:
> > Hello.
> 
> > Here the program crashed.
> > So, we see that emit_in_idle() was called after entering to
> > g_file_monitor_dispose() function, which if I understand this correctly
> > lead to crash. Perhaps, some additional handling is necessary in
> > g_file_monitor_dispose() so that we don't try to emit signal to
> > "disposing" object ?  Do you have some thoughts on how to debug further
> > and fix this issue?
> 
> 
> Now I'm looking on the following patch:

Hi Alexander,

Since the introduction of GIO and async routines; occurrences where
an object fails to cancel one of it's ongoing operations in dispose()
have not been entirely uncommon.

The best would be to start with filing a bug in bugzilla and attaching
a test case which reproduces the crash.

Also, it's possible that the crash you're seeing might be reproducible
already with this existing test case[0].

Cheers,
-Tristan

[0]:https://git.gnome.org/browse/gtk
+/tree/testsuite/gtk/objects-finalize.c


> 
> --- gfilemonitor.c  2015-05-25 16:15:05.066580976 +0300
> +++ glib-2.43.4/gio/gfilemonitor.c  2015-05-25 16:15:49.053863042 +0300
> @@ -442,7 +442,7 @@
> change->event_type = event_type;
> 
> g_mutex_lock (&monitor->priv->mutex);
> -  if (!priv->pending_file_change_source)
> +  if (!priv->pending_file_change_source && !priv->cancelled)
>   {
> source = g_idle_source_new ();
> priv->pending_file_change_source = source;
> 
> Does it make sense? The idea is to avoid calling emit_cb after 
> g_file_monitor_dispose has already been called. I'm not sure if it's 
> correct approach, as we can not be sure that g_file_monitor_dispose will 
> work atomically.
> 


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

Re: a new combo box

[Tristan Van Berkom]

On Sun, 2014-12-28 at 12:53 -0500, Matthias Clasen wrote:
> I am a bit disappointed by the turn this discussion has taken - I was
> hoping people would try the code I pointed to and let me know what
> they think and point out problems (thanks to Tim for doing just that).
> Instead, I get arguments about how much my time is worth compared to
> Mortens, complaints about 10 year old bugs getting wontfixed, or
> philosophical questions about whether a toolkit should ever provide
> more than one tool for a given job...
> 

I'm sorry to see this thread spiral out of control and for my part
in that.

My intention was really to start a rational conversation around this
topic and raise a concern that I think is justified, whichever direction
this takes, it will be nice to know that the decisions made were
carefully considered.

We have a long history on this list of careful consideration of the
benefits and collateral damage of the new APIs we adopt, and in doing
so, make a certain commitment to maintain. This is what makes GTK+ a
safe place to contribute and a viable choice for application developers.

This said, I think Jasper has raised the right course of discussion,
all emotions aside I hope that we can follow his lead by simply
sticking to facts and having some rational discussion.

Best wishes for the new year,

  -Tristan

> Please, it was fun to write this code, I was hoping you would have
> some fun trying it out.
> 
> Anyway, really off now until the new year. Enjoy your new years party,
> everybody!
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 16:29 -0500, Matthias Clasen wrote:
> On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
>  wrote:
> 
> >
> > It's really not that bad, combobox is currently < 6k lines of code which
> > is really not much for all that it does, sure we could afford to do a
> > bit less (like dropping the crazy tabular menus).
> 
> Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c.
> 
> > Honestly I would have rather proposed to just switch the whole internals
> > of combobox to do the more modern looking thing using cell areas, which
> > strikes me as the obvious way forward, bringing a new look to the combo
> > without dropping any of the value of combobox, and every app using
> > combobox automatically benefits - only that it would probably result in
> > breaking API.
> >
> > Frankly I don't appreciate this let's rewrite everything from scratch
> > attitude, it doesnt show a whole lot of respect to the users of our API,
> > who would, I think have a justifiable expectation that their usage of
> > combobox would not be labeled as obsolete at least until GTK+ 4.
> >
> > Sure, exceptions can be made within reason for dropping huge important
> > parts of GTK+, but let's stick within reason right ? Has this been
> > discussed ? Has it been concluded that there is no way forward with
> > the existing API ? Where is that discussion ? What is the rationale ?
> 
> Thats one of the hardest questions, isn't it ?
> 
> Deciding when a codebase that you've invested a lot of time and effort
> into has grown too old and complex, and it is better to start from
> scratch ? I'm often struggling with this, and stick to fixing things
> up to 'preserve existing investment' far too long. Of course, starting
> over is not a panacea: you may end up repeating old mistakes, and do a
> lot of work just to end up in the same place you started from. On the
> flip side, its a chance to revisit old assumptions that are deeply
> embedded in the old code, add modern features without having to
> force-retrofit them into ancient code (and cause collateral damage in
> the process).

The collateral damage really hurts, though. It's really hard to digest
that application developers who have developed an application with GTK+
3.4 or 3.6 have to continually play 'catch up' and rewrite their code to
keep up with the latest release, or to benefit from new features in 
GTK+.

A simple example that comes to mind, we have the 'fresh kids' writing
cool new apps that use the bright and shiny GtkRevealer, and we have the
old and suffering apps which have just not been brought up to speed,
still using GtkExpander - are app developpers to blame for still using
an expander ? Or should we do better to maintain the widgets that are
already part of the API ?

The combo box duplication will just be another instance of this, and the
result is a growing disparity between applications which already exist
and applications which happen to be being written this year.


> That being said, I think the case for GtkComboBox is pretty clear-cut.
> It was doomed from the beginning by the mistake to force two pretty
> distinct user experiences (option menus and combo boxes) into a single
> widget. You've made a valiant attempt to clean this up with the
> introduction of GtkTreeMenu, but it is still a mess. Another mistake
> was to expose a data-driven API (with models and cell renderers) for a
> widget that most of the time is used in non-data-driven scenarios.

Most of the time being the key word here. While perhaps 90% or more
use cases of GtkComboBox want to only display a single text label
which is a controlled (albiet translatable) phrase, it's the 5% - 10%
of outlying cases you encounter as an application developer that you
thank your lucky stars for having chosen GTK+ and have the tools handy
to accomplish something which strayed just a little beyond the most
basic of use cases.

> We've later tried to patch up that mistake by adding the simplified
> GtkComboBoxText. But since it is a subclass, it inherits all of the
> api problems of GtkComboBox. Lastly, there's a number of ill-advised
> APIs in GtkComboBox that make it very hard to do any new
> implementation of the same api: tabular menus, spanning columns, etc.
> Almost as if to prove the last point, your last major refactoring of
> GtkComboBox already broke a bunch of those APIs (e.g. col-span-column
> is not working anymore).
> 
> You'll be happy to learn that the "buildable API" of GtkCombo is
> pretty close to compatible with GtkComboBoxText (I should probably
> rename the active property to active-id to get even closer), so for
> most

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 11:44 -0800, Christian Hergert wrote:
> On 12/27/2014 07:50 AM, 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 ?
> 
> Can I style combobox items with CSS?

I'm not sure how relevant that is in this discussion, if you can't style
a cell renderer that would be a bug (I do recall Carlos reassuring me
that CSS would work with cell renderers when he was originally authoring
the CSS machinery).

A very quick look tells me that yes you certainly can, as the renderers
pick up the style context from the widget they are rendered onto, you
would have to be theming a GtkCellView, which is what displays an item
in a combo.

Cheers,
-Tristan


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 18:05 +0100, Sébastien Wilmet wrote:
> 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 */
> 

Sorry for not having removed that comment after spending significant
time cleaning that up myself.

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

It's really not that bad, combobox is currently < 6k lines of code which
is really not much for all that it does, sure we could afford to do a
bit less (like dropping the crazy tabular menus).

Honestly I would have rather proposed to just switch the whole internals
of combobox to do the more modern looking thing using cell areas, which
strikes me as the obvious way forward, bringing a new look to the combo
without dropping any of the value of combobox, and every app using
combobox automatically benefits - only that it would probably result in
breaking API.

Frankly I don't appreciate this let's rewrite everything from scratch
attitude, it doesnt show a whole lot of respect to the users of our API,
who would, I think have a justifiable expectation that their usage of
combobox would not be labeled as obsolete at least until GTK+ 4.

Sure, exceptions can be made within reason for dropping huge important
parts of GTK+, but let's stick within reason right ? Has this been
discussed ? Has it been concluded that there is no way forward with
the existing API ? Where is that discussion ? What is the rationale ?

Cheers,
-Tristan


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 16:21 +0100, Sébastien Wilmet wrote:
> 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.

Sure, it was suggested as a practical 'cheat' to get away with not
implementing some of the more odd-ball features from combobox which
I have doubts that anyone is actually using.

The reverse approach would IMO be worse, since any additional features
which the new beast might bring to the table would be expected
functionality in the older combo, while explicitly implementing some
vfuncs with g_warnings() on a few APIs, possibly deprecating those
tabular menu APIs in the parent GtkComboBox API), is not really a bad
side effect.

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 ?

Cheers,
-Tristan


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 08:02 -0500, Matthias Clasen wrote:
> Hi,
> 
> over Christmas, I had some for a little side project, a  new combo
> box. It is based on these mockups:
> https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png

Looks very modern and nice :)

> 
> One question I need some feedback on is naming: We currently have
> GtkComboBox and
> GtkComboBoxText. I've gone with GtkCombo for now, which has the
> downside that there is a widget by that name in gtk2. Alternatives
> might be GtkChoice or GtkComboButton (with a possible avenue for
> making the list-of-choices available for direct embeeding as
> GtkComboWidget later).

I guess one obvious question is, how much of this really calls for a
whole new API as a hard requirement ?

Afaics, most of this new look for a GtkComboBox can be accomplished from
the confines of the current GtkComboBox API - filtering the option tree
can also probably be simplified with some GtkTreeModelFiltering and
leveraging of the existing GtkEntryCompletion code... and the group
switching instead of showing recursive menus looks like a nice
refreshing change from the current GtkTreeMenu.

I'm sure the same look can be accomplished with GtkCellViews in the
items, also allowing for flexible customization of the items look
and feel, leveraging the cellview code without adding any additional
API.

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

It would be really great if one could just simply change a class
name in their existing code and suddenly benefit from a whole
new look and feel of GtkComboBox...

Best,
-Tristan


> There are some lose ends in the code, like the interaction of grouping
> and search, but it is complete enough to give it a try and evaluate
> the design. If you want to try it, the code is in the wip/combo
> branch, and there is a testnewcombo test app with some examples.
> 
> I'm off for a few days now - would be great to hear some feedback when
> I come back.
> 
> Matthias
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: Does gobject-introspection support the cross-compile?

[Tristan Van Berkom]

On Wed, 2014-08-13 at 09:09 +0800, Rongqing Li wrote:
> Hi:
> 
> I want to compile gobject-introspection for arm cpu in x86 host,
> both are linux OS. The compilation failed since g-ir-compiler
> (compiled for arm) can not run on x86.
> 
> Could you tell me if it supports the cross-compile, if not, what
> should I do to enable it? is it possible that I use the host's
> g-ir-compiler/g-ir-scanner to compiler the target(arm cpu) file.

This sounds like a typical problem you will run into when cross
compiling your stack, pkg-config is another example.

There are probably a number of techniques you can use, and one
option to consider is to just actually build on the target
arch. If you must cross-compile, one project which I've
used with success is buildroot[0], this solves the said problem
by building two stacks, one 'staging' stack which contains
tools compiled for the build host arch, and then the target
stack which is cross compiled, executing binaries from the
'staging' build directory.

Cheers,
-Tristan

PS: fwiw there is also a new gobject-introspection mailing list:
https://mail.gnome.org/mailman/listinfo/gir-devel-list

[0]:http://buildroot.uclibc.org/

> 
> 
> -Roy
> 
> 
> | ./g-ir-compiler: line 117: 
> /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
>  
> cannot execute binary file: Exec format error
> | ./g-ir-compiler: line 117: 
> /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
>  
> Success
> | make[2]: *** [gir/xfixes-4.0.typelib] Error 126
> | ./g-ir-compiler: line 117: 
> /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
>  
> cannot execute binary file: Exec format error
> | ./g-ir-compiler: line 117: 
> /buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/build/.libs/lt-g-ir-compiler:
>  
> Success
> | make[2]: *** [gir/xlib-2.0.typelib] Error 126
> | Traceback (most recent call last):
> |   File "./g-ir-scanner", line 44, in 
> | from giscanner.scannermain import scanner_main
> |   File 
> "/buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/scannermain.py",
>  
> line 35, in 
> | from giscanner.dumper import compile_introspection_binary
> |   File 
> "/buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/dumper.py",
>  
> line 28, in 
> | from .gdumpparser import IntrospectionBinary
> |   File 
> "/buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/gdumpparser.py",
>  
> line 31, in 
> | from .transformer import TransformerException
> |   File 
> "/buildarea1/lirq/mips/bitbake_build/tmp/work/mips64-wrs-linux/gobject-introspection/1.40.0-r0/gobject-introspection-1.40.0/giscanner/transformer.py",
>  
> line 27, in 
> | from .girparser import GIRParser
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: sorry~~can GTK+ draw flow graph?

[Tristan Van Berkom]

On Tue, 2014-07-29 at 21:43 +0800, gpu wrote:
> hi everyone! I'm sorry to send mail here, but I got no respond at the
> app-list :(

Hi,

I think since everyone's at guadec the lists are slow...

> I have a question here.
> I want to realize some funtionality like the flow graph.And I want to
> know is it easy to do it with gtk? And how to make it if there was no
> way to do it now. 1)The box should be sth like a listbox with each
> item can link to other items in another box ;2)And if i have to draw
> the curve by myself, whick lib or class should I use?
> The graph i want to have is shown below:
> http://staraban.com/wp-content/uploads/2014/03/unreal-engine-4-blueprint-editor.jpg‍

That page says:
  "Oops! That page can’t be found."

For drawing flow charts and the like, I would recommend using goocanvas,
this will let you use a variety of objects (shapes, lines, etc) and give
you some features like zoom, you can place objects in a virtual
coordinate space. You can also implement your own objects of course, and
all drawing is done with cairo.

goocanvas gives you a GtkWidget which can be placed in a scrolled window
or such in your application.

Cheers,
-Tristan

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


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

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

Hi Mike,

On Wed, Apr 16, 2014 at 11:25 PM, mike_s  
wrote:
 It's the same error I am experiencing when I am trying to make my 
ListView
ctrl scrolled without using the ScrolledWindow. It works in GTK+2 but 
really

not in GTK+3.

What I was trying to do is to request it to be smaller




... And this is precisely the issue.

With GTK+3 we enforce size request rules a little more strongly than we
did in GTK+2. A widget may not, under any circumstances, ever be
allocated a size which is LESS than the widget's original request.

The documentation of gtk_widget_set_size_request() does specify[0] this:

 "Sets the minimum size of a widget; that is, the widget’s size 
request

  will be at least width by height . You can use this function to force
  a widget to be larger than it normally would be."

If you need to force a widget to be smaller, then it needs to actually
request less space.

If what you need is a GtkScrolledWindow without scrollbars, you could
use a GtkViewport for this directly. The viewport will take care of
allocating enough space for the child widget's content while only
displaying the portion of the child that you want displayed (this can
be achieved by driving the GtkAdjustements which are associated to
the viewport).

Cheers,
   -Tristan

[0]:https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-size-request



 or else when the list
gets longer it force its self to show all the list out of boundary. I 
notice
that when you didn't even try to resize the column you can still 
change the
size of the window, but once you touch or chage any column's size, 
the size

of the list adjust to the minimum size.

I wonder if this bug is already fix or have any solution for this 
since this
post is quite late. Anyway, at this moment in my GTK+3 it still 
doesn't
work. 




--
View this message in context: 
http://gtk.10911.n7.nabble.com/gtk-widget-set-size-request-stopped-working-with-GTK3-tp26274p84317.html

Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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

Re: GtkWidget:halign and GtkSizeGroup

[Tristan van Berkom]

Hi Murray,

On 2014-07-17, at 5:25 PM, Murray Cumming  wrote:

> I'm trying to replace a use of the deprecated GtkMisc:xalign property
> with the newer GtkWidget:halign property with some labels that are in a
> GtkSizeGroup. The (GTK_ALIGN_START) alignment doesn't seem to be having
> any effect, though it does when work using the deprecated xalign
> property.
> 
> This screenshot shows the result in Glade with some GtkBoxes and a
> GtkSizeGroup, and the correct behaviour in a GtkGrid. Should it work
> with a GtkSizeGroup?

Not in this way it cannot work.

The size group effects the request in a way that all labels have the same size 
(or "at least" the same size) while the widget halign property can only align a 
widget into its potential allocation... I.e the halign property has "allocation 
- request" pixels add to the left or right of those labels before giving a 
final allocation to the label.

The GtkMisc properties work because they center some opaque widget content 
inside that widget's allocation.

What would work is to place each GtkLabel into its own "box", use the halign 
properties on those labels and use the size groups on each label's "box".

Cheers,
-Tristan


> 
> I can't just use a GtkGrid because I am actually using a custom
> container in my application.
> 
> -- 
> Murray Cumming
> murr...@murrayc.com
> www.murrayc.com
> 
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: some mistake in the GtkCellRenderer design

[Tristan Van Berkom]

On Sun, 2014-02-09 at 18:16 +, narcisse doudieu siewe wrote:
> 
> 
> Hello every body,
> 
> 
> I'm not a god designer but I have noticed some mistake with the 
> GtkCellRenderer design.
> 
> 
> To illustrate myself, I take an example.
> 
> 
> Actually, I want to implement a custom GtkCellEditable which inherits
> from
> GtkCalendar and GtkCellEdiatble and create a custom GtkCellRenderer to
> use it
> and renderer it entirelly in a cell when a click appears. from now my
> attation is on the
> custom GtkCellRenderer that I want to build.
> to do that, I have to rewrite its "render" virtual function
> 
> 
> if a click appears in a particular cell, I have to place my custom
> GtkCellEditable which renderer a 
> GtkCalendar. 
> 
> 
> there are two possible choice to do that  
> 
> 
> first choice)
> The width of the corresponding column must have at least the natural
> width of this custom widget (if this widget is larger than the
> previous width of the column) if not if there is an "expand" property
> my widget have to expand itself according to this property. the
> corresponding row must have at least the natural height of my custom
> GtkCellEditable too if not, if there is an "expand" property my widget
> have to expand itself according to this property. for the rest of
> cells not in the concerned column and in the concerned row thier size
> cannot change. All the cells in the concerned column have the same
> width and all the cell in the same row have a same height.
> 
> 
> second choice)
> we can use the clipping functions of cairo and enlarge the row and
> column in the treeview when the user drag a particular row\column
> 
> 
> 3) it is possible to mix the two preceding choice.

There is a fourth choice:

  o Simply derive GtkCellRendererPixbuf so that it can emit an
"activate" signal.

  o When the "calendar icon" is clicked for a given row in your
treeview - then fire up your date editing dialog to edit the
underlying date for the given row

Cheers,
-Tristan
> 
> 
> 
> I alse think that, the renderer function of GtkCellRenderer must have
> a "path" argument :)
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: Removal of icons in buttons/menus

[Tristan Van Berkom]

On Wed, Oct 9, 2013 at 10:55 PM, Bastien Nocera  wrote:
> On Wed, 2013-10-09 at 22:45 +0200, Michael Natterer wrote:
>> On 10/09/2013 10:40 PM, Bastien Nocera wrote:
>> > On Wed, 2013-10-09 at 22:14 +0200, Olivier Brunel wrote:
>> >> Ok, but this isn't about a change in GNOME, but in GTK. And the
>> >> default
>> >> for those options was still TRUE a few days ago in GTK 3.8
>> >
>> > As we're on this subject, I think it's pretty clear, from the committers
>> > to where the mailing-lists are hosted that GTK+ is the GNOME toolkit.
>> > People deeply involved in other desktops that rely on GTK+ should try to
>> > get more involved in decisions made for the GNOME toolkit.
>>
>> Oh please, not this silly "GNOME Toolkit" stuff again. GIMP runs on
>> windows and osx, so do many other applications. So please...
>
> They're GTK+ apps running on Windows and OS X, not Windows apps, or OSX
> apps.

That doesn't really change anything. GTK+ in the last decade has been *the*
choice of cross platform GUI toolkit... that's basically the reason why GTK+
and it's stack is ever popular, because it's flexible (can be used
almost anywhere),
that combined with the LGPL license and our strict policies to
maintain ABI stability.

These are the kind of things which attract people and companies to use our
software, to rely on our software and eventually even to participate and
contribute in furthering our software.

Interestingly I can agree or disagree to your statement "The GNOME toolkit"
based on the definition of GNOME.

GNOME: "A community of free software developers and projects collaborating
together, creating awesome software, mostly in the context of a
desktop environment"

By the above, my own personal (vague) definition of GNOME, what I have always
known GNOME to be... then yes, GTK+ is the GNOME toolkit, it's the toolkit which
evolved in GNOME.

GNOME: "A desktop environment / User experience"

By this definition (which seems to be a common slur these days), then no,
GTK+ is certainly not just a toolbox for the purpose of assembling a
particular user experience.

Let's try not to discredit GTK+, and try not to use slurs which might
imply that GTK+ is becoming "just a toolbox for GNOME".


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

Re: flow box

[Tristan Van Berkom]

Hi Matthias,

On Sun, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote:
> I've pushed a flowbox branch, which adds a GtkFlowBox widget. It is a
> copy of the EggFlowBox widget that has been developed in the
> egg-list-box module for a while, which is in turn based on an earlier
> EggSpreadTable in libegg.

Based on EggWrapBox... EggSpreadTable was something a bit different.

> 
> I think the widget is more or less ready to land in GTK+. It has
> - accessibility
> - height-for-width
> - keynav
> 
> - documentation
> 
> - multi-selection including rubberband selection and autoscroll
> 
> - sorting and filtering
> 
> 
> Some things could still be added:
> 
> - baseline alignment
> 
> - headers
> 
> 
> I'd appreciate review. I'm hoping to land this in the next week or so.
> 
I ran the demo, looked over the API and read some portions of the code,
not line by line... here are my comments:

  o The flow box doesn't really flow anymore, i.e. differently sized
items can no longer wrap freely in the allocated space.

This is a bit disappointing, I also notice that this is already
missing in EggFlowBox, which removes the 'allocation-mode' and adds
a 'homogeneous' property.

The result is that wrapping/flowing widgets in this GtkFlowBox can
only ever show up as columns.

FWIW, the mode that does still exist was a sort of hack to optimize
what would otherwise be 'homogenous' mode, which turns a flow box
into grid like columns anyway.

An example of the functionality we are missing from wrap box:
+---+-+--+
|   A   | B   |//|
+---++---+---++--+
| C  |   D   |   E   |   F   |
++---+---+---+

In the above, the items A-F flow/wrap freely into the available
space, potentially showing the most content possible using less
height to do so.

To see it in action, try running:

./libegg/libegg/wrapbox/testwrapbox
  o Set the test items to "wrappy" for different sized items
  o Set the allocation mode to "wrap free"

  o I like how the spreading options were replaced with the align
properties, it seems we achieve more or less the same effect
by using the align property values.

  o gtk_flow_box_insert() or gtk_container_add() add an intermediate
child, breaking the logical widget hierarchy.

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

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

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

  o Problem in the demo/testflowbox... check and then uncheck the
"Filter" option, for some reason the items which were filtered out
don't show up again.

Not sure if this is a bug in the test case of in the widget code.


Cheers,
-Tristan



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


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

Re: Stock Items Deprecation

[Tristan Van Berkom]

I believe that this is exactly what GtkIconFactory is there for, it allows
you to define named icons for various widget states including RTL/LTR.

Thankfully GtkIconFactory != stock icons... but unfortunately it looks as
though a deprecation of GtkIconFactory snuck in with the stock icon
deprecation (presumably under the guise that the two are somehow related).

Ok, sorry for venting my frustration, but is there really any justification
for this additional deprecation of a useful feature ?

It's also frustrating that GtkIconFactory is silently removed, after not
even receiving any reply on the topic, which was discussed only a
month or two ago:
   https://mail.gnome.org/archives/gtk-devel-list/2013-May/msg00063.html

Is it too late to reverse this deprecation for 3.10 ?

Cheers,
 -Tristan


On Thu, Jul 25, 2013 at 11:37 AM, phil  wrote:
>
> On 02/07/13 14:41, William Jon McCann wrote:
>>
>> Hi,
>>
>> As some of you may have noticed we have recently deprecated Stock Items
>> in master.
>>
>> Some details on this change may be found here:
>>
>> https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub
>>
>> Please let us know what you think.
>
>
> The document doesn't mention anything about stock icons with rtl variants. I
> just changed some code from using the "stock-id" property of a
> GtkCellRendererPixbuf to "icon-name" and I only see the ltr versions of the
> media-playback-start icon on a rtl locale. Is it now the applications
> responsibility to take care of this by changing the icon name or is it just
> a bug? If it is now up to the application then I think that is (a) not a
> good idea as people will forget to do it and (b) it also needs a prominent
> mention in the migration guide.
>
> As others have mentioned it is unfortunate eliminating the #defines for
> stock items also eliminates all compile-time checks for valid icon names &
> makes errors in common menu items more likely.
>
> One other thing, I'm wondering why the migration guide and rationale are on
> goggle docs which tracks who is viewing what and which links they click on
> in the documents. It seems a bit incongruous as GNOME is currently fund
> raising for privacy enhancements and has it's own wiki.
>
> Best Wishes
>
> Phillip Wood
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Expand the child in the GtkHeaderBar

[Tristan Van Berkom]

On Fri, Jul 5, 2013 at 10:55 PM, Yosef Or Boczko  wrote:
> Good afternoon!
>
> I wrote a program that uses in GtkHeaderBar [1].
> In the GtkHeaderBar I put a buttons (GtkButton) and also entry (GtkEntry):
> entry-without-expand.png [2]:
> |<>| |--- entry ---|   | X
>
> I tried to expand the entry which is in haderbar, see something like this:
> entry-with-expand-gimp-editor.png [3]:
> |<>| |- entry -| | X
>
> To expand, I tired use the following functions:
> gtk_widget_set_vexpand (entry, TRUE); /* It does nothing, not expand! */
> g_object_set (entry, "expand", TRUE, NULL); /* It also does nothing, not
> expand */
> It does not work!

Why are you using GtkHeaderBar ?

>From what I understand, the main feature of GtkHeaderBar is to center
the title text in the allocation regardless of the size of any sibling
widgets which are to the left or right.

But you are not displaying a title anyway... so why not just use a
horizontal GtkBox ?

Cheers,
-Tristan

>
> There is a way to expand the entry in headerbar?
>
> I do it so that to port the toolbar in nautilus (NautilusToolbar) to
> headerbar.
>
> [1] attached: main.c or:
> https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/main.c?at=master
>
> [2] attached: entry-without-expand.png or:
> https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/entry-without-expand.png?at=master
>
> [3] attached: entry-with-expand-gimp-editor.png or:
> https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/entry-with-expand-gimp-editor.png?at=master
>
> Regards,
> Yosef Or Boczko
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Tristan Van Berkom]

On Tue, Jul 2, 2013 at 10:41 PM, William Jon McCann
 wrote:
> Hi,
>
> As some of you may have noticed we have recently deprecated Stock Items in
> master.
>
> Some details on this change may be found here:
> https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub
>
> Please let us know what you think.

Besides what Bastian already points out, I have another concern if we
are to consider moving
away from stock items completely.

The document above points to this list of icon names:
   
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names

What guarantees do we have that referring to an icon name in the "icon
naming spec" will
actually produce an icon ?

Will GTK+ have a dependency on an installed icon theme which conforms
to the basic spec ?
(can GTK+'s configure script verify that there is a *complete* set of
icons installed and bail
out if it's not the case ?).

When you refer to a stock icon, you know that if you installed GTK+ on
a given system,
the icon will be there, period, if it's not overridden by an icon
theme, there is always a default
icon.

Having constant definitions of available stock items is also a nice
thing to have i.e.
referring to GTK_STOCK_BUMBLEBEE produces a compiler error, refering to
"gtk-stock-bumblebee" will happily compile and leave you wondering if:

  a.) Did I misspell "bumblebee" ?
  b.) Is "bumblebee" really an icon name ?
  c.) Did I use the wrong Icon Theme, which failed to install a
"bumblebee" icon ?
  d.) Was I so ignorant to use an icon name which was only supported by the
   Icon Theme that existed in my GNOME desktop environment ? Should
   I have known better that "bumblebee" would not exist in other
environments,
   like the embedded device I just setup ?

I'm not really against moving away from the stock items, but I think
that it's important
to be able to guarantee which icon names will be provided for *any*
installation of GTK+,
even if this is a small list of guaranteed icons.

Cheers,
-Tristan

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

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Sun, Jun 23, 2013 at 4:50 PM, Pietro Battiston  
wrote:
> Hi Tristan,
>
> thank you for your clarification. I seem to understand there is
> currently no real answer to my needs, but let me stress a couple of
> points just to be sure I was clear:
>
> Il giorno mer, 19/06/2013 alle 23.00 +0900, Tristan Van Berkom ha
> scritto:
>> On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
>>  wrote:
>> > Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
>> > scritto:
>> >> On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston 
>> >>  wrote:
>> >> >[...]
>> >> > This is, to my eyes, the clearest example of height-for-width space
>> >> > management... and as far as I understand, it is currently impossible.
>> >> >
>> >> > Am I missing something?
>> >>
>> >> This is possible, but I don't know any widgets which do that, that's all.
>> >>
>> >> void
>> >> widget_get_preferred_height_for_width (GtkWidget *widget,
>> >> gint width,
>> >> gint *minimum,
>> >> gint *natural)
>> >> {
>> >>/* You are going to be allocated 'width' which is something greater
>> >> * than the minimum width you reported in
>> >> get_preferred_width_for_height( height = -1);
>> >> */
>> >>
>> >>/* Now you will *request* this much height */
>> >>*minimum = height;
>> >>
>> >>/* Note that 'natural' must be at least as big as 'minimum' */
>> >>*natural = desired_height_for_given_width (height);
>> >>
>> >>/* Now you will *request* this much height */
>> >>*minimum = *natural = height;
>> >> }
>> >>
>> >> Note that you might be allocated more size than that which you requested,
>> >> but not less.
>> >>
>> >> You might want your aspect ratio height to be the minimum & natural
>> >> instead of 'square', depending.
>> >>
>> >> Does this answer your question ?
>> >>
>> >
>> > Well, this did suggest to me that my question was maybe not well
>> > formulated - in fact, I have a problem with the layouting algorithm, not
>> > with the working of a widget on its own. So consider this simple
>> > example:
>> >
>> > 1) in my widget_get_preferred_width(), I set
>> >*minimum = 50
>> >*natural = 200
>> >
>> > 2) in my widget_get_preferred_height_for_width(), I set
>> >*minimum = *natural = 1/width
>> >
>> > 3) I pack_start this widget into a Gtk.VBox()
>> >
>> > 4) I add the VBox in a Gtk.Window, and show_all() it
>> >
>> > Result: a window that's 200x200 (and the user can't shrink vertically).
>> >
>> > Now repeat the steps above, adding, between 3 and 4:
>> >
>> > 3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
>> > GtkImage, that's irrelevant).
>> >
>> > Result: a window that's 200x183!
>> >
>> > So to resume: what annoys me - in both cases - is that the window is
>> > much too tall, and the user cannot even shrink it vertically.
>> > But what I really find inconsistent is that by adding a widget below,
>> > the resulting window may become smaller!
>> >
>> > Anyway, I don't have a better algorithm in mind - if you tell me that
>> > there is nothing I'm missing and there is no obvious solution to such
>> > problem, I'll just make things work reasonably in reasonable contexts.
>>
>> It sounds like you're running into some issues with how the toplevel
>> decides to allocate the default size.
>>
>> When I wrote height-for-width, I made sure the default size was
>> minimum height for minimum width, and then ensured that labels
>> requested a reasonably large minimum width by default (unless
>> the user sets width-chars explicitly to a small value).
>>
>> This has been changed in GTK+ and I'm not sure what the details
>> are exactly now, first the trick I played to ensure labels were
>> reasonably wide by default was removed (resulting in some tall
>> dialogs with wrapping text in 3.2 or 3.4), now there i

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
 wrote:
> Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
> scritto:
>> On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston  
>> wrote:
>> >[...]
>> > This is, to my eyes, the clearest example of height-for-width space
>> > management... and as far as I understand, it is currently impossible.
>> >
>> > Am I missing something?
>>
>> This is possible, but I don't know any widgets which do that, that's all.
>>
>> void
>> widget_get_preferred_height_for_width (GtkWidget *widget,
>> gint width,
>> gint *minimum,
>> gint *natural)
>> {
>>/* You are going to be allocated 'width' which is something greater
>> * than the minimum width you reported in
>> get_preferred_width_for_height( height = -1);
>> */
>>
>>/* Now you will *request* this much height */
>>*minimum = height;
>>
>>/* Note that 'natural' must be at least as big as 'minimum' */
>>*natural = desired_height_for_given_width (height);
>>
>>/* Now you will *request* this much height */
>>*minimum = *natural = height;
>> }
>>
>> Note that you might be allocated more size than that which you requested,
>> but not less.
>>
>> You might want your aspect ratio height to be the minimum & natural
>> instead of 'square', depending.
>>
>> Does this answer your question ?
>>
>
> Well, this did suggest to me that my question was maybe not well
> formulated - in fact, I have a problem with the layouting algorithm, not
> with the working of a widget on its own. So consider this simple
> example:
>
> 1) in my widget_get_preferred_width(), I set
>*minimum = 50
>*natural = 200
>
> 2) in my widget_get_preferred_height_for_width(), I set
>*minimum = *natural = 1/width
>
> 3) I pack_start this widget into a Gtk.VBox()
>
> 4) I add the VBox in a Gtk.Window, and show_all() it
>
> Result: a window that's 200x200 (and the user can't shrink vertically).
>
> Now repeat the steps above, adding, between 3 and 4:
>
> 3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
> GtkImage, that's irrelevant).
>
> Result: a window that's 200x183!
>
> So to resume: what annoys me - in both cases - is that the window is
> much too tall, and the user cannot even shrink it vertically.
> But what I really find inconsistent is that by adding a widget below,
> the resulting window may become smaller!
>
> Anyway, I don't have a better algorithm in mind - if you tell me that
> there is nothing I'm missing and there is no obvious solution to such
> problem, I'll just make things work reasonably in reasonable contexts.

It sounds like you're running into some issues with how the toplevel
decides to allocate the default size.

When I wrote height-for-width, I made sure the default size was
minimum height for minimum width, and then ensured that labels
requested a reasonably large minimum width by default (unless
the user sets width-chars explicitly to a small value).

This has been changed in GTK+ and I'm not sure what the details
are exactly now, first the trick I played to ensure labels were
reasonably wide by default was removed (resulting in some tall
dialogs with wrapping text in 3.2 or 3.4), now there is some other
logic/priority used to guess an appropriate window height (and
I think that's changed very recently, Matthias and Benjamin have
been fixing GtkWindow default sizes afaik so they would be able
to better comment on this).

However I think that what you are trying to do is a bit application
specific and not necessarily in the right place.

The layouting code is used to share space in what is allocated
in a toplevel window (and define some minimums, those minimums
should really be the minimum required to display some content).

If there is no left over space in your application (i.e. no scrolled window,
no area where it is useful to put extra space and then sacrifice some height
if the window is too 'slim' to fit other content), then height-for-width is
not really for you.

What you probably want, is a widget which requests 1x1 width & height,
and is placed in a position where it will receive expand space in both
axis... after allocating you then decide to draw whatever fits in the
space you were allocated, centering  it and drawing it with the desired
aspect ratio (as for example, totem movie player would do with it's
gstreamer widget to fit a scaled video surface into the area available
while preserving the aspect ratio).

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

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston  
wrote:
> Il giorno mer, 19/06/2013 alle 13.40 +0900, Tristan Van Berkom ha
> scritto:
>> On Wed, Jun 19, 2013 at 1:31 AM, Pietro Battiston  
>> wrote:
>> > [...]
>> > If I'm honest about the minimum width, then the (corresponding) minimum
>> > height required is assumed to be something huge, and the result (for
>> > instance directly inside a window) is ugly.
>>
>> This is the nature or height for width, minimum height for minimum width
>> will usually be tall and slim.
>>
>> However there are a few tactics to use which ensure that tall and slim 
>> windows
>> don't occur.
>>
>
> Notice the window in my case is not tall and slim, it is tall and large!
> Because the width is the natural one, but the minimal height corresponds
> to the minimal width.
>
>
>>a.) The toplevel window should not by default present itself at
>> minimum width,
>> I think currently GTK+ toplevels use some trickery with natural 
>> width.
>>
>> I.e., the height of a window is not determined by the minimum
>> width of a window,
>> it's determined by the height for the width which will be
>> *allocated* to the window
>> (that's an important difference).
>
>
> Maybe I misunderstand you, but what seems to happen is precisely that
> the height of a window is "determined by the minimum width of a window":
>
> git clone git://pietrobattiston.it/quack
> cd quack
> git checkout wrapbox_error
> cd plugins/tags
> python test_wrapbox.py
>
>
>> [...]
>>
>>b.) Make sure that labels do not request a ridiculously small
>> minimum width when they
>> are set to wrap.
>>
>
> OK, fine - labels were just an example, I don't claim I know better than
> anybody else how they should behave.
>
>
>>
>>c.) Height for width makes more sense when there are areas in your
>> application which
>> might be smaller or larger or contain some content which might
>> not always be visible.
>> [...]
>
> Sure.
>
>
>>
>> > [...]
>> >
>> > Or in few words: am I missing anything? Taking it to the extreme, is
>> > there actually any way to create a simple widget which always asks for
>> > 100 000 pixels of screen space, but is totally indifferent with respect
>> > to the aspect ratio?
>>
>> Of course, many widgets do this, i.e. a GtkImage loaded from a pixbuf only
>> requests the size of the image, and does not trade any height for width.
>
> Actually, what I'm asking is exactly the opposite: is there any way to
> create a simple widget which
> 1) requests (=minimal) a rectangular area of 10 000 pixels, accepting
> any possible ratio going from 20 x 500 to 500 x 20
> 2) suggests (=natural) a 100 x 100 square
> ?
>
> This is, to my eyes, the clearest example of height-for-width space
> management... and as far as I understand, it is currently impossible.
>
> Am I missing something?

This is possible, but I don't know any widgets which do that, that's all.

void
widget_get_preferred_height_for_width (GtkWidget *widget,
gint width,
gint *minimum,
gint *natural)
{
   /* You are going to be allocated 'width' which is something greater
* than the minimum width you reported in
get_preferred_width_for_height( height = -1);
*/

   /* Now you will *request* this much height */
   *minimum = height;

   /* Note that 'natural' must be at least as big as 'minimum' */
   *natural = desired_height_for_given_width (height);

   /* Now you will *request* this much height */
   *minimum = *natural = height;
}

Note that you might be allocated more size than that which you requested,
but not less.

You might want your aspect ratio height to be the minimum & natural
instead of 'square', depending.

Does this answer your question ?

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

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Wed, Jun 19, 2013 at 1:31 AM, Pietro Battiston  
wrote:
> Dear developers,
>
> I've written a plugin. It is a simple WrapBox, similar to the one which
> was for some time in gtk2 (or at least I think so - I did not actually
> see it working, only read some mails about it). I tell you this only to
> make you grasp an idea of how magically such a plugin can benefit from
> the gtk3 space allocation mechanism: it can play well with a width which
> is just the width of the smallest child, but also with a width which is
> the sum of them all - in the first case, taking many rows, in the
> second, taking only one.
>
> Well, no, I'm lying, it does not, for the simple reason that I stumbled
> in the problem perfectly described by Owen here:
> https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00087.html
>
> If I'm honest about the minimum width, then the (corresponding) minimum
> height required is assumed to be something huge, and the result (for
> instance directly inside a window) is ugly.

This is the nature or height for width, minimum height for minimum width
will usually be tall and slim.

However there are a few tactics to use which ensure that tall and slim windows
don't occur.

   a.) The toplevel window should not by default present itself at
minimum width,
I think currently GTK+ toplevels use some trickery with natural width.

I.e., the height of a window is not determined by the minimum
width of a window,
it's determined by the height for the width which will be
*allocated* to the window
(that's an important difference).

There was also talk about creating an algorithm to aim for
something closest
to the screen's aspect ratio when trying to guess a default window size
(if the programmer did not provide a default size with
gtk_window_set_default_size()).

I think Bejamin Otte might know a bit more about the current
functionality of
GtkWindow.

   b.) Make sure that labels do not request a ridiculously small
minimum width when they
are set to wrap.

This can be done by setting the 'width-chars' property
(originally I had an automatic
minimum width which was larger than "..." but I think that got
removed early in
the 3.0 cycle, causing the tall/skinny dialogs we've seen in
some apps, which I
think was fixed by some other patch to make the GtkWindow
request something
more reasonable since then).

   c.) Height for width makes more sense when there are areas in your
application which
might be smaller or larger or contain some content which might
not always be visible.

I.e. many applications contain paned windows with scrolled
windows, this is where
height for width becomes interesting, because generally the
user's window will be larger
than the minimum possible size.

In this case shrinking the window width would cause some
content to wrap and show
less of the content in the scrolled window area below, making
the window wider will
unwrap and then reveal more of the content in the scrolled window.

The goal is to show as much content that is reasonably
possible, while minimizing
the useless blank space between widgets as much as possible.

> I could in principle
> understand (though it seems to me a hack) that a Gtk.Label doesn't
> declare its minimal width as the width of its largest word. But in the
> current design the author of a widget can't in fact, declare _any_
> minimum width smaller than the natural width - otherwise (what gtk will
> consider) the minimum height will be _larger_ than the space which the
> widget does use, and this will look horrible.
>
> To be honest, I did read the thread which followed the mail linked
> above... but I I'm not sure I fully understood it completely. So I'm
> writing to ask:
> 1) did I say something wrong in my short analysis?
> 2) can you confirm that things are as they were when that thread
> developed?
>
> Or in few words: am I missing anything? Taking it to the extreme, is
> there actually any way to create a simple widget which always asks for
> 100 000 pixels of screen space, but is totally indifferent with respect
> to the aspect ratio?

Of course, many widgets do this, i.e. a GtkImage loaded from a pixbuf only
requests the size of the image, and does not trade any height for width.

I hope this answers most of your questions.

Cheers,
-Tristan

>
> Thank you in advance for any enlightnement,
>
> Pietro
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New GObject Introspection tutorial

[Tristan Van Berkom]

On Thu, Jun 13, 2013 at 3:54 PM, Simon Kågedal Reimer
 wrote:
> Hello!
>
> I've written a tutorial on how to make a basic multilevel "Hello
> World" using GObject Introspection:
>
> http://helgo.net/simon/introspection-tutorial/
>

Just a small nitpick, you are missing introspection comments
in the 'greetee' property:

/**
 * TutGreeter:greetee:
 *
 * The entity to greet.
 */
obj_properties[PROP_GREETEE] =
 

Without comments on properties (and signals), then it becomes impossible
to tell certain things about these entities, such as the ABI version
in which they
are introduced, and whether they are deprecated (this information can be useful
for compilers who wish to implement 'greeter.greetee = greetee' using
g_object_set(),
so they can warn about use of deprecated properties, or fire runtime errors if
the runtime C library is not as new as the C library which the calling
application
was compiled for).

Not to mention, it becomes impossible for us to know the version in which
a property was installed in Glade.

While this introspection comment might not be relevant to your tutorial per se,
if we publish this then we will be setting a trend, and it would be nice to set
the trend of complete introspection comments (not to get lazy when it comes
to commenting on properties and signals, which are also a part of the API).

Cheers,
-Tristan

> It's written in Mallard; the markup is in a git repository at
> https://www.gitorious.org/gobject-introspection-tutorial
>
> There's a fine tutorial on this subject at the Gnome Live wiki, but
> there were a few things I thought should be different. It uses
> Clutter, which I think gets in the way if you're not already familiar
> with that library; I couldn't get it to build since my system has
> Clutter 1.0 and the tutorial uses 0.8. I also think it's preferable to
> show the build steps such as g-ir-scanner instead of using a build
> tool (waf) not all readers will be familiar with, and to not rely so
> much on git.
>
> So I wrote this as a way of learning for myself. I was also influenced
> by a blog post by Miguel de Icaza to add some exercises. :-) Would
> love to get all kinds of feedback, on both content and style. I have
> some ideas for future expansion, should really cover annotations e.g.
> And I need to figure out how to get yelp-build to use a Gnome standard
> style sheet that looks nicer on the web.
>
> Regards,
> Simon Kågedal Reimer
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GtkIconSize/GtkIconFactory [was: Re: wip/hires-icons]

[Tristan Van Berkom]

[branching thread here]

On Fri, May 17, 2013 at 8:20 PM, Alexander Larsson  wrote:
[...]
>> This branch doesn't precisely reinvent the wheel, there's just a few API
>> additions to current components to have this work as seamlessly as
>> possible. As choosing an icon must be postponed till rendering time, the
>> preferred way to hold this information is GtkIconSet and GtkIconSource,
>> as these already do a few things we want here:
>>
>>   * It may already hold multiple sources for an image
>>   * GtkIconSize works as a scale-independent size abstraction
>>
>> This has implied making GtkIconSets more prominent, so the matching
>> properties have been added to GtkEntry and GtkCellRendererPixbuf.
>>
>> GtkIconTheme has been regarded as a lower level file->pixbuf abstraction
>> and mainly a few *_for_scale() calls have been added there so
>> GtkIconSets can resolve rendering to the bes3t pixbuf.
>
> Ugh. I hate GtkIconFactory. Mainly due to the GtkIconSize abstraction.
> Any time i use it I have to fight that crap, because what you really
> *do* want is a (possibly scaled) pixel size. In fact, GtkIconFactory has
> been mostly "deprecated" due to this and all modern code use icon names
> and GIcons.

Hmmm, I happen to really like the GtkIconSize abstraction (and have
found that GtkIconFactory is a nice way to get custom icons into applications).

I'm curious, from a user facing API perspective, why we would want a pixel size
instead of a nice symbolic GtkIconSize in the form of an enumeration ?

Main reason I'm asking about this, is because GtkIconSize itself seems to
be the only sensible thing to configure an icon with in Glade.

Also Glade supports GtkIconFactory which seems to be a very practical way
to introduce custom icons into an application (since any pixbuf added to the
icon factory can then be referenced by the "icon-name" property which is
already available for many widgets).

Also we don't have any support for GIcons, and I'm not sure how exactly
we should support them to be loadable in GtkBuilder script (or more importantly,
"why" we would want to support that when we already have a pretty usable
interface of "icon-name" and "icon-size" pairs already on many widgets).

My understanding of GIcon so far has been that, it's a low level abstraction
which helps widgets with implementing the user facing APIs of themed icons
and icon sizes.

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

Re: Crashes with long words in strings passed to gtk_widget_set_tooltip_text()

[Tristan Van Berkom]

On Sat, May 11, 2013 at 8:56 PM, Fabian Keil
 wrote:
> Fabian Keil  wrote:
>
>> Emmanuel Thomas-Maurin  wrote:
>>
>> > On 04/21/2011 02:44 PM, Fabian Keil wrote:
>>
>> > > I haven't filed a bug report yet as it wasn't clear to me
>> > > if the behaviour is actually considered a bug. If there's
>> > > an agreement that the behaviour is a bug, I wouldn't mind
>> > > filing one.
>> >
>> > IMHO, it's definitely a bug and it's worth beeing reported so that it
>> > can be reviewed, along with your patch, by a maintainer, then finally 
>> > fixed.
>>
>> I filed https://bugzilla.gnome.org/show_bug.cgi?id=648381
>
> And two years later this bug still exists ...
>

FWIW, compiling the same program with GTK+-3 doesn't crash for me
(it simply doesn't display the ridiculously large tooltip at all, which seems
reasonable).

Probably this is something that can be backported to GTK+2 (if it's
not too GDK centric, at least).

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

Re: CSS Transitions

[Tristan Van Berkom]

On Fri, May 10, 2013 at 7:05 PM, Allan Day  wrote:
> Owen Taylor  wrote:
>> I think you can quickly get into prohibitively heavy complexity here,
>> which is why, presumably, that CSS doesn't try to to have the idea of
>> start and end states.
>
> Indeed.

Just out of curiosity... wouldn't it make sense to have the concept of
start and end states, if at least the start states could be wildcarded ?

This way one could specify:

  "pressed" -> "insensitive" (a custom transition to become insensitive)
  "*" -> "insensitive" (the default transition to become insensitive)

Anyway, if this is intentionally impossible by the CSS specification,
and if we are hell bent on following that specification to the letter,
then I suppose there is no argument... just seems a bit impractical
to define these intermediate states in code...

Cheers,
-Tristan

>> If I was handling this on the web, I'd probably do something like,
>> in setup:
>>
>>   $(button).transitionEnd(
>>function() {
>>$(this).removeClass('pressing');
>>});
>>
>> When pressed:
>>
>>  $(button).addClass('pressed').addClass('pressing');
>>
>> In CSS:
>>
>>  .button.pressed { background: red; }
>>  .button.pressing { transition: background 1s; }
>>
>> I think we possibly should do something similar here. We could do
>> something like:
>>
>>  gtk_style_context_add_temporary_class(button,
>> GTK_STYLE_CLASS_PRESSING);
>>
>> With the semantics of "temporary" meaning "removed when last transition
>> finishes". I don't think you'd need many of these style classes to allow
>> most of what the designers want.
>
> If you want to get an idea of how many transitions there might be, I'd
> be happy to write up what I'd like to happen in terms of behaviour.
>
> Allan
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: capture "changed" signal for the cell of treeview

[tristan . van . berkom]

On 2013-05-04, at 7:00 PM, yu wu  wrote:

> As I wrote in my original email, the renderer is ** not ** set editable. 
> Therefore, it can't be connected to ** edited ** signal. 
> 
> Here is the situation for example. Renderer 1 -- column 0 is set editable. 
> Renderer 2-4, i.e., column 1-3, is not set editable. When column 0 is edited, 
> the value of column 1 is set. As to the values for column 2-3, they are set 
> by other functions. Then I would like to capture the changes of column 1-3. 
> After I get the changes, some other widgets (inside treeview or outside 
> treeview) will be updated. 
> 

I see, well the most efficient way to handle your situation really depends on 
what you need.

For your other display widgets, you might consider using GtkCellView (a widget 
for rendering a single row from a tree model), or like you mention in the other 
mail, you could listen to "row-chaned" and update all the widgets which need to 
display the changed row.

You could also implement custom display widgets like GtkCellView, by keeping a 
GtkTreeRowReference, queuing a redraw when the row changes, and drawing the 
visual state based of the row data at "draw" time.

> By the way, I don't know the difference between gtk-list and gtk-devel-list. 
> Now I know it. Could you or someone tell me how to move this post to gtk-list?

Don't worry about it, posts can't be "moved", just use the other lists next 
time ;)

> 
> 在 2013年5月4日星期六，Tristan Van Berkom 写道：
> On Sat, May 4, 2013 at 12:37 PM, yu wu  wrote:
> > I am using the followed to renderer text in cells:
> >
> > 
> >
> >   renderer = gtk_cell_renderer_text_new();
> >   column = gtk_tree_view_column_new_with_attributes((local = char_to_utf8
> > ("weight(kg/m)")), renderer, "text", MEM_SEC_WEIGHT_PER_METER, NULL);
> >   g_free(local);
> >   gtk_tree_view_append_column(treeview, column);
> >
> > 
> >
> > I don't set `editable' attribute for the renderer. The value for specified
> > cell is set by
> >
> > other sub-function. Then how can I get the `changed' signal for the
> > specified cell when its
> > value is changed? My purpose is to update other widget when text value in
> > cell is changed.
> > For the text cell renderer, it only has edited signal that is not useful for
> > my case
> 
> How come the "edited" signal is not useful ?
> 
> You want to catch *every* change while the user is editing a cell ?
> 
> This can be done, but it kind of changes the way cell editing usually
> works, i.e. pressing escape, or losing editor focus while editing a text
> cell is generally supposed to "cancel" the current edit, hence usually
> you wait until the "edited" signal is fired in order to commit any changes
> to the underlying model.
> 
> If you need to handle every keystroke, then connect to the "editing-started"
> signal of a GtkCellRendererText for example, the GtkCellEditable widget will
> in this case be a GtkEntry (which will exist for the duration of the edit), 
> then
> you can connect to the "changed" signal of this entry.
> 
> Note also, this list is about development of GTK+ itself, you should direct
> your questions about using GTK+ to gtk-app-devel-list instead.
> 
> Cheers,
>-Tristan
> 
> > (or maybe I misunderstand some points). When some cell is changed, it might
> > have no
> > any selection. That's, the `changed' signal for selection has no use here.
> >
> > Please help.
> >
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: capture "changed" signal for the cell of treeview

[Tristan Van Berkom]

On Sat, May 4, 2013 at 8:02 PM, yu wu  wrote:
> Since more than one column is changed, row-changed signal will be emitted
> more than once and widgets will be updated more than once. But I just want
> to update other widget once.

This is only more or less true.

When you receive "row-changed" multiple times, then you probably do
something like:

  o gtk_label_set_text()... which is not going to queue a redraw if
the new text is the same as the old text

  o If the text has changed, it will queue a redraw...

So even if a couple things actually changed on a couple different
widgets, that is all happening
synchronously, and then a redraw is queued, things only get painted
once with the new value.

Cheers,
   -Tristan

> This is why I want to know if it is possible to
> know which column is changed in other email. But from your reply to my other
> email, there is no way to know which column to change when row-changed is
> emitted. Then I have to update widgets when cell of column 0 is edited or in
> other functions which result in the change in column 1~3 mentioned above.
>
> As to GtkCellView, I have never used it. I have to read it first and then
> see.
>
>
> 2013/5/4 
>
>>
>> On 2013-05-04, at 7:00 PM, yu wu  wrote:
>>
>> As I wrote in my original email, the renderer is ** not ** set editable.
>> Therefore, it can't be connected to ** edited ** signal.
>>
>> Here is the situation for example. Renderer 1 -- column 0 is set editable.
>> Renderer 2-4, i.e., column 1-3, is not set editable. When column 0 is
>> edited, the value of column 1 is set. As to the values for column 2-3, they
>> are set by other functions. Then I would like to capture the changes of
>> column 1-3. After I get the changes, some other widgets (inside treeview or
>> outside treeview) will be updated.
>>
>>
>> I see, well the most efficient way to handle your situation really depends
>> on what you need.
>>
>> For your other display widgets, you might consider using GtkCellView (a
>> widget for rendering a single row from a tree model), or like you mention in
>> the other mail, you could listen to "row-chaned" and update all the widgets
>> which need to display the changed row.
>>
>> You could also implement custom display widgets like GtkCellView, by
>> keeping a GtkTreeRowReference, queuing a redraw when the row changes, and
>> drawing the visual state based of the row data at "draw" time.
>>
>> By the way, I don't know the difference between gtk-list and
>> gtk-devel-list. Now I know it. Could you or someone tell me how to move this
>> post to gtk-list?
>>
>>
>> Don't worry about it, posts can't be "moved", just use the other lists
>> next time ;)
>>
>>
>> 在 2013年5月4日星期六，Tristan Van Berkom 写道：
>>>
>>> On Sat, May 4, 2013 at 12:37 PM, yu wu  wrote:
>>> > I am using the followed to renderer text in cells:
>>> >
>>> > 
>>> >
>>> >   renderer = gtk_cell_renderer_text_new();
>>> >   column = gtk_tree_view_column_new_with_attributes((local =
>>> > char_to_utf8
>>> > ("weight(kg/m)")), renderer, "text", MEM_SEC_WEIGHT_PER_METER, NULL);
>>> >   g_free(local);
>>> >   gtk_tree_view_append_column(treeview, column);
>>> >
>>> > 
>>> >
>>> > I don't set `editable' attribute for the renderer. The value for
>>> > specified
>>> > cell is set by
>>> >
>>> > other sub-function. Then how can I get the `changed' signal for the
>>> > specified cell when its
>>> > value is changed? My purpose is to update other widget when text value
>>> > in
>>> > cell is changed.
>>> > For the text cell renderer, it only has edited signal that is not
>>> > useful for
>>> > my case
>>>
>>> How come the "edited" signal is not useful ?
>>>
>>> You want to catch *every* change while the user is editing a cell ?
>>>
>>> This can be done, but it kind of changes the way cell editing usually
>>> works, i.e. pressing escape, or losing editor focus while editing a text
>>> cell is generally supposed to "cancel" the current edit, hence usually
>>> you wait until the "edited" signal is fired in order to commit any
>>> changes
>>> to the underlying model.
>>>
>>> If you need to handle every keystroke, then connect to the
>

Re: which column cell is changed when "row-changed" is emitted

[Tristan Van Berkom]

On Sat, May 4, 2013 at 12:44 PM, yu wu  wrote:
> For the signal "row-changed" of GtkTreeModel, how can I know which column
> cell is changed. For example, I defined 10 renderers by
> `gtk_cell_renderer_text_new' which means 10 columns. When column 1 and
> column 3 in a row are changed, the signal "row-changed" will be emitted
> twice. Then how can I know who emitted the change -- column 1 or column 3?

You don't need to know which cell renderer is effected by a given row change,
in fact, even if you did, you wouldn't be informed of what data in the row has
changed, only that the row itself has changed.

The row change will cause the GtkTreeView/GtkIconView to render the row
again (if it's visible), at which time the renderer will render the new data
(or your custom function will set the cell attributes, if you used
gtk_cell_layout_set_cell_data_func()).

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

Re: capture "changed" signal for the cell of treeview

[Tristan Van Berkom]

On Sat, May 4, 2013 at 12:37 PM, yu wu  wrote:
> I am using the followed to renderer text in cells:
>
> 
>
>   renderer = gtk_cell_renderer_text_new();
>   column = gtk_tree_view_column_new_with_attributes((local = char_to_utf8
> ("weight(kg/m)")), renderer, "text", MEM_SEC_WEIGHT_PER_METER, NULL);
>   g_free(local);
>   gtk_tree_view_append_column(treeview, column);
>
> 
>
> I don't set `editable' attribute for the renderer. The value for specified
> cell is set by
>
> other sub-function. Then how can I get the `changed' signal for the
> specified cell when its
> value is changed? My purpose is to update other widget when text value in
> cell is changed.
> For the text cell renderer, it only has edited signal that is not useful for
> my case

How come the "edited" signal is not useful ?

You want to catch *every* change while the user is editing a cell ?

This can be done, but it kind of changes the way cell editing usually
works, i.e. pressing escape, or losing editor focus while editing a text
cell is generally supposed to "cancel" the current edit, hence usually
you wait until the "edited" signal is fired in order to commit any changes
to the underlying model.

If you need to handle every keystroke, then connect to the "editing-started"
signal of a GtkCellRendererText for example, the GtkCellEditable widget will
in this case be a GtkEntry (which will exist for the duration of the edit), then
you can connect to the "changed" signal of this entry.

Note also, this list is about development of GTK+ itself, you should direct
your questions about using GTK+ to gtk-app-devel-list instead.

Cheers,
   -Tristan

> (or maybe I misunderstand some points). When some cell is changed, it might
> have no
> any selection. That's, the `changed' signal for selection has no use here.
>
> Please help.
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

On regressions and carelessness

[Tristan Van Berkom]

Dear fellow hackers,

I am sorry to bore you all with this email, I've tried to resolve this
in bugzilla and IRC and failed, if I am to have any trust in GTK+
development practices, I must unfortunately share this conflict
in public.

Around a week ago, while I was tirelessly spending my evenings and
weekends improving Glade, I noticed a height-for-width regression
in GtkBin derived widgets.

While this might not be serious or noticeable for many GNOME core
applications, the regression sticks out like a sore thumb in Glade
(since Glade uses wrapping labels for all of it's property editors, in the
interest of economizing space), and frankly I expect GTK+ to be much
much more than just a toolbox for the current GNOME core applications.

The regression was originally introduced in the 3.8 cycle with this commit:

commit f4438a1ffc6aaab92fb6b751cd16e95c2abaa0e3
Author: Jasper St. Pierre 
Date:   Thu Nov 8 19:13:52 2012 -0500

Which was signed off by Benjamin Otte.

My course of action was to fix the regression, as this is code of my
own doing, and I spent many hours getting it right the first time, I
understand that I have license to fix these things, but fixing it would
not be enough, because if I just fix the regression, who's to say that
this type of careless regression will not recur in the future ?

So, in the interest of notifying those responsible for the regression,
I first opened this bug:
   https://bugzilla.gnome.org/show_bug.cgi?id=698433

Naturally, I wanted to be sure that those who removed code and
caused regressions will pay better attention in the future, so I put
Jasper and Benjamin on CC explicitly in the bug report, in the hope
that they will learn from this and be more careful in the future.

So, I closed the bug after fixing it with this commit:

commit b164df74506505ac0f4559744ad9b59b5ea57ebf
Author: Tristan Van Berkom 
Date:   Sat Apr 20 17:52:16 2013 +0900

And all was well in the world again, labels wrapped and requested
enough height inside their check buttons.

Until yesterday, when I updated my local copy of GTK+ sources again
and rebuilt Glade and found the nasty behaviour again.

This was a blow to the face, the regression was silently re-introduced
without re-opening bug 698433, without even acknowledging that
there is a serious misbehaviour caused by this commit.

After looking through the commit log today I find the offending commit

commit b8e4adfff9ba62330a71ea7498595227979bb4f0
Author: Benjamin Otte 
Date:   Mon Apr 22 08:23:08 2013 -0400

This looks very irresponsible to me, and is alarming for several
reasons.

 a.) It seems that the regression is only a matter of Benjamin's taste,
  he does not like how things are implemented, and instead of
  changing the implementation, he has simply removed code and
  caused regressions.

 b.) It seems that Benjamin's superiority complex transcends the
  need for software that actually works. He would rather have
  the last word and break GTK+ in doing so, than swallowing
  his own pride and living with some code he doesn't like, at
  least until which time he could replace it with code that works
  without introducing regressions in the meantime.

  This is called "too cool for school".

 c.) Worse still, he presumes to suddenly turn this in to my own
  problem. It is his prerogative that he remove code that does
  not suit his taste, and that the regressions he causes should be
  my own fault. That I should devote more of my own time to
  change this implementation to his taste, for "free as in beer".

All I ask of you, dear fellow GTK+ developers, is that responsibility
be taken for your own actions. If your code introduces a regression,
you should be responsible for fixing that regression, it's not right
to introduce regressions and expect that others clean up the mess
you leave behind.

Carelessness is something that we all practice at times, but we
should strive to be less careless. If you read code and you are
uncertain what it does, "Assume people mean well", don't assume
that it's useless and can be safely removed. Removing code that
you do not understand is almost certain to cause breakage.

By all means, simplify code that you do not understand at first
sight, by first understanding why it exists and then replacing it with
something that is more readable, that is a step forward, careless
removal of code however is not a step forward.

I hope you will understand the awkwardness of this, it is with
much regret that I bring this topic to the list.

I sincerely hope that measures will be taken to avoid this type
of carelessness and irresponsibility in the future.

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

Re: regarding GtkIconView

[Tristan Van Berkom]

On Tue, Apr 23, 2013 at 3:30 AM, D.H. Bahr  wrote:

> Hello list!
>
> I'm facing a problem trying to use an IconView: the thing is icons
> inside IconView get distributed considering the size of the IconView at
> population time: if IconView is resized after population the items won't
> accommodate themselves to the new dimensions.
>
> Is this a known bug? Should I be enabling some mask I am not? is this
> implemented via callbacks??
>

Hi,
   GTK+'s test cases seem to show that this is working properly at least
in recent versions.

Make sure you haven't done something like explicitly setting the "columns"
property of the icon view, and it should relayout the icons to fit as many
columns as possible (adding width should result in more columns).

Cheers,
  -Tristan

PS: Perhaps gtk-app-devel-l...@gnome.org is a better venue for
questions related to using GTK+ apis.



> Best regards
>
> http://www.uci.cu
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Wed, 2013-04-17 at 21:42 -0500, Federico Mena Quintero wrote:
> On Thu, 2013-04-11 at 17:49 -0500, Federico Mena Quintero wrote:
> 
> > I'll do something like this.  First, revert the commit.  Then, merge my
> > branch.  Doing a straight rebase is not trivial, as places-sidebar has
> > gotten master merged into it a few times to keep up with general
> > development.  And finally, apply your commit again with lots of changes.
> 
> So I went ahead and did this.  I learned why you don't support binding
> widgets to fields in public structures (it's done on the class private
> structure).
> 
> I refactored your patch to use priv->foo instead of impl->priv->foo
> everywhere, and it is much nicer that way.  I may end up doing this to
> gtk-2-24 as well for consistency.

Yes,
   I admit that wasn't nice of me. I just did a search replace
and it compiled, but you're right, it's much more readable when
you have a 'priv' variable declared in each function.

> 
> Tristan, the composite templates stuff is *excellent* work.  The file
> chooser's code is much cleaner now that all the silly widgetry is
> editable in Glade!
> 
> I guess the next thing would be to have GtkPlacesSidebar set up its
> internal GtkTreeView using Glade.  I'll investigate that later, but if
> you already have a good pattern for doing this... :)
> 
> Thanks for this massively useful work - doing megawidgets in Glade is
> really nice this way.

I'm glad that you enjoy it :)

And I hope it wasn't too much trouble for your merge, I know how big
merges can be discouraging... so thank you too for your patience.

Cheers,
-Tristan


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Thu, 2013-04-11 at 17:49 -0500, Federico Mena Quintero wrote:
> On Thu, 2013-04-11 at 13:36 +0900, Tristan Van Berkom wrote:
> 
> First, let me apologize for the rather harsh tone in my message
> yesterday.  I had a big "WTF" moment when I saw how the composite
> templates patches played badly with my branch.  Your message made things
> look easier to fix than I expected.
> 
> > So, this is how I propose we handle the situation:
> > 
> >   o First, you rebase your branch in such a way
> > that the filechooserdefault is reverted as
> > the first commit in your branch.
> 
> I'll do something like this.  First, revert the commit.  Then, merge my
> branch.  Doing a straight rebase is not trivial, as places-sidebar has
> gotten master merged into it a few times to keep up with general
> development.  And finally, apply your commit again with lots of changes.
> 
> >   o Second, I know you wont like this part but
> > I need you to put the instance members on
> > a private structure.
> > 
> > We do not support automatically assigning
> > component pointers to public structure offsets.
> > 
> > And frankly, using a public structure defined
> > openly in gtkfilechooserprivate.h is an open
> > invitation for other components to access
> > the components of GtkFileChooserDefault directly
> > (which I think we both feel is unintended).
> 
> I totally agree with this for *public* widgets, those that go into the
> public API.
> 
> But for GtkFileChooserDefault, I have two objections:
> 
> 1. It's a private, internal widget, never meant to be exported.
> 
> 2. I'd really really really like to keep the file chooser's code as
> similar as possible between gtk2 and gtk3.  Otherwise, cherry-picking
> fixes becomes much harder.

I can understand the second argument here, but access to components
created from a .ui file can't be done on the public scope of an
instance (whether it's type is private or public).

To illustrate this, this line of code in _class_init():

gtk_widget_class_bind_child (widget_class,
 GtkFileChooserDefaultPrivate,
 browse_files_tree_view);

... makes the 'browse_files_tree_view' variable on the widget's
private data point to the GtkTreeView built by GtkBuilder
for a given instance, automatically, for the lifetime of
the GtkFileChooserDefault's instance.

Now, GtkFileChooserDefault is not public but the
gtk_widget_class_bind_child() API is public.

We have previously decided (Benjamin and I) that the
gtk_widget_class_bind_child() API should not allow automation
of pointers on the public scope of the instance structure.

Supporting the binding of components to the public scope
of an instance would send a sort of message in the API,
like "It's OK and even encouraged, to write code with
members declared on the public scope of a GObject's
instance structure".

This is the main reason for not supporting the public
scope variables.

Now, at the cost of adding more code to GtkFileChooserDefault,
you could call the function gtk_widget_class_automate_child()
with a negative structure offset, which will avoid assigning
the pointer to the private data... and after calling
gtk_widget_init_template(), you could write a bunch of
calls that would look like:

chooser->browse_files_tree_view =
gtk_widget_get_automated_child (chooser,
GTK_TYPE_FILE_CHOOSER_DEFAULT,
"browse_files_tree_view");


However, I think the above is really undesirable, but it may
improve the cherry picking situation between master and gtk-2-24.

Note that the above is available for the sake of language bindings,
which might not be able to use instance private data on the types
that they create.

> 
> I do appreciate having the private stuff in the .c file.  And I
> definitely don't like the current state (well, before your patches)
> where the GtkFileChooserDefault struct is not in
> gtkfilechooserdefault.h, but in a gtkfilechooserprivate.h file.  I don't
> remember why it ended up there; probably so that the unit tests would be
> able to poke at internal widgets.  *That* is not the right thing to do,
> anyway, so I'm happy to see the struct move elsewhere.  But the
> objections still stand.
> 
> I haven't even seen how the code for composite templates pokes at
> structs... but why does it have to care whether the struct is private or
> public?  Could we have:
> 
> gtkfilechooserdefault.h:
> 
>   /* no struct definitions at all */
>   typedef struct GtkFileChooserDefault *GtkFileChooserDefault;
>   typedef struct GtkFileChooserDefaul

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Thu, 2013-04-11 at 13:20 +0900, Tristan Van Berkom wrote:
> On Wed, 2013-04-10 at 20:30 -0500, Federico Mena Quintero wrote:
> > On Tue, 2013-04-02 at 17:59 +0900, Tristan Van Berkom wrote:
> > 
> > > And while it's a huge list of changes, any thorough peer reviews
> > > would be greatly appreciated of course.
> > 
> > This work makes merging my places-sidebar branch completely impossible.
> > There is a highly nontrivial amount of work in that branch and I really
> > don't feel like essentially rewriting the whole file due to merge
> > conflicts.
> > 
> 
> Federico,
>I feel your pain, and have also been on the receiving
> end of a merge conflict before.
> 
> I don't think it's sensible to be doing this kind of
> surgery on master directly (and I'm just not willing
> to repeat the 2 full days work I did on filechooser from
> scratch) but I'll be happy to help you merge this
> in your branch so that it applies cleanly.
> 
> 

Eeek, looks like I hit send by accident too soon (I think
that perhaps the 'send' button should not 'can-focus' in
Evolution)... luckily the above text is already what I meant
to write :)

So, this is how I propose we handle the situation:

  o First, you rebase your branch in such a way
that the filechooserdefault is reverted as
the first commit in your branch.

You should be able to do this easily enough
with an interactive rebase on top of master.

You will find a single commit in the log
which atomically does GtkFileChooserDefault.

  o Second, I know you wont like this part but
I need you to put the instance members on
a private structure.

We do not support automatically assigning
component pointers to public structure offsets.

And frankly, using a public structure defined
openly in gtkfilechooserprivate.h is an open
invitation for other components to access
the components of GtkFileChooserDefault directly
(which I think we both feel is unintended).

So before I touch this, please make sure that
there is a GtkFileChooserDefaultPrivate _and_
a GtkSideBarPrivate structure defined in their
C files.

  o If you have made any changes to the UI, i.e.
changes like spacing settings, expand/align
settings of any widgets in the filechooser,
any newly added widgets, anything that actually
changes the UI components, I would like you
to list those changes to me so I can make
the changes while splitting up gtkfilechooserdefault.ui
into 2 .ui files.

  o At this point, I'll look into your branch
and make both the GtkSideBar & GtkFileChooserDefault
use the .ui files again.

I know you're not going to like the mandatory usage
of the private structure, but I think that supporting
public struct offsets in the templates API is a path
we don't want to walk (as it should be generally discouraged
to use publicly accessible object members).

Even in private filechooser code, defining the members in
the .c files will have its benefits.

Cheers,
  -Tristan


> > I'm going to ask you to do these:
> > 
> > 1. Revert the commits that modify gtkfilechooserdefault.*, and ensure
> > that the code compiles.
> > 
> > 2. Tell me about it, and I'll merge places-sidebar into master.
> > 
> > 3. Then you can go back and re-do your changes for
> > gtkfilechooserdefault, BUT do not use a ->priv field.
> > GtkFileChooserDefault *is* a private widget, and it doesn't need a priv
> > structure.  Having it also makes the code unreadable.  (I'd like the
> > other internal widgets in GtkFileChooser to be the same, but I can live
> > with just the main gtkfilechooserdefault being clean).
> > 
> > I can only imagine how much work it was to complete the composite
> > templates branch; please think that the places-sidebar branch is a
> > similar investment on my part :)
> > 
> > Thanks,
> > 
> >   Federico
> 


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Wed, 2013-04-10 at 20:30 -0500, Federico Mena Quintero wrote:
> On Tue, 2013-04-02 at 17:59 +0900, Tristan Van Berkom wrote:
> 
> > And while it's a huge list of changes, any thorough peer reviews
> > would be greatly appreciated of course.
> 
> This work makes merging my places-sidebar branch completely impossible.
> There is a highly nontrivial amount of work in that branch and I really
> don't feel like essentially rewriting the whole file due to merge
> conflicts.
> 

Federico,
   I feel your pain, and have also been on the receiving
end of a merge conflict before.

I don't think it's sensible to be doing this kind of
surgery on master directly (and I'm just not willing
to repeat the 2 full days work I did on filechooser from
scratch) but I'll be happy to help you merge this
in your branch so that it applies cleanly.


> I'm going to ask you to do these:
> 
> 1. Revert the commits that modify gtkfilechooserdefault.*, and ensure
> that the code compiles.
> 
> 2. Tell me about it, and I'll merge places-sidebar into master.
> 
> 3. Then you can go back and re-do your changes for
> gtkfilechooserdefault, BUT do not use a ->priv field.
> GtkFileChooserDefault *is* a private widget, and it doesn't need a priv
> structure.  Having it also makes the code unreadable.  (I'd like the
> other internal widgets in GtkFileChooser to be the same, but I can live
> with just the main gtkfilechooserdefault being clean).
> 
> I can only imagine how much work it was to complete the composite
> templates branch; please think that the places-sidebar branch is a
> similar investment on my part :)
> 
> Thanks,
> 
>   Federico


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Mon, 2013-04-08 at 07:30 -0400, Matthias Clasen wrote:
> > Are we about ready to move forward with this ?
> 
> The color editor still has a round knob, where it didn't use to.
> That's the only thing I still notice being different.

I have just pushed a fix for this.

I was unable to really reproduce the problem, as my knobs show up
square and there is no easy way to load a specific .css (that I know
of).

But stepping through GtkWidget's buildable implementation showed that
the 

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sun, 2013-04-07 at 23:50 -0400, Matthias Clasen wrote:
> > I guess it's time for me to drop this for the day, I just dont
> > know if I can afford to spend time on it tomorrow, looks like
> > I'll be spending some long nights after hours on this...
> 
> Here is a patch that seems to work ok.

Mathias,
   Thanks a lot for taking time to and writing code towards
addressing the i18n issues without intltool.

I've taken the following actions on the branch:

  o Removed the initial INTLTOOL commit so it's not in the history

  o Edited all the commits which port widgets to use templates,
to NOT modify POTFILES.in at all (so the base work compiles
but is not translatable).

  o Applied your patch, with some modifications, at the HEAD of the
branch, with the additions of all the .ui.h entries in POTFILES.in

(the modifications I made was just to ensure that the .ui.h files
actually get generated, by adding them as a dependency to the
gtkresources.c build).

This way, the branch compiles at any given commit in the history, and
the last patch addresses the i18n issues.

I've also tested it, by adding some random translatable text into a .ui
file, building, running "make -C po/ update-po" and grepping for my new
translatable text.

This is working well.

Are we about ready to move forward with this ?

Cheers,
-Tristan


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sun, 2013-04-07 at 13:39 -0400, Matthias Clasen wrote:
> And just to complete that thought, here is how I think this should work:
> 
> - Write some Makefile goo to use my utility to generate foo.ui.h from foo.ui
> 
> - Add foo.ui.h to POTFILES.in
> 
> The only slight downside is that putting generated files in
> POTFILES.in means you have to generate those files before you can
> update .po files.

Right, I did not know about the 'make update-po' targets, actually.

I've been spending hours trying to fix the sed command in
po/Makefile.in.in, just to find that the POTFILES target
in there doesnt actually run (at least not on a fresh checkout).

I've also tried adding sed mumbo-jumbo similar to the extra
stuff for po-properties... into configure.ac... but still
no luck stripping out the "\[.*\]" from POTFILES.

I was under the impression translators, for instance spanish,
would just go into the po/ dir and type 'intltool-update es',
but now that you mention a special target for that in GTK+,
I wonder that... even if I got my sed command to run, if
it would manage to extract the translations from the .ui files
or not.

Generating an intermediate .ui.h file is something that crossed
my mind after looking at your attached program, but I've been
spending some time now... really trying to avoid that, but
if that's what you want, we could do that.

Note that, afaics (not sure about 'make update-po'), just naming
the glade files as .glade, fixes this issue without the need
for intermediate generated headers and the like.

I guess it's time for me to drop this for the day, I just dont
know if I can afford to spend time on it tomorrow, looks like
I'll be spending some long nights after hours on this...

Regards,
-Tristan


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sun, 2013-04-07 at 10:13 -0400, Matthias Clasen wrote:
> On Sun, Apr 7, 2013 at 2:57 AM, Tristan Van Berkom
>  wrote:
> > On Sat, 2013-04-06 at 23:59 -0400, Matthias Clasen wrote:
> 
> >
> > I'm afraid that your efforts on writing an intltool-extract
> > replacement are misplaced.
> 
> Depends on whether you want your stuff merged or not...
> 
> >
> > So I have to reiterate my question: How exactly does intltool make
> > your life difficult maintaining GTK+ ?
> >
> > I don't understand why it causes you problems while every other
> > project containing .ui files get along fine.
> 
> I just don't like it, and I don't want stuff that I maintain to depend
> on it. I don't allow myself many unfounded opinions, but this is one
> of them. You'll have to deal with it.

Ok, here's the problem.

intltool (used by hand, by translators) cannot handle the .ui
suffix without the [type gettext/glade] attributes specified
in POTFILES.in.

And GTK+ Makefiles cannot handle the POTFILES.in if the appropriate
attributes are set.

I don't know if you would be happy to tell translators to use
your tool, instead of intltool, in order to update all relevant
translations and merge them into the existing ${LANG}.po files,
but that could be an option (if the program actually did that).

But, as I understand it, a simple escape route would be to
rename all of GTK+'s .ui files to .glade, using the age old
.glade suffix will allow translators to merge translatable
strings into their favorite .po file, without ever needing
the explicit [type gettext/glade] attribute.

Would you be satisfied with this approach, at least until
a day that intltool-merge (used manually by translators)
is able to understand what a .ui file is without the
special attribute ?

Cheers,
   -Tristan


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sat, 2013-04-06 at 23:59 -0400, Matthias Clasen wrote:
> Hey Tristan,

Ok I've spent some hours perfecting this, I had not run the doc-shooter
program before so vigorously but now all of the captures from master
are identical to the ones in composite-templates-new.

> 
> thanks for sending this detailed status update. Here is some initial
> feedback after playing with the branch for a few minutes:
> 
> 1. intltool - I don't like it, and really want to avoid adding a
> intltool dependency to GTK+. I've attached a small program that can
> get the job done for the .ui files in your branch.
> 
> 2. All the composite dialogs flash black and in wrong size when
> mapped. I hope that is just an oversight, and can be corrected. I
> don't think we can merge it like that

About the 'flash black' issue, I've verified this is really not
related to composite-templates-new branch.

I.e.:

  o Try the 'Printing' demo which fires up GtkPrintUnixDialog,
on master or composite-templates-new... in this case it's
snappy and I don't see any black (with either branch)

Note that GtkPrintUnixDialog is by far the largest .ui
file.

  o Now in the demo, fire up the 'Tool Palette' demo on
master or composite-templates-new... in both branches
I *do* see the flashing black on screen.

Note that the GtkToolPalette is not implemented
using composite templates at all.

These observations lead me to believe that the black
flashing issue is not related at all to my branch,
but rather an intricate issue with drawing complex
interfaces all around (I see it sometimes at Glade's
startup which has lot's of widgets), something should
be done to ensure that displaying a new window and drawing
it's contents should be done in the right order.

As for your remark about the "wrong size", this is taken
care of (specifically the GtkFileChooserDefault widget
had some things visible by default which should not have
been, that's been fixed in the last couple hours).

> 
> 3. The print dialog segfaults.

I found the 'Printing' demo (which I had seemed before) and
addressed the issues.

Actually I was not aware that GtkBuilder ignores the 'swapped'
flag of a signal if the 'object' is not specified in the Glade file.

Instead of the risky route of changing GtkBuilder behavior, I just
added the 'object' parameter to any swapped signals in Glade.

> 
> 4. The Pickers example in gtk3-demo has issues: the filechooser button
> has the wrong height, and the directory chooser doesn't show up at
> all. The filechooser also has an empy filter combo that should not be
> visible.

This is fixed, I had the combo box packed in the wrong place in
GtkFileChooserButton, this also showed up with the doc-shooter.

> 
> 5. The Color Chooser example in gtk3-demo has issues: the alpha slider
> in the color editor has a round knob, instead of a pointy one.

This particular one is tricky, I personally cannot reproduce the problem
as both sliders show up as regular rectangular knobs.

The only trace in GtkColorEditor which is a hint to what is going on
here is that GTK_STYLE_CLASS_HAS_MARKS_ABOVE is specified on the
alpha slider.

And 'scale-has-marks-above' is specified for the alpha slider
in the GtkColorEditor .ui file.

Any hint on what else would need to be tweaked to get the right
theme for the pointy knob ?

> 
> 6. The button order in the assistant is flipped.

This was a silly error, the buttons were packed with the default
GTK_PACK_START instead of the GTK_PACK_END, this is also fixed.

Cheers,
-Tristan


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sat, 2013-04-06 at 23:59 -0400, Matthias Clasen wrote:
> Hey Tristan,
> 
> thanks for sending this detailed status update. Here is some initial
> feedback after playing with the branch for a few minutes:
> 
> 1. intltool - I don't like it, and really want to avoid adding a
> intltool dependency to GTK+. I've attached a small program that can
> get the job done for the .ui files in your branch.
> 

I'm afraid that your efforts on writing an intltool-extract
replacement are misplaced.

>From my original mail:
>   In order to properly extract translations of strings
>   defined in .ui files, the files need to be listed
>   with lines like the following in POTFILES.in:
>
> [type: gettext/glade]gtk/gtkfilechooserdefault.ui
>
>   This breaks the build without adding IT_PROG_INTLTOOL()
>   to configure.ac.

In other words, intltool extracts the translations from GTK+
just fine, without the added line to configure.ac

I've been asking around and it seems that translator teams
get the .po files from a website called damn lies. The .po
files presumably get put there by translator team leaders
who run intltool-update or such (perhaps as a batch process
in a script, I'm not clear on that part)... anyway... cd
into gtk+/ and intltool-update manually works fine to extract
translations.

However. Remove the important from configure.ac, and GTK+'s
makefiles in po/ (which are normally intltool generated) choke
on the entries in POTFILES.in.

To reproduce:
  o Checkout composite-templates-new branch
  o Revert the first commit (the one that adds IT_PROG_INTLTOOL)
  o git clean -xdf
  o ./autogen.sh  your args
  o make

Now things screw up, the makefiles in gtk+/po/, are not smart enough
to deal with the [type gettext/glade] annotations, and just abort
the whole build.

So I have to reiterate my question: How exactly does intltool make
your life difficult maintaining GTK+ ?

I don't understand why it causes you problems while every other
project containing .ui files get along fine.

> 2. All the composite dialogs flash black and in wrong size when
> mapped. I hope that is just an oversight, and can be corrected. I
> don't think we can merge it like that

I've witnessed the black flashing yes. It annoyed me but I didn't
once think it possibly that my branch was causing this (dialogs
are certainly constructed before being mapped, before any visual
surface is ever created for them, and all of the template building
is done quite synchronously before ever reaching ->map()).

Glade uses GtkAboutDialog, GtkFileChooserDialog, GtkColorChooserDialog
and maybe more, I did pay very strict attention to porting the
properties of existing composite widgets, and dont find them to
be in the wrong size (I may have missed a couple issues, as you
point out in your further comments, and thanks for catching them).

I'll look into this in more detail, and try using the doc-shooter
program to compare the before/after dialog sizes.

> 3. The print dialog segfaults.

Indeed, I've just tried it with gedit, actually (I was looking for
a good case).

I actually wrote off the print dialog because GTK+ doesnt have
a test case for it that I could find, and GTK+ master as well
as my branch segfault equally when the treeview is clicked.

I'll try to identify if it's a regression in my branch and
if I can fix it, using gedit.

> 
> 4. The Pickers example in gtk3-demo has issues: the filechooser button
> has the wrong height, and the directory chooser doesn't show up at
> all. The filechooser also has an empy filter combo that should not be
> visible.
> 
> 5. The Color Chooser example in gtk3-demo has issues: the alpha slider
> in the color editor has a round knob, instead of a pointy one.
> 
> 6. The button order in the assistant is flipped.

I'll look into all of these problems right now.

Cheers,
-Tristan


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

Composite GtkBuilder template

[Tristan Van Berkom]

I meant to address the list by the end of last week but 
some issues cropped proving that the work was not yet finished.

I have been working closely with Benjamin, refining the API
and discussing some of the finer points. This has been a
huge effort that ate up my last two weeks full time work.

The work can be viewed here:
  https://git.gnome.org/browse/gtk+/log/?h=composite-templates-new

And while it's a huge list of changes, any thorough peer reviews
would be greatly appreciated of course.

A version of Glade which can be used with this branch can 
be built from:
  https://git.gnome.org/browse/glade/log/?h=composite-templates-new

Since it's nice and early in the 3.10 cycle, I would like
to finally land this by the end of this week if there are
no objections (I say finally, because I prototyped this years
ago but never got around to really cleaning it up until now).

So here below follows my detailed report.

Cheers,
   -Tristan


What is Composite Templates ?
~
This feature is an association of GtkWidget class data
with GtkBuilder xml.

It allows automation of the creation of composite widgets
without directly accessing the GtkBuilder APIs and comes
with a few features that help to bind a GtkWidget with
it's GtkBuilder xml.

What has been done ?


  o The implementation of the API, of course

  o A total of 23 composite widgets in GTK+ have been
ported to use GtkBuilder xml to define their content.

The actual xml data is stored in GTK+'s global resources
in a compressed format.

Each widget migration has it's own individual commit
on the branch, which should give any observer a clear
picture of what a migrated composite widget looks like.

  o A catalog file for Glade was added to the gtk+/gtk/glade
directory.

This catalog is not meant to be installed, but rather
it gives GTK+ developers access to GTK+'s private
widget classes so that, for instance, a GtkColorSwatch
can be added to a GtkColorEditor, or a GtkPathBar
to a GtkFileChooserDefault interface description.

When running Glade with this custom catalog, a new
section with "GTK+ Private Widgets" appears in
Glade's palette.

  o Glade itself has seen improvements in stability
and features, supporting new widgets and the like
up until GTK+ 3.8

I've verified that all of GTK+'s composite widget
xml files can be saved without any data loss or
any meaningless changes (so that commits should be
as relevant as possible).

  o A test case has been added which verifies that each of
these classes construct and finalize properly (and
that all of the object which they refer to in the
xml also finalize properly).

  o The  format is moderately documented in
gtkwidget.h

  o gtk_widget_push/pop_composite_child and relevant
APIs (set/get_composite_name()) have been deprecated.

As far as I know, they were never actually useful for
anything, but now we have a real story for composite
widgets so I would like the old APIs gone.

Some critical points


As it currently stands, there are two critical points which
I think need discussion, I'll list four points here for
completeness.

  o Intltool

In order to properly extract translations of strings
defined in .ui files, the files need to be listed
with lines like the following in POTFILES.in:

  [type: gettext/glade]gtk/gtkfilechooserdefault.ui

This breaks the build without adding IT_PROG_INTLTOOL()
to configure.ac.

Most projects however do use intltool in configure.ac.

Matthias, does this make your life maintaining GTK+
difficult in any specific way ?

Can we merge this and live with it at least until a
newer version of gettext is released that supports
the ".ui" suffix or the [type: ] annotation properly ?

  o Private widget types

In order for Glade to load private widget types (which is
needed to edit some of GTK+'s composite widgets), Glade
needs the types to be registered in advance, since they
cannot be loaded with g_module_lookup() in the normal way.

I've added gtk/gtkgladecatalog.c which exports an initialization
function and that registers the private types.

GTK+'s internal catalog (gtk/glade/gtk-private-widgets.xml)
declares this symbol as it's catalog initializer, which
I think is an elegant enough solution.

Benjamin also noted that gtk_test_register_all_types() also
exists but currently does not register the private types.

I could alternatively make that function register private
types and have Glade call it explicitly at initialization
time.

  o Ryan's work on overriding default properties.

Ryan is addressing some issues currently in GObject which
will allow us to declare new default values for properties
registered in parent classes.

This will particularly address a problem that exists with

Re: Test Modules

[Tristan Van Berkom]

On Wed, 2013-03-06 at 12:41 +, John Emmas wrote:
> On 6 Mar 2013, at 12:14, Tristan Van Berkom wrote:
> 
> > Is this question stemming from the fact that you got glib to
> > compile using MSVC, where I suppose you are hacking the source
> > tree severely and not using the autotools/makefiles at all ?
> > 
> 
> I wouldn't say I've hacked anything too severely Tristan.  Glib already 
> contains projects for building with Visual Studio.  I've just extended them a 
> bit - so that I can build everything (including the various auto-generated 
> files etc) from a Visual Studio project.  Of course, I need to have Perl and 
> Python installed too but autoconf can be skipped (there are already some 
> "config.*.msc" type files available in the distro).
> 
> 
> > I do recall there was a time that compiling glib with MSVC
> > was needed in order to create more compatible binaries, is
> > this still the case ?
> > 
> 
> Undoubtedly, yes.  If you build the binaries with MinGW, then later change 
> something and rebuild, MinGW does not seem to guarantee that the second build 
> will use the same ordinal values as your first build (in each DLL).  It's a 
> great recipe for DLL Hell.
> 

This is seriously unfortunate, if glib maintainers need to maintain an
alternate build system to compile glib on win32, that is a serious
problem (considering we are having a hard time already just to get
win32 related patches upstreamed in glib/gtk+).

> > is there any reason to not use a
> > more standard/friendly toolchain like MSYS/mingw where
> > the same configure.ac/Makefiles can be used without modification ?
> > 
> 
> In my case there are 2 reasons:-  1)  I need to be able to debug all my code 
> using Visual Studio's debugger.  2) MinGW uses the CRT from VC6.0 which is 
> nearly 20 years old now and it's only a matter of time before Microsoft makes 
> it obsolete.
> 

Is '2' really a problem ? I would think that using the earliest ABI
possible is intentionally done by mingw maintainers, in order to support
as many variants of win32 as possible, right ?

As for 1, I think the bigger problem here is really about MinGW, if we
don't trust the compatibility of the dlls it generates, that's really
a bug that should be fixed in MinGW.

Working around this and trying to maintain multiple build systems
is something I think we all want to avoid (i.e. there's no way I
can see that we can afford to maintain this double-standard in the
long run).

FWIW, any time I've created win32 packages of glib based programs,
I've always used a technique which bundles the glib dll together
with the program I wish to distribute on win32 (avoiding any
sharing of prebuilt glib dlls).

While this approach to distribution is sub-optimal (and results
in overly-huge distributions for a single program), I would rather
encourage this approach until MinGW dll compatibility issues can
be fixed... than to push glib maintainers to support a double
standard of build techniques.

To be clear, personally I think portability is a high priority
for us and I take it seriously... in order to protect/ensure
portability in the long term we need to lower the bar of entry
to doing so (i.e. we need make things easier on glib maintainers
and developers), not heighten it.

That said, I'm not a designated glib maintainer, perhaps Ryan
and others have another view on this.

Best,
-Tristan

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


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

Re: Test Modules

[Tristan Van Berkom]

On Wed, 2013-03-06 at 11:56 +, John Emmas wrote:
> I recently built libglib (version 2) using MSVC.  I noticed that there 
> are several dozen test modules available (i.e. 'C' source modules) but 
> it looks as if they all need to be built as individual apps.  Does 
> anyone think it would be a good idea to have one app that could run all 
> the tests?  Or is that in fact already available somehow?

There are 2 brands of tests in glib (or 3, depending how you perceive
them)

 a.) Unit tests - tests which require no interaction and include 
 assertions, these are automatically run by 'make check' to
 ensure that a given build passes these requirements

 b.) Functional tests, i.e. programs which might require user
 interaction and as such cannot be run as a step in 'make check'
 these also can be run to test/debug various aspects of the
 software

 c.) Some functional tests can also be perceived as 'demos', some
 of them are advertised as such (i.e. they are compilable
 working code linked directly into the glib/gio documentation).

I don't see any advantage of combining any of these test cases
into a single program, do you ?

Is this question stemming from the fact that you got glib to
compile using MSVC, where I suppose you are hacking the source
tree severely and not using the autotools/makefiles at all ?

I do recall there was a time that compiling glib with MSVC
was needed in order to create more compatible binaries, is
this still the case ? is there any reason to not use a
more standard/friendly toolchain like MSYS/mingw where
the same configure.ac/Makefiles can be used without modification ?
Where 'make check' is undoubtedly useful ?

Cheers,
-Tristan


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

Re: Baseline alignment ideas

[Tristan Van Berkom]

On Wed, Feb 27, 2013 at 8:44 PM, Alexander Larsson  wrote:
> On ons, 2013-02-27 at 17:47 +0900, Tristan wrote:
>
>> Ah, I think I understand your question better now.
>>
>> Use a natural allocation process similar to
>> gtk_distribute_natural_allocation():
>> http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n599
>>
>> Instead of looping over widget size requests, provide a normalized
>> value for the minimum and natural requests "above" and "below" the
>> children (after allocating the absolute minimum height).
>>
>>  o Start by giving equal minimum "above" height to all children and
>>equal minimum "below" height to all children
>
> Well, this just means give each child their minimum height initially.
>
>>  o Distribute extra allocated space above and below equally until
>>one of the sides ("above" or "below") reaches natural allocation
>
> But, this is where I don't really follow. In practice all we have are
> child widgets which we can ask for "what would the baseline be if you
> had this height (and width, since its always fixed by now). From this
> we want to decide the *total* height of each child.
>
> How do we assign 5 pixels above the baseline based on this? All we can
> do is give the child more total height (via gtk_widget_size_allocate),
> we have in general no control of where that height will go. The child
> might be expandable both above and below its baseline, but how can we
> "tell" it to only grow above?

Interesting... taking your previous example of HBox with widgets
A, B, B, and D... let's consider that A & B is in VBox1 and B & D is
in VBox2

What you are asking (I think) is how can we determine that VBox2
can only grow /below/ and that VBox1 can only grow /above/.

Is this correct ?

I think this conversation needs a little bit more context (as to how
precisely you plan to layout the groundwork APIs for this), but
here's what I would envision:

I think that HBox has the responsibility to 'request and set the baseline'
of it's contents (being VBox1 & VBox2)

VBox1 reports a baseline which is close to the bottom of it's content,
while VBox2 requests a baseline which is near the top of it's content.

HBox then determines at allocation time, that the baseline of it's content
is an offset which agrees with VBox1 & VBox2, and then proceeds to
inform both VBoxes of the 'allocated baseline' and also distributes
the _full_ height of HBox to both children.

Determining what is a suitable baseline for the children of HBox is
problematic for HBox to solve, I would say let's _start_ by trying to
ignore natural height and use only minimum height, expand space
could either be distributed equally above and below both VBoxes,
but perhaps a BASELINE_TYPE_ABOVE/BELOW/CENTER would
allow this to be declarative (it will probably end up being needed)

Then, at this point HBox has determined a suitable baseline (either
by guessing and distributing equally above and below, or by using
some semantics)

Then, VBox1 and VBox2 allocate() routines kick in, and they have
a strict baseline rule to follow. This baseline is semantically linked
with widget "B" somehow (there must be some way that you determine
which of the children of either VBoxes 'own' the baseline for it's parent).

VBox1 (and VBox2) now have to satisfy the requirement that the
baseline offset request from it's widget B must be placed at the
same VBox1 relative position that it was assigned by it's parent
HBox directly before allocating.

Now note that we absolutely don't care about how much extra
space will be allocated to widgets A and D, they should align
themselves into whatever extra space which was given them
according to their own alignments.

I'm pretty sure this approach work's in theory, but there's a big
'gotcha' in play... which is the intrusive 'halign'/'valign' properties
and any properties which are implicitly calculated by the
->adjust_size_request() and ->adjust_size_allocate() vfuncs.

Which means the whole thing breaks down if either VBoxes
have a valign property that != GTK_ALIGN_FILL or that
margins or border_width are set... this is a hard problem to
figure out too... it might require that widgets retain access to
the full allocation given them by their parent, instead of the
final allocation stored after adjustments are made.

Finally, it's worth noting (I'm sure you're already aware) that
minimum & natural preferred_height_for_width() will hardly
ever differ (they will only differ for vertically rotated text, or
perhaps some GtkWrapBox which is oriented to wrap from
top to bottom).

Hope this helps,
  -Tristan

>
> The only way I can see is this iterative algorithm. Its based on the
> fact that as we add height to each child it may appear above or below
> the baseline, and in the worst case of two children growing on different
> sides the container height will grow by double of what we add to the
> children.
>
> So, we do something like:
>
> 1. allocate each child its own min height, calculate baseline 

Re: Function completion for GVariant maybe types?

[Tristan Van Berkom]

On Thu, Feb 21, 2013 at 7:05 PM, Markus Elfring  wrote:
>> Until a couple of days ago I'd never even encountered GVariant so forgive me
>> if I've misunderstood the concept - but from what you've written, it seems
>> like you want to be able to map a nullable object to the state of a checkbox
>> for some reason.
>
> Yes, that is right.
>
> I give a bit more background information so that you can better understand the
> "history" for this issue.
>
>
> 1. I started to adjust the application "GParted" a while ago.
>
> 2. I added a Gtk::TreeModelColumn attribute.
>
> 3. I noticed that such model classes could not be marked to contain "nothing".
> How should "unknown" or "indeterminate" items be represented then?

Perhaps here (at step 3) is where you should pursue a different method,
since the immutable GVariant all by itself is clearly not suitable for your
purpose (and convincing glib maintainers to make it mutable is not going
to work, as it opens up a whole new problem space for glib which is
most likely unneeded, remember that adding features costs maintenance
in the long term, and a smaller API suited for specific purposes can be
more maintainable without being less powerful - less is more).

In other words, perhaps you should simply create your own GObject
type in the GParted code, which would in turn own a nullable but
immutable GVariant type property.

This will allow you to use your own GType as a GtkTreeModel column type,
at the same time allowing you to modify the actual GVariant that your
type owns (by replacing it with another GVariant, if need be).

Cheers,
-Tristan

>
> 4. I moved from the abstraction level "C++ glibmm" to "C glib" to add the
> missing feature.
>
> 5. I wrote the prototype function "g_variant_new_nothing_from_type" according 
> to
> my imaginations.
>
> 6. I do not like its implementation detail to call the function
> "g_variant_get_child_value" if I would only like to extract/inspect a data 
> type
> and not to copy a complete value.
>
> 7. I try to improve this situation.
>
>
>> So GVariant doesn't seem to be a suitable type for mapping the state of
>> something whose state can change.
>
> Your conclusion is wrong. - I suggest to read a bit more about the concept of
> "immutable objects".
> http://en.wikipedia.org/wiki/Immutable_object
>
> A new object can always be created from a previous one which represents a
> read-only status.
>
>
>> Could that be why there's so much reluctance to implement what you want?
>
> No. - I see various factors like the following that result in usual challenges
> for my feature request.
>
> - I dare to fiddle with nullable data types and their mappings in different
> programming interfaces.
>
> - I try to gather attention from potentially interested parties like software
> developers.
>
> - I need to convince corresponding library maintainers to get the desired
> functionality added.
>
>
> Would you like to contribute any more suggestions to improve the involved
> communication?
>
> Regards,
> Markus
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: bugzilla cleanup

[Tristan Van Berkom]

On Wed, Feb 6, 2013 at 9:24 AM, Matthias Clasen
 wrote:
> On Tue, Feb 5, 2013 at 3:49 PM, Morten Welinder  wrote:
>
>>
>> Note, that there are other large parts of glib, such as gio, that
>> have basically don't work on win32.  And have five-year old
>> patches in bugzilla.
>>
>
> Getting win32 patches merged requires somebody with an interest in
> GLib/GTK+ on that platform to step up and do patch review and
> maintenance. I've never ever built anything on Windows, so I'm not
> really in a position to review patches.

Perhaps we should explore some new possibilities for getting
these patches in.

While I think many of us recognize the value of being
cross-platform and even see it as a high priority for our
stack, many of us (me included), just dont want to actuallypa
run windows on our machines, or... if we use osx, prefer
not to compile there.

On the other hand we still have people willing to submit
patches for bugs which crop up on these platforms.

My initial thoughts are, is there any way to take a different
strategy for reviewing patches on these platforms ?

Perhaps (and this might be far fetched, I don't have
much experience working with VMs so I couldn't say)...
But perhaps it's possible to set up a battery of unit tests
which can be run in a VM... one which can be a requirement
for passing make check (or at least, make distcheck).

If that could work, then we could at least require that,
where possible, a regression test be provided with any
submitted patch... proving that your patch passes the
unit test could be a requirement to landing your patch.

Otherwise, perhaps having a hand full of testimonies
(even >= 2), from various users saying that the patch
works for them, should be enough to land a given
contribution... this would at least be better than stalling
the platform completely (and might even help to attract
someone that we can rely on to review win32 patches
again, stalling the platform is certainly not helping).

I'm not sure that this is exactly the right approach, but
I think we need a technical solution to the problem, since
we probably wont have someone from inside the community
that we trust to review patches, who also wants to build and
test on win32. But that is not to say there is no interest
in win32, obviously submitted patches is proof that there is.

Thoughts ?

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

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Tristan Van Berkom]

On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman  wrote:
> I could easily be misunderstanding the internals, but at some point isn't a
> call to something like gtk_widget_set_parent on the children needed for
> widgets to ever be displayed or useful? (which sinks the children)

One of the more gross internal details of GTK+ is that GtkWindows
(any toplevel widgets) get added to an internal 'list of toplevels'.

So a GtkWindow is an odd subclass that (like someone else
pointed out), sinks it's own floating reference at initialization time.

The ownership of the window is virtually given to "GTK+" and then
disposed of automatically at gtk_widget_destory() time.

I suppose that strictly speaking, an object constructor can indeed
have side effects (but I can't think of any case where it would be
anywhere close to 'sane' to intentionally use object constructors
for their side effects and ignore the results).

Best,
 -Tristan

>
> If it really might be a problem we could work around the leak by tracking if
> the instance was created within python and if the instance has ever been
> marshaled to C. At which point we could rely on the GC cleanup of the
> wrapper to sink and unref the extra ref in cases the GObject was never
> passed on to C at any point. This sucks but it seems a little better than
> checking GObject ref counts during marshaling and floating sunk objects
> based on if it was initially floating and the GObject ref count is only 1,
> which might be unsafe.
>
> -Simon
>
>
>
> On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld 
> wrote:
>>
>> On 04.02.2013 03:39, Simon Feltman wrote:
>>>
>>> I am starting to warm up to an idea where we simply never sink objects
>>> and always follow the rules entailed by
>>> ownership transference annotations already in place, with one caveat:
>>> g_object_new is annotated as transfer full but can also return floating
>>> references. In this case, we must check the returned type and not
>>> believe the annotation when it returns InitiallyUnowned instances, but
>>> instead treat it like transfer none and add a new ref.
>>
>>
>> What about custom implementations of classes that are supposed to take
>> over floating refs?  For example, how would you write a custom GtkContainer
>> subclass in Python with your scheme?  Wouldn't you then need a way to
>> explicitly sink the floating ref?
>>
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Tristan Van Berkom]

On Mon, Feb 4, 2013 at 11:39 AM, Simon Feltman  wrote:
[...]
> However, it also adds a leak for the most basic (and useless) case:
> for i in range(10):
> Gtk.Button()

This could arguably trigger a compiler warning, or even an error.

In any case, since there is no variable assignment, I don't think it makes
sense to make an effort to manage the returned memory (so I think your
reasoning here is perfectly sound).

I only wonder if it can be done using the G_IS_INITIALLY_UNOWNED() and
g_object_is_floating() APIs instead of GIR annotations. Aside from the low-level
platform stack I don't think the gtk-doc annotations are widely used, or obeyed
to the letter (so it feels a bit scary to trust those annotations)...
not sure if that
is wildly impossible, but I was under the impression that language bindings have
been using the 'floating' indicators for a long time before GIRs
started to exist.

Best of luck,
 -Tristan

>
> This would leak the initial floating ref and the memory would be lost.
> However, I can't think of a real use case where something like that would
> ever be needed.
>
> The alternatives to can become grossly convoluted:
> https://bugzilla.gnome.org/show_bug.cgi?id=687522#c15
>
> Thoughts?
>
> -Simon
>
>
>
>
>
> On Tue, Jan 29, 2013 at 3:44 AM, Simon Feltman  wrote:
>>
>> I tend to agree we should be avoiding reliance on main loops (or GC
>> timing) to get the ref counts right if possible.
>>
>> PyGObject also uses toggle refs similarly to gjs for keeping the wrappers
>> alive. However, in PyGObject this only happens if a Python instance
>> attribute is set. Whereas with gjs it seems to use a toggle ref all the time
>> just in case an attribute is set?
>>
>> It seems like the problem at hand can be solved by maintaining the
>> floating ref and adding our own safety ref for the wrapper. With one caveat:
>> upon completion of the python callback we may consider sinking the GObject
>> if the ref is floating and the Python wrapper has a reference count greater
>> than one. This basically means code in the callback made an assignment of
>> the object to something outside of its scope and that should be considered a
>> strong reference. But that might not even be necessary. I've attempted to
>> describe this along with all the other problematic reference counting
>> situations in a separate document:
>>
>> https://live.gnome.org/PyGObject/Analysis/ObjectReferenceCountingForVFuncsAndClosures
>>
>> The biggest concern at this point is how to properly deal with vfunc
>> implementations which return objects and are annotated as "transfer none".
>> Review, corrections, and feedback is very welcome.
>>
>> Thanks,
>> -Simon
>>
>>
>>
>> On Fri, Jan 18, 2013 at 12:19 AM, Tristan Van Berkom 
>> wrote:
>>>
>>> On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna
>>>  wrote:
>>> [...]
>>> > I know that Python doesn't have a GC in the traditional sense, but you
>>> > could still send finalization for GObject wrappers to a idle callback
>>> > so there is no risk of finalizing objects that C code assumes are
>>> > still alive.
>>>
>>> That doesn't sound like a very safe workaround to me.
>>>
>>> There are situations where a lot of code can run without the mainloop
>>> ever becoming idle, while running a ClutterTimeline is one of those
>>> cases (or at least I've observed that idle callbacks dont generally
>>> get called while a ClutterTimeline is playing, perhaps they do with
>>> an ultra high priority).
>>>
>>> Another thing to consider is that not all code written with the glib
>>> stack is actually reactive & event based, code that does not run
>>> a mainloop will risk blowing up in size quickly, possibly attaining
>>> out of memory conditions unnecessarily if the code happens to
>>> be highly recursive.
>>>
>>> Cheers,
>>> -Tristan
>>
>>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Tristan Van Berkom]

On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna
 wrote:
[...]
> I know that Python doesn't have a GC in the traditional sense, but you
> could still send finalization for GObject wrappers to a idle callback
> so there is no risk of finalizing objects that C code assumes are
> still alive.

That doesn't sound like a very safe workaround to me.

There are situations where a lot of code can run without the mainloop
ever becoming idle, while running a ClutterTimeline is one of those
cases (or at least I've observed that idle callbacks dont generally
get called while a ClutterTimeline is playing, perhaps they do with
an ultra high priority).

Another thing to consider is that not all code written with the glib
stack is actually reactive & event based, code that does not run
a mainloop will risk blowing up in size quickly, possibly attaining
out of memory conditions unnecessarily if the code happens to
be highly recursive.

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

Re: GtkWidget::visible

[Tristan Van Berkom]

On Thu, Jan 17, 2013 at 11:59 AM, Tristan Van Berkom  wrote:
> On Wed, Jan 9, 2013 at 12:04 AM, Benjamin Otte  wrote:
>> Hey,
>>
>> Today, in my quest to make things clearer in the GTK core, I'm
>> tackling GtkWidget::visible.
>> The flag is documented as "Whether the widget is visible."[1] or a bit
>> better in the documentation for gtk_widget_show() as "Any widget that
>> isn't shown will not appear on the screen."[2]
>> However, this doesn't say anything about sizes, in particular sizes
>> requested from a widget. So far, GTK would not check the visibility
>> flag when calling size request functions ad would happily allocate a
>> size to a hidden widget. It also would happily expose the widgets to
>> the accessibility APIs. This has a bunch of problems:
>> - performance suffers
>> If we need to compute all these things for widgets we're not going to
>> use anyway doesn't make Stuff Go Faster.
>> - containers don't know what to do
>> Should they skip invisible widgets when allocating? Or still reserve
>> space for them?
>
> That's not exactly true. All containers know what to do with invisible
> children, all containers skip invisible children when requesting and
> allocating sizes. They even have the option of doing different things
> depending on the container type or the child properties of the given
> invisible widget.
>
> For instance, it can be useful in notebooks if the notebook reserves
> space for invisible children, this way the notebook size does not
> jump/change whenever one of the optional pages is shown/hidden
> (I can't seem to find it, but was sure there was a
> "request-space-even-if-invisible"
> child property in one of our containers).

I realize this wasn't the most constructive reply, I've been busy
and planned to reply to this when I initially received it, so wrote
a reply in a hurry.

What I think we're looking for here, is just an alternative way to iterate
over container children, i.e. a convenience API that would iterate
over only visible children.

I'm only a bit wary of removing the capacity to request the size of
an invisible widget, since that can also have it's uses.

With an alternative API, like gtk_container_foreach_visible(), or
gtk_container_list_visible_children(), we could eliminate all of those
statements which exist in GtkContainer size request/allocate
implementations which basically all already do:

if (!gtk_widget_get_visible (child))
   continue;

It might not be too much code reduction, but would probably make
things more readable (and easier to implement, it can be easy to
forget to skip the invisible widgets when implementing containers).

Cheers,
  -Tristan

>
>> - developers implementing widgets get confused
>> Can they optimize things away when their child is not visible? Like
>> can I skip the whole CSS machinery for hidden widgets in GTK?
>> - developer expect those widgets to not do anything
>> A11y people have lots of "fun" fixing bugs when Orca pokes into
>> widgets nobody expects to be pokable. Usually developers just hide()
>> widgets when they are supposed to be unresponsive and invisible and
>> then they don't update them anymore and expect no callbacks to happen
>> from them.
>>
>> So as a result, 2 things are going to be changed:
>> (1) gtk_widget_get_preferred_width/height() will return 0
>> With a recent commit[3], GTK will shortcut all
>> get_preferred_width/height() to return 0 for minimum and natural sizes
>> for all invisible widgets. Also, the allocation of the widget will be
>> immediately recent to an invalid state, so gtk_widget_get_allocation()
>> will return the initial { -1, -1, 1, 1 }.
>
> I don't think this is exactly right.
>
> There can be reasons to calculate the size of a widget regardless if it is
> mapped or visible.
>
> One example could be when creating a target surface for gtk_widget_draw().
>
> Cheers,
>-Tristan
>
>
>> (2) A11y code will ignore invisible widgets
>> We're working on a patch that will make sure no accessibles show up
>> for invisible widgets.[4]
>>
>> Why am I writing this? Because if you happen to run code that breaks
>> due to these commits or think this is a bad idea in general, you now
>> know that it's happening and still have a chance to stop us before we
>> release this as GTK 3.8.
>>
>> Benjamin
>>
>>
>> 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible
>> 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show
>> 3: 
>> http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515
>> 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkWidget::visible

[Tristan Van Berkom]

On Thu, Jan 17, 2013 at 11:59 AM, Tristan Van Berkom  wrote:
> On Wed, Jan 9, 2013 at 12:04 AM, Benjamin Otte  wrote:
>> Hey,
>>
>> Today, in my quest to make things clearer in the GTK core, I'm
>> tackling GtkWidget::visible.
>> The flag is documented as "Whether the widget is visible."[1] or a bit
>> better in the documentation for gtk_widget_show() as "Any widget that
>> isn't shown will not appear on the screen."[2]
>> However, this doesn't say anything about sizes, in particular sizes
>> requested from a widget. So far, GTK would not check the visibility
>> flag when calling size request functions ad would happily allocate a
>> size to a hidden widget. It also would happily expose the widgets to
>> the accessibility APIs. This has a bunch of problems:
>> - performance suffers
>> If we need to compute all these things for widgets we're not going to
>> use anyway doesn't make Stuff Go Faster.
>> - containers don't know what to do
>> Should they skip invisible widgets when allocating? Or still reserve
>> space for them?
>
> That's not exactly true. All containers know what to do with invisible
> children, all containers skip invisible children when requesting and
> allocating sizes. They even have the option of doing different things
> depending on the container type or the child properties of the given
> invisible widget.
>
> For instance, it can be useful in notebooks if the notebook reserves
> space for invisible children, this way the notebook size does not
> jump/change whenever one of the optional pages is shown/hidden
> (I can't seem to find it, but was sure there was a
> "request-space-even-if-invisible"
> child property in one of our containers).
>
> In any case, if we really want to do something drastic like this,
> we should modify all the containers at the same time so that
> they actually dont know what to do with invisible children anymore...
>
>> - developers implementing widgets get confused
>> Can they optimize things away when their child is not visible? Like
>> can I skip the whole CSS machinery for hidden widgets in GTK?
>> - developer expect those widgets to not do anything
>> A11y people have lots of "fun" fixing bugs when Orca pokes into
>> widgets nobody expects to be pokable. Usually developers just hide()
>> widgets when they are supposed to be unresponsive and invisible and
>> then they don't update them anymore and expect no callbacks to happen
>> from them.
>>
>> So as a result, 2 things are going to be changed:
>> (1) gtk_widget_get_preferred_width/height() will return 0
>> With a recent commit[3], GTK will shortcut all
>> get_preferred_width/height() to return 0 for minimum and natural sizes
>> for all invisible widgets. Also, the allocation of the widget will be
>> immediately recent to an invalid state, so gtk_widget_get_allocation()
>> will return the initial { -1, -1, 1, 1 }.
>
> I don't think this is exactly right.
>
> There can be reasons to calculate the size of a widget regardless if it is
> mapped or visible.
>
> One example could be when creating a target surface for gtk_widget_draw().

Another example is when using GtkSizeGroup, you dont want all your widgets
in the group to suddenly become bigger because you just called gtk_widget_show()
on one of the optionally visible members of the group (hence the "ignore-hidden"
property on GtkSizeGroup to override this default behaviour).

>
> Cheers,
>-Tristan
>
>
>> (2) A11y code will ignore invisible widgets
>> We're working on a patch that will make sure no accessibles show up
>> for invisible widgets.[4]
>>
>> Why am I writing this? Because if you happen to run code that breaks
>> due to these commits or think this is a bad idea in general, you now
>> know that it's happening and still have a chance to stop us before we
>> release this as GTK 3.8.
>>
>> Benjamin
>>
>>
>> 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible
>> 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show
>> 3: 
>> http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515
>> 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkWidget::visible

[Tristan Van Berkom]

On Wed, Jan 9, 2013 at 12:04 AM, Benjamin Otte  wrote:
> Hey,
>
> Today, in my quest to make things clearer in the GTK core, I'm
> tackling GtkWidget::visible.
> The flag is documented as "Whether the widget is visible."[1] or a bit
> better in the documentation for gtk_widget_show() as "Any widget that
> isn't shown will not appear on the screen."[2]
> However, this doesn't say anything about sizes, in particular sizes
> requested from a widget. So far, GTK would not check the visibility
> flag when calling size request functions ad would happily allocate a
> size to a hidden widget. It also would happily expose the widgets to
> the accessibility APIs. This has a bunch of problems:
> - performance suffers
> If we need to compute all these things for widgets we're not going to
> use anyway doesn't make Stuff Go Faster.
> - containers don't know what to do
> Should they skip invisible widgets when allocating? Or still reserve
> space for them?

That's not exactly true. All containers know what to do with invisible
children, all containers skip invisible children when requesting and
allocating sizes. They even have the option of doing different things
depending on the container type or the child properties of the given
invisible widget.

For instance, it can be useful in notebooks if the notebook reserves
space for invisible children, this way the notebook size does not
jump/change whenever one of the optional pages is shown/hidden
(I can't seem to find it, but was sure there was a
"request-space-even-if-invisible"
child property in one of our containers).

In any case, if we really want to do something drastic like this,
we should modify all the containers at the same time so that
they actually dont know what to do with invisible children anymore...

> - developers implementing widgets get confused
> Can they optimize things away when their child is not visible? Like
> can I skip the whole CSS machinery for hidden widgets in GTK?
> - developer expect those widgets to not do anything
> A11y people have lots of "fun" fixing bugs when Orca pokes into
> widgets nobody expects to be pokable. Usually developers just hide()
> widgets when they are supposed to be unresponsive and invisible and
> then they don't update them anymore and expect no callbacks to happen
> from them.
>
> So as a result, 2 things are going to be changed:
> (1) gtk_widget_get_preferred_width/height() will return 0
> With a recent commit[3], GTK will shortcut all
> get_preferred_width/height() to return 0 for minimum and natural sizes
> for all invisible widgets. Also, the allocation of the widget will be
> immediately recent to an invalid state, so gtk_widget_get_allocation()
> will return the initial { -1, -1, 1, 1 }.

I don't think this is exactly right.

There can be reasons to calculate the size of a widget regardless if it is
mapped or visible.

One example could be when creating a target surface for gtk_widget_draw().

Cheers,
   -Tristan


> (2) A11y code will ignore invisible widgets
> We're working on a patch that will make sure no accessibles show up
> for invisible widgets.[4]
>
> Why am I writing this? Because if you happen to run code that breaks
> due to these commits or think this is a bad idea in general, you now
> know that it's happening and still have a chance to stop us before we
> release this as GTK 3.8.
>
> Benjamin
>
>
> 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible
> 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show
> 3: 
> http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515
> 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Tristan Van Berkom]

On Thu, Jan 17, 2013 at 9:42 AM, Simon Feltman  wrote:
> Hi Everyone,
>
> I'm trying to figure out a complete solution for proper reference management
> of gobjects passed into python vfuncs and signal closures as "in" arguments.
> Currently pygobject will add a ref to gobject arguments marked as
> transfer-none during marshaling and additionally sink/ref the gobject when
> the python object wrapper is created around it. The initial added ref during
> marshaling is then leaked upon the closure finishing in most cases.
>
> The fix could simply be to not add the initial ref during marshaling (or we
> need to make sure it is released when the closure finishes). The problem is
> this behavior is relied upon when a floating ref is passed and is the
> explicit fix described in the following ticket (which un-fortunately causes
> a leak in the non-floating case):
> https://bugzilla.gnome.org/show_bug.cgi?id=661359
>
> The specific problem described in bug 661359 occurs when a python closure is
> connected to a GtkCellRendererTexts "editing-started" signal. During the
> start of editing, a GtkEntry is created and passed almost immediately to
> signal emission before any ownership takes place:
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderer.c#n864
>
> This results in the following ref counting behavior of the GtkEntry as it is
> used by gtk_cell_area_activate_cell and gtk_cell_renderer_start_editing:
>
> 1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry
> 2 (floating) - g_signal_emit argument marshaling adds an additional ref
> during signal emission
> 3 (floating) - python closure marshaling adds an additional ref described
> above
> 3 (owned) - A PyGObject wraps the GtkEntry and sinks the floating ref
> * python callback is called and passed the wrapper
> 2 (owned) - The PyGObject wrapper is destroyed after the python callback
> finishes additionally freeing a gobject ref
> 1 (owned) - g_signal_emit argument marshaling completes and frees the ref it
> added
> 2 (owned) - gtk_cell_area_activate_cell sets the CellAreas edit widget which
> adds a ref
> 1 (owned) - cell editing finishes and removes the widget from the CellArea
>
> Given the above it seems cell editing will leak a new editor each time
> editing occurs even if no closures are connected to the "editing-started"
> signal (python or otherwise). The pygobject specific problems I mention
> could be solved by tracking incoming floating refs and re-floating them upon
> closure exit if the python ref is not stored anywhere (or by attempting to
> just keep it floating). However, the root cause of all this could simply be
> that cell editing needs better reference management of the editors being
> created. For instance, gtk_cell_renderer_text_start_editing creates the
> GtkEntry and stores it as an attribute in GtkCellRendererText.priv.entry
> without sinking the ref:
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderertext.c#n2049
>
> I think this should be changed to immediately sink the ref and unref it
> during gtk_cell_renderer_text_editing_done. This would solve the python
> problems and fix the reference leak for the editor (and bug 661359 can be
> backed out). Additionally I think gtk_cell_area_set_edit_widget should be
> sinking the incoming editable widget instead of simply adding a ref:
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellarea.c#n3309
>
> As a general practice shouldn't refs be sunk when they are being assigned to
> a structured attribute especially when dealing with GInitiallyUnowned based
> objects?

Perhaps, but this would not solve your problem as I understand it.

  o Working around the problem by changing the way GTK+ code is written is
 not a viable long term solution afaict

  o Your issue as far as I can see is that a floating object gets passed as
 a signal argument, this can happen in a variety of situations,
 consider a construct where a code segment creates an object and
 passes it to another object immediately:

 --
 BaseBall *ball =
   g_object_new (BASE_TYPE_BALL,
 "pitch-type", PITCH_TYPE_CURVE,
  NULL);

 pitcher_throw_ball (pitcher, ball);
 --

 In this case the pitcher might own the ball for some time, or it
might in turn
 relinquish ownership and give the ball to the global Stadium * object.

 o Forcing the object to become floating again after the PyGObject is
finalized feels
rather hacky, it sounds like you will leak the underlying object
in cases where
ownership was actually intended (i.e. assignment to a PyObject member)

Rather, it sounds like PyGObject should not mandate sinking the
floating reference
until ownership is actually implied, i.e. by tying the lifecycle of
the said object to a member
of another PyGObject (a strong reference). Stack variables on the
other hand, such as
declared 

Re: Generalization of the GtkBuilder idea to arbitrary graphs of GObjects

[Tristan Van Berkom]

On Thu, Dec 13, 2012 at 4:52 PM, Dimitri  wrote:
> Hi,
>
> I am working on a multimedia-related project that will use
> GLib/GObject/GTK+/GStreamer/Clutter technologies extensively. The
> project will feature a number of externalized (not hardcoded) GUI
> fragments as well as a number of external GStreamer pipeline
> definitions. Most likely GTK+ will be used only for prototyping (if at
> all), and the production code will use Mx or even custom Clutter-based
> widget toolkit.
>

Hi,
   I don't have time for a full-fledged response but a couple of points
I'll write down in passing.

First, yes most of us agree that GtkBuilder/GtkBuildable should have
went down into GObject (actually the fact that we could transparently
put them in GObject later, was a reason why this was not a blocker
for Johan to originally land the GtkBuilder patches years ago), it
just never happened.

I've also had the idea to use it with GStreamer, however after
a brief conversation with people on #gstreamer it became clear
to me that building pipelines from xml was broken by design.

GStreamer has evolved into something much more dynamic and
should generally not be defined in the strict confines of xml
(i.e. dynamic caps negotiation etc make it possible to resolve
an undefined pipeline by examining the data which runs through it).

However, perhaps a less strict xml definition could be of benefit,
I'm not sure if there is much middle ground to be reached there.

In any case, thanks for bringing up discussion on this, it would
be nice indeed to have something more unified for deserialization
of GObjects.

Best Regards,
 -Tristan


> Thinking over the externalization mechanism, I've figured out that 1)
> since 1.0, GStreamer doesn't use XML pipeline representation anymore
> ("it was broken and never worked"), and 2) GtkBuilder won't help me
> much, because it is limited to GtkBuildable classes and isn't extensible
> enough. That's why I've come up with the idea of having more generic
> (de)serialization framework that could be extrapolated to arbitrary
> graphs of GObjects. It's also good to have single unified technology for
> dealing with both GUIs and GStreamer pipelines. With this, GUI controls
> and GStreamer elements could be addressed using unified mechanism. That
> would facilitate, for example, defining in a declarative way bindings
> for properties of GUI controls and Gst elements.
>
> What's similar between GTK+ and Mx GUIs and GStreamer pipelines:
> * they are all composed of GObjects;
> * GObjects have properties that could be either primitive or refer to
> another GObject (association link);
> * GObjects can emit signals that could be connected to handlers (this or
> other GObjects' methods).
>
> What's different:
> * Instantiation strategy:
>  - GTK+ and Mx objects are instantiated via simple construction;
>  - GStreamer elements should be instantiated via factory call;
> * Implementation of child/parent relationship:
>  - GTK+ uses GtkContainer semantics;
>  - GStreamer uses GstBin;
>  - Mx uses MxBin;
> * Other specific features:
>  - GStreamer elements' pads could be connected.
>
> Seems like the first part (dealing with generic GObject graphs) could be
> implemented in the framework core, while specific features (support for
> GTK+, Mx, GStreamer etc.) could be moved into plugins. As for
> externalization format, it should be human/machine
> readable/editable/writable (some sort of visual composer is planned).
> Here, XML seems to be a good choice due to (among other benefits) its
> extensibility via namespaces mechanism. Imagine the following code:
>
> 
>  Foo
>  
>   ...
>  
> 
>
> Or:
>
> 
>  
>   
>  
>  
>   
>  
>  
> 
>
> Thus, the root namespace (elements without prefix) should be handled by
> the core, while other namespaces (prefixed elements) will be handled by
> corresponding plugins. Support for St (GNOME Shell Toolkit) could be
> added as well, giving the ability for shell extension developers to use
> declarative UI technology. As far as I know, at the moment shell
> extensions have to define their UIs in JavaScript in an imperative way.
>
> I'll appreciate any considerations on this.
>
> Thanks!
> Dimitri
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Add new element and gtk_builder_expose_object() function to GtkBuilder

[Tristan Van Berkom]

On Thu, Nov 15, 2012 at 2:59 AM, Juan Pablo Ugarte
 wrote:
> Hello guys
>
> Question for Tristan and Marco
>
> Is there any specific reason why we should keep external object in a
> different name space (other table)
> now that this is only for object and not any variable?

They should ideally use the same hash (or namespace, as you put it).

However it calls to question some nastier implications, such as... what
happens when you expose an external object which has the same
name as a declared object... should the external object be used instead ?
(i.e. should it be able to override internally declared fragments ?)

I think at least for now, we want to keep things as simple as possible
so the answer is no, it should not be able to override anything, and
a warning should be issued if there are any collisions in the internal
hash.

Cheers,
  -Tristan

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

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

On Fri, Oct 5, 2012 at 1:57 AM, Steffen Gutmann  wrote:
> Hi Tristan!
>
>> Right, the bug might have to do more with cropping/scaling support
>
>> GtkImage, rather than it's size request.
>
> Filed as [Bug 685506] New: GtkImage and size/space management
>
>>>  Regarding size request:
>>>
>>>  We add a new property of type boolean to GtkImage.  If it is set (default),
>> the size request for GtkImage will be the size of the underlying image (or 
>> the
>> pixel-size), i.e. the exact same behaviour as it is now.  If it is set to 
>> FALSE
>> then the minimum size will be (1, 1) and an application can use
>> "width-request" and "height-request" for making the widget
>> size larger.  I am not sure what a good name for this new property would be, 
>> but
>> maybe you have a suggestion?.  Something like "min-size-is-image-size"
>> would probably make the property self-explanatory but is obviously too long
>> compared to other existing property names.  Maybe "full-image" or
>> "image-size-request"?
>
> Any comment about how to allow a smaller size request?  Any good name for 
> this property?
>
>
>>>  Regading placement:
>>>
>>>  In GTK2, GtkImage cropped the image such that only the center is shown,
>> i.e. it took off an equal amount of image content on the left and right, and 
>> top
>> and bottom.  It probably just sets the right clipping mask when drawing the
>> image for achieving this.  We could simply use the same policy, or we modify 
>> the
>> usage of GtkWidget's "halign" and "valign" properties.
>> Currently the docs reads:
>>>
>>>  "halign" GtkAlign : Read / Write
>>
>> While it's true that the align properties make no sense when the
>> widget's natural size is equal to,
>> or exceeds the widget's allocation;
>
> From a programmer's point of view, the align properties also make sense when 
> the widget size is smaller than its allocation.
> For example, for centering, one would draw the contents at 
> (allocation.width/height - contents.width/height) / 2 which works in both 
> cases, when there is extra space as well when there is insufficient space 
> (assuming clipping is done by cairo correctly).
>
>
>> I'm not exactly sure it's a good
>> idea to use the GtkWidget's
>> halign/valign properties directly (i.e. it's like hidden candy, people
>> wont see it evidently in
>> the docs/headers for GtkImage and so will probably not discover it).
>
> We could cross-ref the halign/valign properties in the docs of above new 
> property that describes how to obtain a smaller size request for GtkImage.
>
>
>> However I do like the idea of GtkAlign properties for that, where FILL
>> would mean scale
>> and CENTER/START/END have the obvious clipping behaviors.
>
>
> Right.  Actually I tried the FILL alignment with a GtkImage having extra 
> space.  The image becomes centered but not streched.  For keeping 
> compatibility, I guess we want to keep it this way.
>
>> Also, it should have reasonable behaviors defined for the various
>> configurations of
>> a GtkImage
>
>
> I think we are shooting too far here.  For icons and such I think the 
> "pixel-size" property is the right approach and the new property suggested 
> above should have no effect.  Otherwise, if we are trying to support all 
> combinations of configurations, pixel-sizes and the new property then we will 
> likely end up in open problems and the chance that any patch will be accepted 
> is going to be small.

I disagree with this.

What we definitely want to avoid in GTK+, is overextending the API
in ways that only apply to special case configurations (remember that
in most cases, once you introduce a new API it can not be removed in
a later release, this imposes more and more constraints on code
maintainability in the long term).

i.e., it's already annoying that "pixel-size" only applies to an icon loaded
from the icon theme (and so if we were to add some scaling/cropping
features that are more general, it would be better to deprecate the pixel-size
property if the same effect can be achieved with a newer API).

It's a priority for the API to be readable, and to avoid additions of
properties which introduce 'crowding' into the api, we should keep
GTK+ API as short and sweet as possible. Yes, that requires more
thought and consideration when writing platform code, that pays
off when the user is satisfied that user facing apis such as "pixel-size" does
what it says; regardless of other property settings.

If for instance, it is not possible to respect a property for a
given configuration of a widget, or it clutters the code to much and the
code becomes unreadable due to the attempt to manage all configurations,
then a good approach to that problem is to introduce subclasses to
handle that in a sensible way (i.e. it would have probably made sense
originally that only the GtkImageIconTheme subclass exports a
'pixel-size' property)

Like for instance, how we've split out the convenience apis for
GtkComboBox into a separate GtkComboBoxText class.

For n

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

On Thu, Oct 4, 2012 at 1:46 AM, Steffen Gutmann  wrote:
> Hi Tristan!
>
>> I suggest you start by filing an enhancement bug against GtkImage for this.
>
> Yes, I can do that.  Just to make sure, I file a new bug for component gtk, 
> severity set to enhancement, and put somethign like "Size request of 
> GtkImage" into the title.  Is this correct?

Right, the bug might have to do more with cropping/scaling support in
GtkImage, rather than it's size request.

>
>> If you have a patch to propose, here would be a good place to discuss
>> the proposed new apis.
>
> I might also be able to work on this and provide a patch.  Before starting on 
> this, how about the following changes:
>
> Regarding size request:
>
> We add a new property of type boolean to GtkImage.  If it is set (default), 
> the size request for GtkImage will be the size of the underlying image (or 
> the pixel-size), i.e. the exact same behaviour as it is now.  If it is set to 
> FALSE then the minimum size will be (1, 1) and an application can use 
> "width-request" and "height-request" for making the widget size larger.  I am 
> not sure what a good name for this new property would be, but maybe you have 
> a suggestion?.  Something like "min-size-is-image-size" would probably make 
> the property self-explanatory but is obviously too long compared to other 
> existing property names.  Maybe "full-image" or "image-size-request"?
>
> Regading placement:
>
> In GTK2, GtkImage cropped the image such that only the center is shown, i.e. 
> it took off an equal amount of image content on the left and right, and top 
> and bottom.  It probably just sets the right clipping mask when drawing the 
> image for achieving this.  We could simply use the same policy, or we modify 
> the usage of GtkWidget's "halign" and "valign" properties.  Currently the 
> docs reads:
>
> "halign" GtkAlign : Read / Write

While it's true that the align properties make no sense when the
widget's natural size is equal to,
or exceeds the widget's allocation; I'm not exactly sure it's a good
idea to use the GtkWidget's
halign/valign properties directly (i.e. it's like hidden candy, people
wont see it evidently in
the docs/headers for GtkImage and so will probably not discover it).

However I do like the idea of GtkAlign properties for that, where FILL
would mean scale
and CENTER/START/END have the obvious clipping behaviors.

It would have to deal well with situations where the user asked the
image to scale (FILL)
horizontally but to clip vertically ;-)

Also, it should have reasonable behaviors defined for the various
configurations of
a GtkImage (i.e, how does GtkIconSize fit into this ? does it make
sense to allow
the image to try loading the given icon at different sizes to satisfy
the allocation ?
naturally the natural size of the image would have to still be determined by the
user specified icon size, in the case that GtkImage be allocated extra space,
should a larger icon size be tried ? and should the image be upscaled as
a fallback or in situations where the source is a GdkPixbuf ?)

If you're serious about working on this, I would open an enhancement bug
and put your ideas there. You'll be sure to receive more feedback if you do
provide a patch with some test cases showing how it works.

Cheers,
  -Tristan

>
> How to distribute horizontal space if widget gets extra space, see GtkAlign
>
> enum GtkAlign
> typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, 
> GTK_ALIGN_CENTER
> } GtkAlign;
>
> Controls how a widget deals with extra space in a single (x or y)
> dimension.
>
> Alignment only matters if the widget receives a "too large" allocation,
> for example if you packed the widget with the "expand" flag inside a GtkBox, 
> then the widget might get extra space.  If
> you have for example a 16x16 icon inside a 32x32 space, the icon
> could be scaled and stretched, it could be centered, or it could be
> positioned to one side of the space.
>
> Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are 
> interpreted relative to text direction.
> GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful 
> way to stretch
> GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
> GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
> GTK_ALIGN_CENTER center natural width of widget inside the allocation
>
> My suggestion is to make halign and valign also deal with the case where the 
> content of the widget is larger than the allocated space.  The modified docs 
> would then read:
>
> "halign" GtkAlign : Read / Write
>
> How to distribute horizontal space, see GtkAlign
>
> enum GtkAlign
> typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, 
> GTK_ALIGN_CENTER
> } GtkAlign;
>
> Controls how a widget deals with space in a single (x or y)
> dimension.
>
> Alignment only matters if the widget receives a "too large" or "too small" 
> allocation,
> for example if you packe

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

On Tue, Oct 2, 2012 at 1:52 AM, Steffen Gutmann  wrote:
> Hi Tristan!
>
>
>
>> Lets not go around the merry-go-round one more time.
>>
>> In GTK+3, widgets receive *at least* what they requested in the size
>> requesting phase.
>>
>> User facing apis cannot undermine the minimal requirements for the geometry
>> which a widget has requested.
>>
>> User facing apis can however, enforce a minimum size (i.e. the widget
>> will be at least "this big")
>> or they can configure a widget in such a way that it will require less size.
>
> Ok, I accept this statement.  Will the docs of gtk_widget_set_size_request be 
> updated accordingly?

Yes, I'll take care of it tonight.

>
> For GtkImage though, I think we need some way to specify the minimum size 
> when a GdkPixbuf is used.
>
>> The "pixel-size" thing not working for pixbufs could be considered an
>> enhancement
>> request bug for GtkImage.
>>
>> i.e. it should support clipping of pixbufs (and then, it should also
>> need some alignment
>> parameters to decide which portion of the input image should be
>> clipped, also pixel-size
>> does not really imply clipping directly, the user might very well
>> expect the image to scale
>> to the desired size).
>
> The docs for gtk_image_set_pixel size says:
>
> "Sets the pixel size to use for named icons. If the pixel size is set
> to a value != -1, it is used instead of the icon size set by 
> gtk_image_set_from_icon_name().
> "
>
> This is not really clear to me.  Does it scale the image to the desired pixel 
> size, or center or crop them?  This should be specified in the docs.
>
> Also for a GtkImage based on a GdkPixbuf, don't we want to support different 
> values for width and height?  The pixel size only specifies one dimension.  
> Are the icons always of a squared size?
>
> Maybe two new properties in GtkImage would do the job, say 
> "pixbuf-width-request" and "pixbuf-height-request".  They would do the same 
> thing as
> "width-request" and "height-request" in GTK2.  Or, say we allow shrinking of 
> the size in "width-request" and "height-request" but only if an additional 
> new property "size-request-enforce" (boolean, default is FALSE) is set to 
> TRUE.
>
> Regarding alignment, the "halign" and "valign" properties in GtkWidget may be 
> useful.  Although they currently are only meaningful when there is extra 
> space, not when the content of the Widget is larger than the allocated space.

I suggest you start by filing an enhancement bug against GtkImage for this.

If you have a patch to propose, here would be a good place to discuss
the proposed new apis.

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

Re: g_get_home_dir (), ${HOME}, and getpwuid ()->pw_dir

[Tristan Van Berkom]

On Fri, Sep 28, 2012 at 1:38 AM, Stef Walter  wrote:
> On 09/27/2012 04:48 PM, Ivan Shmakov wrote:
>> $ HOME=/net/home/jrh emacs
>>
>>   Moreover, GNU Bash started under such a Emacs instance will also
>>   use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so
>>   will GNU Wget, or Lynx, and a sheer variety of other tools.
>>
>>   … But not the bulk of GNOME, which will insist on using
>>   /home/jrh/.whatever, perhaps leaving the user no way to choose
>>   otherwise (sans of persuading the local passwd(5) — or the
>>   site's LDAP — administrator to change his or her account.)
>
> Nah, you can use XDG Base directories to get the bulk of GNOME to use
> another directory for files, config, settings and so on. [1]
>
> Set $XDG_CONFIG_HOME, $XDG_DATA_HOME and $XDG_CACHE_HOME.
>
> These are exposed to GLib based software as g_get_user_data_dir(),
> g_get_user_cache_dir() and g_get_user_config_dir(). GNOME is actively
> moving towards using those. [2]
>
> FWIW, the default values for those are supposed to be derived from $HOME
> according to the XDG Basedir spec. So if the spec is to be taken
> literally it seems like we should be using $HOME instead of
> g_get_home_dir().
>
> But anyway, there is a way to use environment variables to change where
> the 'bulk of GNOME' looks for its stuff. And where not, there is active
> progress in fixing this issue.

Ok... I've been enjoying this read and, just thought I might point out that...

For example in my system which I installed 2 days ago, there is no
$XDG_CONFIG_HOME defined by default in my shell.

The spec seems to clearly state that if $XDG_CONFIG_HOME
is not defined, $HOME/.config/ should be chosen.

g_get_user_config_dir() ... probably getting popular in newer apps...
docs say:
   "On UNIX platforms this is determined using the mechanisms
described in the XDG Base Directory Specification."

However... upon reading the source... it actually falls back to
the value of g_get_home_dir() and not the $HOME which
was prescribed by the spec.

So, whether glib apps today try to comply with the XDG spec or
whether they store things directly in g_get_home_dir()... for the
grand majority of systems, they are instead... still getting the
password dir instead of the correct directory.

Interesting...

So... maybe we dont want to change the behavior of an api
that dates 10 years back, but we might want to at least correct
g_get_user_config/data_dir() at this point ?

Or, is it a bug in the documentation for g_get_user_*_dir() ?

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

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

Lets not go around the merry-go-round one more time.

In GTK+3, widgets receive *at least* what they requested in the size
requesting phase.

User facing apis cannot undermine the minimal requirements for the geometry
which a widget has requested.

User facing apis can however, enforce a minimum size (i.e. the widget
will be at least "this big")
or they can configure a widget in such a way that it will require less size.

The "pixel-size" thing not working for pixbufs could be considered an
enhancement
request bug for GtkImage.

i.e. it should support clipping of pixbufs (and then, it should also
need some alignment
parameters to decide which portion of the input image should be
clipped, also pixel-size
does not really imply clipping directly, the user might very well
expect the image to scale
to the desired size).

On Sat, Sep 29, 2012 at 2:28 AM, Steffen Gutmann  wrote:
[...]
> Here is what I am trying to do.
>
> I have an image.  The center part of the image contains a logo that I want to 
> display to the user.  Around the center part there is little extra content 
> that is not important but nice to have.  With GTK2 I set the min size 
> (properties "with-request" and "height-request") to just about the size of 
> the logo, place the GtkImage into a GtkWindow, set the default size of the 
> GtkWindow to slightly larger than the min size but smaller than the fulll 
> size of the image, make the window resizable, and show it to the user.  
> GtkImage in GTK2 automatically clipped the image and centered it.  The user 
> can enlarge the window and see more of the image, or shrink it down to the 
> min size where only the logo stays visible.
>
> I have not found a way yet to achive the same with GTK3.

a.) Create a GtkDrawingArea

b.) Connect to "draw" signal

c.) Use this code:

   gdk_cairo_set_source_pixbuf (cr, pixbuf, x, y);
   cairo_paint (cr);
   (borrowed directly from:
http://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html)


The above should pretty much get you what you want, just consider the widget's
allocation at "draw" time and use that to offset the given x,y for
gdk_cairo_set_source_pixbuf().

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

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

On 09/28/2012 02:16 AM, Steffen Gutmann wrote:

Hi,

with GTK2 some applications used to set the minimum size of some widgets using 
gtk_widget_set_size_request.  E.g. the min size of a GtkImage.  This no longer 
works with GTK3 and the min size of the GtkImage is that of the underlying 
image, e.g. a GdkPixbuf.


There is also a bug report here:


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

Is gtk_widget_set_size_request broken?  Or how is an application supposed to 
set (or override if the app knows better) the min size?


gtk_widget_set_size_request()

I must admit the docs are incorrect about this, it says:

   "Sets the minimum size of a widget; that is, the widget's size 
request will be/|width|/by/|height|/. You can use this function to force 
a widget to be either larger or smaller than it normally would be."


But what it should say:

   "Sets the minimum size of a widget; that is, the widget's size 
request will be/|width|/by/|height|/. You can use this function to force 
a widget to be larger than it normally would be."



In other words, as Cosimo already mentioned in the report, a widget can 
never be smaller than the minimum size reported by the implementation.


He also mentioned that you can configure that particular widget to 
actually be smaller.


Two other options are:
  o If you cant display the whole widget, put it in a scrolled window
  o Use clutter-gtk library to put the GtkWidget one a stage and then 
scale it and transform it to the desired size ;-)



Cheers,
  -Tristan


This email may reach you with EVIL HTML formatting which of 
course has no place in emails... for some config reasons TB needed to be 
used instead of Evo... and I still have to find the switch to NUKE EVIL 
HTML from emails





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


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

Re: runtime accel changes

[Tristan Van Berkom]

On Sun, Sep 16, 2012 at 8:05 AM, Benjamin Otte  wrote:
> Michael Natterer  gimp.org> writes:
>
>> I think my actual point here is: There are so many usecases
>> and levels of complexity in peoples' workflows, and
>> in the applications that can be written in GTK+, we should
>> not disable useful things because they are either not in
>> fashion any longer according to whoever defines "fashion",
>> or are out of scope for some refactoring. Instead, rather
>> adjust the scope of the refactoring.
>>
> I think this is not a very good argument. GTK is still severely understaffed 
> and
> has such a huge complexity already that it is necessary to cut. And to cut
> heavily. In particular because people expect GTK to grow even more features
> (mostly in the graphics and touch departments).
>
> Also, there is a lot of places where developers don't really understand the 
> code
> they are touching and the code does things in a "weird" way (read: It was
> written 10+ years ago when we were all writing code differently). And when
> someone actually does dare to touch these codepaths again, he'll have to make
> choices - and oftentimes the choice is not 100% backwards compatibility, but
> implementing desired new functionality. And I personally prefer people 
> reducing
> the amount of unmaintained code, even if the cost to that is features. And if 
> it
> turns out those features were great, hopefully someone will volunteer to add
> them back later.

I do agree and do disagree, in this particular case I think that we have code
in place that does do runtime accelerator changing properly, even if I would
personally like to privatise that accelmap/accelgroup stuff into some basement,
we do have a good GtkAction[Group] api that at least should take care of all
of this stuff automatically. There's no sensible reason to just throw that away.

Some examples in contrast; for instance when we ditched code generation
feature from Glade, *so many people complained* really they did, but we
did it on the grounds that the feature was crap and the feature itself had more
negative impact than positive.

On the other hand, ... oh how I would have loved to throw GtkSizeGroup in
the garbage when implementing height-for-width... based on the same arguments
perhaps I should have... but it's a useful feature that already worked (read: I
had not considered them properly and so I had to expand the scope of my
refactoring, that was my own fault and my own responsibility) it probably cost
me an extra week (maybe more) of hair pulling to get h4w apis to play well
with size groups.

And dont even get me started about GtkUIManager and that silly "merge ui"
feature... if it wasnt for that feature and our lazyness in porting that feature
into GtkBuilder proper then we would have ditched that double standard
of UI building years ago.

> I'm pointing this out because I don't like the way of reasoning here. I have 
> no
> real opinion on editability of keybindings.

...

I would think that anyone who has played starcraft... would have an opinion
about the usefulness of configuring keybindings without restarting the
application ;-)
(couldnt resist).

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

Re: runtime accel changes

[Tristan Van Berkom]

On Wed, Sep 12, 2012 at 9:15 PM, Paul Davis  wrote:
>
>
> On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer  wrote:
>>
>> On Wed, 2012-09-12 at 16:27 -0400, Ryan Lortie wrote:
>> > hi,
>> >
>> > I recently wrote a patch[1] to re-enable accel labels in GtkMenu
>> > generated from GMenuModel.  They got lost in the shuffle during some
>> > related recent changes.
>> >
>> > Essentially, the new approach means that the accel='' attribute of each
>> > menuitem directly determines what the accel label will be (instead of
>> > doing the lookup in the accelgroup).
>> >
>> > The most noteworthy impact of the patch (and the topic of this email) is
>> > the strong implication that we will no longer support runtime changing
>> > of accel keys.
>>
>> I object. Do you really want to disable shortcut editors in
>> complex applications such as GIMP? That would seriously hurt GTK+
>> as a general purpose toolkit. I can't imagine why you would do
>> such a change.
>
>
> I echo Mitch's objections. Ardour users find it very convenient to do
> runtime changes to key bindings. Requiring program restarts and all that,
> let alone the idea that bindings have to set at menuitem creation, all seems
> pretty piss poor to me.

While on the topic of accelerators, and since we have the attention of two real
user of them... I'm curious what you guys think of removing the need to use
GtkAccelGroup in GTK+ api.

>From what I see... all one should *need* to do is specify the accelerator keys
desired to trigger a given GtkAction and add that action to an action group
(either with GtkBuilder constructs or with
gtk_action_group_add_action_with_accel()).

The fact that a GtkAccelGroup must be added to a GtkWindow... and that it must
be referred to by the GtkActionGroup (need to set the
property/relation somewhere)...
is all a bit sub-par as an API (i.e. it's confusing, not obvious to figure out).

So my basic question is... is there anything good about manually
setting up these
accel groups at all ? GIMP is an example of a multi-windowed application (and
many apps can have a 'floating' editor for some purpose)... as it
stands whenever
you create an extra floating window that is not a temporal dialog, you must set
the GtkAccelGroup manually also for those windows for accelerators to work
while those windows have focus.

GTK+ of course manages an internal list of the app's GtkWindows... I
really dont
see the reason why GtkAccelGroup couldnt just be completely automated...
could we possibly just deprecate/eventually remove that from the (public) api ?

Cheers,
-Tristan

(PS: Sorry Paul for receiving twice this mail... forgot to reply-all first shot)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve handling of bug reports for GTK+?

[Tristan Van Berkom]

On Fri, Aug 10, 2012 at 2:29 PM, Andre Klapper  wrote:
> [Please CC me on answers as I am not subscribed ot this list.]
>
> The situation of GTK+ in bugzilla.gnome.org:
> High number of open tickets, high number of unreviewed patches,
> constantly growing number of tickets, no real triaging of reports.
>
> Feedback, please: I'd like to know how you (GTK+ developers/maintainers)
> handle GTK+ bugmail and work in Bugzilla.
> Do you read gtk+ bugmail at all? Does it scale? Is it too noisy?
>
> A first proposal (please tell me if it makes sense):
> https://bugzilla.gnome.org/describecomponents.cgi?product=gtk%2B lists
> for most components the default assignee "gtk-b...@gtk.org".
> In case you are only interested in following specific areas of the GTK+
> codebase (is that the case?), would it make sense to have one default
> assignees per one component (for example introducing
> gtk-gtkapplication-ma...@gnome.bugs for GtkApplication, and likewise)?
>
> Are there components missing? Which ones? It feels like lots of stuff is
> dumped under "general" that does not find a better home because there
> are no Bugzilla components for some of the newer widgets.

The important thing here is to have a high quality list of components I think.

Perhaps the GTK+ bugmail is not as high traffic as I expect it might be, but
personally I already receive all the bugmail for Glade and I also receive any
bugmail in GTK+ bugzilla regarding the GtkBuilder component.

When I was working on height-for-width support, we created the "EL"
(extended layout) whiteboard keyword for triaging... this is awkward
because one needs to perform explicit searches to get the EL bugs.

So, while I was working on the geometry management, I did lookup
those bugs on a regular basis... however since then I do not receive
any notifications regarding GTK+ geometry management issues.

If we can have at least a geometry management component,
which would be the appropriate place to submit patches/bugs
related to size requests and allocations done by various widgets,
then I would be happy to subscribe to those bugs as well and
it would be no trouble for me to review those patches as they
come in.

Perhaps GtkApplication would also be a good component, not
sure, however I think we want to define the components in such
a way that they are "domains of issues" and not particularly
code bases (the GtkTextView is a good exception since it is
really complex and separated from the rest of GTK+, the same
goes for GtkTreeView/GtkCellArea, which should probably
be in the same bug domain).

Also iirc, subscribing to bugmail is done in an obscure fashion,
it might help to have some additional support in bugzilla for that
(perhaps a list of check boxes to select the components which
one is watching in a given product... with a real user interface,
without having to understand that one needs to "watch the
activity of a virtual user who is assigned as the maintainer of a
given component", the current way is only really discoverable
over longer term interaction with other GNOME folks either by
irc or mailing lists (i.e. you have to be told that it's possible
before you can even subscribe to bugmail).

I also think that having more people easily subscribe to
bugmail is good for the project; I try to encourage any
of Glade's newer contributors to subscribe to the relatively
low traffic bugmail, I think it helps to give contributors a sense
of what's going on, a greater sense of responsibility and
a stronger feeling of being a part of something great.

My 2 cents,

Best,
-Tristan

>
> So, how would Bugzilla work better for you?
> (I'd also happy to discuss this in a GTK+ meeting, but
> https://live.gnome.org/GTK+/Meetings lists the next meeting for 15
> months ago.)
>
> andre
> --
> mailto:ak...@gmx.net | failed
> http://blogs.gnome.org/aklapper
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: next steps for touch support in GTK+

[Tristan Van Berkom]

Hi,
   I just went through a midnight read of this thread, might as well throw some
ideas relating to the several points which have (or have not) been made.

From a touchscreen perspective, you want to avoid spin buttons at large
cost if not all cost.

From my experience, in the context of a kiosk type machine (think touchscreen
jukebox or point of sales unit or such), first of all you want every
touchable area
to be *at least* as large as an index finger, even then some people with huge
fingers can and will be annoyed from using the interface.

If you have a 15" or 17" monitor & touchscreen to work with, as we did, then
you will probably permit yourself some spin buttons in the
operator/configuration
screens... you wont put very many in that screen... and the up and down arrows
will appear after the entry (not on top of each other but beside eachother, as
Emmanuele mentioned that takes too much height to be usable at all with touch).

However, even then with a 17" monitor we would never allow ourselves to place
these spin buttons in any "user" screens, the operator of the jukebox
has to spend
time configuring the thing, you dont want to annoy users with spin buttons.

On a tablet, if you really really cant avoid it, perhaps you can get away with
using a spin button. On a handset, I think you can just forget about it, or
limit yourself to having only one (or two ?) spin button visible at a
time (perhaps
inside a vertical scroll window, however sliders are usually better for this if
exact precision is not an issue).

Slider widgets need special care with touch as well, specifically you want
a huge knob, and you want the indication of "where you are" to be indicated
outside of the knob and not on top of the knob (perhaps the scale widget
is an index into the alphabet, or a numerical value, you want to see that
value "outside" the knob, not covered by your finger).

Secondly on slider widgets, you generally dont want this awkward "jumping" by
page size when the user touches the trough area.

The user's intention with a scale widget is to first "get the knob"
and then make
a modification to the scroll position (Up and Down buttons positioned above
and below the scale widget are helpful for fine grained modifications).

So the correct behaviour is to allow the finger to slide into the trough area
without modifying the scale value and allow the finger to "Enter" the knob
area... once the finger has entered the knob's area then the knob should
stick to the finger and move with it.
  a.) It should not "jump" unexpectedly towards your finger
  b.) It should not require that your finger cause the "button-press-event" to
   occur on the knob, it should instead be tollerant and allow the finger
   to slide into the knob area and control it.

The slider behaviour is also very critical when the slider is controlling
the master volume (of your home stereo system or whatever it is), of course
you dont want the volume to "jump" up just because you missed the knob
initially when trying to "catch" it).



On "bastardising" the toolkit to get touchscreen support in GTK+, I personally
never thought this was the point to touchscreen support in GTK+.

It will definitely be useful if for instance, GTK+ makes some things possible
on touchscreens which were not possible before, perhaps panning mode
in scrolled windows is a good example, at least some features in basic
widgets that you *need* in order to extend your UX to touchscreens.

One thing I'm most certainly convinced of is that applications (or their
user interfaces) will be written separately for touchscreen devices.
You wont be able to ship exactly the same code on a touchscreen
enabled device, set the gtk settings touchscreen mode = TRUE and
just hope for the best... that will never happen, or perhaps I'll just have
to see it to believe it.

So yes I think it's completely logical to build a widget kit on top of GTK+
which is particularly suitable for touchscreen environments, in any case
its what people will do (write custom widgets for touch in their own
applications).

I also believe that a GtkSwitch is programaticaly interchangable with a
GtkToggleButton, and it's a bit confusing too... when one changes a toggle
button to look "switchy" then one potentially needs to actually change code
(i.e. that vfunc which I was overriding in togglebutton no longer compiles
when I derive from switch ? ... I changed it for a switch and now
GTK_IS_TOGGLE_BUTTON() fails for a switch ? can I connect it
to that toggle action which I've been proxying my toggle buttons through
like before ?... definitely seems awkward).

Then again that's not really worth arguing, there wont be an api break till
GTK+4 anyway so...

Ok long night... food for though... lets sleep on it guys ;-)

Cheers,
-Tristan


On Sat, Aug 4, 2012 at 8:15 PM, Simon Feltman  wrote:
> Toggle buttons and the switch widget both suffer usability problems for me.
> The visual look of a button represents an a

Re: Fully winding down my involvement in GTK+

[Tristan Van Berkom]

On Sun, Jul 22, 2012 at 6:20 AM, John Emmas  wrote:
> On 22 Jul 2012, at 02:14, Michael Torrie wrote:
>
>>
>> I consider web-based forums to be the scourge of the internet.
>>
>
> Curiously, that's exactly how I feel about mailing lists.  Mailing lists work 
> well as long as the volume of traffic is relatively low.  They probably also 
> work well if you're a dedicated user who's willing to install and configure 
> an email client that supports them.  But once they start becoming busy, 
> mailing lists become a turn-off for the average user who doesn't want that 
> level of sophistication and doesn't need to be involved in most of the 
> discussions.
>
> Taking myself as an example...  during the past 3 years I've probably signed 
> up to 30 mailing lists.  Today, only 3 of those subscriptions are still 
> active.  I've unsubscribed from the other 27.
>
> Conversely, I've never unsubscribed from a web forum.  There are plenty of 
> forums that I use only rarely - but I've never unsubscribed from one.  I 
> still feel a connection to the relevant community, even if I rarely use it.  
> But I don't feel any connection at all to a community once I've unsubscribed 
> from its mailing list.
>
> So if the aim is to make users feel more engaged / more connected, I don't 
> believe that mailing lists are helpful.  In fact, if that's what you're 
> trying to achieve I'd go as far as saying that mailing lists are actually a 
> hindrance.  Whilst they can (and do) build a strong sense of community 
> between developers and the more dedicated users, the high volume of traffic 
> (which often isn't of much interest to the more casual user) makes them feel 
> irrelevant and excluded.  That's been my experience anyway.

No I don't think that is the aim at all.

The point is about developers, not users. Mailing lists are the only
proven way I know of
for coherently developing a product with many developers in many time zones.

This point is critical, after that... with remaining efforts left over
from developing said
software, or by the efforts of other unrelated contributors: help
forums and better
documentation can be written... none of that happens without the first
thing though,
i.e. the software being written by the developers who communicate on a
mailing list.

Support for users need not be delivered in the form of a mailing list,
but since there are
mailing lists for them... no reason to take that away from them
either... I'm sure there
are some user forums for GTK+ out in the wild as well.

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

Re: Fully winding down my involvement in GTK+

[Tristan Van Berkom]

On Sat, Jul 21, 2012 at 12:32 AM, Michael Torrie  wrote:
> On 07/19/2012 06:54 AM, Kristian Rietveld wrote:
>> Also, I struggle to identify with the community these days -- that
>> is, I do not agree how GTK+ is being developed. Discussions appear to
>> mainly happen on IRC, which I can impossibly follow, contrary to on
>> the mailing list;
>
> Now that you mention this, I have noticed practically no traffic on any
> of the devel lists in the last few years.  I am probably not alone in
> thinking GTK development had stalled (though GTK 3 is obvious evidence
> to the contrary!).  Does not give a good message to potential GTK users
> who want to check things out.  The non-devel lists do have a fair amount
> of traffic, but it is now somewhat rare to have core GTK developers
> participate like they used to in the old days.
>
> I agree heartily that the mailing list is a much better place for
> tracking development.  IRC is too instantaneous (time zones preclude
> participation often), and IRC logs are extremely tedious and difficult
> to follow as they lack the structure that e-mail has.
>
> As a lurker who would like to follow gtk development, if the developers
> would return to the list I think it would be of great benefit to
> potential contributors like me (though maybe the potential is too small
> to even consider).  Certainly as long as GTK development discussions
> primarily take place on IRC I will be unable to follow and even consider
> contributing in any way, even a tiny way.

I can see the perspective that one might have as a user or as a
potential tentative contributor.

>From a developer stand point, and I think I see where Kris is going
with his statements, I think that if we're going to stop using the mailing
list and discussing changes of relative or greater impact to the software,
then as a contributor, it feels like a flat out waste of time to contribute
to that project on your own free time and dollar.

Usually a contributor will have sporadic moments in which they can
contribute significant portions of GTK+, we all have our areas of
knowledge and our reasoning of why we implemented things the
way that we did.

When some poeple go ahead and start making serious changes
at a rapid rate without consulting the mailing list, with only some
IRC quick discussions... well... dont expect that it's up to Kris
to go sifting through the IRC logs and find the day that someone broke
the treeview code... and don't expect me to automatically know
when the size request caching logic gets broken because someone
wants CSS to be ideal and perfect and is willing to queue resizes
on every random widget in order to get there.

However, we ALL read the mailing list. If you bring up your proposal
on gtk-devel-list about how you intended to do something that
might implicitly break GtkTreeView code, well up until now we would
always have Kris to notice that.. and guide us better wrt code that
he knows better.

Honestly though, we shouldn't let ourselves run unchecked like
this for too long, it was GTK+3.0 that was released, yes it has not
reached a level of stability what we've come to expect from GTK+ 2.0

Yes that allows us to brake more things between releases, and
yes that's generally a good thing while GTK+ 3.0 is a young
new API ... and I think it's entirely fair to say that developers
have been bleeding to deliver something cool for a new GTK+ 3.0
API... and that discussing everything in the normal manner would
have slowed things down.

Sigh, and on a not-so-completely-off-topic... I also miss how
we used to have module proposal on d-d-l...

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

Re: Why are GtkAdjustments not buildable?

[Tristan Van Berkom]

On Sun, May 6, 2012 at 3:08 PM, Tadej Borovšak  wrote:
> Hello
>
>> Hello, does anyone know why GtkAdjustments are not buildable?
>
> They are buildable. (Glade has been producing markup for adjustments
> for as long as I know). What makes you think they are not?

Note: GtkBuilder builds any GObject, some object can optionally
implement the GtkBuilder inferface. This allows them to handle
the xml parsing phase in custom ways, effectively extending the
GtkBuilder format in the context of a specific object type.

GtkAdjustments are buildable simply because we can build them
using g_object_new() and configure it's properties using
g_object_set_property().

Cheers,
  -Tristan

>
> Cheers,
> Tadej
>
> --
> Tadej Borovšak
> blog.borovsak.si
> tadeb...@gmail.com
> tadej.borov...@gmail.com
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_rename() problem on Windows (and suggested remedy)

[Tristan Van Berkom]

On Sun, Apr 1, 2012 at 2:31 AM, John Emmas  wrote:
> I made the changes that were needed to make g_rename() more consistent but 
> they're fairly extensive and would probably benefit from being reviewed by 
> somebody else.  Initial reports from our end though, seem to suggest that the 
> renaming issue is greatly improved (on Windows).
>
> But  is this the best place to post about glib or is there a more 
> appropriate mailing list?

Hi,
   Yes this is the right mailing list to discuss glib development.

The appropriate thing to do next would be to create a patch against glib
git master, open a bug report in gnome bugzilla (if one does not exist
for the g_rename() issue yet, please try to search for an existing bug first)
and then attach your proposed patch there:
https://bugzilla.gnome.org/enter_bug.cgi?product=glib

Best Regards,
 -Tristan

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

Fwd: Requesting enough size, but not too much

[tristan . van . berkom]

forgot to CC the list:

Begin forwarded message:

> From: tristan.van.ber...@gmail.com
> Date: 12 February, 2012 9:29:37 PM GMT+09:00
> To: Murray Cumming 
> Subject: Re: Requesting enough size, but not too much
> 
> 
> On 2012-02-10, at 10:38 PM, Murray Cumming  wrote:
> 
>> I would like my application window to be:
>> - At least as big as a certain minimum size.
>> - A little bigger if the screen is big enough for that.
>> - Not bigger than the screen.
>> - Not bigger than necessary.
>> 
>> I can control the size of my window by calling these functions on the
>> individual widgets:
>> gtk_widget_set_size_request ()
>> gtk_entry_set_width_chars()
>> but they only let me set a minimum size.
> 
> gtk_widget_set_natural_size() was a desirable API which
> we did not land by 3.0 but I think it would be a very welcome
> addition (havoc also suggested that one).
> 
> I've also noticed that current 3.x behavior is to
> have the windows's default size be derived from 
> the natural size request automatically.
> 
> I'm not sure if the default size also automatically
> maxes out at the screen size... but I think essentially
> we're just missing the API to manually force the natural
> request of a given widget.
> 
> Sry for quick short reply from hand held device...
> 
> 
>> I can also call
>> gtk_window_set_default_size()
>> but I consider that hacky compared to setting child widget sizes, and
>> it has the same problem anyway. 
>> 
>> Is there no way to specify both a minimum width and natural width (and
>> height) without deriving custom widgets, to override
>> GtkWidget::get_preferred_width() ?
>> 
>> 
>> I fear that I have to use 
>> gtk_window_set_geometry_hints(), but that would need me to hard-code
>> window sizes:
>> http://developer.gnome.org/gdk3/stable/gdk3-Windows.html#GdkGeometry
>> 
>> -- 
>> Murray Cumming
>> murr...@murrayc.com
>> www.murrayc.com
>> www.openismus.com
>> 
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Tristan Van Berkom]

On Thu, Jan 12, 2012 at 9:37 PM, Paul Davis  wrote:
> On Thu, Jan 12, 2012 at 7:31 AM, Ross Burton  wrote:
>
>> Tasks has a undo manager/undoable implementation and that's
>> implemented by function pointers that do the right thing, so you can
>> probably implement both methods with that.
>
> well, sure. i guess i was assuming that much. maybe i'm just thinking
> too much about how you actually implement undo/redo, not what the API
> for "undo the last change" or "redo the last undone thing" looks like.

Actually, my latest attempt at undo/redo, after analyzing the
difficulties which cropped up in Glade I've recently taken a
wildly different approach.

Hint, validation of whether a newly created command is a key
point in a data-model centric undo/redo system, there is much
pain involved when trying to mount an api "layer" on top of
an undo/redo system which interacts with the data model.

In this light I've decided to make my data models themselves
implement an "executable" interface, depending on object state
and of course, object type in a complex hierarchical model,
an executable object can simply refuse to create a command which
operates on the model.

I've found this greatly reduces complexity in policing command
validity (for instance if I were to apply this to Glade,
then a derived widget adaptor for say, a GtkBin widget could
simply refuse to create a command which adds a second child
to the widget... in the process it could even pop-up a dialog
informing the user why his request was impossible... Glade
is a good example here because there can be many specific
cases where a command would fail... centralizing that check
work on the widget adaptors make's a lot of sense).

Possibly it makes sense for GtkTextView to implement it's own
undo/redo system internally, if it can be assumed that the
text view (or text buffer more likely) is really only modifying
text.

However it would be good to be able to disable that feature,
consider for instance an elaborate implementation of GtkSourceView:
perhaps in that case there are many portions of text, but also
perhaps the underlying buffer implementation should be implemented
with "symbol" objects, possibly making reference to objects
constructed/introspected from a loaded gir file... in that case
implementing undo/redo on a "code structure" data model that
is displayed in a derived GtkTextView should be done separately
from the base "only text" implementation.

Anyway, some food for thought...

Cheers,
 -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Tristan Van Berkom]

On Thu, Jan 12, 2012 at 7:23 PM, Alexander Larsson  wrote:
> On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
>
>> VALIDATION
>> Many developers in the web world have become accustom to "validating"
>> the contents of forms before submitting them. While we would often argue
>> against allowing invalid input in the first place, that can often
>> confuse users. In this case, allowing the input and providing an
>> accurate reason why the input is invalid yields better results. I'm not
>> sure what a good API here would look like, but it needs to be flexible
>> enough to work with built-in and custom widgets.
>
> There is some level of validation in the gtk+ printing dialog. The
> printer configuration files (PPD files) can specify certain combination
> of enabled features as "incompatible" (i.e. can't do full duplex while
> stapling or whatnot). Whenever something is invalid we show a label
> somewhere explaining the problem and then each problematic settings
> widget gets a warning icon.
>
> This is imho a pretty nice way to handle validation. You're not unable
> to input invalid input (which can be confusing), but you get instant
> feedback on when and what is invalid.

This is a very good point, it would be great to incorporate some basic
validation mechanisms in GTK+, in many cases form style validation
is possible, i.e. one can fire up a dialog and hit the "Apply" or "Commit"
button at which time entry validation can take place, but in some cases
that's just really annoying (i.e. who needs to waste time with the extra
step of firing up a dialog and hitting a "Commit" button). While configuration
dialogs definitely fall into the first category, many editor applications
such as user interface designers or image manipulation programs have
property editors available at all times. In these cases validation should
always happen synchronously.

I think the warning icon with tooltip is a good idea, I've also considered
changing an entry's background color to be red while invalid input is
entered (of course this requires that the theme define what is a proper
"error" color...)

One classical error we should keep in mind is that entry validation
at focus-out time is just not stable, in many cases for instance you
get a situation where:
  a.) User selects object
  b.) As a consequence, current values are set in the editor widget
  c.) User enters invalid input
  d.) User selects another object
  e.) New values are entered into the editor frame
  f.) Finally, after old input is potentially lost, the focus-out event is
  finally delivered and validation is no longer possible or logical

This is a common problem in multiple platforms and toolkits, it would
be great IMO to have some backing support from the toolkit to help
developers to get it right the first time.

Cheers,
   -Tristan

>
>> MENU BUTTON
>> A GtkButton that shows a menu when clicked (and handles positioning,
>> etc). Some would just use a combobox, but I find them pretty different.
>> You'll find this sort of "menu button" in various VMware products on
>> Linux. (I know the fullscreen toolbar used to have it at least).
>
> Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to
> do but would be nice to have in a single place. Also, it needs some help
> from the theme to look good, like adwaita does here:
> http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705
>
>> WIDGET STACK
>> Like a notebook with no tabs or decoration. You "push" and "pop" widgets
>> on and off the stack. This is the navigational structure often found on
>> iOS. The reason I think abstracting it might make sense is more about
>> animating between widgets once Gtk starts landing animation (post
>> clutter integration obviously). It would be great if this nicely
>> integrated with a "navigation bar" type widget. Here[3] is a video of
>> some crappy animation code I wrote to do this.
>
> Not only does it help with animation, but its also nice in terms of size
> allocation. Often you want a set of widgets that can temporarily change
> into another set (for instance during editing) without causing a UI
> reflow. Having a widget stack like this helps with this size allocation
> handling.
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: new features

[Tristan Van Berkom]

On Thu, Jan 12, 2012 at 1:38 PM, Christian Hergert  wrote:
> On Thu, 2012-01-12 at 03:59 +0100, Benjamin Otte wrote:
>
>> PLOTS
>> This is my personal pet peeve. I often have something I'd like to
>> quickly plot in GTK, but it always ends up being more complicated then
>> I thought, so I either stare at text or use Gnumeric to get my plots.
>> And all the other applications (like virt-manager or
>> gnome-system-monitor) that do plotting look rather crappy and their
>> plots don't provide a lot of features (no zooms, no tooltips with
>> actual values, no ability to expand or collapse certain parts).
>> However, is a plotting widget a useful addition to GTK? If it works
>> well, it would surely enable people to show lots of useful statistics
>> that we'd all be thankful for - collecting them is not hard after all,
>> but making their output useful is. I'm sure a lot of people would like
>> bandwidth graphs in NetworkManager, page load performance graphs in
>> Epiphany or an interactive bootchart. Even if it's "just" the
>> developers using it to improve the rest of the world.
>> That said, such a widget would need a simple interface - both in API
>> and UI, and I'm not seeing anybody working on that. But I'd be very
>> interested.
>
> The part I found frustrating while working on scrolling[1] graphs was
> coming up with a good model for storing data points. Especially when you
> consider being able to graph different scales or modes of graphs. Say
> heatmap, 2d plot, 3d plot, etc. Linear or logarithmic scales, etc. And
> then also abstracting the look of the plot and the renderers.
>
> Below is a list of things that come to mind. I'm kind of forcing it, not
> particularly attached to the list below. I'm just trying to provide some
> diversity.
>
> VALIDATION
> Many developers in the web world have become accustom to "validating"
> the contents of forms before submitting them. While we would often argue
> against allowing invalid input in the first place, that can often
> confuse users. In this case, allowing the input and providing an
> accurate reason why the input is invalid yields better results. I'm not
> sure what a good API here would look like, but it needs to be flexible
> enough to work with built-in and custom widgets.
>
> DOCKABLE PANELS
> There is an in-between that might be reachable instead of a full docking
> library. The idea is more of "panels". It's like float-able tool palette
> that can be joined together. GIMP has this, and it's pretty bad. Which
> could be an argument against it. But you can see a good implementation
> in OmniGraffle[2] for OS X.
>
> MENU BUTTON
> A GtkButton that shows a menu when clicked (and handles positioning,
> etc). Some would just use a combobox, but I find them pretty different.
> You'll find this sort of "menu button" in various VMware products on
> Linux. (I know the fullscreen toolbar used to have it at least).
>
> WIDGET STACK
> Like a notebook with no tabs or decoration. You "push" and "pop" widgets
> on and off the stack. This is the navigational structure often found on
> iOS. The reason I think abstracting it might make sense is more about
> animating between widgets once Gtk starts landing animation (post
> clutter integration obviously). It would be great if this nicely
> integrated with a "navigation bar" type widget. Here[3] is a video of
> some crappy animation code I wrote to do this.
>
> ENTRY COMPLETION
> We already have entry completion, but it would be much more useful if it
> let you see the list of possible completions.

I'm not 100% sure, but I think this can be done now, if not it's really not
so far off the mark.

Generally you would create a gtk_combo_box_new_with_entry()
and add a GtkEntryCompletion to it.

We might be missing the part that, the dropdown menu should be
positioned completely *below* the combo box and the items should
be filtered while the user types, but I haven't tried it recently, it wouldn't
surprise me if we already support this feature.

>
> Cheers,
>
> [1] http://audidude.com/?p=470
> [2]
> http://westergaard.eu/wp-content/uploads/2010/11/OmniGraffle-Professional-001.png
> [3] http://www.youtube.com/watch?v=lp6ceGP-6vU
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: UI design

[Tristan Van Berkom]

On Tue, Jan 10, 2012 at 2:25 AM, Benjamin Otte  wrote:
> On Mon, Jan 9, 2012 at 5:40 PM, Tristan Van Berkom  wrote:
>> I think the first thing we have to keep in mind is that while well-known
>> use cases of GTK+ are in the domain of "desktop applications" there
>> is a great deal of use cases that are not tied in to desktop environments
>> (be they, mobile desktops or laptops or other generalized personal
>> computing devices).
>>
> Keep in mind that those kiosk or other embedded applications
> themselves are the platform though. So for those cases, the
> distinction does not matter. It doesn't even matter if you have
> multiple applications if you still control the design of all of them
> (you can do sth like
> http://git.gnome.org/browse/gnome-themes-standard/tree/themes/Adwaita/gtk-3.0/gnome-applications.css
> to the system theme).  It only gets interesting once you want to allow
> external developers to integrate with your platform.

(sorry for late reply ;-))

Yes that is a good point, when you write a GTK+ application for a
dedicated device, of course you control the platform so essentially
this distinction is moot.

>> Application developers obviously have a stronger say, they can:
>>  - augment the theme experience by adding their own css
>>    on top of whatever is running underneath
>>
> Keep in mind that if your application wants to "extend" the desktop
> theme and the desktop theme can be changed by users, these extensions
> must work with any theme, including future themes that do not exist
> yet. So you must make your widget integrate well with any color,
> padding, size and so on. And from my experience most custom CSS
> already fails when using the dark theme, let alone the a11y ones.
> I would actually go so far as to say every call to
> gtk_widget_override_*() is broken if you don't control the theme.

Ok here is a good example of a problem we need to solve and
I think I have a decent idea of the direction we need to take to
solve it.

Essentially: we need a way to make things absolutely clear
when it comes to communicating the application's needs to
the theme.

One problem IIRC was that GTK+ theme had been
overriding explicitly set toolbar style, I think that the current
solution is that if the user sets a toolbar style, GTK+ theme
will not override it, giving application developers the opportunity
to use GtkToolbar widget in different portions of their application
than up at the top as what we commonly refer to now as
"the main application toolbar".

Now it's kind of assumed that application developers should
not override the toolbar style for the main application toolbar
because this configuration should follow the desktop settings etc.

For the case of the toolbar, this is working fine enough IMO.

Now a problem we currently have in Glade/gedit, is that we
absolutely need to override the padding of a GtkButton which
we place into the notebook tabs with a stock rendered 'X'
icon.

This is a more difficult issue because GtkButton can be used
in many different contexts, it's easy to say that a GtkButton
which is placed into a GtkButtonBox should have a certain
appearance... and then application developers have the
choice to pack the button into something different than a
GtkButtonBox if they need to escape the implied theming
consequences, but it's completely inappropriate to say
that theme writers should start to theme the GtkButton
differently if it's somewhere in a notebook tab, or elsewhere.

There are possibly a few approaches to address this
problem:

   a.) Introduce some sort of "role" attribute on widgets which
allow theme writers to base their theming on a specific
"role" for which the widget was indented by the application
developer.

This is a bit undesirable because roles could quicky become
too many in number and hard to control, every apps needs
can be different after all.

   b.) We could consider white-listing specific widgets for theming,
perhaps even if it only goes as far as padding and alignment
white listing

For instance, a GtkButton would receive the regular theme attributes
but only a GtkThemedButton would be effected by spacial attributes
from the theme (i.e. this would become the "law" for theme writers).

Option b.) makes a lot of sense when it comes to composite widgets such
as GtkInfoBar, GtkButtonBox children etc, then we get grey area around
widgets like GtkProgressBar (again, I need to put those in notebook tabs,
I dont want theme writers to muck about with the padding/alignment of
progress bars in my notebook tabs, but perhaps the padding and alignment
should be assigned for the progress bar which is specifically inside a
GtkProgressDialog
o

Re: RFC: UI design

[Tristan Van Berkom]

Very interesting topic, I'm going to throw some responses out there
without thinking too hard, if the thread gets very interesting we can
build from there ;-)

I think the first thing we have to keep in mind is that while well-known
use cases of GTK+ are in the domain of "desktop applications" there
is a great deal of use cases that are not tied in to desktop environments
(be they, mobile desktops or laptops or other generalized personal
computing devices).

It's hard to say even if desktop applications written with GTK+ actually
outnumber other kiosk or embedded use-cases (generally competent
companies developing on any embedded platforms tend to whine a lot
less so we just dont hear about them very much on the lists), so let's
please try not to setup any barriers to our beloved toolkit.

On Tue, Jan 10, 2012 at 12:29 AM, Benjamin Otte  wrote:
> Hey,
>
> Here's another discussion point I want people to think about before
> the hackfest. This time it's not so much about API in a direct way but
> more about a guiding principles for the kinds of APIs we want to
> provide. The short question is this:
>
>  Who gets to decide how an application looks?

I think this is easy enough, the answer of course is both the
desktop theme writers and application developers.

Application developers obviously have a stronger say, they can:
  - write applications which leverage the theme, by using
stock GTK+ widgets
  - augment the theme experience by adding their own css
on top of whatever is running underneath
  - they should probably have the option to opt-out of desktop
installed themes, if their CSS is complete enough for their
use case and don't wish to pick up unexpected artifacts
on systems with odd themes installed
  - application authors can also use completely customized
widget kits (i.e., start with 3 or 4 derived GtkWidgets and
build an application with that), which dont use CSS at all
and perhaps load & cache images directly.

In the end I think that application developers will always find
a way to circumvent an installed theme, so it makes no sense
to make their life harder and force desktop installed css to
be pushed into their app.

Theme writers don't design applications in the first place, they
can decorate standard GTK+ widgets which are used in application
design, changing the look of an already designed application, for
applications which chose to leverage the theme (which is probably
default for any desktop application).

In this light, desktop themes should consist only of basic elements,
i.e. main application toolbar (may have a different look from other
toolbars used in the application), entries... GtkButtonBox and
GtkButton (for grouped buttons you may want to round the first
and last button edges, but never make this kind of assumption
for a GtkBox).

Desktop themes should refrain completely from setting up complex
CSS selectors, such as "if this button is somewhere inside a Grid
which is in the second scrolled window if it's parent GtkBox", I don't
know why it might happen but I can imagine a theme writer saying
to himself "Damn it, Evolution should look _exactly_ like this with
my theme installed", I think theme writers should not have that right,
they should instead be limiting themselves to providing a nice theming
environment for basic elements of the application.

> This question is aimed at theming and the question of graphic
> design[1] and not at intersection design[2]. The way I see it, there
> is two extremes to this:
> A) The application decides on the theme
> Examples: The Web, Windows, Games
> On the web, no page looks like any other page. If you for example
> compare http://maps.google.com and http://www.openstreetmap.org/ one
> of them looks greenish with a lot of rounded corners, the other
> blueish with sharp corners; font sizes are different and so on. Every
> application decides on its own how it wants to look and implements
> that look.
> B) The platform decides on the theme
> Examples: GNOME 2, OS X, office suites
> Here the platform decides how things look and it's discouraged to
> deviate from the norm with custom designs. ITunes could win a Finder
> look-alike contest, even though both are very different applications.
> Even portable applications try to blend in. You will notice that
> Firefox looks a lot more like a platform app on OS X and GNOME than it
> does on Windows.
> Of course, there are a lot of shades of gray inbetween. Phone
> platforms have UI guidelines but applications often break it and games
> don't look like Apple apps even on OS X. OTOH Microsoft applications
> blend in quite well with the Windows design and all the Google web
> pages look very similar, too.
>
> There is no obvious answer for which way is better. But a lot of
> things need to be done very differently depending on what way you
> decide to implement. Some examples:
> - switching themes
> Using a completely different theme is a thing people like. With
> platfo

Re: Bug 666728 - critical warning in libgee

[Tristan Van Berkom]

On Thu, Jan 5, 2012 at 10:40 AM, Ryan Lortie  wrote:
> hi Maciej,
>
> Thanks for bringing up this topic.  I'm not exactly sure what the proper
> way forward is, but you raise some interesting possibilities.
>
> On Thu, 2012-01-05 at 01:32 +0100, Maciej Marcin Piechotka wrote:
>> I don't think I can fix on libgee side without breaking API/ABI (at
>> least I don't see it). I believe that because currently various GNOME
>> applications depends on libgee it means that bug effectively breaks
>> GNOME (by breaking for example gnome-shell or empathy).
>
> I talked to Jürg a bit about this problem and I think he decided that
> the appropriate thing to do would be to modify Vala to prevent Gee from
> doing this in the first place.
>
>>  - Treating g_object_interface_install_property as override property if
>> interface have prerequisite
>
> I think this wouldn't help.  The problem comes from the fact that two
> separate interfaces are defining a property with the same name and
> different types (so far so good) and then a class tries to implement
> both interfaces (one directly and one by inheritance).  Boom.
>
> What we could do is to try to step up the intelligence in GObject about
> *which* property to override to pick the more-compatible type.  I resist
> this because it's not simple and because in the event that you have two
> properties with the same name, why should we arbitrarily pick one over
> the other at all?  Even if the types are compatible, we still have
> (admittedly small) questions about things like which description string
> we want to end up with.  That might be a small practical concern, but it
> gives me a distinct feeling of "this is icky...".

Strongly agree with Ryan here, lets please refrain from allowing subclasses
to implement interfaces with conflicting property names at all.

Critical warnings should be fired, perhaps g_object_class_add_interface()
should simply fail in the case that a property name clashes with a class
property or another interface property (is this not already the case anyway ?).

Otherwise it becomes very easy to introduce undefined/random behavior
from apis like g_object_set/get() (or g_object_class_list_properties()... etc)

Cheers,
   -Tristan

>
> I think we should possibly consider being *more* strict in this area: if
> there are two possible properties of the same name that you could be
> overriding then g_object_class_override_property() should probably fail.
>
>>  - Change Vala to use g_object_class_install_property(s) instead of
>> g_object_class_override_property.
>
> I think this would be pretty reasonable.  Vala has enough information to
> be able to pick the correct information to register the property with,
> from scratch.  It could also give a meaningful compile time error if
> it's not possible to reconcile the types in a way that works with the
> access flags of each of the properties.
>
>>  - Change error into warning, remove it from libgee 0.7/0.8 and change
>> back into error when the old software die.
>
> It's just a critical now, so nothing should die.
>
> I suppose we could downgrade that to a warning if you're worried about
> people running with fatal criticals.
>
> Cheers
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[tristan . van . berkom]

On 2011-12-14, at 12:34 AM, Matthias Clasen  wrote:

> On Tue, Dec 13, 2011 at 12:21 AM, Tristan Van Berkom  wrote:
> 
>> GMenuModel in itself is a little stuck, it depends on GActions which
>> are really tied into the whole DBus thing, so even though conceptually
>> it might not be IO, actually it is an IPC data model (I'm really starting
>> to think we should definitely remove the word "Menu" from that
>> data model, GActionModel or GModel even... and keep it low-level
>> generic, reusable and "sweet", not a specially targetted dinasaur just
>> for menus).
> 
> Not sure why you think so. While

Simply because I've only seen GAction
as a counterpart of GApplication apis.

I was not aware of their usefulness 
outside of the 'application' context

> GActions certainly have been designed
> with an eye towards easy exporting on the bus, they work perfectly
> fine in-process as well.

are you arguing that perhaps GAction
as well as the encapsulating GMenuModel abstract interfaces should find a 
living area below libgio ?
(or as I recall, "above" since your
stack was upside down ;))

Personally I think data models & abstract interfaces for working with GObject 
look better in libgobject than
in libgio, it's not worth arguing that to the death but obviously, avoiding 
another occurrence of libgnomeui is worth arguing for... 

Cheers,
  -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Tue, Dec 13, 2011 at 6:53 AM, Matthew Brush  wrote:
> On 12/12/2011 10:45 AM, Ryan Lortie wrote:
>>
>> On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:
>>>
>>> My (probably misguided) opinion is that if this type of stuff can't go
>>> into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
>>> library or something like this.  I have doubts how many apps linking to
>>> GIO without GTK+ are going to need such a model, either because they
>>> don't have a UI at all or are using some other toolkit which likely
>>> provides a mechanism of its own for this.
>>
>>
>> We had this conversation in context of GSettings, a few years ago.  It
>> wasn't really IO, so why should it go in GIO?  We threw around the idea
>> of libgplatform or libdesktop and so on and decided that we should just
>> treat libgio as this.  That's when we started (only half-jokingly)
>> insisting that GIO stands for "GLib Interfaces and Objects".
>>
>
> I think a separate G library would be an *excellent* idea, much more
> sensible and practical from a "consumer" (app developer) POV.  A quick scan
> through the API docs, I'd nominate the following to be moved to a separate
> library:
>
>  - Icons
>  - Settings
>  - Application support
>  - (the menu stuff)
>
> Everything else in there seems to be, even if not purely "IO", at least used
> by or in conjunction with the other stuff that is (I think).
>
>
>> I have a long-held belief that the "model" side of things that are not
>> directly related to widgets should be kept outside of the toolkit.  I'd
>> support, for example, a GtkTreeModel replacement to be merged into
>> libgio.
>>
>
> Yep, I certainly don't disagree with this either, just that it's strange to
> put this type of stuff in the IO library (IMO).  It feels like there's some
> stuff in the G stack that's looking for a home and everything just winds up
> in GIO, like it's a dumping ground for miscellaneous stuff (which I guess it
> is as you said, presently).
>
> I just fear people will start calling GIO "bloated" and GNOME-bound  and
> might cause people who would've otherwise used this excellent IO library to
> either re-write their own or look elsewhere.

I have to agree with Matthew to an extent, no people will probably not
rewrite their own versions of this code just because we eventually become
terribly disorganized, however they will notice the disorganization of the
stack and will become disgusted with it.

GMenuModel in itself is a little stuck, it depends on GActions which
are really tied into the whole DBus thing, so even though conceptually
it might not be IO, actually it is an IPC data model (I'm really starting
to think we should definitely remove the word "Menu" from that
data model, GActionModel or GModel even... and keep it low-level
generic, reusable and "sweet", not a specially targetted dinasaur just
for menus).

I would have to disagree about treemodel, data models, yes, would
be nice to push down the stack from way on top in GTK+, but why
not glib ? Of course I think the treemodel interface would have to
be re-engineered to reach our expectations of excellence before
being pushed all the way down to glib, but I think that would be
more appropriate than "dumping it into libgio just because".

GtkBuilder belongs in glib for instance, not in libgio.

Cheers,
   -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Mon, 2011-12-12 at 10:18 +0100, Stefan Sauer wrote:
> On 12/12/2011 03:24 AM, Matthew Brush wrote:
> > On 12/11/2011 12:14 PM, Stefan Sauer wrote:
> >> On 12/09/2011 01:00 AM, Ryan Lortie wrote:
> >>> hi,
> >>>
> >>> Today I landed the GMenuModel work on glib master.  A release will be
> >>> following shortly.
> >>
> >> Just one quick question - why is this in GLib? Is that to allow
> >> command-line apps to have a menu?
> >>
> >
> > I tried to ask this here a day or two ago but had problems, so I asked
> > Ryan on IRC. The answer is that it's in GIO rather than GLib and there
> > is precedence; GIcon for example.
> >
> > My (probably misguided) opinion is that if this type of stuff can't go
> > into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
> > library or something like this.  I have doubts how many apps linking
> > to GIO without GTK+ are going to need such a model, either because
> > they don't have a UI at all or are using some other toolkit which
> > likely provides a mechanism of its own for this.
> 
> I think this is not so easy. Having a glib-app library sounds goo, but I
> believe we don't want to have too many mini libraries. On the other hand
> I wouldn't look for it in gio either.

I know not everyone is so crazy about the idea, but perhaps this
will be a good starting point for implementing a decent desktop
IPC environment.

For an example that I'm familiar with, currently Glade has to
invoke DevHelp and detect DevHelp existence entirely through
the command line.

Ideally Glade, IMO should simply be activating the 'search' action
on the DevHelp entitiy.

>From my very limited understanding of GMenuModel, essentially this
is only a wrapper around GActions and action groups, implements a
hierarchy of actions and such with some probable merging/pathing
sugar apis, those actions will be accessible by other programs on
the Bus.

Some of those programs *might* happen to be a desktop environment
that wants to display menus from these hierarchical actions which
have been assigned a special token such as "I am the App menu", other
applications might very well not have anything to do with displaying
menus at all... perhaps a11y technologies could be transparently
integrated into a system that exports good introspection via the
GMenuModel, perhaps one could use GMenuModel to extend their 
application with a sister application which syncs the application 
state with some database or webserver interface... simply by
adding the extra program, starting it and giving it access to
the bus.

Point being that just because having a hierarchical structure of actions
exported on the bus might be useful for a desktop menuing system, does
not mean that it's not a useful concept when applied in different
ways... it might rather be called 'GActionModel' and then just by it's
name have much more relevance in libgio...

Just 2 extra cents...

Cheers,
   -Tristan


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

Re: GMenuModel has landed

[Tristan Van Berkom]

On Fri, Dec 9, 2011 at 6:11 PM, Petr Tomasek  wrote:
> On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
>> hi,
>>
>> On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
>> > Does this mean different windows belonging to the same application will
>> > not be able to have different per–window menubars? I’m thinking about
>> > Empathy here, with its Buddy List and Conversation windows having
>> > different menubars, but it’s not an uncommon scenario.
>>
>> I guess a reasonable question to ask here is what empathy would look
>> like if it were an application designed for mac os.
>
> Who cares about some stupid mac os?
> I'm sick of people trying to criple gnome to look like mac os :-(

Just as many of us are very sick of crippling GTK+ just to conform
to the GNOME desktop.

In this way it's a two-way street and we need to walk a thin line
and make sure that features like this can stand-alone without
GNOME or OSX or whatever system people want to build software
for.

Cheers,
 -Tristan

>
> --
> Petr Tomasek 
> Jabber: but...@jabbim.cz
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
> On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote:
> 
> > hi,
> > 
> > On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> >> Does this mean different windows belonging to the same application will
> >> not be able to have different per–window menubars? I’m thinking about
> >> Empathy here, with its Buddy List and Conversation windows having
> >> different menubars, but it’s not an uncommon scenario.
> > 
> > I guess a reasonable question to ask here is what empathy would look
> > like if it were an application designed for mac os.
> 
> I think that you misunderstand how mac os works. 
> 
> Yes, a single menu bar is displayed at the top of the screen. This is correct 
> behavior according to Fit's Law, because you can bang the pointer to the top 
> of the screen and it can't overshoot.
> 
> No, applications are not limited to having a single menu bar. It's a 
> one-liner to switch menubars when different window (or notebook tab, for that 
> matter) gets focus.


I think that the (twice) mentioned solution to this problem sounds
elegant enough, i.e. if you have 2 windows with different menubars
then they can easily be '2 applications' at least in terms of data
sets.

However, I'm curious as to how elegantly one can implement this.

Can someone dish out an example (hopefully less than 10 lines of code)
that shows us how to make our applications become 
'multiple applications' ?

Of course, the prerequisites are:
  - All applications that my application creates should run in the
same process.
  - If D-Bus is present on the system, the application set should
still be one, single instance process.
  - There should only be one interface for loading files/uris,
not one interface 'per application' which my application 'is'.

Also, I'm still concerned about GApplication, I raised this point
last year and I wonder if any progress has been made... what is 
the fallback ?

Can g_application_run() please at the very minimum fall back on
calling g_main_loop_run() when there is no D-Bus daemon ?

If I write an application with this abstract GMenu model and then
run it on a system that by no means has any need to run a D-Bus
daemon, nor any need to run a window manager, or has a window
manager that is not GMenu aware at all, what happens ?

Can the menu bar automatically display using a basic GtkMenuBar
in the main GtkApplicationWindow... when there is no D-Bus
daemon running ?


Also... concerning MVC menus in general:

Can this whole GMenuModel and GMenu thing be extendable 
without modifying GTK+ sources at all ?

In my imagination, all I have to do is:
  - Implement menus to understand an extra property name
i.e. implement the view, by deriving a GtkMenuItem with
widgets to represent that data
  - Create the data model from my application and assign
this extra property name a value, perhaps
  "is-range" = TRUE and "range-value" = 50
  - Bingo, all of a sudden I'm using my new GtkScaleMenuItem
with an embedded GtkHScale and it's value preset to 50

Thanks,
  -Tristan


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

Re: GObjectClass.dispose and bringing objects back to life

[Tristan Van Berkom]

On Mon, Dec 5, 2011 at 3:20 AM, Benjamin Otte  wrote:
> I would be somewhat tempted to listen to all the stuff you're saying
> below. But then I looked at the code you maintain[1], and I realized
> it doesn't do anything of that. So I'm inclined to think that what
> you're talking about is more about an ideal world that you wish we all
> aspired to, but is not in any way related to how people write code in
> the real world.

Ok let's do rant then

>
> Benjamin
>
> 1: http://git.gnome.org/browse/gnumeric/tree/gnumeric.doap
>
>
> On Sun, Dec 4, 2011 at 3:15 PM, Morten Welinder  wrote:
>>> What we probably also should do is deprecate one of the two
>>> virtual functions, so people use the same one to clean up everywhere.
>>
>> That would be a _really_ bad idea.
>>
>> _finalize gets rid of the last fragments of the object.  Since random
>> code could have obtained refs to the object, the object designer
>> can generally not control when this happens.
>>
>> _dispose has two functions: (1) break reference cycles by getting
>> rid of as many objects as it can, and (2) getting rid of externally-
>> visible parts of the object and subobjects it owns.
>>
>> (2) tells you why you can't merge the two methods.  Widgets,
>> for example, really need to go away from the screen when you
>> tell them, not whenever something else decides to release a ref.
>> Objects that have open files really need to close them at dispose
>> time, not next Wednesday.
>>
>> Gtk1 didn't have dispose in name, but it had the destroy method
>> instead.  Same thing.
>>
>>> [...] we [...] know that trying to support objects functioning
>>> after dispose is like trying to make your code handle
>>> NULL returns
>>
>> I don't think we know that, not do I think it's true.
>>
>> Making _dispose work really comes down to following one
>> simple rule: after _dispose, the object should be as well defined
>> as it was after _init.  I.e., anything you free you set to NULL
>> and you don't free anything that was allocated in _init[*].

He has a point here, except most code doesn't follow this rule
because *so much* code (GTK+ code, even) goes ahead and
over-allocates resources in the _init() step.

Much of that code should actually be happening in the
GObjectClass.constructor() instead of _init()... code for instance
which does: gtk_container_add(self, new_widget)

Of course all of that code which (naively) assumes that
GtkContainerClass has finished initializing will break the moment that
GtkContainerClass decides to (withing it's own rights) not function until
finished initializing in the ->constructor().

Of course GtkContainer wont do that (as specially since so much
"broken" code depends on it not changing), but many widgets
have use of construct-time assigned properties at initialization time.

Hence the rule: Don't access parent class's apis at all until ->constructor()
runs and you know that the parent class is actually ready.

Even if we assume that everybody hates construct-only properties (who's
usage cause the above rule to be even more essential), and go to the
pain of handling every api prematurely (from child class's _init() function),
then we run a high risk of doing things twice at initialization time
and significantly
slowing down widget hierarchy creation cycles.

I.e.:
 o  Parent Class has api called from child class's _init() function
 o  Parent Class initializes resources prematurely, due to premature api access
 o  Later during object construction, a property is set
 o  That property setting causes the same resource to be
re-initialized in a different 'mode'

In summary, if most code was written with a 2 step, "safe"
initialization, it would
resemble much more what Morten is describing, only initial property states and
various caches (delegate arrays/queues/hash tables) would be setup at
_init() time,
which is all you really want to get rid of at ->finalize time.

Cheers,
 -Tristan

>>
>> M.
>>
>>
>> [*] Unless you allocate a new dummy object to put in its place.
>> That wouldn't make much sense unless you have big trouble
>> with circular references.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObjectClass.dispose and bringing objects back to life

[Tristan Van Berkom]

2011/12/5 David Nečas :
> On Sun, Dec 04, 2011 at 01:40:58PM +, Emmanuele Bassi wrote:
>>
>> this is, of course, not true: GNOME is full of badly written GObject
>> code, mostly because it has been written at various stages of the
>> learning process of various people. plus, the documentation is not
>> entirely clear in a lot of places, thus the learning process can (and
>> effectively is) broken.
>> ...
>>
>> objects should obviously not be in a fully functional state after
>> dispose - but they should be in a stable state, so that other objects
>> referencing them from outside of the boundaries of their code space
>> can still hold a valid reference to them, until such time that every
>> reference can be released.
>
> So, who thinks this idea is not actually inherently inconsistent please
> please specify in the documentation, based on your rationale, how are
> objects supposed to behave in the disposed state.  Namely with respect
> to (not) keeping impossible invariants, returning nontrivial
> no-longer-available values, methods that normally create or acquire
> something before returning it and other practical issues.  Or say that
> there can be certain things the object owners may not do with disposed
> objects.  Or anything.  This
>
>     The object is also expected to be able to answer client method
>     invocations (with possibly an error code but no memory violation)
>     until finalize is executed.
>
> has as, a practical guide, approximately the same value as ‘people
> should live together in peace’.

It's a gray area that has not needed real clarification with real-world
code thus far, and I doubt it really absolutely needs clarification.

'Let us live in peace' is actually pretty much the gist of it afaics.

Why is this a non-issue ?

Because during the dispose cycle of objects, sane people don't
call apis which would ever fail at dispose time.

People might however call functions/macros like:
 - g_object_get_qdata(), i.e. I have some explicitly attached data I
want to inspect once while disposing,
 and for whatever reason I
chose not to call g_object_set_data_full()
 - g_type_name_from_instance() (i.e., sometimes I like to print the type
  names and
reference counts of object
  hierarchies
being destroyed, just to debug my own code)

Probably much existing code will fire run-time assertions when asked
to actually
perform a task at dispose time after an important resource is already discarded.

I think the policy right now, and has always been, "don't crash because your api
has been accessed at dispose time".

Do we need a more explicit policy ? Do we need to define what code should do
when asked to do something useful after dispose time ?

Considering that any sane code does not ever ask an object to do anything
useful after dispose time, no... it would just be an exercise of
planning for what
to do in code that is anyway, not meant to be reached.

That said, policy about locking and sharing of objects in MT environments
(related more to GIO than pure GObject) _might_ need clarification.

Implementing MT-safe singleton objects (as was I think the case in the referred
bug report) is probably just damn complex to do, definitely needs to be done
with some manual locking around the access to the singleton static pointer
and probably just a really bad idea to use in conjunction with GObject weak
references.

That is anyway, IMO, a separate discussion than the one we are having
about policy at dispose time.

Cheers,
  -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObjectClass.dispose and bringing objects back to life

[Tristan Van Berkom]

On Fri, Dec 2, 2011 at 4:26 AM, Simon McVittie
 wrote:
> Hi,
> I've been looking into the details of how GObjects are destroyed,
> hoping to solve , in
> which disposing a global singleton GDBusConnection in one thread races with
> reffing and using it in another thread, causing resurrection and a crash if
> both happen. (Advice from GObject gurus on that bug would be very much
> appreciated.)
>
> While doing so I noticed these bits of documentation:
>
> http://developer.gnome.org/gobject/stable/howto-gobject-destruction.html
>> It is possible that object methods might be invoked after dispose is
>> run and before finalize runs. GObject does not consider this to be a
>> program error: you must gracefully detect this and neither crash nor
>> warn the user.
>
> http://developer.gnome.org/gobject/stable/gobject-memory.html#gobject-destruction-table
>> The object is also expected to be able to answer client method invocations
>> (with possibly an error code but no memory violation) until finalize
>> is executed.
>
> http://developer.gnome.org/gobject/stable/gobject-memory.html#gobject-memory-cycles
>> Object methods should be able to run without program error (that is,
>> without segfault :) in-between the two phases.
>
> I'm pretty sure typical real-world code doesn't follow these (mine certainly
> doesn't); in general it isn't possible to do anything useful in an object
> after its state and the objects it uses have been discarded, however much
> someone might want to ref it halfway through dispose.

Yes, real-world well-written GObjects *must* not crash after being disposed,
code that crashes because apis are called after dispose time are bugs,
and you should fix them as specially if you have possible circular object
references.

For instance, in many cases an object might fire a signal during it's
dispose cycle, that dispose cycle might run a few times and listeners
to a signal fired from dispose might query the disposing object's state.

This should absolutely not cause a crash, if it does, you need to make
sure that:

  o Most resources are normally freed in GObjectClass.finalize()

  o References to other GObjects are broken in dispose, and since
 dispose can run multiple times, care must be taken, i.e.:

 if (priv->reffed_object != NULL) {
 g_object_unref (priv->reffed_object);
 priv->reffed_object = NULL;
 }

> When this documentation says "object method" or "client method", does that
> refer to semi-internal GObject virtual functions like get_property() and
> dispose(), or to methods defined by the object like g_io_stream_close(),
> or both?
>
> I did a quick survey of GLib (in recent master) to get an idea of how widely
> the rules I quoted are followed. Here are the cases I spotted where they
> aren't:
>
> * GDBusConnection
>  * drops its reference to the GDBusWorker
>    * start_message_processing will assert
>    * flush_sync will assert
>    * close will assert
>    * send_message_unlocked will segfault
>    * dispatching incoming messages ceases to happen

GIO is still pretty young and generally, the age-old rule 'if it's not
broken, don't fix it' applies.

In other words, I don't think people are hitting these assertions, because
(as I mention below...), revived objects are not really revived in the
full sense
of the word, they are just temporarily available so that everyone who has
a reference to them can "finish up"...

If you really have 2 threads which refer to the same object, then naturally
they will both hold a reference to it and the object wont die until the last
thread is finished using it.

If for some odd reason you need a second thread to be "notified of the
forced destruction" of a said object, then it's probably best to use
a GtkWidget::destroy paradigm on that object... i.e. both objects
do hold a reference and either one releases their reference at "destroy"
signal emission time.

The bug Ryan is referring to in his reply seems to imply that people
should be allowed to use 'weak references' for this... I dont see how
that could be very safe... personally I would probably prefer using a
"destroy" signal run from the dispose handler for such notifications.

> * GFileEnumerator
>  * drops its ref to contained
>    * get_container will return NULL (which it can't normally), potentially
>      crashing its users
> * GFilterOutputStream
>  * drops its reference to the base_stream
>    * get_base_stream will return NULL, which it can't normally
>    * write, flush, close will critical (or segfault if checks are disabled)
> * GInetSocketAddress
>  * dispose() isn't idempotent (I'll open a bug)
>  * drops its ref to address
>    * get_address will return NULL, which it can't normally
>    * get_family, get_native_size, to_native will critical or segfault
>
> GDBusProxy appears to keep working correctly if resurrected from dispose(),
> which surprised me, but that's only because it doesn't unref its connectio

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Tristan Van Berkom]

On Tue, Nov 22, 2011 at 4:48 AM, Emmanuele Bassi  wrote:
> hi;
>
> On 22 November 2011 09:44, Tristan Van Berkom  wrote:
>> Similarly the GMainLoop, by virtue of being a loop,
>> should also push a pool onto the autorelease pool stack
>> and pop it while dispatching GSources (and this is where
>> you get the extra 'unref on mainloop hit' detail).
>
> it's not strictly necessary to have a default behaviour, though.
>
> we could have two distinct functions:
>
>  /* schedules a idle source to release the resources when we re-enter
> the main loop */
>  void
>  g_autorelease_pool_pop_in_idle (GAutoreleasePool*);
>
>  /* releases the resources immediately */
>  void
>  g_autorelease_pool_pop (GAutoreleasePool*);
>
> following the pattern in GIO. for MT applications we could even
> provide a function to release resources within a specific GMainContext
> as well, to release the resources in a specific thread instead of the
> default main context.
>
> the obvious issue is: how does this interact with languages that do
> have a GC, and how does the API work to avoid making the life of
> developers for high-level languages apps and/or bindings a nightmare.
> if libraries start using this object for their internal allocations,
> for instance, or start relying on it when using their API.

Interesting idea for GIO like threaded operations to be sure, I doubt
that language bindings would be the obstacle, language bindings
generally cope with gobject apis to manage gobject ref counts and
are probably already special casing floating references (or by now
they are unconditionally ref_sink'ing *everything* and doing their
own garbage collection)...

I only wonder how to implement an API for that which makes
sense, is very simple to use and allows the author of threaded
async operations to virtually ignore ref-counting (which I think is
the point of the autorelease exercise).

I also predict some confusion when executing an asynchronous
function's top half in the calling thread... i.e. who determines that
that particular function has a separate autorelease pool target
than the default one on top of the stack for that thread ?

Also while running the top half of:

foo_bar_do_something_async ()
{
   foo = foo_new ();   // assume that foo_new() and bar_new() return
   bar = bar_new ();   // a soft reference which will be unreffed by
the autorelease pool

   /* ... do stuff with foo and bar */

   /* Save 'bar' so that it's attached to the async response */

   /* Get rid of expensively huge 'foo' right _now_, dont save it
* around for later use in the result callback
*/
   g_object_unref (foo);
}

In this case one would presume that 'foo' and 'bar' (if created with a
soft reference)
would be added to the same autorelease pool, even if we could somehow step in
and give that function a new autorelease pool without that function
doing anything
declarative... that function will still want to decide which objects
must be saved
for the async reply.

As soon as the function starts to do something declarative to decide
which memory
lasts until the async callback, of course the whole plan becomes
useless (i.e. we already
have g_object_ref() for that).

Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Tristan Van Berkom]

On Tue, 2011-11-22 at 09:03 +0100, Mikkel Kamstrup Erlandsen wrote:
> On 11/21/2011 04:54 PM, Hub Figuière wrote:
> > On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote:
> >> This is precisely my motivation for introducing this; ie. not to catch
> >> leaks, but to tidy the code. Bigger code bases almost always grow
> >> functions with multiple returns - notably when error handling is
> >> introduced. Automatic freeing can cut down on that complexity
> >> considerably. On less complex functions it can still add clarity by
> >> making the actual algorithms more apparent in between all the g_free()s
> >> and g_object_unref()s.
> >
> > Which is basically what my counter-proposal of g_object_autorelease() is
> > about.
> >
> > That's exactly the use case in Objective-C with Cocoa that, unlike C++,
> > does not have scope based life cycle of object, but supports exceptions.
> >
> > Also to make it more useful with Glib, we would need to have actually
> > containers implemented as GObjects.
> >
> 
> I am guessing that you expect this autorelease pool to trigger a garbage 
> collection in an idle call on the mainloop or something?
> 
> Assuming "yes"; I can see that this has its use cases, but also some 
> pretty huge drawbacks. Like 1) needing a mainloop, and 2) being 
> susceptible to memory ballooning with something like a for-loop doing 
> lots of string manipulations. And 2) is a very common use case for 
> automatic cleanup since looping often has a few early-breaks with the 
> required extra cleanup logic.

Auto-release pools come with a hard requirement of the user
understanding them, that being said after having used them
I can say that it's a practical and comfortable idea as specially
when compared to our floating ref solution (i.e. the floating object
is owned by noone... but somehow needs to be ref_sinked and unreffed
anyway)

So... for instance, when implementing an iterative api such
as gtk_container_foreach(), a pool should be pushed onto the
stack:

g_autorelease_pool_push ();

for (i in children)
   user_callback (child, data);

g_autorelease_pool_pop ();

Pushing a pool puts one on top of the stack, popping a
pool will release all of the references which it has
accumulated during it's life-cycle. Authors of programs
in Cocoa need to understand this and manually push/pop
autorelease pools when such memory balooning might be
a problem (again, a much simpler concept to cope with
than floating refs IMO).

Similarly the GMainLoop, by virtue of being a loop, 
should also push a pool onto the autorelease pool stack
and pop it while dispatching GSources (and this is where
you get the extra 'unref on mainloop hit' detail).

Cheers,
 -Tristan

> 
> That said, I am not against the concept either. It does have the 
> advantage on ref counted types that any function on the call stack can 
> grab a ref before the next idle. So it can work over returns and such.

Right, you can have functions that return a soft reference like so:

   return g_object_autorelease (object);

But the value can and should only be trusted in the scope of the
function calling a function which returns a soft reference (because
you never know when your original caller will pop the current pool
off of the stack, it becomes conceptually invalid after you run out
of the current scope).

Cheers,
 -Tristan

> 
> Cheers,
> Mikkel
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Tristan Van Berkom]

On Mon, 2011-11-21 at 00:00 -0800, Hub Figuière wrote:
> On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote:
> > So; what say you? If there is interest I'll gladly polish it up for
> > inclusion. There are also tonnes of other low hanging fruits like
> > freeing other ref counted types, closing of streams, etc.
> 
> How about a g_autorelease_pool() or something like that? (see
> NSAutoreleasPool in GNUStep / Cocoa)

Just throwing this out there randomly...

I would buy autorelease pools over GtkObject's 'floating ref'
concept any day of the week and twice on sunday.

Unfortunately GtkObject's floating reference concept has bled
so deep into GObject by now and I think we're stuck with it

(although the idea of reimplementing GInitiallyUnowned to
just create an autoreleased object from the constructor is...
really intriguing...)


> 
> For those who don't know, basically you would do a
> g_object_autorelease() on a (refcounted) object you want to unref in the
> short term but keep long enough to be ref elsewhere.
> The actual unref is performed when the outer main loop runs or when the
> autorelease pool is destroy.
> 
> (that's the pattern in GNUStep / Cocoa)
> 
> And it might even actually work with floating references and it does not
> need a specific C compiler extension or C++.
> 
> 
> Hub
> 
> PS: and if that whole thing has already been debated and rejected, just
> say so. I might have been under a rock at that time or something.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: GTK3 size negotiation

[Tristan Van Berkom]

On Wed, 2011-09-28 at 15:25 +0100, Tony Houghton wrote:
> On Tue, 27 Sep 2011 12:06:06 -0400
> Tristan Van Berkom  wrote:
> 
> > On Tue, Sep 27, 2011 at 10:04 AM, Tony Houghton  wrote:
> > > I found a bug in the GTK3 version of my X terminal application, roxterm
> > > <http://roxterm.sourceforge.net>: If you maximize a window with a single
> > > tab then unmaximize it, its width increases to more than it was before
> > > the window was maximized.
> > 
> > Hi,
> >Just a friendly reminder, in general this kind of query should probably 
> > go
> > to gtk-app-devel-list (a list about developing with GTK+), we like to keep
> > this list limited to discussion on the development of GTK+ itself.
> 
> OK. But I thought it was on topic because there does seem to be a
> problem with GTK, but I don't know exactly what the bug is and what
> component(s) it's in so I wanted to discuss it before filing a bugrep.
> 
> BTW, I posted about g-ir-scanner on the list because I was pointed to it
> by <https://live.gnome.org/GObjectIntrospection>. I thought it was a bit
> strange though. Would gtk-app-devel-list be more appropriate for that
> too? I'm surprised not to find lists especially for
> glib/gobject/introspection.

GObject/GLib/[GIO Also ?] are all discussed on the GTK+ lists
(historically they are all the same project, GObject was
originally GtkObject and glib/gobject then grew out GIO etc).

For gobject-introspection you might have a harder time
finding people who are "in the know", trying gtk-app-devel-list
is a very good start, also opening up an irc client and asking
a question in #gobject-introspection... and then leaving your
irc client run for a good few hours on a weekday afternoon,
is also a very good bet.

> 
> > Comments below...
> > 
> > > Unlike gnome-terminal, roxterm (optionally) always shows the tab bar.
> > > When there are multiple tabs the children are set to expand and fill and
> > > the tab bar spans the entire window. In this mode the window unmaximizes
> > > to its correct size. With a single tab expand is FALSE and I've written
> > > a custom label widget to try to make the tab approximately half the
> > > width of the window, which looks good.
> > >
> > > I realised why the size was changing: when the window is maximized, the
> > > tab is wider than the window's unmaximized width. When unmaximizing GTK
> > > prevents the window from becoing too small for that tab even though its
> > > size is renegotiated so it's approximately half the window's new width.
> > >
> > > During size negotiation the label has to request its mimimum_width to be
> > > the target width. If I try to use natural_width instead it ignores it
> > > and uses the minimum_width set by the base class, which is just enough
> > > to show the three dots when it's fully ellipsized, so that's no good. [1]
> > 
> > That's a problem with the parent container, if it's modern and uses
> > gtk_distribute_natural_allocation() for size allocations then you wont
> > have this problem. (if your "tab bar" is a GtkBox or GtkGrid derived widget
> > then it should allocate correctly, if it's a custom widget, it should be
> > ported to use modern allocation logic).
> > 
> > If we are taking about the tabs built-in to a GtkNotebook, then perhaps
> > it's worthwhile to write a very short test case showing the bad behavour
> > (I'm thinking a test case with just a window with a notebook and a "broken"
> > ellipsized tab would be perfect) and file a bug against the notebook widget
> > with that here:
> > http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B
> 
> It is a GtkNotebook. I haven't checked yet whether it's specific to that
> or containers in general.

Then I would try the new GTK+ to check if your bug is fixed.

I suspect it is, the release notes a few days ago highlight new h4w 
support in GtkNotebook:
http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00175.html

Cheers,
 -Tristan

> > > I connected signal handlers for size-allocate and configure-event on the
> > > toplevel window, but the first time they get called during unmaximizing
> > > their data already contains the incorrect width based on the label's
> > > maxtimized size, so it seems it's already decided on its new size before
> > > any attempt to renegotiate the tab size can be performed. [2]
> > 
> > That's normal, size requests are cached, widgets are only re-requested
> > if their content 

Re: GTK3 size negotiation

[Tristan Van Berkom]

On Tue, Sep 27, 2011 at 10:04 AM, Tony Houghton  wrote:
> I found a bug in the GTK3 version of my X terminal application, roxterm
> : If you maximize a window with a single
> tab then unmaximize it, its width increases to more than it was before
> the window was maximized.

Hi,
   Just a friendly reminder, in general this kind of query should probably go
to gtk-app-devel-list (a list about developing with GTK+), we like to keep
this list limited to discussion on the development of GTK+ itself.

Comments below...

> Unlike gnome-terminal, roxterm (optionally) always shows the tab bar.
> When there are multiple tabs the children are set to expand and fill and
> the tab bar spans the entire window. In this mode the window unmaximizes
> to its correct size. With a single tab expand is FALSE and I've written
> a custom label widget to try to make the tab approximately half the
> width of the window, which looks good.
>
> I realised why the size was changing: when the window is maximized, the
> tab is wider than the window's unmaximized width. When unmaximizing GTK
> prevents the window from becoing too small for that tab even though its
> size is renegotiated so it's approximately half the window's new width.
>
> During size negotiation the label has to request its mimimum_width to be
> the target width. If I try to use natural_width instead it ignores it
> and uses the minimum_width set by the base class, which is just enough
> to show the three dots when it's fully ellipsized, so that's no good. [1]

That's a problem with the parent container, if it's modern and uses
gtk_distribute_natural_allocation() for size allocations then you wont
have this problem. (if your "tab bar" is a GtkBox or GtkGrid derived widget
then it should allocate correctly, if it's a custom widget, it should be
ported to use modern allocation logic).

If we are taking about the tabs built-in to a GtkNotebook, then perhaps
it's worthwhile to write a very short test case showing the bad behavour
(I'm thinking a test case with just a window with a notebook and a "broken"
ellipsized tab would be perfect) and file a bug against the notebook widget
with that here:
http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

> I connected signal handlers for size-allocate and configure-event on the
> toplevel window, but the first time they get called during unmaximizing
> their data already contains the incorrect width based on the label's
> maxtimized size, so it seems it's already decided on its new size before
> any attempt to renegotiate the tab size can be performed. [2]

That's normal, size requests are cached, widgets are only re-requested
if their content changes (or say, the height might be re-requested in
response to a window resize if the widget is height-for-width).

Cheers,
  -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Geometry Management

[Tristan Van Berkom]

On Sun, 2011-09-25 at 18:23 -0400, Paul Davis wrote:
> On Sun, Sep 25, 2011 at 6:20 PM, Matthew Bucknall
>  wrote:
> 
> > What I'm not clear on is the meaning of the 'natural' arguments in
> > calls to gtk_widget_get_preferred_height () and
> > gtk_widget_get_preferred_width ().
> >
> > Are the natural sizes just some sort hint to containers which may
> > result in more aesthetically pleasing layouts than just going by the
> > minimum sizes alone?

It's a bit confusing what is the right answer for "natural_width"
when implementing a widget, the accurate explanation about natural
size is:
  the size at which a widget will cease to compete with it's siblings
  for space in a said container.

But you could just say they are 'hints', they basically mean "at what
size am I satisfied that I have enough width", it does not mean that
no greater width given can be used (a wrapping label can have a
natural width that is not the entire text length).

Long winded story I guess I felt like writing...

When allocating children of a container we always have enough space
to satisfy the minimum size, after that (assuming the container is
height-for-width aware) space is distributed to smaller widgets first
until every sibling reaches it's natural size and then finally
extra space is given to widgets who requested to 'expand'.

Allocating children taking into consideration minimum and natural
width allows for better management of space, simply put; more 
(possibly dynamic) content can appear on screen at once.

Imagine a setup where you have a details box of sorts on the
left and a content area on the right. Lets say that the content
area is set to expand horizontally and the details box's width
is limited by a translatable "title" label at the top which is
set to ellipsize.

In this case, the title label's full width will (by default)
define the natural width of the label and consequently when
resizing the application; the parent box will always try to fit
the detail area with the entire title label (if possible) and 
leave the remainder to the content window.

Cheers,
-Tristan


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

Re: no Gtk hackfest for now

[Tristan Van Berkom]

On Wed, Sep 7, 2011 at 8:03 PM, Ryan Lortie  wrote:
> hi all,
>
> I just sent an email to foundation-announce about Boston Summit being in
> Montréal.  We're not going to attach a Gtk hackfest to that since the
> notice is short and we already know that some important participants can
> not attend.
>
> The plan for now seems to be to have one early next year.
>

Sorry to hear that, a GTK+ hackfest in Montreal at this time would have
been the first time in history I would have easily been able to attend
(I would definitely devote some days of my time for that... if it did happen)

Perhaps the next "Boston" summit in Montreal then ;-)

Best Regards,
   -Tristan

(oops, sent to the list this time...)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Tristan Van Berkom]

On Wed, 2011-09-07 at 11:27 +0200, Milan Bouchet-Valat wrote:
> Le mercredi 07 septembre 2011 à 01:53 +0200, Jannis Pohlmann a écrit :
> >   * the sidebar has no mount/eject progress indicators,
> There's a rough patch for it, maybe it will be committed soon:
> https://bugzilla.gnome.org/show_bug.cgi?id=619665
> 
> >   * the eject buttons do not look/feel clickable, i.e., they don't
> > change their appearance on hover events, 
> This was apparently committed before 3.0, but I don't see it. Bug is:
> https://bugzilla.gnome.org/show_bug.cgi?id=544103
> 
> > Of course, some of these missing features are due to cell renderer
> > limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
> > events for individual cells to work good enough to implement a
> > fully-working button renderer. But still, the places sidebar has more
> > potential and the current implement feels somewhat half-baked.
> Yeah, GtkTreeView would need some changes to implement this properly,
> but a hacky solution works currently (see patches). I had filed this:
> https://bugzilla.gnome.org/show_bug.cgi?id=586458
> 

I just added some comments to that bug, I *think* the solution will
be much less 'hacky' after introducing GtkCellArea (the patches on
that bug seem to sadly predate GtkCellArea by only a couple of months).

Cheers,
 -Tristan


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

Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns

[Tristan Van Berkom]

Exciting topic.

Just a few comments scattered through the email...

On Tue, 2011-09-06 at 14:26 +, Benjamin Otte wrote:
> Emmanuele Bassi  gmail.com> writes:
> > 
> >   a) drop GTK+, move to Clutter and port the complex widges over;
> >   b) re-implement Clutter inside GTK+;
> >   c) use Clutter between GDK and GTK+;
> >
> I would translate that as:
> a) tell GTK developers their code is crap
> b) tell Clutter developers their code is crap
> c) make Clutter and GTK developers work together on the best of both worlds
> 
> I have a good idea what solution causes the least tension here... ;)
> 
> > the Clutter UI description format is JSON and not XML because I honestly
> > don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong
> > position in the stack (GTK instead of GLib) and exposing the wrong API
> > (GMarkup to create custom parsers); on the other hand, ClutterScript
> > made JSON-GLib possible. 
> > 
> I still maintain that the person that writes and maintains the parser and the 
> UI
> for editing gets to decide what format we use. I can handcraft JSON and XML
> files that test GTK. I can even handcraft binary files to break things if I 
> need
> to. And nobody else does care, because they'll all be using the editor anyway.
> (right? :))
> Last but not least, I can also live with JSON existing in Clutter and XML
> existing in GTK. One of them will not work on the GTK level, so 

For the record, having a common serialization framework would make
things much, much easier for the guys trying to generate this stuff.

If, for instance GtkBuilder was indeed GBuilder, and would have been
the obvious choice for ClutterScript... 

The result would have been:
   - Someone creates clutter-gtk widgets (already done)
   - Someone easily integrates the clutter widget into Glade catalog
 (some have done privately, quite easy to do as it stands)
   - The 'GtkClutter' widget could simply extend the definition
 of it's xml with the GBuildable interface, simply by creating
 ClutterActors from the embedded GBuilder xml.

All ClutterActors, simply by nature of being GObjects, would be
automatically supported by Glade, the only remaining work to be
done to create clutter projects in Glade would be the UI.

However unfortunately, things did not go down this road, and so
we are that much further from editing ClutterScript, at least
from Glade (and combined with GTK+ from Glade).


> 
> > Clutter also has some cool concepts like Constraints, which are similar
> > to SizeGroups/Alignments; Actions, which are objects that set up actors
> > to provide high level concepts like click/long-click, gesture
> > recognition, drag and drop; and Effects, which are post-processing
> > filters that use GPU shaders or rendering to offscreen framebuffers.
> > 
> So, let's say we think these concepts are awesome and we want them in GTK. In
> particular, actions are something I'd want in GTK preferably right now so that
> when we do the switch in event bubbling, there's not that many event handlers
> left to fix. How do we do that? We don't want to introduce GTK API that is in
> effect identical to the Clutter API. And we don't want to depend on Clutter. 
> Is
> there a solution that can work for this?
> 
> > obviously, we cannot shove Clutter as it is inside GTK and call it a
> > day: both Clutter and GTK would require extensive API changes.
> > 
> > there are a couple of different ways of incorporating Clutter inside
> > GTK. one is going the CoreAnimation route, and have GtkWidget exposing a
> > ClutterActor as part of its class; essentially, any GtkWidget would be
> > able to embed a ClutterActor - and be embedded inside a ClutterActor.
> > 
> There is one thing I'd like to do, and that is providing state for the drawing
> operations we do in GTK. An entry would no longer need to do complex
> computations whenever it draws[1] (frame, text, progressbar and icons) and
> doesn't need to do complex border, margin and padding computations for each of
> them, but it would just have Frame, Text, Progressbar and Icon render objects,
> that took care of this job. They'd of course need to hook into the CSS theming
> infrastructure to get their rendering informations. And it seems to me it's a
> good idea to use ClutterActors for that.
> 
> If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I
> don't think that matters a lot. In particular because changing from one to the
> other just requires changing 3 lines of code. ;)
> 
> >   - drop containers and make the scene graph explicitly part of the
> > ClutterActor API;
> >
> The question of how to present containers in the public API is an interesting
> one. I poked you about this on IRC, so I won't go into the arguments here and
> don't want you to answer, but I'll point it out anyway so people reading this
> can think about it:
> There is 3 consumers of a "container" interface to an Actor/Widget:
> 1) someone implementing a subclass of the A

Re: GtkBuilder syntax for property bindings

[Tristan Van Berkom]

On Fri, 2011-05-06 at 18:48 -0400, Matthew Barnes wrote:
> On Fri, 2011-05-06 at 12:42 -0700, Christian Hergert wrote: 
> > Since GBinding, is itself, an object, why not just have the GBinding
> > instance represented in the GtkBuilder XML. The normal object syntax
> > might work as well:
> > 
> >   
> > object1
> > object2
> >   
> > 
> > I think this would mean the majority of work is how to make it easy to
> > manage from within Glade.

Exactly, this is why we discussed augmenting the GtkBuilder format to
add some way setup bindings as an attribute of the property itself.

My preference still at the moment is to separate  from
, i.e.


  

  
  

  
  ...


The main incentive to specifically *not* go with:

 
  object1
  object2


... is because while setting up bindings from the
GtkBuilder is easy to do, managing the association
of bindings to properties and ensuring the user
makes meaningful choices, is not easy to do.

The work is significantly reduced by the fact
that Glade does not have to run around and parse
the GBindings separately and associate them to
their relevant properties (and then do the same
at save time).

The reason why Glade should not simply let the
user manage a list of GBindings separately from
the rest of the objects in Glade (as that would
be the obvious thing to do), is that it makes it
near impossible for Glade to guide the user in
any reliable way.

What I mean by "guide the user" here is, for instance
some properties are not relevant in some configurations
of widgets, take a GtkButton for instance that is
registered to get it's text from it's related
GtkAction, in this case Glade should not let you
assign the value source of the button text to
both a GBinding *and* an action.

In general, it's better for Glade to manage bindings
as metadata of properties, for this reason it makes
more sense to add some builder sugar than to go
working around the problem in Glade.

Cheers,
 -Tristan

> 
> +1, and don't forget GBindingFlags.
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list



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

Re: Please fill out the GtkLabel questionnaire

[Tristan Van Berkom]

On Sun, 2011-04-10 at 00:42 +0900, Tristan Van Berkom wrote:
> On Sun, 2011-04-10 at 02:58 +0200, Benjamin Otte wrote:
> > On Sat, Apr 9, 2011 at 2:14 PM, Tristan Van Berkom
> >  wrote:
> > > What I should have done, as Owen pointed out back in december was to
> > > leave the label requests very straight-forward and require the program
> > > author to set an explicit minimum size of the toplevel GtkWindow,
> > > essentially the difference would only be that instead of having to
> > > potentially configure a lot of label sizes inside the interface, you
> > > just configure the desired size of the toplevel and you get a reasonable
> > > allocation (Havoc also suggested we do some one-shot binary search to
> > > find a good aspect ratio for the initial size of the toplevel window).
> > >
> > So what you are saying is to essentially get rid of the
> > guess_wrap_width argument to gtk_label_ensure_layout(), right?
> 
> Unfortunately we did not make the change before releasing 3.0 so now I
> guess we're stuck with the wrap width guessing (any interfaces
> with wrapping text would suddenly be effected and have a tall and 
> thin size)... possibly we could fix it by adding api to gtklabel
> (however the apis that would be needed to opt-out of the wrap-width
> guesswork don't sound very attractive).
> 
> > 
> > > A caveat here is that currently there is no straight-forward way for
> > > obtaining things like "the size of the largest word in the text" or
> > > "the size of the widest character".
> > >
> > According to Behdad:
> > pango_layout_set_wrap_mode (layout, mode);
> > pango_layout_set_width (layout, 0);
> > pango_layout_get_extents (layout, &extents);
> > will give you exactly that. It will cause as much wrapping as possible
> > and then of course the width of the resulting text will be the size of
> > the widest word/character.
> 
> That's very fortunate :) we can use that to avoid
> clipping when using width-chars properties (we have
> the same problem with cell renderers too).
> 
> > 
> > > Labels currently don't wrap and ellipsize both, it would be nice if
> > > they did however (and it's certainly possible, I would imagine the
> > > whole text would wrap as much as possible and the text that doesnt
> > > fit would be ellipsized only on the last line).
> > >
> > Oh? Is this a limitation in Pango or is that just missing inside GtkLabel?
> 
> Looks like we could use pango_layout_set_height ().
> 
> > > As far as "max-width-chars" and "width-chars" effects go, I dont have
> > > any strong opinion so far as it's useful, the subtleties are:
> > >
> > >  - Do we blatently always request "width-chars" as minimum if set ?
> > >  - Do we request MIN (text_width, width-chars) ?
> > >(I think this is more useful and I think it's how it currently
> > > works)
> > >
> > > Same for max:
> > >  - Do we blindly request "max-width-chars" as the natural width ?
> > >  - Do we request MIN (text_width, max-width-chars) as natural ?
> > >(Again I think it's currently the latter and I personally think
> > >that is more useful).
> > >
> > Paolo and I discussed that, and what we discussed was setting the
> > minimum/natural size in characters.
> > There seem to be 4 values that you could want to set:
> > - minimum value to request for minimum width
> > - maximum value to request for minimum width
> > - minimum value to request for natural width
> > - maximum value to request for natural width
> > And we have two properties for them:
> > - width-chars
> > - max-width-chars
> > 
> > Now I would argue that 2 of the values are kind of useless: the
> > maximum minimum width and the minimum natural size. If you'd agree
> > with that premise, you could use width-chars as the minimum minimum
> > width and max-width-chars as the maximum natural size. (Which is what
> > I did in my reply.)
> 
> I think I agree... max-width-chars should be the limit of natural
> text width.
> 
> the other is harder... width-chars is currently useful to make 
> sure wrapping labels request enough width (and the UI ends up 
> really tall, hence we have the wrap-width guessing fallback) 

Err, "and the UI ends up..." should read "Otherwise the UI ends up..."

> Questions about width-chars ...
> 
> should a wrapping/ellipsizing label have an api to set the 
> absolute mi

Re: Please fill out the GtkLabel questionnaire

[Tristan Van Berkom]

On Sun, 2011-04-10 at 02:58 +0200, Benjamin Otte wrote:
> On Sat, Apr 9, 2011 at 2:14 PM, Tristan Van Berkom
>  wrote:
> > What I should have done, as Owen pointed out back in december was to
> > leave the label requests very straight-forward and require the program
> > author to set an explicit minimum size of the toplevel GtkWindow,
> > essentially the difference would only be that instead of having to
> > potentially configure a lot of label sizes inside the interface, you
> > just configure the desired size of the toplevel and you get a reasonable
> > allocation (Havoc also suggested we do some one-shot binary search to
> > find a good aspect ratio for the initial size of the toplevel window).
> >
> So what you are saying is to essentially get rid of the
> guess_wrap_width argument to gtk_label_ensure_layout(), right?

Unfortunately we did not make the change before releasing 3.0 so now I
guess we're stuck with the wrap width guessing (any interfaces
with wrapping text would suddenly be effected and have a tall and 
thin size)... possibly we could fix it by adding api to gtklabel
(however the apis that would be needed to opt-out of the wrap-width
guesswork don't sound very attractive).

> 
> > A caveat here is that currently there is no straight-forward way for
> > obtaining things like "the size of the largest word in the text" or
> > "the size of the widest character".
> >
> According to Behdad:
> pango_layout_set_wrap_mode (layout, mode);
> pango_layout_set_width (layout, 0);
> pango_layout_get_extents (layout, &extents);
> will give you exactly that. It will cause as much wrapping as possible
> and then of course the width of the resulting text will be the size of
> the widest word/character.

That's very fortunate :) we can use that to avoid
clipping when using width-chars properties (we have
the same problem with cell renderers too).

> 
> > Labels currently don't wrap and ellipsize both, it would be nice if
> > they did however (and it's certainly possible, I would imagine the
> > whole text would wrap as much as possible and the text that doesnt
> > fit would be ellipsized only on the last line).
> >
> Oh? Is this a limitation in Pango or is that just missing inside GtkLabel?

Looks like we could use pango_layout_set_height ().

> > As far as "max-width-chars" and "width-chars" effects go, I dont have
> > any strong opinion so far as it's useful, the subtleties are:
> >
> >  - Do we blatently always request "width-chars" as minimum if set ?
> >  - Do we request MIN (text_width, width-chars) ?
> >(I think this is more useful and I think it's how it currently
> > works)
> >
> > Same for max:
> >  - Do we blindly request "max-width-chars" as the natural width ?
> >  - Do we request MIN (text_width, max-width-chars) as natural ?
> >(Again I think it's currently the latter and I personally think
> >that is more useful).
> >
> Paolo and I discussed that, and what we discussed was setting the
> minimum/natural size in characters.
> There seem to be 4 values that you could want to set:
> - minimum value to request for minimum width
> - maximum value to request for minimum width
> - minimum value to request for natural width
> - maximum value to request for natural width
> And we have two properties for them:
> - width-chars
> - max-width-chars
> 
> Now I would argue that 2 of the values are kind of useless: the
> maximum minimum width and the minimum natural size. If you'd agree
> with that premise, you could use width-chars as the minimum minimum
> width and max-width-chars as the maximum natural size. (Which is what
> I did in my reply.)

I think I agree... max-width-chars should be the limit of natural
text width.

the other is harder... width-chars is currently useful to make 
sure wrapping labels request enough width (and the UI ends up 
really tall, hence we have the wrap-width guessing fallback) 

Questions about width-chars ...

should a wrapping/ellipsizing label have an api to set the 
absolute minimum size in characters ? 

I think probably yes

should such a label have an api for limiting the minimum request ?
(i.e. 'MIN (text_width, width-chars)')

I think definitely yes 

should a label have a way to request at least 'n-chars' in width ?
(i.e. 'MAX (width-chars, MIN (text_width, max-width-chars))')

Yes I think that's useful too (for cases where you want to show 
some labels in a status bar about download speed and progress, 
and you want to use something like width-chars to ensure some 
padding for your labels so they don't lose their alig

Re: Please fill out the GtkLabel questionnaire

[Tristan Van Berkom]

On Sun, 2011-04-10 at 00:25 +0200, Benjamin Otte wrote:
> Hey,
> 
> So this came up while discussing
> https://bugzilla.gnome.org/show_bug.cgi?id=647284 and we weren't sure
> what the proper answers for all those questions were. So we were
> wondering.
> We are thinking about GtkLabel size reuqests, in particular about the
> width. For ease of discussion, we assume that the font is monospaced,
> so we can forget about pixels and only think about characters. The
> text set on the label is "12345 1234" (10 characters in 2 words). And
> the question is: Given the properties on the left what width should
> the label request? Please fill out the table.

Benjamin,
   Essentially the width request of a label should be quite simple,
things became overcomplicated by the guessed minimum width of a wrapping
label and by my addition of max-width-chars... while it's a little bit
besides the point let me describe what should have have been done
instead.

Basically what happened is that I discovered if you give wrapping labels
a straight-forward size request you end up with a very tall and skinny 
interface by default... at the time I was working fast and I resorted to
giving wrapping labels "reasonably large" minimum widths to compensate 
for this (keep in mind an interface/GtkWindow is initially allocated the
minimum-height-for-minimum-width by default).

What I should have done, as Owen pointed out back in december was to
leave the label requests very straight-forward and require the program
author to set an explicit minimum size of the toplevel GtkWindow,
essentially the difference would only be that instead of having to
potentially configure a lot of label sizes inside the interface, you
just configure the desired size of the toplevel and you get a reasonable
allocation (Havoc also suggested we do some one-shot binary search to
find a good aspect ratio for the initial size of the toplevel window).

So, assuming that things were a bit simpler and we did not have to
guarantee that wrapping labels get a larger-than-life size by default,
my answer would be.

For ellipsizing labels:
   Minimum size: the size of the "..." or the size of the label,
 whichever is smaller (an empty label can be smaller).
   Natural size: the full text length.

For labels wrapping with WRAP_CHAR or WRAP_WORD_CHAR:
   Minimum size: The width of the widest character in the label text
   Natural size: The fully unwrapped text length

For labels wrapping with WRAP_WORD:
   Minimum size: The width of the longest *word* in the full label text
   Natural size: The fully unwrapped text length

Natural size, it's important to remember is the size where a widget
ceases to compete with sibling widgets for space in a given container,
so it's still interesting to let the user set a natural-width-chars
(or max-width-chars), assigning a natural width in charachters does
not mean the widget will never get larger/wider... but it will only
get larger than the natural size after all siblings receive their
respective natural sizes and the label starts to receive expand space.

A caveat here is that currently there is no straight-forward way for
obtaining things like "the size of the largest word in the text" or
"the size of the widest character".

Labels currently don't wrap and ellipsize both, it would be nice if
they did however (and it's certainly possible, I would imagine the
whole text would wrap as much as possible and the text that doesnt
fit would be ellipsized only on the last line).

As far as "max-width-chars" and "width-chars" effects go, I dont have
any strong opinion so far as it's useful, the subtleties are:

  - Do we blatently always request "width-chars" as minimum if set ?
  - Do we request MIN (text_width, width-chars) ? 
(I think this is more useful and I think it's how it currently
 works)

Same for max:
  - Do we blindly request "max-width-chars" as the natural width ?
  - Do we request MIN (text_width, max-width-chars) as natural ?
(Again I think it's currently the latter and I personally think
that is more useful).

Hope this was helpful,
-Tristan


> 
> label properties number of
> characters label should request
> wrapellipsize   width_chars max_width_chars  minimum   natural
> false   false   -1  -1   ? ?
> truefalse   -1  -1   ? ?
> false   true-1  -1   ? ?
> truetrue-1  -1   ? ?
> false   false4  -1   ? ?
> truefalse4  -1   ? ?
> false   true 4  -1   ? ?
> truetrue 4  -1   ? ?
> false   false8  -1   ? ?
> truefalse8  -1   ? ?
> false   true