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: compiling glade

[Tristan Van Berkom]

On Thu, 2018-03-22 at 19:13 +0100, arkkimede wrote:
> Thank You Tristan for Your Kindness.
> Unfortunately, this new release of Glade require libgtk-3.20.0 and in
> my linuxbox Ubuntu 16.04 I have only 3.18.0.
> The 3.20.0 is present in Ubuntu 17 but this release is not stable
> enough to start to work with it.
> 
> Thank you in any case. 

Ok, in that case, I recommend the following:

Follow instructions to install BuildStream, better to follow the wiki
page here:

https://wiki.gnome.org/Newcomers/BuildSystemComponent

Or directly:

http://buildstream.gitlab.io/buildstream/install.html
(pay attention to the system requirements, the debian
instructions should be close to ubuntu)

Then once you have installed BuildStream, do the following:

# Get the build metadata repo
#
$ git clone https://gitlab.gnome.org/GNOME/gnome-build-meta.git

# Build Glade
#
$ bst build --track-all world/glade.bst

# Run Glade, note the --mount option just makes your /home available
# in the shell, so you can edit files in your home dir.
#
$ bst shell --mount /home /home world/glade.bst

... this will drop you into a shell, where you can run `glade` ...

This will take a bunch of your disk space, and may take a long time the
first time around, because we dont have a regular builder contributing
to the shared artifact cache *yet*.

However, so long as BuildStream can be installed on Ubuntu 16.04, it
should get you glade from git master reliably.

Cheers,
-Tristan

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

Re: compiling glade

[Tristan Van Berkom]

Hi,

On Thu, 2018-03-22 at 14:52 +0100, arkkimede wrote:
> HI!
> I want to install the latest version of glade downloaded from git-hub.
> 
> I read the instruction.
> 
> There is written that configure.ac or configure.in is used to generate the
> script configure.
> To do that execute the command autoconf.
> 
> I executed this command but some macro are missed
> 
> Searching I found who write:
> to solve the problem run "autoreconf -fvi".
> 
> Running this command it ends with this error:
> 
> automake: error: cannot open < gtk-doc.make: No such file or directory
> autoreconf: automake failed with exit status: 1
> 
> consider that I've installed
> 
> libgtk-3-doc
> gtk-doc-tools.
> 
> Please, could you help me?

First just noting, this question would be better targeted at the Glade
users mailing list: glade-us...@lists.ximian.com

But I'll just answer you here anyway :)

I suggest you use the most recent tarball release, which is very
recent; at:

  https://download.gnome.org/sources/glade/3.22/glade-3.22.0.tar.xz

Otherwise, to build directly from the official upstream git repository,
which can be found at: https://git.gnome.org/browse/glade (if there is
a github, it is either only a mirror, or it is someone's private fork),
you should use the autogen.sh script, feeding it directly the arguments
you would normally pass to ./configure

When building directly from git, you have a couple of extra
requirements, so it is a little bit harder than just using the release
tarball - you will need at least gtkdocize, and I think libtoolize,
along with the m4-common macros.

Note that once you have *built* Glade, you need to install it, you can
install it to any prefix you like, it need not be installed to /usr,
but it will not run directly from the build directory.

Cheers,
-Tristan

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

Re: centered and right justified label in the same line.

[Tristan Van Berkom]

On Mon, 2018-02-26 at 09:23 +0100, Stefan Salewski wrote:
> On Mon, 2018-02-26 at 09:16 +0100, Wojciech Puchar wrote:
> > How to do this in GTK 2. whatever i try i'm getting first label
> > centered 
> > relative to space remaining after second label not to whole hbox. how
> > to 
> > do this properly?
> > 
> > 
> 
> That may be not that easy.
> 
> Maybe try a hbox, which again contains 3 hboxes. 3 because so it may
> allow center the middle one. Then put your labels into some of these 3
> boxes.

I dont think 3 boxes will change anything, as size requisition will
just pass through to a widget which actually requested size.

A decent approach is to ensure that there are 3 widgets in the box,
while the left widget shows no content (this could be anything; an
empty label or an empty box would do it).

Need to make sure that the first and last widget in your horizontal box
requested to "expand" while the middle label which you want centered
does not ask to "expand".

To set this, you need to set the *packing* properties of the children
of the main horizontal box, e.g. like this:

   gtk_container_child_set(GTK_CONTAINER(box), first_child,
   "expand", TRUE,
   NULL);
   gtk_container_child_set(GTK_CONTAINER(box), second_child,
   
   "expand", FALSE,
   NULL);
  
gtk_container_child_set(GTK_CONTAINER(box), third_child,
   
   "expand", TRUE,
   NULL);

Alternatively, you could probably achieve similar by adding the first
and last child to a GtkSizeGroup; this would additionally cause the
horizontal box to have a minimum size which honors the appearance you
want to achieve (without a size group, the minimum possible size would
allow both center and right justified labels to appear side by side).

Cheers,
-Tristan

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

Re: Two issues with librsvg

[Tristan Van Berkom]

With a very brief look at your valgrind output i can tell you that you need a 
suppressions file.

You may be leaking, but you are also counting GType registration as "possibly 
lost", this is constant data for static types which will be allocated once and 
remain on the heap for program lifetime, these are not leaks.

Other things, you might be leaking, i havent poured through the whole log.

Cheers,
-Tristan

> On Oct 22, 2017, at 5:15 AM, Oren Ben-Kiki  wrote:
> 
> Oops, the sample program I gave was missing the call to rsvg_handle_close.
> However, adding it doesn't change anything. The corrected program is:
> 
> --- cheese.cpp ---
> #include 
> #include 
> 
> using namespace std;
> 
> static const char s_svg[] = R"EOF(
> 
> 
> 
> )EOF";
> 
> int main() {
>cerr << "RSVG VERSION: " << LIBRSVG_VERSION << endl;
> 
>RsvgHandle* rsvg = rsvg_handle_new();
>GError* error = nullptr;
>if (!rsvg_handle_write(rsvg,
>   reinterpret_cast(s_svg),
>   sizeof(s_svg) - 1,
>   )
>|| !rsvg_handle_close(rsvg, )) { // <-- fixed
>cerr << "Oops: " << error->message << endl;
>g_error_free(error);
>} else if (rsvg_handle_has_sub(rsvg, "cheese")) {
>cerr << "Yummy cheese!" << endl;
>} else {
>cerr << "WHERE IS MY CHEESE?" << endl;
>}
>g_object_unref(rsvg);
>return 0;
> }
> --- cheese.cpp ---
> 
> It generates the same output (rsvg_handle_has_sub returns false, and the
> valgrind memory leak reports).
> 
> Thanks,
> 
> Oren Ben-Kiki
> 
> On Sat, Oct 21, 2017 at 11:06 PM, Oren Ben-Kiki 
> wrote:
> 
>> My main issue is that librsvg seems to not find sub elements by id.
>> Specifically, rsvg_handle_has_sub returns false, and therefore querying
>> for the element's size and position fails. I'm probably doing something
>> wrong here... or is this a bug? I really want the ability to access
>> sub-elements size and position (by id or name or something along these
>> lines), so any advice/workaround to make this work would be appreciated.
>> 
>> The secondary issue is that librsvg causes memory leaks, or at least
>> causes valgrind to think there is such a leak. I can easily work around
>> this with a suppression file, but... Is there some additional cleanup
>> function I should call to release all allocated memory?
>> 
>> As you can see in the output (below), I am using version 2.40.13, if that
>> matters.
>> 
>> Here is the tiny test program:
>> 
>> --- cheese.cpp ---
>> #include 
>> #include 
>> 
>> using namespace std;
>> 
>> static const char s_svg[] = R"EOF(
>> 
>> 
>> 
>> )EOF";
>> 
>> int main() {
>>cerr << "RSVG VERSION: " << LIBRSVG_VERSION << endl;
>> 
>>RsvgHandle* rsvg = rsvg_handle_new();
>>GError* error = nullptr;
>>if (!rsvg_handle_write(rsvg,
>>   reinterpret_cast(s_svg),
>>   sizeof(s_svg) - 1,
>>   )) {
>>cerr << "Oops: " << error->message << endl;
>>g_error_free(error);
>>} else if (rsvg_handle_has_sub(rsvg, "cheese")) {
>>cerr << "YUMMY CHEESE!" << endl;
>>} else {
>>cerr << "WHERE IS MY CHEESE?" << endl;
>>}
>>g_object_unref(rsvg);
>>return 0;
>> }
>> --- cheese.cpp ---
>> 
>> And a tinier shell script running it:
>> 
>> --- cheese.sh ---
>> #!/bin/sh
>> set -x
>> g++ \
>>-std=c++14 \
>>-isystem /usr/include/librsvg-2.0/librsvg \
>>-isystem /usr/include/glib-2.0 \
>>-isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include \
>>-isystem /usr/include/gdk-pixbuf-2.0 \
>>-isystem /usr/include/cairo \
>>-o cheese \
>>cheese.cpp \
>>-lrsvg-2 \
>>-lglib-2.0 \
>>-lgobject-2.0
>> valgrind --leak-check=full --track-origins=yes ./cheese
>> --- cheese.sh ---
>> 
>> The results are longer:
>> 
>> --- cheese.out ---
>> + g++ -std=c++14 -isystem /usr/include/librsvg-2.0/librsvg -isystem
>> /usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include
>> -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/cairo -o cheese
>> cheese.cpp -lrsvg-2 -lglib-2.0 -lgobject-2.0
>> + valgrind --leak-check=full --track-origins=yes ./cheese
>> ==20434== Memcheck, a memory error detector
>> ==20434== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>> ==20434== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright
>> info
>> ==20434== Command: ./cheese
>> ==20434==
>> RSVG VERSION: 2.40.13
>> WHERE IS MY CHEESE?
>> ==20434==
>> ==20434== HEAP SUMMARY:
>> ==20434== in use at exit: 149,205 bytes in 361 blocks
>> ==20434==   total heap usage: 522 allocs, 161 frees, 170,579 bytes
>> allocated
>> ==20434==
>> ==20434== 8 bytes in 1 blocks are possibly lost in loss record 17 of 349
>> ==20434==at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_
>> memcheck-amd64-linux.so)
>> ==20434==by 0x4C2FDEF: realloc (in 

Re: Locale switch on the fly

[Tristan Van Berkom]

On Mon, 2017-07-17 at 12:32 +0300, Igor Chetverovod wrote:
> Hi all, I have a need to switch locale on the fly (without  an
> application
> UI reload).
> I  have a function which are using gkt_container_forall()  for
> marking of
> all widgets are having GObject property "label" ,  all of them get
> aditional GObject field  "msg_id" with original english text of
> property
> "label").   When user press the button "Change locale"  function
> iterates
> through all children of  the main window and reads thier marks
> "msg_id"
> added before and uses them as a parameter for get_text() to
> get  translated
> version of the label.  And it sets  localized text of every label by
> function g_object_set(). Function works good for all widgets in my
> application. But there is exclusion - GtkMenuItems widgets. Function
>  gkt_container_forall() iterates trough them only once - at the
> "marking"
> phase. In "change locale" phase it does not iterate them. It
> translates
> only top level of GtkMenuBar, but does not GtkMenuItems and
> GtkCheckMenuItems.
> 
> Fuction gtk_container_foreach () givese the same results.
> 
> Is there method to solve this issue by gtk-functions?
> 
> I am using gtk3.22.1 for Windows7.

Hi Igor,

Translating the UI on the fly is something I have wanted for many
years, and would be awesome to have real support for :)

That said, using your current 'hack' (which seems a bit dangerous as it
makes assumptions about "label" properties on widgets and their
meaning), you are just missing some special cases to traverse through
the UI.

For this case, you can probably get away with somthing like the
following inserted into your recursive widget crawling loop:

  if (GTK_IS_MENU_ITEM(widget))
     child = gtk_menu_item_get_submenu(GTK_MENU_ITEM(widget))

https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#gtk-menu-item-get-submenu


Cheers,
-Tristan

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

Re: Can I get GTK_RESPONSE_ACCEPT/REJECT from modal dialog by glade.

[Tristan Van Berkom]

Hi

> On Jun 25, 2017, at 5:40 PM, michinari.nukazawa 
>  wrote:
> 
> Hello.
> I develop vecterion vector graphics editor in GTK3/cairo.
> https://github.com/MichinariNukazawa/vecterion_vge
> I try porting the "New Document" dialog to xml file by glade from C code.
> 
> ```
>GtkDialogFlags flags = GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT;
> 
>dialog = gtk_dialog_new_with_buttons ("New Document",
>NULL,
>flags,
>"_OK",
>GTK_RESPONSE_ACCEPT,
>"_Cancel",
>GTK_RESPONSE_REJECT,
>NULL);
> 
> ~
> 
>gint result = gtk_dialog_run (GTK_DIALOG (dialog));
>switch (result)
>{
>case GTK_RESPONSE_ACCEPT:
> ~
> ```
> This is good easy way because callback/connect not necessary OK/Cancel.
> 
> My modal dialog by glade don't return, when OK/Cancel button clicked.
> (I checked General>Window Flags>Destroy with Parent, and Modal.)
> I need GTK_RESPONSE_ACCEPT/REJECT.
> 
> Can I get the dialog with GTK_RESPONSE_ACCEPT/REJECT, by configuration in 
> glade( or other way)?
> 
> Thanks.

Yes, this is one of the weirder constructs (dialog editor UX could be much 
improved here i think)...

To do this, you need to set the "Response ID" property on the buttons you add 
in the action area.

In very recent Glade, you dont have to know the integer values and can select 
the standard named response values from a list.

Cheers,
-Tristan

> 
> 
> -- 
> ==
> Michinari.Nukazawa
> 
> in the project "daisy bell"
> https://daisy-bell.booth.pm/
> ==
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 

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

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: Best practise inheritance

[Tristan Van Berkom]

On Tue, 2017-03-21 at 18:27 +0100, S. Jacobi wrote:
> On Mon, 20 Mar 2017 16:01:39 +
> Tristan Van Berkom <tristan.vanber...@codethink.co.uk> wrote:
> 
> > 
> > 
> > Use instance private data, this will not need any priv pointer and
> > can be done with th G_DEFINE_TYPE_WITH_PRIVATE() macro, and another
> > to lookup your private data inside your C file (under the hood,
> > this
> > uses negative instance offsets with power nter arithmatic, so
> > public
> > and private data are on the same allocated memory slice)
> > 
> 
> This is still a bit unclear to me, because I found no good reference
> what instance private data really is, apart from a patch on the
> mailing
> list. So is it just GObject "magic" that puts private fields into
> special memory locations and can therefore retain ABI compatibility?
> Because from what I read, I define my structs the same way.
> 
> struct _MyType
> {
>   GtkWidget   parent;
>   MyTypePriv *priv;
> }
> G_DEFINE_TYPE (MyType, my_type, GTK_TYPE_WIDGET)
> 
> and
> 
> struct _MyType
> {
>   GtkWidget   parent;
>   MyTypePriv *priv;
> }
> G_DEFINE_TYPE_WITH_PRIVATE (MyType, my_type, GTK_TYPE_WIDGET)
> 
> would be first a struct with "normal" private data and second a
> struct
> with instance private data. Or am I completely on the wrong track
> here?

This describes a bit of what you're after:

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

The key points here are that:

  o MyType structure does not need any 'priv' pointer, as it can be
    looked up at any time.
  o G_DEFINE_TYPE_WITH_PRIVATE() expects that a MyTypePrivate structure
    is defined above
  o G_TYPE_INSTANCE_GET_PRIVATE() can be called in your C file to
    access the allocated MyTypePrivate structure for a given instance.

    See: https://developer.gnome.org/gobject/stable/gobject-Type-Inform
ation.html#G-TYPE-INSTANCE-GET-PRIVATE:CAPS

At the end of the day, the main memory slice for an object instance
will be created with space for your MyTypePrivate structure, but the
sizeof() that structure will be computed at runtime so it does not
effect ABI.

This means:
  o No need for allocating an extra pointer to point to private data
  o Less overall memory fragmentation, because private data is
    allocated on the object instance itself.
  o I believe the lookups with G_TYPE_INSTANCE_GET_PRIVATE() are just
    as cheap as the pointer dereference (as it will be implemented
    using simple pointer arithmetic).

Cheers,
    -Tristan

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

Re: Best practise inheritance

[Tristan Van Berkom]

On Mon, 2017-03-20 at 16:36 +0100, S. Jacobi wrote:
> First of all, inheritance may be the wrong word here in plain c, but
> I
> don't know how else to name it.

Sorry replied to this from my phone and missed some things...

> In different projects I see different approaches how to derive custom
> widgets from existing ones. I can roughly group them into 2 to 3.
> 
> 1) The header only has a typedef to make the struct opaque. All
> variables needed are put into the struct in the .c file.
> 
> myType.h
> typedef struct _MyTypeMyType;
> 
> myType.c
> struct _MyType
> {
>   GtkWidget   *parent;
>   /* additions */
>   guint    i;
>   ...
> };

Note also that this approach imposes that absolutely nothing can derive
from MyType later, because MyType becomes anonymous.

> 
> 2a) The header defines a private struct, and all variables needed are
> put into this private struct.
> 
> myType.h
> typedef struct _MyTypePriv MyTypePriv;
> typedef struct _MyType   MyType;
> 
> myType.c
> struct _MyTypePriv
> {
>   GtkWidget   *parent;
>   /* additions */
>   guint    i;
> };
> 
> struct _MyType
> {
>   MyTypePriv  *priv;
> };

Actually this approach (2a) I've never seen before, not a good idea,
but possibly works (except for the other detail below)...


> 2b) Similar to 2a, but the parent is put in the "main" struct, not
> the
> private part.
> 
> myType.h
> typedef struct _MyTypePriv MyTypePriv;
> typedef struct _MyType   MyType;
> 
> myType.c
> struct _MyTypePriv
> {
>   /* additions */
>   guint    i;
> };
> 
> struct _MyType
> {
>   GtkWidget   *parent
>   MyTypePriv  *priv;
> };

So in all of these cases, you have missed an important detail:

struct _MyType {
    GtkWidget *parent_instance;

    ... anything else...
}

Is wrong, as it will only reserve one pointer size for the parent
structure, what you have been seeing is always in fact:

struct _MyType {
    GtkWidget parent_instance

    ... anything else ...
}

The parent instance must be known and not anonymous, you need to
include the struct itself as the first member of your derived type, not
merely a pointer to that.

Cheers,
    -Tristan

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

Re: Best practise inheritance

[Tristan Van Berkom]

Hi

> On Mar 20, 2017, at 3:36 PM, S. Jacobi  wrote:
> 
> First of all, inheritance may be the wrong word here in plain c, but I
> don't know how else to name it.
> 
> In different projects I see different approaches how to derive custom
> widgets from existing ones. I can roughly group them into 2 to 3.
> 
> 1) The header only has a typedef to make the struct opaque. All
> variables needed are put into the struct in the .c file.
> 
> myType.h
> typedef struct _MyTypeMyType;
> 
> myType.c
> struct _MyType
> {
>  GtkWidget*parent;
>  /* additions */
>  guint i;
>  ...
> };

This is unsafe, the size of an instance structure is part of ABI so it can 
never change without releasing a completely new library soname.

You can use this style but its then easy to forget that restriction, so just 
dont.

> 2a) The header defines a private struct, and all variables needed are
> put into this private struct.
> 
> myType.h
> typedef struct _MyTypePriv MyTypePriv;
> typedef struct _MyType   MyType;
> 
> myType.c
> struct _MyTypePriv
> {
>  GtkWidget*parent;
>  /* additions */
>  guint i;
> };
> 
> struct _MyType
> {
>  MyTypePriv*priv;
> };

This is safe, and was a measure to ensure private details stay private while 
retaining instance size (before better approaches were developed).

> 
> 2b) Similar to 2a, but the parent is put in the "main" struct, not the
> private part.
> 
> myType.h
> typedef struct _MyTypePriv MyTypePriv;
> typedef struct _MyType   MyType;
> 
> myType.c
> struct _MyTypePriv
> {
>  /* additions */
>  guint i;
> };
> 
> struct _MyType
> {
>  GtkWidget*parent
>  MyTypePriv*priv;
> };
> 

This is also legacy, occurrences of this in gtk+ proper will only exist to 
retain ABI compat with an older release where publicly exposed members already 
existed.

Even in the cases where the pointer is considered public, we prefer to wrap it 
in an explicit accessor (this also makes life easier for bindings using 
introspection).

> So my first question: What is the best way here? And are there
> (functional) differences between these?

Use instance private data, this will not need any priv pointer and can be done 
with th G_DEFINE_TYPE_WITH_PRIVATE() macro, and another to lookup your private 
data inside your C file (under the hood, this uses negative instance offsets 
with power nter arithmatic, so public and private data are on the same 
allocated memory slice)


> And my second question is closely related: How to access "inherited"
> properties, or call "inherited" functions? I see these variants in the
> following examples, where I have:
> MyType *myWidget;

There is no difference for accessing these things as inherited code or external 
code: do so with API (no such thing as "protected").

Alternatively, you can bend the rules by providing private accessors usually 
prefixed with _, without exporting these symbols in your shared library to 
users (gtk+ does this in many places, for strictly private object interactions).

Cheers,
-Tristan

> 1) gtk_widget_set_name (GTK_WIDGET (myWidget), "myWidget");
> 2) gtk_widget_set_name (myWidget->parent, "myWidget");
> 3) gtk_widget_set_name (myWidget->priv->parent, "myWidget");
> 
> I am looking forward to helpful replies.
> Thanks and kind regards
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> 

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

Re: How to use glade with a GtkHeaderBar with different layouts

[Tristan Van Berkom]

On Tue, 2017-03-07 at 11:05 +0100, Iñigo Martínez wrote:
> Thank you very much for your kind support Tristan, those hints are
> very much appreciated.
> 
> While I understand that the template actually is a definition of the
> class hierarchy, I was thinking about it as a description of the UI,
> and in that sense it would have been nice to have some way to define
> different states of a widget and be able to change between those
> changing the layout.
> 
> One last question regarding widgets that are not displayed. What
> should be the best approach, add and remove the widgets to the header
> bar depending on what should be shown or have all the widgets packed
> in the header bar and just show/hide them?
> 
> I was thinking on the latter approach as it involves only one widget,
> the one that is going to be shown or hide, versus the former one that
> involves two, the container and the widget to be added/removed.
> 

In the old days, I would use a notebook without tabs. In the modern
world, I think you can just use a GtkStack (you may even want to
animate/fade them when it switches for extra giggles).

This approach is more maintainable I think than showing/hiding widgets
(or adding removing them, adding and removing them is even more of a
headache, as you have to make sure you retain ownership while carrying
them over, floating refs and all that noise).

Cheers,
    -Tristan

> Best regards,
> 
> 2017-03-07 5:51 GMT+01:00 Tristan Van Berkom
> <tristan.vanber...@codethink.co.uk>:
> > 
> > On Mon, 2017-03-06 at 22:26 +0100, Iñigo Martínez wrote:
> > > 
> > > Recently, I started moving UI code from bare C to Glade XML
> > > files, so
> > > the UI definition gets split from the UI logic.
> > > 
> > > One of the widgets I have been moving is a GtkHeaderBar. The
> > > application uses a GtkStack to move between diferent windows, and
> > > the
> > > code creates, adds and destroys the buttons on the header
> > > everytime
> > > it
> > > moves through those window states. All is done in the same class,
> > > derived from GtkHeaderBar.
> > > 
> > > The first challenge here is that, as far as I know, I can only
> > > init/load one template per class. This solves only part of the
> > > problem, as I can create a template file for the most used/common
> > > window state, and create and change the buttons while they
> > > change,
> > > although I feel that I'm not taking any of the advantages from
> > > Glade.
> > > Here goes my first question: Is there any possibility of using
> > > more
> > > than one template on the same class?
> > 
> > No.
> > 
> > A template is the definition of the class's hierarchy, this is
> > static
> > and is that way by design.
> > 
> > > 
> > > I have been looking at some GNOME applications code, and none of
> > > them
> > > do this, so I think that its probably not possible. I've been
> > > thinking
> > > about other approaches, but I don't know what could be the proper
> > > one,
> > > or even if I could be doing some weird things.
> > > 
> > > One approach could be to define all the possible widgets/buttons
> > > of
> > > the header in the template file. They would be created but I
> > > should
> > > add and remove them continuously which doesn't look very
> > > efficient/clean.
> > > 
> > > Another approach would be to create different classes for every
> > > possible header, each with their different template file, loading
> > > them
> > > on every window state and adding and removing the full header
> > > to/from
> > > the window. The idea is similar to what GtkStack does with
> > > windows,
> > > but applied to headers.
> > > 
> > > Is there any reasonable answer for this or has anyone encountered
> > > a
> > > similar problem?
> > 
> > Either of the above approaches are valid ones, I would probably opt
> > for
> > the former since in this case you are only talking about some
> > buttons
> > in a headerbar, which _should_ be ridiculously inexpensive.
> > 
> > Some things to keep in mind:
> > 
> >   o Using templated classes keeps your business logic encapsulated
> > into an object type, this is the win you take home from using
> > templates rather than old fashioned manual usage of GtkBuilder
> > 
> > The older approach tends to make your code hard to debug and
> > understand as your applic

Re: How to use glade with a GtkHeaderBar with different layouts

[Tristan Van Berkom]

On Mon, 2017-03-06 at 22:26 +0100, Iñigo Martínez wrote:
> Recently, I started moving UI code from bare C to Glade XML files, so
> the UI definition gets split from the UI logic.
> 
> One of the widgets I have been moving is a GtkHeaderBar. The
> application uses a GtkStack to move between diferent windows, and the
> code creates, adds and destroys the buttons on the header everytime
> it
> moves through those window states. All is done in the same class,
> derived from GtkHeaderBar.
> 
> The first challenge here is that, as far as I know, I can only
> init/load one template per class. This solves only part of the
> problem, as I can create a template file for the most used/common
> window state, and create and change the buttons while they change,
> although I feel that I'm not taking any of the advantages from Glade.
> Here goes my first question: Is there any possibility of using more
> than one template on the same class?

No.

A template is the definition of the class's hierarchy, this is static
and is that way by design.

> I have been looking at some GNOME applications code, and none of them
> do this, so I think that its probably not possible. I've been
> thinking
> about other approaches, but I don't know what could be the proper
> one,
> or even if I could be doing some weird things.
> 
> One approach could be to define all the possible widgets/buttons of
> the header in the template file. They would be created but I should
> add and remove them continuously which doesn't look very
> efficient/clean.
> 
> Another approach would be to create different classes for every
> possible header, each with their different template file, loading
> them
> on every window state and adding and removing the full header to/from
> the window. The idea is similar to what GtkStack does with windows,
> but applied to headers.
> 
> Is there any reasonable answer for this or has anyone encountered a
> similar problem?

Either of the above approaches are valid ones, I would probably opt for
the former since in this case you are only talking about some buttons
in a headerbar, which _should_ be ridiculously inexpensive.

Some things to keep in mind:

  o Using templated classes keeps your business logic encapsulated
    into an object type, this is the win you take home from using
    templates rather than old fashioned manual usage of GtkBuilder

    The older approach tends to make your code hard to debug and
    understand as your application gains complexity, as you would
    traditionally just handle GSignals in callbacks which in turn
    call other GTK+ apis, triggering more signals, this is what I've
    referred to as "implicit invocation hell".

  o Based on the above, I would opt for declaring one widget class
    for anything which serves a specific and identifiable purpose
    in an app (whether or not the thing is complex enough to merit
    a template, you might have some stand alone widget types with no
    children, custom buttons or controls, which dont need templates at
    all, but its cleaner to make widgets out of these than to handle
    "draw" and event signals on a GtkDrawingArea).

  o Widgets should be assumed to consume very little resources when
    they are not mapped and visible.

    Class methods, class-wide template XML, is all class data that is
    in memory exactly once; for every widget you instantiate that
    is not on screen (i.e. a button in a stack page that is not shown),
    we are talking about some data structures allocated in memory to
    track widgets visible/realized/mapped state, and some state about
    whether a button is currently pressed etc.

    So just remember, instantiating a widget that is not displayed
    should not consume any resources associated with drawing or
    receiving events and whatnot.

  o As with any modular code, when a widget starts to have very many
    features and gets overly complex, or when a widget hierarchy starts
    to become huge, it's better to separate those features into
    separate widgets (components of a larger program, either serving
    different purposes or implementing a common interface differently).

    Interestingly, when we are talking about "smart" widgets which
    manage their own business logic, code complexity and widget
    hierarchy tends to scale hand in hand (bigger hierarchies are
    both more difficult to reason about, and also consume more
    resources).

Cheers,
    -Tristan


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

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

Re: Ideas of new widgets and critics, only for enhance gtk+.

[Tristan Van Berkom]

On Sun, 2016-12-11 at 10:18 +0100, eddie wrote:
> Hi to all gtk+ users,
> 
> At first I get few ideas about some new widgets.
> 
> 
> 
> 1. The 3 states button.
> ---
> 
> The most important, the most easy to implement is the idea of a
> button which can take 3 different states.
> 
> I had this idea because I often have the need of something that I
> have called the triboolean logic.
> 
> Which consist of something like a boolean but instead of 0 or 1 as
> possible values you get 3 values:
> 
> -1, 0 and 1.
> 
> It's of course easy to create this type with **typedef**:
> 
> https://github.com/mrcyberfighter/mk-project/blob/master/mk-project-1
> .0.0/data/templates/C_Project/headers/tribool.h
> 
> But gtk+ don't have this kind of widget and I never try to D.I.Y a
> widget with gtk+.
> 
> ASCII Image of a 3 state button:
> 
> 
> ```
> 
> +-+-+-+
> > 
> >  -  |  0  |  +  |
> +-+-+-+
> 
> ```

Hi Eddie,

For your above tristate button, this should be achievable without
adding anything to GTK+.

What you want I think is three GtkRadioButtons, and you want them to
be 'linked' together with the CSS - I think this is already the default
appearance when placing 3 radio buttons together in a GtkButtonBox.

I don't think however that a Joystick gizmo widget qualifies as general
purpose enough to be included in GTK+, this kind of thing should
certainly be application specific, or, shared in some other library
with similar widgets (dials ? for apps like q-base and sound mixers ?)

Cheers,
    -Tristan

> 2. The gizmo widget.
> 
> 
> What do you think of a widget emulating a gizmo ?
> 
> A gizmo looks like a joystick stick and is used to control a camera
> for moving the camera and zooming.
> 
> Of course I think it's difficult to set it up to be as generic as
> possible into gtk but not impossible.
> 
> You can per example make a widget looking like this:
> 
> 
> ```
>    
>   /\
>   ||
>   \/
> 
> 
> ```
> 
>    /\
>   /  \
>  |   \_|_/   |
>  | --|___|-- |
>  |   / | \   |
>  \  /
>   \/
> 
>   
> ```
> 
> A cross to indicate the directions, Inscribe in a circle with
> reactive regions, with a central button.
> 
> 
> I think the best for emulating a gizmo is to take the cross of a
> joystick,
> 
> with 8 directions, and adding a center region to press in/out...
>   
> 
> Once done you can set the increments for every region for X and Y.
> 
> And the action to bind to bind to the central button press button.
> 
> 
> Maybe you can use the inner drag-n-drop mechanic of gtk as base
> for a better control of this widget with the mouse or touch devices.
> 
> Some critics about the Windows compatibility.
> 
> 
> I have seen on this mail list that the bug of the native file chooser
> manifesting by displaying a windows saying that the CD reader device
> is not ready
> comes from the BIOS CD reading capability...???
> 
> I had the same problem but it has fast disappear after some use of my
> music player.
> 
> What's the problem for implementing a native folder chooser in fact ?
> 
> ---
> 
> My first critic rely on the Gio GAppInfo which simply doesn't work.
> 
> Okay I can't set my application as default for content type per
> example,
> 
> but why ?
> 
> Is this due of the underlying GvFS which Windows not implement ?
>   
> the developers of gtk won't make otherwise, they won't touch the hive
> in writing ?
> 
> 
> I don't really care about it.
> 
> It's a hallas to make Windows understand that your program
> 
> take more than one file as argument, once incomportementstalled,
> 
> whereas you can launch it with cmd.exe then it works.
> 
> They tell me I have to build something like COM serv(er|ice) for
> passing more
> than one file as argument to my music player. For making it work
> properly
> for selecting and open with...
> 
> Instead that Windows emulate the cmd.exe to launch a program
> 
> the graphic server (open with) work's otherwise: winshit !
> 
> Good work to the gtk development team but
> 
> stop to change the behavior of some components by every version
> incrementation please.
> 
> I gonna go crazy if I must rewrite parts of all my program due of
> this every time.
> 
> 
> Thanks, best regards,
> 
> mrcyberfighter.
> 

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

Re: Editable SpinButton on a TreeView: detect *every* changes

[Tristan Van Berkom]

Hi,

On Tue, 2016-11-15 at 02:09 +0100, pozzugno wrote:
[...]
> I have tried to catch "editing_started", "editing_canceled" and
> "edited" 
> signals of CellRenderer. In "editing_started" callback, I retrieve
> and 
> save the row and column of the cell the user is going to edit. I
> also 
> connect a callback to "value_changed" signal of the GtkAdjustment 
> associated to the GtkCellRendererSpin. Moreover I save the starting 
> value so I can restore it if the user will cancel the editing.
> 
> When the user clicks on +/- buttons, "value_changed" is called (so I
> can 
> send the request to the remote device).
> 
> With some tricks, I'm able to restore the original value if the user 
> cancels the editing and to avoid a duplicate request to the remote 
> device when the user confirm the value changed by +/- buttons
> (actually 
> when the user moves the focus away from the spinbutton, thus
> terminated 
> the editing).
> 
> As you know, I'm very new to Gtk programming, so I'm wondering
> wethere 
> there's a better approach.

Without reading your python code, your approach sounds correct.

If you want to get notifications (callbacks) for live editing of
editable widgets, you need to handle the editing started signal and
then handle signals on the editable widget which is created for that
edit session.

Cheers,
    -Tristan

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

Re: gtk_widget_grab_focus sets scrollbar adjustments to 0

[Tristan Van Berkom]

On Mon, 2015-12-28 at 18:01 +0800, Franco Broi wrote:
> Hi
> 
> I have a drawingarea inside a scrolled window for which I'd like to
> grab
> the focus so the user can use keyboard inputs but I want to do it
> without changing the scrolled window position. What I'm finding is
> the
> gtk_widget_grab_focus call on the drawable results in the scrolled
> window adjustments being set to zero.
> 
[...]

> I can see the code in gtk_container_real_set_focus_child calling
> gtk_adjustment_clamp_page but don't understand why and I don't see
> any
> way to stop it from doing it.
[...]

Hi,
   the reasoning is that usually focus is not given to the direct child
of a scrolled window, but to another grandchild.

This usually makes sense so that when using keynav and tabbing from
widget to widget inside a scrolled area, the scrolled window will
automatically adjust itself to reveal the new button/entry/widget which
may otherwise be hidden (so the user doesnt end up having to manually
move the scrollbars to see what widget is focused).

For your case, you should be able to opt out by simply clearing the
focus adjustments with the gtk_container_set_focus_[v/h]adjustment()
APIs.

Cheers,
    -Tristan

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

Re: data type that preserve order

[Tristan van Berkom]

> On Oct 31, 2015, at 4:10 PM, Andrea Zagli  wrote:
> 
> Il giorno ven 30 ott 2015 19:09:47 CET, Emmanuele Bassi ha scritto:
>> Hi;
>> 
>>> On 30 October 2015 at 16:43, Andrea Zagli  wrote:
>>> is there a data type, similar to array, that preserve the order on which
>>> elements are inserted?
>> 
>> All the array and list types preserve the order of insertion. For
>> obvious reasons, GHashTable doesn't.
>> 
>>> for example ghashtable and gptrarray doesn't preserve the order, so when
>>> they are traversed (for example with a "for" cicle, regarding gptrarray) the
>>> order may be not the same when elements are inserted
>> 
>> GPtrArray preserves the order of insertion — it's an array, after all.
>> Why do you think it does not?
> 
> it is written on the help
> 
> https://developer.gnome.org/glib/stable/glib-Pointer-Arrays.html
> 
> "If you remove elements from the array, elements at the end of the array are 
> moved into the space previously occupied by the removed element. This means 
> that you should not rely on the index of particular elements remaining the 
> same."
> 

Elements plural here.

The order of elements in a pointer array are preserved and do not change, the 
above comment only points out that arrays do not become "sparse" when removing 
elements. A given index cannot be expected to be valid after removing elements.

Cheers,
-Tristan

> 
> may be also other data type makes the same thing? i didn't find reference 
> about that
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Template Widgets inside another GtkBuilder file

[Tristan Van Berkom]

On Sat, Oct 3, 2015 at 10:14 AM, Victor Aurélio Santos 
 wrote:

How can I do that ?
Just build all together results in this warning:

 (ajami:3475): Gtk-CRITICAL **: Error building template class 
'AjamiMainWindow' for an instance of type 'AjamiMainWindow': Invalid 
object type 'HVMeter' on line 2


I've asked on SO[1] and got only one answer.

I stick at "_get_type" workaround/hack but I didn't like it and I
can't do the same thing in Vala (I've not found how to do the same
thing).



Hello Victor,

The regular way to do this is in fact to compile your app with 
gmodule-export-2.0.pc


I.e. adding `pkg-config --libs gmodule-export-2.0` to your link stage 
(using autotools you
would just add gmodule-export-2.0 to your regular pkg-config m4 macro 
invocations).


This indeed makes your applications global symbols visible so that they 
can be found using dlsym() on unices and other methods on other 
platforms.


Regarding the comment on the SO post, the deriving of the _get_type() 
function by the type name is not considered a heuristic but rather it 
is a standard, which is at least enforced in any code written in the 
last decade or so by way of the G_DEFINE_TYPE() macros (vala generated 
types will also comply with this standard). So, if you have a type 
which is named FooBar, and it's low level GType accessor is not 
correctly named foo_bar_get_type(), it is in fact the 
application/library code declaring the type which is at fault for not 
complying with this.


Granted, one can argument that documentation in this area is weak. Any 
other methods provided in GtkBuilder (such as overridable 
get_type_from_name() virtual methods) are specifically targeted at 
language bindings which need to resolve the type in other ways.


With all that said, it could be plausible to create some tooling 
perhaps which parses your builder files at compile time, perhaps 
generating a resource to be compiled into your app which could be 
automatically inspected at gtk_init() time, to automate the process of 
initializing the required types - and removing the requirement of 
exporting your symbols in the regular way - that's one approach I can 
imagine anyway, perhaps there are others, there would have to be 
interest and someone would of course have to write that code :)


I hope this clarifies the situation a bit more for you.

Best,
   -Tristan



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

Re: GtkFileChooserDialog, Glade and header bars

[Tristan van Berkom]

> On Sep 5, 2015, at 1:09 PM, rastersoft  wrote:
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi all:
> 
> I'm using a GtkFileChooserDialog created with Glade, but I receive a
> warning when I create it:
> 
>   Warning: Content added to the action area of a dialog using
> header bars
> 
> I suspect that this is because I added Cancel and OK buttons into it
> instead of doing it in the header bar. Unfortunately I'm unable to
> modify the header bar from Glade (I have Glade 3.18.3, from Debian SID).
> 
> How can I get rid of these warnings?
> 

Hi Raster,

I wont comment on the gtk+ part except that it seems intentional that you have 
an action area or headerbar but not both simultaneously.

Glade has support for headerbar and a few others only in 3.19.x dev releases. 
Its been an unfortunate reality historically that you need a bleeding edge 
glade to work with recent gtk+ (admittedly we got further behind last year but 
we're always behind by at least one cycle at our best).

We hope to address this by rolling out self contained linux distro-agnostic 
binaries, ill see if i can roll one of those for 3.19 soon, in the meantime, 
one option is to build glade in a jhbuild sandbox to access the headerbar 
support.

Best,
-Tristan


> Thanks.
> 
> - -- 
> Nos leemos
> RASTER(Linux user #228804)
> ras...@rastersoft.com  http://www.rastersoft.com
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCgAGBQJV60wPAAoJED690wQnnlF1vgkP/0xPYc97f7vslzQWk3xNdW7H
> hVzzemuJHawqBAEc7iknG3RgRkgpU3nn1nRvBZsU1ptrbdGmy10llD/RmnG4qedt
> MAJEHKD8hlcB0zpcGMGfU4Wdq3ZsYycCTybuLMU19rtDXt1KGl97f59AaNKBwqDY
> /wQK8f9h2ETyLs1q/XvvcZRyJubc7nqR2Bz2OUurE1kpndOo+Mz7ePMfmNRP3cXE
> 8NYe2AJs7Jf7AqVJuxxDOnjYZ8tbi01cNXWV9+fTXUnlGYXqoLQ5DxwDpl9l2hkp
> HNDkGWGYwK5tuTCXY12l8U2WAyKq5G+f+o4yciMhcLqwl1wcMhXr01ew40NxF326
> fOjUpV3y/X36YWlQuWnHpCsKfmYz6cpE8uEJTzeS3w5+7Qu7vQUUAix8S+sbuBeV
> vZadR+jbqsmSREQdFVQZkcRkgRVI+RkdUbwOWPErSQD03ZJs/DO/OXg9Evu+2uDk
> 0TnktAPgPAARwlA+W3tB9GvspvpXlesxslhR8xGQuv7UnEt447JO9FAbhGtEMvtD
> oBNXu56jzhmQaslh45vIw5ihjjFPVLU2SJIRn/CRkzArDlAnYEItxvF0resM7Rmb
> o7Bw0ADeGjkt5RtkrQbXAJ9JYlEBCLI+sRRM25cIuStezKKs8nZVR2kT9mWUUVGY
> GC/lGR+jgPxWHescsb0C
> =GN6Q
> -END PGP SIGNATURE-
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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: glade3, how to get the response of GtkFileChooserDialog somwhere in my code and open a file?

[Tristan Van Berkom]

On Sat, 2015-01-17 at 00:57 -0500, Nicolas Jäger wrote:
 Hi g(tk)uys,
 
 I have a GtkFileChooserDialog with two buttons, one Open and one
 Cancel. They have the respective Response ID set to 0 and 1. So
 when I select a file and click on Open GTK sents the code 0
 somewhere, but I don't know how to get this in my code...

Hi Nicolas.

To get the response of a dialog, you should connect to
the GtkDialog::response signal[0].

For the rest of your mail, please note that you are trying
to access 'pOpenDialog' as if it were a pointer to a filechooser
dialog, however you have not assigned that pointer to anything
other than 0.

Cheers,
-Tristan

[0]:https://developer.gnome.org/gtk3/stable/GtkDialog.html#GtkDialog-response


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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 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 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 16:29 -0500, Matthias Clasen wrote:
 On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
 tris...@upstairslabs.com 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 users, switching from GtkComboBoxText to GtkCombo should be as
 simple as s/GtkComboBoxText/GtkCombo/ in their ui files.
 
 Since you are asking about discussions and conclusion, I'll state that
 in my opinion, combo boxes should not use (even less expose in the
 api) cell renderers and tree models. I believe that is pretty much
 agreed upon between most people who regularly touch GTK+ code

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote:
 I have some questions about various situations and whether or not GTK or my
 program is responsible for freeing the objects/memory in these situations.
 
 Situation 1:  I have a (visible) form, with a container, with a widget.  I
 close the form.  Are all the widgets (and the form) cleaned up?

Normally yes, this of course depends on if you are just 'hiding' the
window (afaik there is no such thing as a 'form'), or destroying the
window.

Also depends on whether you have any explicit refs to any of the
children.

 Situation 2:  I have the same as above, but the window is never shown, so
 is never closed. However, gtk_main_quit() is called.  Am I responsible for
 the cleanup of the window?  (And if I destroy the window manually, will it
 clean up all of its children?)

Yes you are responsible for destroying the window, and yes, normally it
will clean up all children.

 Situation 3:  I have a container, that has children, but that container is
 never added to a form.  Am I responsible for cleaning up the container?
 And, as above, if I destroy the container, will it clean up its children,
 or am I responsible for that?

Yes, you are responsible for g_object_ref_sink()ing, destroying that
container and then unreffing it, this is an abnormal case, and yes
it will clean up it's children.


 Situation 4:  I have a container with children (as in Situation 3), but it
 was added to a form at one point (and later removed).  Am I responsible for
 that (are we back to Situation 3 at that point?)

This depends if you held any explicit ref count to the container, if you
did not, it will automatically free itself and it's children when you
remove it from it's parent.

 With those 4 situations, is the following the correct way to clean up any
 of the objects that I am responsible for?
 
 g_object_ref_sink(G_OBJECT(widget));
 gtk_widget_destroy(widget);
 g_object_unref(G_OBJECT(widget));

This should work consistently yes.

Widgets are GInitiallyUnowned, so their ownership is consumed by
their parent widget when they are added to a parent.

The exception to the rule is GtkWindow and it's derived classes, which
is owned by GTK+'s toplevel window list, regardless of whether the
window was ever shown or not, or shown and then hidden.

Cheers,
-Tristan


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

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

On Mon, 2014-11-17 at 10:02 -0600, The Devils Jester wrote:
 I'm sorry, Form is (I believe) a holdover term from using Visual Basic over
 a decade ago.   I do mean Window when I say that.
 
 Most of those answers are what I expected except I am not sure what GTK
 considers as holding a reference.
 
 From my understanding when a widget is created it initially has a reference
 count of 1.

No, that's indicative that you have indeed not read the documentation of
GInitiallyUnowned.

As I mentioned in the previous mail, GtkWidget is GInitiallyUnowned,
which means it is initially created with no hard reference, and only
a floating reference.

Best,
-Tristan

   If you add it to a container, the container sinks that
 reference  (so it's now at 0).  When the container is destroyed it calls
 destroy on its children (which deletes them if the reference count is
 zero).  If I float the reference count manually, then the widget (and it's
 children if it's a container) won't be destroyed.
 
 When you say holding a reference,  do you mean something that has manually
 increased the reference count?
 On Nov 17, 2014 9:33 AM, Tristan Van Berkom tris...@upstairslabs.com
 wrote:
 
  On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote:
   I have some questions about various situations and whether or not GTK or
  my
   program is responsible for freeing the objects/memory in these
  situations.
  
   Situation 1:  I have a (visible) form, with a container, with a widget.
  I
   close the form.  Are all the widgets (and the form) cleaned up?
 
  Normally yes, this of course depends on if you are just 'hiding' the
  window (afaik there is no such thing as a 'form'), or destroying the
  window.
 
  Also depends on whether you have any explicit refs to any of the
  children.
 
   Situation 2:  I have the same as above, but the window is never shown, so
   is never closed. However, gtk_main_quit() is called.  Am I responsible
  for
   the cleanup of the window?  (And if I destroy the window manually, will
  it
   clean up all of its children?)
 
  Yes you are responsible for destroying the window, and yes, normally it
  will clean up all children.
 
   Situation 3:  I have a container, that has children, but that container
  is
   never added to a form.  Am I responsible for cleaning up the container?
   And, as above, if I destroy the container, will it clean up its children,
   or am I responsible for that?
 
  Yes, you are responsible for g_object_ref_sink()ing, destroying that
  container and then unreffing it, this is an abnormal case, and yes
  it will clean up it's children.
 
 
   Situation 4:  I have a container with children (as in Situation 3), but
  it
   was added to a form at one point (and later removed).  Am I responsible
  for
   that (are we back to Situation 3 at that point?)
 
  This depends if you held any explicit ref count to the container, if you
  did not, it will automatically free itself and it's children when you
  remove it from it's parent.
 
   With those 4 situations, is the following the correct way to clean up any
   of the objects that I am responsible for?
  
   g_object_ref_sink(G_OBJECT(widget));
   gtk_widget_destroy(widget);
   g_object_unref(G_OBJECT(widget));
 
  This should work consistently yes.
 
  Widgets are GInitiallyUnowned, so their ownership is consumed by
  their parent widget when they are added to a parent.
 
  The exception to the rule is GtkWindow and it's derived classes, which
  is owned by GTK+'s toplevel window list, regardless of whether the
  window was ever shown or not, or shown and then hidden.
 
  Cheers,
  -Tristan
 
 
 
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

On Tue, 2014-11-18 at 01:05 +0900, Tristan Van Berkom wrote:
 On Mon, 2014-11-17 at 10:02 -0600, The Devils Jester wrote:
  I'm sorry, Form is (I believe) a holdover term from using Visual Basic over
  a decade ago.   I do mean Window when I say that.
  
  Most of those answers are what I expected except I am not sure what GTK
  considers as holding a reference.
  
  From my understanding when a widget is created it initially has a reference
  count of 1.
 
 No, that's indicative that you have indeed not read the documentation of
 GInitiallyUnowned.
 
 As I mentioned in the previous mail, GtkWidget is GInitiallyUnowned,
 which means it is initially created with no hard reference, and only
 a floating reference.
 
 Best,
 -Tristan
 
If you add it to a container, the container sinks that
  reference  (so it's now at 0).  When the container is destroyed it calls
  destroy on its children (which deletes them if the reference count is
  zero).  If I float the reference count manually, then the widget (and it's
  children if it's a container) won't be destroyed.

As an additional note, this is also a misconception of
gtk_widget_destroy().

gtk_widget_destroy() actually has no effect on the reference count, it
emits a signal which must be trapped by any code segment which holds a
strong reference to the said widget (this is the contract of any object
which holds a reference to a GtkWidget, it must unref at destroy
time).

A GtkContainer holds a strong reference to all of it's children, so
when a child is destroyed, it is automatically removed from the
container (that's the container's responsibility) - removing the
child from the container in turn, releases the container's strong
reference to that child.

The destroy signal also results in destroy being emitted on
all of the destroyed container's children.

Note that any GObject cannot exist with a ref count of 0, an object
is disposed and finalized when it's ref count reaches 0.

Cheers,
-Tristan

  
  When you say holding a reference,  do you mean something that has manually
  increased the reference count?
  On Nov 17, 2014 9:33 AM, Tristan Van Berkom tris...@upstairslabs.com
  wrote:
  
   On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote:
I have some questions about various situations and whether or not GTK or
   my
program is responsible for freeing the objects/memory in these
   situations.
   
Situation 1:  I have a (visible) form, with a container, with a widget.
   I
close the form.  Are all the widgets (and the form) cleaned up?
  
   Normally yes, this of course depends on if you are just 'hiding' the
   window (afaik there is no such thing as a 'form'), or destroying the
   window.
  
   Also depends on whether you have any explicit refs to any of the
   children.
  
Situation 2:  I have the same as above, but the window is never shown, 
so
is never closed. However, gtk_main_quit() is called.  Am I responsible
   for
the cleanup of the window?  (And if I destroy the window manually, will
   it
clean up all of its children?)
  
   Yes you are responsible for destroying the window, and yes, normally it
   will clean up all children.
  
Situation 3:  I have a container, that has children, but that container
   is
never added to a form.  Am I responsible for cleaning up the container?
And, as above, if I destroy the container, will it clean up its 
children,
or am I responsible for that?
  
   Yes, you are responsible for g_object_ref_sink()ing, destroying that
   container and then unreffing it, this is an abnormal case, and yes
   it will clean up it's children.
  
  
Situation 4:  I have a container with children (as in Situation 3), but
   it
was added to a form at one point (and later removed).  Am I responsible
   for
that (are we back to Situation 3 at that point?)
  
   This depends if you held any explicit ref count to the container, if you
   did not, it will automatically free itself and it's children when you
   remove it from it's parent.
  
With those 4 situations, is the following the correct way to clean up 
any
of the objects that I am responsible for?
   
g_object_ref_sink(G_OBJECT(widget));
gtk_widget_destroy(widget);
g_object_unref(G_OBJECT(widget));
  
   This should work consistently yes.
  
   Widgets are GInitiallyUnowned, so their ownership is consumed by
   their parent widget when they are added to a parent.
  
   The exception to the rule is GtkWindow and it's derived classes, which
   is owned by GTK+'s toplevel window list, regardless of whether the
   window was ever shown or not, or shown and then hidden.
  
   Cheers,
   -Tristan
  
  
  
  ___
  gtk-app-devel-list mailing list
  gtk-app-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 
 ___
 gtk-app-devel-list

Re: Widget sizing?

[Tristan Van Berkom]

On Sat, 2014-11-15 at 15:38 -0600, The Devils Jester wrote:
 A GtkLayout does not seem to work, it seems that it does indeed request the
 size of its children, so that if I put a GtkLayout inside a GtkWindow, and
 I size the GtkLayout to a specific size, then I cant resize the window
 smaller than that.

The *I size the GtkLayout to a specific size* is where things go awry.

Use less restrictive API, one that does not force a size, like for
example; gtk_window_set_default_size().

As its not clear to me *exactly* what you want to accomplish with this,
I'm not exactly certain GtkLayout is the behavior you want (maybe you
want to resize and reposition children according to a given aspect
ratio or something ? clipping sounds like a bad idea, and is correct
for GtkLayout because it's intended to be used inside a
GtkScrolledWindow).

Cheers,
-Tristan


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

Re: Flowbox: widget expanding

[Tristan Van Berkom]

On Wed, 2014-11-05 at 10:56 +0100, Cedric Bellegarde wrote:
 Here the code:
 
First, please remember to Reply-All or reply to the list, this is not
a private discussion I'm having.

 #!/usr/bin/python
 from gi.repository import Gtk
 
 
 win = Gtk.Window()
 flow = Gtk.FlowBox()
 b1 = Gtk.Button(plop)
 b1.set_property(vexpand, False)
 flow.set_property(vexpand, False)
 flow.insert(b1, -1)
 win.add(flow)
 win.connect(delete-event, Gtk.main_quit)
 win.show_all()
 Gtk.main()

When you say that a widget will not 'expand', it means that it does not
want any of the left over space beyond it's request which is left over
from that widget's siblings.

If there is only one widget, or if none of the siblings ask to expand,
then it is the same as all widgets expanding and extra space will be
distributed evenly.

By default the halign and valign properties are set to GTK_ALIGN_FILL,
which means after the parent has decided on the space to allocate it's
child, that child will 'fill' the allocated space.

You can either add siblings which do expand to your UI, in which case
any extra space will only be given to widgets which do expand, or
alternatively you can accept that the single button in the UI you've
created will receive all the space, and tell it how to align itself
in the allocated space using the haligh/valign properties.

Cheers,
-Tristan


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

Re: Can put a GtkLayout in a GtkListBox

[Tristan Van Berkom]

On Wed, 2014-11-05 at 13:08 +0100, Cedric Bellegarde wrote:
 Hello, in this code, adding a layout to a GtkListBox do not show layout 
 content :(
 
 What am i missing?
 

A GtkLayout is like a GtkViewport which you can place widgets at
specific locations and draw on etc, it has the special property
that it does not require space (typically it's used in a scrolled
window).

The reason you would not see the label would be that the layout
does not have any specific size request and as such does not get
allocated any space, so anything packed inside it would be clipped
away from view.

Cheers,
-Tristan

 regards,
 
 from gi.repository import Gtk
 
 class mywindow(Gtk.Window):
 
 def __init__(self):
 Gtk.Window.__init__(self, title=Hello)
 box = Gtk.ListBox()
 label = Gtk.Label(Hello)
 label2 = Gtk.Label(Hello2)
 layout = Gtk.Layout()
 layout.put(label, 0, 0)
 box.add(layout)
 box.add(label2)
 self.add(box)
 
 win = mywindow()
 win.connect(delete-event, Gtk.main_quit)
 win.show_all()
 win.resize(300, 300)
 Gtk.main()
 
 --
 Cédric Bellegarde
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: Flowbox: widget expanding

[Tristan Van Berkom]

On Tue, 2014-11-04 at 08:57 +0100, Cedric Bellegarde wrote:
 Hello,
 
 i'm looking for a way to stop widgets vertically expand in a 
 gtkflowbox()...
 
 Look at exemple, if you resize the window, button gets vertical space...

I'm afraid you must have forgotten to attach the example, or
perhaps it just did not make it to the list.

Cheers,
-Tristan


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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 module
 | 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 module
 | 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 module
 | 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 module
 | 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 module
 | 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: nuts!

[Tristan Van Berkom]

On Tue, Jul 29, 2014 at 6:36 AM, Chris Vine 
ch...@cvine.freeserve.co.uk wrote:

On Mon, 28 Jul 2014 23:00:34 -0700
Gary Kline kl...@thought.org wrote:
 while I can create several {N} labels, they print centered.  how do 
I 
 get the labels to print from the left side of the window widget:



Use 'gtk_misc_set_alignment(GTK_MISC(label), 0, 0.5)' to align left,
and 'gtk_misc_set_alignment(GTK_MISC(label), 1, 0.5)' to align right.
For multi-line labels, you would also want to call gtk_set_justify().




Note that since GTK+-3.0 there are the 'halign' and 'valign' properties
of GtkWidget which accomplish the same as setting the GtkMisc alignment
properties.

These are preferred and the GtkMisc API, while not officially 
deprecated,

is not recommended for use in new code[0].

Instead, you should be able to use:
  gtk_widget_set_halign (label, GTK_ALIGN_START);


This should align whatever widget to the left of the available space for
the given widget (or to the right in RTL mode) - this API can also be 
used

for any widget (it is not limited to GtkMisc derived widgets).

Cheers,
   -Tristan

[0]: https://developer.gnome.org/gtk3/stable/GtkMisc.html




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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 michael.u.santi...@gmail.com 
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 murr...@murrayc.com 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
 
 screenshot_label_alignment_in_sizegroup.png
 ___
 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: How to do backend-per-process with GDBus properly

[Tristan Van Berkom]

Hi Milan,

On Fri, 2014-05-30 at 17:34 +0200, Milan Crha wrote:
[...]
In case of another client trying to open a different backend, the steps
 above will look the same, only the factory will open a new 
subprocess.

 The subprocess part makes it complicated, because:
 a) the needed D-Bus interface moved from the factory process to the
 subprocess
 b) there can be multiple subprocesses running at the same time, while
 the old behaviour made sure that only one factory was running all the
 time.
 
 Fidencio (he's working on this) managed to write some basic code

 changes, but they do not fully work. GDBus currently claims that the
 required interface is not available. We may probably miss something
 obvious to someone more knowledgeable in GDBus, thus I do not want 
to go
 too deep into detail now, I'd rather appreciate an advice, a 
direction

 where to look and how to cover the above described scenario properly.
 
I think we're missing a bit of detail here, when you say another client

trying to open a different backend, do you really mean a different
backend ? or the same backend on a different persistence (i.e. in EDS,
the same backend for a separate ESource) ?

From what I understand, the same interface can be exported on the same
D-Bus 'bus' as many times as you want, provided that they are exported
on different paths - however I may be missing something as well, there
may be a rule about one process being the 'provider' of a given
interface and perhaps in a D-Bus session environment, there can only be
one 'provider' of a given entity, regardless of how many paths it's
exported on (This might be a logical restriction in the D-Bus design, as
it would reduce the possibility of deadlocking processes which make
D-Bus method calls to eachother). And indeed, the way that the D-Bus
bus concept includes the concept of name owners seems to imply that
an interface can only be implemented by a single client (and this is
where I think your multiple-process approach is breaking down).

That said, there is a flaw (IMO) in the way EDS uses D-Bus from the
beginning, and fixing that flaw may well be the answer which also fixes
this issue. The flaw I'm referring to is that EDS does not create any
GDBusServer instance for it's backends, meaning every client
communicates with EDS indirectly and over the session bus, while that is
only necessary for the client instantiation (i.e. opening a connection
to a backend should return a D-Bus address to a running D-Bus server,
instead of an object path).

So while currently we have this pattern:
~~~

e_book_client_connect()
 - D-Bus Server (send)
 - EDS Factory (return object path of the D-Bus Client/EDS Backend)
 - D-Bus Server (receive)
Return from e_book_client_connect()

e_book_client_get_contacts()
 - D-Bus Server (send)
 - EDS Factory (backend creates huge list of contacts)
 - D-Bus Server (receive payload, choking up the session bus)
Return from e_book_client_get_contacts()


We should instead have this pattern:
~~~

e_book_client_connect()
 - D-Bus Server (send)
 - EDS Factory (return D-Bus address of the D-Bus Server/EDS Backend)
 - D-Bus Server (receive)
Return from e_book_client_connect()

e_book_client_get_contacts ()
 - EDS Backend creates huge list of contacts
Return from e_book_client_get_contacts()


With the second pattern, each running EDS backend *is* a D-Bus server
instance with it's own D-Bus address, in which case:

 a.) EDS does not slow down the session bus by pushing payloads
 through it (the session bus is only used to obtain the D-Bus
 address of a running backend)

 b.) Pushing and receiving batches to and from EDS is faster, no
 middle man is needed

 c.) There can be fuss about each backend providing the same interface
 at one or more object path, because each backend is it's own
 encapsulated D-Bus environment and they don't compete for the
 interface name in the session bus

This is something I've recommended before and we've discussed on IRC
also, I don't think it would be very complicated to do especially if you
are already trying to split the backends into separate processes. I also
suspect that this approach will fix the problem you've stated in this
email, if I've interpreted it correctly ;-)

Hope this is of some help,

Cheers,
   -Tristan

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

Re: When to free GtkBuilder

[Tristan van Berkom]

On 2014-04-18, at 10:31 AM, Tristian Celestin tristian.celes...@outlook.com 
wrote:

 Is it necessary to keep a GtkBuilder object around once I've obtained 
 references to relevant widgets and connected the widgets to handlers?

No, there is no reason to keep the builder object alive after that point - some 
existing code does that just because it enjoys calling calling 
gtk_builder_get_object() a lot - no other reason.

Cheers,
-Tristan


 Lots of code I've seen doesn't free the builder after it's been instantiated, 
 such as in this example: 
 https://github.com/chergert/custom-gtk-widgets/blob/master/eggpanel/main.c
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Redistribution of GTK DLLs

[Tristan Van Berkom]

On Wed, 2014-03-05 at 17:13 +1100, Chris Angelico wrote:
 On Wed, Mar 5, 2014 at 12:27 PM, Daniel Kasak d.j.kasak...@gmail.com wrote:
  If you're in doubt, I think the best way to do this is to distribute things
  separately. Just make an installer / updater for the GTK libs ( that would
  be handy, by the way ... oh and if you build some Windows themes, *please*
  distribute these too ). Then in your MIT licensed app, say You'll need GTK
  libs ... and an installer / updater exists at location blah.
 
 So, effectively, I make a separately-downloadable thing that I'd
 license more restrictively than the rest of my app. Hmm. Seems an odd
 way to do things.

Personally I wouldnt like to do it this way either, on win32 I would
rather not trust DLL sharing - and rather just pack everything into
the same bundle and run it, avoiding any possible binary
incompatibilities which might otherwise creep in.

I don't believe that your MIT licensing problem is any different than
a proprietary license for your app, at least with regards to the
usage of LGPL libraries.

I.e. using LGPL libraries does not infect the calling code which
links these libraries in with the GPL contagion - what is required
is that if you do distribute these libraries in compiled form, you
must also make available those LGPL sources which were used to build
those said libraries.

Since these particular LGPL sources are already made available by
other parties (i.e. GTK+  friends by GNOME etc) - I believe
that you do not need to host these files directly - but must somehow
at least link to these sources when distributing your app, possibly
in your application release notes, on your website if any, and
ideally in some text which reaches those people you distribute software
to (I.e. perhaps in a GtkAboutDialog somewhere it would be prudent to
mention that the application is built with LGPL libraries which are
available at some specific location).

I am not a lawyer either, but this is my understanding of the issue.

Cheers,
-Tristan


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


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

Re: GTK signals question.

[Tristan Van Berkom]

On Wed, 2014-03-05 at 18:01 +1100, Chris Angelico wrote:
 On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote:
  I'm writing an app, that among a lot of other stuff, has three mutually
  interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
  then updates values in B and C.  B and then would try to update A, and C,
  etc., resulting in a bottomless recursion.  So, what I need to do is, while
  I'm in A's callback, block the B and C callbacks; while in in B, block A and
  C and so on.
 
 Are you simply setting the three to the same value? If so, just check
 first to see if it's already that value, and if it is, don't set it.
 That's a technique that's worked for me since my earliest GUI
 programming days on VX-REXX... great system, that, pity it's bound to
 the obscure and forgotten platform of OS/2! :)

In case this is of any help, the GtkAdjustment::value-changed signal
does this check for this exact reason (to avoid some unneeded feedback
when the value has not actually changed).

Cheers,
-Tristan

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


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

Re: GTK signals question.

[Tristan Van Berkom]

On Wed, 2014-03-05 at 02:20 -0500, Chris Moller wrote:
 On 03/05/14 02:01, Chris Angelico wrote:
  On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote:
  I'm writing an app, that among a lot of other stuff, has three mutually
  interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
  then updates values in B and C.  B and then would try to update A, and C,
  etc., resulting in a bottomless recursion.  So, what I need to do is, while
  I'm in A's callback, block the B and C callbacks; while in in B, block A 
  and
  C and so on.
  Are you simply setting the three to the same value? If so, just check
  first to see if it's already that value, and if it is, don't set it.
  That's a technique that's worked for me since my earliest GUI
  programming days on VX-REXX... great system, that, pity it's bound to
  the obscure and forgotten platform of OS/2! :)
 
 No, they're not the same value.  They're all for setting an angle, in 
 radians, pi-radians, and degrees, and I want the user to be able to set 
 the angle in any unit and have the equivalent angle in the other units 
 show up in the other spinbuttons.

Interesting, if I were you I would try to share the same adjustment
between all of your views.

I.e. I would keep the adjustment in the finest grained unit of each
unit you want to display, and have your spin buttons format the value
differently depending on what they are used for (or perhaps use GtkScale
if that makes sense in your UI).

The idea of multiple GtkAdjustments holding separate values when you
really only want a single value that is displayed differently by
different widgets - is a bit maddening.

Note that this might prove challenging with the way GtkAdjustment is
designed, I was just speculating that this approach of multiple
adjustments is not ideal... ideally these views should share the
same value.

Cheers,
-Tristan


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


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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: Using a TextView as a sort of Hbox with wrapping

[Tristan Van Berkom]

On Tue, 2014-01-28 at 01:56 +1100, Chris Angelico wrote:
 On Tue, Jan 28, 2014 at 1:30 AM, Tristan Van Berkom
 tris...@upstairslabs.com wrote:
  You can get the behavior you are looking for with EggWrapBox:
https://git.gnome.org/browse/libegg/tree/libegg/wrapbox
 
  Just copy the eggwrapbox.[ch] and compile it as a part of your
  code (or compile a libegg separately and link to it if LGPL is
  a problem for you).
 
 That looks fairly decent! Unfortunately I can't compile in extra C
 code (I'm doing this in a high level language, Pike, and I want this
 to work on an unmodified install of Pike - I do build my own Pike on
 Linux, but my clients generally use a pre-built), so I can't use this
 directly. And... that is a LOT of code (2641 lines), though a lot of
 it looks like stuff that would be way shorter in a high level
 language. I don't know that I want to port it to Pike, even if it's
 possible to do that.
 
 But it does look good, and it answers the big question (I can't be
 the first person to want this, so what did other people do?).
 
  ... also the EggWrapBox
  handles height-for-width geometry well for it's children,
  while textview itself does some height-for-width, I'm not
  sure it is done well for embedded child widgets
 
 What do you mean by height-for-width here? I just tried on GTK
 2.24.10 on Windows and it failed to wrap the way I expected, so I'm
 not sure what's going on (the same version of GTK on Linux worked
 fine). Is that the sort of issue you mean?

Sorry I did not take into account that you were working with the
GTK+2 library and not GTK+3.

height for width is a geometry management system which says to
the widget:
  o What is your minimum width and what is your natural width ?
  o Oh... so you can fit into 40 pixels but you would prefer 80 !
  o Ok I've decided that, taking into account all horizontal space, you
will receive 60 pixels in width, how much height do you need for
a width of 60 pixels ?
  o Ah, you want 20 height ? we're done here, you will receive 60 
pixels in width and 20 pixels in height.

This geometry management is more complex than just:
what is your width  height
but allows dynamic content such as wrapping labels to unwrap
and fit the window allocation, leaving more vertical space
for other widgets above or below a wrapping label which might
desire that space.

GtkTextView had it's own way of doing height-for-width internally,
insomuch that it would eventually ask for enough height to fit the
wrapping text into whatever width you had given it.

GTK+3 has this geometry management built-in, but GTK+2 does not
(so doing things like EggWrapBox with GTK+2 is more tricky).

If you are stuck with GTK+2, I suggest you take a look into
GtkToolPalette, you might be able to trick your statusbar
items into being GtkToolItems and use the wrapping behaviour
of GtkToolPalette to achieve the same effect (or at least use
some prior art in there, I think you are stuck with the
expanders if you use GtkToolPalette directly... GtkToolItemGroup
would have the precise code you are looking for).

Cheers,
-Tristan

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


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

Re: Using a TextView as a sort of Hbox with wrapping

[Tristan Van Berkom]

On Mon, 2014-01-27 at 03:49 +1100, Chris Angelico wrote:
 On Mon, Jan 27, 2014 at 3:43 AM, James Tappin jtap...@gmail.com wrote:
If I interpret what you are trying to do correctly (not necessarily a
  given), then I would have thought that GtkScrolledWindow (possibly in
  conjunction with GtkViewport) would be the tool for the job.
 
 Not scrolling, wrapping. The window might be large enough to hold all
 the statusbar entries (and I expect that it normally will be), but if
 it's not, I would prefer the more graceful degradation of doubling the
 height of the status bar and moving the excess to a new row rather
 than widening the window. Scrolling would force the user to
 consciously manipulate the status bar, which is contrary to its goal
 of being subtle and just there. Suddenly expanding to double its
 normal height isn't perfect either, but maybe someone will actually
 want it to be taller, who knows.
 
 I could use a Table, or a Vbox with multiple Hboxes in it, but then
 I'd need to decide in advance which elements drop to the next row. I
 want it to be automatic: if there's room, use one row, otherwise wrap
 to a second (and third, and fourth, if necessary, but I would hope
 that's never the case!).

You can get the behavior you are looking for with EggWrapBox:
  https://git.gnome.org/browse/libegg/tree/libegg/wrapbox

Just copy the eggwrapbox.[ch] and compile it as a part of your
code (or compile a libegg separately and link to it if LGPL is
a problem for you).

EggWrapBox has been modified and added to GTK+ as GtkFlowBox,
however the GTK+ version is lacking the primary feature that
you want, i.e. children do not wrap freely but instead they
are forced to appear in columns.

Perhaps if you use the EggWrapBox and prove to the GTK+ team
that the free-form wrapping is useful and important, we can
get the free flowing behavior back into GtkFlowBox.

FWIW I would certainly rather use the EggWrapBox widget for
the purpose you describe rather than to repurpose a GtkTextView
for that (the text view is much more complex for such a
simple purpose as wrapping widgets - also the EggWrapBox
handles height-for-width geometry well for it's children,
while textview itself does some height-for-width, I'm not
sure it is done well for embedded child widgets).

Cheers,
-Tristan

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


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

Re: Using a TextView as a sort of Hbox with wrapping

[Tristan Van Berkom]

On Tue, 2014-01-28 at 03:08 +1100, Chris Angelico wrote:
 On Tue, Jan 28, 2014 at 3:00 AM, Tristan Van Berkom
 tris...@upstairslabs.com wrote:
  Sorry I did not take into account that you were working with the
  GTK+2 library and not GTK+3.
 
 Ah, I should have mentioned, sorry. There has been talk of supporting
 GTK3 in Pike, but I won't move to it till I can confidently expect
 that my clients will have it. (It's kinda weird. I'm using a language
 that's more designed for servers - web servers, MUD servers, and so on
 - and writing a client in it. More often than you might think, I run
 into Pike bugs and have to fix them before I can move on. Fortunately
 it's an open source language!)
 
  height for width is a geometry management system which says to
  the widget:
o What is your minimum width and what is your natural width ?
o Oh... so you can fit into 40 pixels but you would prefer 80 !
o Ok I've decided that, taking into account all horizontal space, you
  will receive 60 pixels in width, how much height do you need for
  a width of 60 pixels ?
o Ah, you want 20 height ? we're done here, you will receive 60
  pixels in width and 20 pixels in height.
 
  This geometry management is more complex than just:
  what is your width  height
  but allows dynamic content such as wrapping labels to unwrap
  and fit the window allocation, leaving more vertical space
  for other widgets above or below a wrapping label which might
  desire that space.
 
 Ah, gotcha. That makes a lot of sense, since there'll be a good few
 widgets that can wrap like that.
 
  GtkTextView had it's own way of doing height-for-width internally,
  insomuch that it would eventually ask for enough height to fit the
  wrapping text into whatever width you had given it.
 
 That's actually the exact behaviour I want here. The status bar will
 fill whatever width the window is sized to, and then I want it to
 claim as much or as little height as it needs. (The bulk of the
 window's height is taken up with a ScrolledWindow, so it makes little
 difference to the layout if there's another row of status.)
 
  GTK+3 has this geometry management built-in, but GTK+2 does not
  (so doing things like EggWrapBox with GTK+2 is more tricky).
 
  If you are stuck with GTK+2, I suggest you take a look into
  GtkToolPalette, you might be able to trick your statusbar
  items into being GtkToolItems and use the wrapping behaviour
  of GtkToolPalette to achieve the same effect (or at least use
  some prior art in there, I think you are stuck with the
  expanders if you use GtkToolPalette directly... GtkToolItemGroup
  would have the precise code you are looking for).
 
 Yeah, I looked into that, but wasn't able to make it do what I wanted.
 I'll give that another shot tomorrow; it might be better suited to
 what I'm trying to do (especially if it works properly on Windows and
 Mac). It's called GTK2.Toolbar in Pike, but I'm assuming that's the
 same thing as GtkToolPalette.

No, GtkToolbar != GtkToolPalette, they are separate things.

The GtkToolPalette is what we use in Glade to show all the
widget icons for example - there is a demo of it if you run
gtk-demo you should be able to see it in action, and I'm quite
sure that it exists in one of the later versions of GTK+2
(it should really be there in 2.24).

Cheers,
-Tristan

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


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

Re: Sorting a TreeView with Glade/GtkBuilder

[Tristan Van Berkom]

On Thu, 2013-12-26 at 09:34 -0600, Craig wrote:
 Hello,
 
 I was wondering how I could sort a liststore-based treeview in glade? I've
 already set all columns' sort column id, but that apparently doesn't
 initiate the sorting behavior.
 
 Basically, I have a boolean/toggle column and then a text column and I want
 to sort by the toggle column. Any suggestions?

I don't think it's possible with only property settings.

I think that you can get away with defining all the properties
in Glade and after building the UI you will at least have to 
call gtk_tree_sortable_set_sort_func() or
gtk_tree_sortable_set_default_sort_func() on the liststore to provide
a sort function.

Cheers,
-Tristan


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


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

Re: GtkTreeView isn't updating when GtkListStore appended and set

[Tristan Van Berkom]

On Sat, 2014-01-04 at 23:46 -0600, Michael Cronenworth wrote:
 On 01/04/2014 05:21 PM, Jordan H. wrote:
  In Glade I've defined column 0 in the list store as a gchararray
  cell. I even tried forcing the assignment of GtkListStore to GtkTreeView
  (knowing full well I wouldn't need to) to no avail.
 
  I don't get any errors, but the GtkTreeView doesn't reflect the changes
  made to the GtkListStore. Any suggestions? Thanks in advance!
 
 I haven't used Glade/GtkBuilder, but I'm not sure if it automatically assigns 
 the ListStore column to the TreeView like you are thinking. You can make sure 
 by 
 calling a few functions.
 
 gtk_tree_view_set_model( tree_view, GTK_TREE_MODEL( list_store ) );
 gtk_tree_view_column_add_attribute( column, cell, text, 0 );
 // 0 being the column you want to assign to the column in the GtkTreeView

The treeview editor does indeed set these attributes for you and
GtkBuilder properly sets them up.

If you've declared the liststore with Glade before adding your cell
renderers then Glade should let you set the column by name, even
(Glade saves 'named' columns of the liststore in the form of xml
comments, even if columns names are not a part of the GtkTreeModel 
API). 

Jordan, can your provide some more information ?

For instance, are you certain that the treeview is not updating
at the time you append only ? or is it not showing any of the data
you added to the liststore at all ?

Can you also show us the Glade file in question so I can see if
it's indeed setup properly ?

Also, instead of using GtkBuilder API directly (and even worse,
needlessly keeping a GtkBuilder instance around for the life cycle
of your UI component), please consider using the composite templates
features introduced in GTK+ 3.10, it's a much cleaner way of using
GtkBuilder (but only available in 3.10 so that might still be an
issue for you)

See this file for a quick example of a dialog:
https://git.gnome.org/browse/glade/tree/src/glade-preferences.c#n172

For more info on how composite templates work, see these posts:
Vala:http://blogs.gnome.org/tvb/2013/05/29/composite-templates-lands-in-vala/
C:http://blogs.gnome.org/tvb/2013/04/09/announcing-composite-widget-templates/

Cheers,
-Tristan

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


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

Re: Best practice query: Entry field user's done editing handling?

[Tristan Van Berkom]

On Mon, 2013-12-23 at 09:41 +, Phillip Wood wrote:
 On 16/12/13 21:27, Chris Angelico wrote:
 
  I have a form with a whole pile of entry fields (GTK2.Entry), and I
  need to do some processing (and save the edit) whenever the user's
  edited a field and is now done editing. Is there a standard way to
  recognize this? I'm thinking of something like the VX-REXX Verify
  event, which fires on a changed entry field when focus moves to
  another control on the same window, but not if focus moves to another
  window altogether.
 
  Currently, I'm hooking focus-out-event signals and checking the
  current text to see if it differs from a saved copy of the text. I'd
  rather not save every time a 'changed' signal comes through, as that
  would be hopelessly inefficient most of the time.
 
 In your focus-out handler you can call gtk_widget_is_focus on the entry, 
 if it returns true then the focus has passed to another window and you 
 don't need to do anything. If it returns false then it's possible that 
 the user has popped up the context menu rather than moved to a different 
 control in the same window. Keeping track of this is a bit more 
 complicated. You need to connect to the popup-menu signal with the 
 entry as the user_data and do something like
 
 g_object_set_data (G_OBJECT(entry), in-popup, G_INT_TO_POINTER(TRUE));
 g_signal_connect (menu, unmap, on_menu_unmap, entry);
 
 in on_menu_unmap
 g_object_set_data (G_OBJECT(entry), in-popup, G_INT_TO_POINTER(FALSE));
 g_object_set_data (G_OBJECT(entry), popdown-id, G_UINT_TO_POINTER 
 (g_timeout_add (500, popdown_cb, entry)));
 
 in popdown_cb
 if (!gtk_widget_is_focus(entry))
do_processing
 
 In the focus out handler you can check in-popup for the entry, you 
 should also remove the timeout function to avoid doing the processing 
 twice. The timeout ensures that if the user transfers the focus from the 
 context menu directly to another control you still save the result. 
 Gnome shell seems to prevent the user from doing that but other window 
 managers may not. This is the scheme that GtkCellRendererText uses to 
 keep track of the context menu.

It's my understanding that committing user data in a focus-out handler
is a common mistake, and it will bite you with multiple toolkits, not
only GTK+.

In Glade we avoid this, primarily because of scenarios such as the
following:

  o User selects widget in the workspace (or inspector treeview)
  o This causes the property editor to show up, containing some entries
  o The user then modifies an entry (let's imagine we're naive and
ignore the new text in the entry)
  o Then the user goes ahead and selects another widget, user is happy,
they changed the entry value and expect it to persist.
  o Selecting the new widget will cause a new set of properties to be
loaded up in the property editor, the old property editor
will be detached from the GladeWidget it was editing (i.e. the
view/controller is detached from the model, something new is loaded)
  o All of the above happens over the course of selecting a new
widget, typically this is a mouse click... what happens next ?
  o A new focus widget is set and the old entry receives a focus out
event

We don't want to be chasing down scenarios where this could possibly
break, so the best thing we can do is commit everything immediately
(you could have an asynchronous layer in your data model which handles
this, if performance or flash wear is an issue).

Another existing bug, along the same parallel, is values committed in
cell renderers. The user doesnt always know they need to press Enter
or somehow cause the edited signal to fire on a cell renderer, we
continuously receive bug reports related to I entered a value in a cell
renderer and selected something else, Glade doesnt remember the value
I put in the cell renderer.

I strongly advise against usage of focus out events for committing
data, if your application is simple enough now that it doesnt cause
problems, it will certainly cause you problems later as your
application gains complexity.

Cheers,
 -Tristan


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

Re: FW: Question About Creating Composite Widget Template

[Tristan Van Berkom]

On Fri, Oct 25, 2013 at 3:47 AM, Tristian Celestin
tristian.celes...@outlook.com wrote:
 I created a composite widget template with Glade, and now I am binding all 
 the children in the composite widget template to private data members in my 
 class. When I bind one particular member, box1, I get a segfault in 
 gtk_widget_is_toplevel (widget=0x837b60) at gtkwidget.c:8474.

 If I don't bind box1, the application starts. Why would binding this child 
 cause a segfault even though it is GtkWidget, defined in channel_list.ui?

This looks like a good reason to crash:

struct _HRChannelList
{
/* private */
GtkContainer container; /* -- oops ! not big enough for a GtkBox ... */
HRChannelListPrivate *priv;
};

struct _HRChannelListClass
{
GtkBoxClass parent_class;
};

Cheers,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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 p...@philandanna.no-ip.org 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: Expander question

[Tristan Van Berkom]

Hi Robert,
   My first impression is that GtkExpander just does not support this
type of setup,
there may be some way around this but it would be a hack, the expander will
want to just eat events in the label-widget area and you will probably have to
fight the expander in order to get your events first.

But I think you can achieve what you want using GtkRevealer, if you can
have GTK+ 3.10 available to you.

Cheers,
-Tristan



On Sat, Aug 17, 2013 at 2:06 PM, Robert Roth robert.roth@gmail.com wrote:
 Hi,

 While developing an application, I have ran into the following problem:
 * I have a window with a GtkExpander on it
 * the GtkExpander's labelwidget is a container horizontal GtkBox with a
 GtkLabel and a GtkButton on it
 * the GtkButton can only be clicked on it's bottom few pixels, above that
 click is intercepted by the expander, and expands/collapses the expander
 instead of clicking the button.
 Is there a way to overcome this by returning TRUE from some kind of signal
 handler of the GtkButton to avoid the event being sent to the expander?

 Find a simple example glade UI attached, the problem can be seen by running
 glade-previewer on the UI file.

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

Re: How should I use GtkHeaderBar without having a duplicate title bar on older platforms?

[Tristan Van Berkom]

On Fri, Jul 26, 2013 at 7:27 AM, Dylan McCall dylanmcc...@gmail.com wrote:
 For my GSoC project, I'm writing an application that uses
 GtkHeaderBar. Using Gtk 3.8, with libgd as a handy drop-in replacement
 for the new features in 3.9+, it looks like this:
 http://ubuntuone.com/0cr9GKuwrbULXMmL3eExmq

From what I understand, using a GtkHeaderBar does not mean that it
will show up as a header bar for your application.

You could potentially use dozens of GtkHeaderBars, in list items
for example... but if you call gtk_window_set_titlebar() with a given
widget... that widget itself will show up in the title bar area of
the GtkWidget.

Coincidentally, a GtkHeaderBar widget happens to be a suitable
choice of widget type to use for gtk_window_set_titlebar().

Now what would make sense, is that GtkWindow probably
does not guarantee that gtk_window_set_titlebar() actually
does anything, nor does it guarantee that gtk_window_set_title()
does anything... but uses the user supplied titlebar if provided
and if there is support for client side windows in the given
platform.

Cheers,
-Tristan



 As you can see, my application ends up with the title in two places,
 and I'm not sure how best to deal with that. I imagine I can detect
 whether I'm running in an environment that does client-side
 decorations and react accordingly, but then I'm still uncertain how
 the application is supposed to handle this. Is it better if the header
 just doesn't have a title in this case, or should I do something like
 System Settings 3.8 where the window titlebar has the primary title
 and the header bar has what would be the secondary title? Is there an
 API that can deal with this for me so I don't have to keep track of
 these special cases myself?

 By the way, I'm happy depending on just Gtk 3.9+, but as I understand
 it we still have to deal with the possibility that the window may or
 may not have a titlebar provided by the window manager.

 Thanks for any help!

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

Re: Simulate mouse/button presses?

[Tristan Van Berkom]

On Wed, Jul 10, 2013 at 6:25 AM, Jim Norton jimnor...@jimnorton.org wrote:
 Greetings,

 I have some unique embedded hardware that has a touchscreen device that
 doesn't have any Linux drivers to make it appear as a mouse etc. The
 touchscreen communicates via USB using a proprietary protocol.

If you are writing for a specific hardware, then you might want to just provide
a driver for it, here is a sample touchscreen input module for you:

http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/tree/src/xf86Elo.c

If you are installing wayland or something other than X, then there's probably
a different method.

Cheers,
-Tristan


 I have built a simple WebKitGTK 1.6 web-browser running on gtk+ 2.24.14 that
 runs on the embedded hardware and receives the touchscreen touch events.

 Currently, when the user is interacting with the loaded web-page by touching
 the screen my application sees them and generates mouse button presses to be
 processed by GDK and sent to webkit using gdk_test_simulate_button(). This
 appears to work fairly well.

 However, I'm wondering if there is a better/ more proper way?

 Would using gdk_event_new() and gdk_event_put() be a better option?
 https://developer.gnome.org/gdk/unstable/gdk-Events.html#gdk-event-put

 If so can anybody provide a small sample or snippet of code that
 demonstrates how to use gdk_event_put() and setup the GdkEventButton event
 fields?

 Any advise would be appreciated.

 Thank you,
 Jim


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

Re: Expand the child in the GtkHeaderBar

[Tristan Van Berkom]

On Fri, Jul 5, 2013 at 10:55 PM, Yosef Or Boczko yosef...@gmail.com 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: gtk_print_operation_run() blocks and ignores callback

[Tristan Van Berkom]

On Thu, Jul 4, 2013 at 9:22 PM, Satz Klauer satzkla...@googlemail.com wrote:
 I want to print out some vectordata using GTK/Linux. That's what I already 
 have:


 GtkPrintOperation *op;

 op = gtk_print_operation_new();
 gtk_print_operation_set_n_pages(op, 1);
 gtk_print_operation_set_unit (op,GTK_UNIT_POINTS);
 g_signal_connect (op, draw_page, G_CALLBACK(draw_page), NULL);
 if (data-config.m_printparams==1) gtk_print_operation_run(op,
 GTK_PRINT_OPERATION_ACTION_PRINT,NULL, NULL);
 else gtk_print_operation_run (op,
 GTK_PRINT_OPERATION_ACTION_PRINT_DIALOG,NULL, NULL);

I think what you are missing here is
   gtk_print_operation_set_allow_async()

Otherwise I would expect that the print operation runs it's own
main loop and synchronously runs the operation blocking any
other events until the operation completes.

Note, I have not tried using GtkPrintOperation myself, I could
be misguided, but this seems like an obvious bet ;-)

Cheers,
-Tristan


 draw_page() of course exists as well:

 static void draw_page (GtkPrintOperation *operation,GtkPrintContext
 *context,int page_nr)
 {
GtkPrintSettings *settings;

cairo_t *cr = gtk_print_context_get_cairo_context (context);
settings = gtk_print_operation_get_print_settings (operation);
...do my printing stuff here...
 }

 Unfortunately it does not work, gtk_print_operation_run() blocks
 forever and draw_page() is never called. Any ideas what could be
 wrong?

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

Re: Stock Items Deprecation

[Tristan Van Berkom]

On Tue, Jul 2, 2013 at 10:41 PM, William Jon McCann
william.jon.mcc...@gmail.com 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: Insert Various GTKWidgets into a dlg_window

[Tristan Van Berkom]

On Sun, Jun 30, 2013 at 12:34 AM, Rui Pedro Caldeira
rpcalde...@outlook.com wrote:
 Thanks Andrew, that worked perfectly. I'm being able to put all my widgets
 into the table. But now I'm having another problem. How can I re-size the
 widgets the way I want (standard size)? Because they are taking up all the
 space in their own cell in the table [1], I've tried to add more rows, but
 the window expands and the buttons stay the same size.

Hi Rui,

With GTK+2 / GtkTable you will need to add padding widgets to take up
extra space,
if you don't want the widgets in the GtkTable to spread out and take
all available space.

This is done with the GtkAttachOptions argument to gtk_table_attach()
when adding
widgets to a GtkTable.

Here are the basic rules which apply to a GtkTable

  o If any children in a row has the GTK_EXPAND option set, then that row
 will receive some extra space when the table is allocated more space
 than it requests.

  o The same rule applies to columns, if a widget in a given column
has GTK_EXPAND
 set, then that column will receive more space than it requested.

  o If no widgets in any row specify GTK_EXPAND, then all rows expand equally

  o And again the same applies to columns, if no columns explicitly expand, they
 all expand.

So if you want all of your widgets to stay in the top / right portion
of the allocation,
then you can add a GtkLabel with no text in the last column and the
last row, and
set only those labels to expand.

Alternatively, you can pack your GtkTable into a GtkVBox or GtkHBox (which
is more typical).

Example:

  GtkVBox {
  GtkMenuBar (expand = FALSE),
  GtkScrolledWindow (expand = TRUE) {
  Some content in the scrolled window
  which would normally eat up all the extra
  vertical space
  },
  GtkTable (expand = FALSE) {
  Some buttons which will never
  receive any extra vertical space
  }
  }

I think you can extrapolate from here, the expand packing
option is what you are after, with this it's possible to create
a variety of dynamic layouts who's base size will depend
mostly on system font sizes, you just decide which elements
receive extra space when your interface receives extra space.

Cheers,
-Tristan


 Thanks in advance,
 Rui

 [1] Image - http://tinypic.com/r/sxlw0l/5

 Cumprimentos,
 Rui Pedro Caldeira


 On Sat, Jun 29, 2013 at 1:05 AM, Andrew Potter agpot...@gmail.com wrote:

 On Fri, Jun 28, 2013 at 2:10 PM, Rui Pedro Caldeira
 rpcalde...@outlook.com wrote:
  I'm sorry Andrew but I'm using GTK+ 2.24.19 and there is not GTKGrid on
 this
  version, aren't you aware of an equivalent for version 2.24.19 of GTK+?

 The documentation for Gtk2 can be found here [1]. As you've noticed,
 there is no GtkGrid in Gtk2; instead you can use a [2] GtkTable or a
 [3] GtkHBox or [4] GtkVBox.

 You may also find the Gtk 2 tutorial useful [5].

 [1] https://developer.gnome.org/gtk2/2.24/
 [2] https://developer.gnome.org/gtk2/2.24/GtkTable.html
 [3] https://developer.gnome.org/gtk2/2.24/GtkHBox.html
 [4] https://developer.gnome.org/gtk2/2.24/GtkVBox.html
 [5] https://developer.gnome.org/gtk-tutorial/stable/book1.html

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

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
m...@pietrobattiston.it 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 m...@pietrobattiston.it 
 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: gobject across network

[Tristan Van Berkom]

On Mon, Jun 17, 2013 at 1:38 AM, Emmanuele Bassi eba...@gmail.com wrote:
 hi;

 On 16 June 2013 17:24, Andrea Zagli aza...@libero.it wrote:
 is there a way to send a gobject from a server to a client via network (ex.
 via http or other protocol)?

 i want to create a gobject in a daemon in a server and pass it to a client

 if you're doing in on the same machine, then you can use DBus and the
 GDBus facilities in GIO. [0]

Also, note that GDBus does not have any requirement for usage on the
same system.

I've found gdbus-codegen to produce a very nice API, and you can use
GDBusServer directly for the server side, and export a generated
GDBusInterfaceSkeleton on any incoming client connections (clients
can also export interfaces directly onto connections which they've made
to the remote GDBusServer).

I've also found it to be quite practical to use the Avahi service discovery
library to share GDBus objects on a LAN (just tell Avahi to advertise the
tcp ip address reported by g_dbus_server_get_client_address(), and have
your clients connect to an ip/port discovered by Avahi).

Cheers,
-Tristan


 if you want to just send an object representing state from one process
 on one machine, to another process on another machine, you can
 serialize the instance on the server and deserialize it on the client;
 you can use whatever interchange format you want — I have a soft spot
 for JSON, so you can check out JSON-GLib, which has facilities for the
 serialization/deserialization passes. [1]

 if you want to invoke methods, on the other hand, you may want to have
 a look at an RPC system, like the XML-RPC API exposed by LibSoup. [2]

 ciao,
  Emmanuele.

 [0] https://developer.gnome.org/gio/stable/gdbus-convenience.html
 [1] 
 https://developer.gnome.org/json-glib/0.16/json-glib-GObject-Serialization.html
 [2] https://developer.gnome.org/libsoup/stable/libsoup-2.4-XMLRPC-Support.html

 --
 W: http://www.emmanuelebassi.name
 B: http://blogs.gnome.org/ebassi/
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freeze and long blocking operation

[Tristan Van Berkom]

On Fri, Jun 14, 2013 at 8:28 AM, Kip Warner k...@thevertigo.com wrote:
 On Thu, 2013-06-13 at 08:59 +0100, jcup...@gmail.com wrote:
 Hi Kip,

 Hey John,

 There are two easy ways to do a long operation in Python.

 First, with idle_add(). Your callback should run for no more than 50ms
 or so before returning. If you need to do more work than that, just
 wait to be called again. Do not process events, you can leave that up
 to the main loop. This style is handy for non-blocking, background
 tasks that don't need interaction from the user.

 Ok, fair enough. I didn't know idle callbacks were intended to be used
 only for fast non-blocking tasks.

 Secondly, with a regular loop that takes control for a long period.
 You can keep the GUI alive by processing events, as you say above.
 This style is better for modal actions that either block the GUI or
 may require interaction.

 So as I mentioned I tried abandoning the idle_add() approach and instead
 relied on calling the worker function directly.

 It sounds like you have done both at the same time, which seems
 confusing to me. I'd make a pure 2) one. If the GUI doesn't refresh,
 you probably have a bug in your code somewhere.

 I do this by calling the long job function directly from within the
 GtkAssistant's prepare signal callback immediately. The problem is
 that the GUI doesn't refresh throughout the duration of the long job,
 even though I do explicitly pump the message queue by calling
 _updateGUI() method regularly:

Kip,
   Let me try to illustrate what you need to do to make this work.

What you currently have is:
~

prepare_signal_callback ()
{
/* Update the GUI and flush the event queue, only once, at the
beginning of your operation */
while (gtk_events_pending())
gtk_main_iteration_do ();


/* Process some data that takes a long time, without ever again
updating the GUI */
while (there_is_data)
process_data();
}

What you need to do instead is:
~~~

prepare_signal_callback ()
{
/* Do your huge intensive loop that takes a long time */
while (there_is_data)
{
/* Process a chunk of your long data operation */
process_only_a_little_bit_of_data();

/* Every once and a while, during your huge task, be friendly
to the user and show
 * some feedback, i.e. update the GUI often enough so that
things appear to run smoothly.
 */
while (gtk_events_pending())
gtk_main_iteration_do ();

}
}

What you seem to be missing, is that GTK+ doesnt update itself in a
separate thread, your program
by default is single threaded and can only be processing data or
updating the GUI at a given time,
but not both.

If you have to call a function in a proprietary library which you
cannot modify, and that function
atomically takes a long time, the only way to keep the GUI responsive
during that time is to
add your own worker thread to call the function, and then signal the
main thread when the
operation completes (usually by queuing a g_idle_add() at the end of
your worker thread
so that the completion notification callback is queued to execute in
the main GUI thread).

Cheers,
-Tristan


 # Update the GUI...
 def _updateGUI(self):

 # Update GUI...
 (...)

 # Flush the event queue so we don't block...
 while Gtk.events_pending():
 Gtk.main_iteration()

 The GUI just appears to hang on the previously displayed page in the
 assistant and doesn't advance to the one that actually should be visible
 following the prepare signal callback.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK free function doesn't appear to have any affect.

[Tristan Van Berkom]

On Sat, Jun 15, 2013 at 12:23 AM, dE de.tec...@gmail.com wrote:
 On 06/14/13 17:02, Matthias Clasen wrote:

 On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote:

 I was monitoring the memory usage before and after execution of
 g_object_unref and gtk_list_store_clear, and it didnt change the memory
 usage by a bit.

 Is this normal (am I doing it right?)?

 What are you monitoring, and how ?

 It is i normal that freeing memory does not change the resource
 consumption of the process. The freed memory will be available for
 reuse by malloc, but malloc does not immediately return the memory to
 the OS.


 So I'll try allocating like 7GB of memory to fill up the ram, after
 finishing, it should free. I'll report back.

For more fine grained memory profiling you should use valgrind.

See some hints here for running your Glib program with valgrind:
https://live.gnome.org/Valgrind

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

Re: GTK free function doesn't appear to have any affect.

[Tristan Van Berkom]

On Sat, Jun 15, 2013 at 2:33 AM, dE de.tec...@gmail.com wrote:
 On 06/14/13 22:09, Chris Vine wrote:

 On Fri, 14 Jun 2013 21:41:05 +0530
 dEde.tec...@gmail.com  wrote:

 On 06/14/13 17:02, Matthias Clasen wrote:

 On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com  wrote:

 I was monitoring the memory usage before and after execution of
 g_object_unref and gtk_list_store_clear, and it didnt change the
 memory usage by a bit.

 Is this normal (am I doing it right?)?

 What are you monitoring, and how ?

 It is i normal that freeing memory does not change the resource
 consumption of the process. The freed memory will be available for
 reuse by malloc, but malloc does not immediately return the memory
 to the OS.

 No, filled more than 7GB, swap was at ~350 MB, and then I loaded a
 small table which would otherwise take less than 10 MB memory, but
 the memory usage increased.

 Can you post the smallest compilable program which demonstrates your
 problem (run with G_SLICE=always-malloc set), and with particulars of
 how you are measuring memory usage?  That should identify if you are
 doing something wrong with how you are handling the memory in your
 program.

 Chris


 You can have the whole source code:

 http://pastebin.com/4a5DiMsQ

 I'd been distributing it around to fix issues.

dE,

Surely you can conjure something small which you expect
not to leak memory, but does.

Obviously, there must be a leak in this program, but
sending us this huge file sort of implies that we should
do the debugging and find your memory leak for you.

If you send us something small, as Chris says:
the smallest compilable program which demonstrates
 your problem,

then we can surely easily spot the problem and guide you
on how to fix it, without spending our time doing your homework.

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

Re: Prevent sort of GtkListStore.

[Tristan Van Berkom]

On Wed, Jun 12, 2013 at 11:38 PM, dE de.tec...@gmail.com wrote:
 With gtk_tree_view_column_set_sort_column_id (), it appears that
 GtkListStore also gets sorted.

 I don't want that to happen, since the data in it has to be compared.

The sorting of GtkTreeView actually sorts the model, it does so
using the GtkTreeSortable interface.

If you dont want the data model to actually be modified by sorting,
then you can use a GtkTreeModelSort, which is an intermediate
data model for this particular purpose (just set the GtkTreeModelSort
as the model for the GtkTreeView, and set your data model as the
child model of the GtkTreeModelSort).

Cheers,
-Tristan


 How can I do this? Thanks!!
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: glade and C code

[Tristan Van Berkom]

On Tue, May 28, 2013 at 4:59 AM, Thomas A. Moulton t...@moulton.us wrote:
 ok here's a simple question...

 If I have c code that creates all the widgets I can get the pointers to them
 as needed.

 How can I get the GtkNotebook *pointer when I create things with glade?

 If there a function I can call to scan the created objects by name?

After parsing the xml input with GtkBuilder, just call gtk_builder_get_object()

https://developer.gnome.org/gtk3/unstable/GtkBuilder.html#gtk-builder-get-object

Cheers,
-Tristan


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

Re: GTK+3 motion events and is_hint

[Tristan Van Berkom]

This is a good question, actually I haven't used this feature since GTK+2...

I'd be curious to know the answer but here is my input anyway.

Your application doesn't do much between is_hint events, so it could
be that if you were slow handling the hint events, you might receive
events that are not 'is_hint' in between the regular 'is_hint' events.

FWIW, I don't think you should be concerned about which events are
'is_hint' or not 'is_hint'.

Rather, the hint mask traditionally prevents you from receiving too many
motion events that are queued up while your widget is processing a previous
event, and the call to gdk_event_request_motions() tells GDK that your
GdkWindow is ready to handle more motion events.

Actually, I don't see why you should be trying to handle the 'is_hint' events
any differently from the normal events (it should be enough to just call
gdk_event_request_motions() at the end of a motion-notify-event handler,
after you're done processing the event).

Cheers,
-Tristan

On Fri, May 17, 2013 at 6:15 PM, Donn donn.in...@gmail.com wrote:
 Anyone?


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

Re: Can I install both GTK+2 and GTK+3?

[Tristan Van Berkom]

On Fri, May 17, 2013 at 11:17 PM, Emmanuele Bassi eba...@gmail.com wrote:
 hi;

 On 17 May 2013 12:37, David Nečas y...@physics.muni.cz wrote:
 On Fri, May 17, 2013 at 11:40:10AM +0100, Emmanuele Bassi wrote:
 it's maintained only for critical bugs, or for platform support; no
 new feature, and no new API is *ever* going in to the gtk-2-24 branch.

 And that's what many 3rd party developers like.  Absolutely no changes
 except critical bug and platform support fixes.

 yes, I suppose there is a part of ISVs that favour this approach.

 after all, there are still a ton of corporate Motif applications
 written in 1994 lying around that still need to be replaced by web
 apps.

  All the small bugs and
 peculiarities are known, are not replaced with a different set of small
 bugs and peculiarities in the next release and we've learned how to work
 around them.

 sure, let's work around bugs and peculiarities instead of, you know,
 fixing them. ;-)

Right, but let's try to fix them without radically changing the set of
particularities and introducing new bugs in the process ;-)

Basically, we must care about not breaking applications which were
written 3 or 4 years ago, those applications are just as important as
applications which were written, or hacked on, in the current release
cycle. The more we care about code which others have written in
the past, and not breaking their code by our fixing of bugs the more
we build trust.

Anyway, I'm sure this trust is getting stronger the more that
applications do port to GTK+3 and the more GTK+3 matures.

I.e. it's hard to fix back-compat problems when nobody files bugs
about them, the more applications which do port, the more bugs get
filed, and the more awareness is raised in general. It's that awareness
which helps us to pay attention to older applications, helps us to
avoid breaking older applications (which are just as important as
newer applications).

Cheers,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-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 al...@redhat.com 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
freebsd-lis...@fabiankeil.de wrote:
 Fabian Keil freebsd-lis...@fabiankeil.de wrote:

 Emmanuel Thomas-Maurin manutm...@gmail.com 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 allanp...@gmail.com wrote:
 Owen Taylor otay...@redhat.com 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 Sat, May 4, 2013 at 12:37 PM, yu wu vanii.wa...@gmail.com 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: which column cell is changed when row-changed is emitted

[Tristan Van Berkom]

On Sat, May 4, 2013 at 12:44 PM, yu wu vanii.wa...@gmail.com 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 8:02 PM, yu wu vanii.wa...@gmail.com 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 tristan.van.ber...@gmail.com


 On 2013-05-04, at 7:00 PM, yu wu vanii.wa...@gmail.com 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 vanii.wa...@gmail.com 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 2013-05-04, at 7:00 PM, yu wu vanii.wa...@gmail.com 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 vanii.wa...@gmail.com 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 jstpie...@mecheye.net
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 trista...@openismus.com
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 o...@redhat.com
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 IconView use

[Tristan Van Berkom]

It's not the expected behaviour.

GtkIconView lays out it's icons based on the available/allocated width,
unless the columns property is explicitly set, it always has.

It's possible that there was a bug earlier on in 3.x (3.2 ? 3.4 ?), but
if you see ./tests/testiconview you will find icons that layout properly
(and I'm sure GtkIconView was working properly in 3.0.0, since I made
sure of that).

Cheers,
-Tristan




On Tue, Apr 23, 2013 at 9:49 PM, Erick Pérez Castellanos
eric...@gnome.orgwrote:

 Nope, that's not a bug, it is the expected behavior. You should look in
 libgd, there should be something like EggListBox but IconView like


  Is this a known bug? Should I be enabling some mask I am not? is this
  implemented via callbacks??
 
 
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

Re: code crash after 25-30 min only!

[Tristan Van Berkom]

On Tue, Apr 16, 2013 at 8:58 PM, Eric Wajnberg eric.wajnb...@sophia.inra.fr
 wrote:

 Hi there,

 I just remain unable to debug this code. Actually, it runs very well but
 crashes after 30-35 minutes only.

 This is a stopwatch-type app. However, I actually need to refresh things
 on a continuous basis. Hence, a g_timeout_add_seconds() is **not** what I
 need. The idea of a stopwatch is just a way for me to learn and practice.


Jaime your franglais ;-)

I can't tell exactly where or how your app crashes, but a few remarks:

  o If you're studying, it would be better to use GTK+3, as GTK+2 is rather
old now

  o It's unclear to call your timer a widget... calling g_timer_elapsed
(widget2, NULL) looks
 like a crash, but it's not, because widget2 is not a widget, but a
timer (it's possible that
 cleaning up your code to use appropriately named variables will show
you where things
 went wrong).

  o It looks as though you've given a wild pointer to g_signal_connect()
the way you've prototyped
 the OnExpose callback inside main... better to put the prototypes
before main at the global scope.

  o Don't fight the event loop by trying to implement it, I'd argue that
you rather **do** want g_timeout_add()
 to asynchronously refresh the GUI widgets every couple milliseconds.

 Even using a g_idle_add() would ensure that you recalculate your time
every chance that you get.

 Bonus points for getting your rounding correctly and avoiding to call
gtk_widget_queue_redraw()
 when the time you want to display is not any different from the last
time you displayed.

Even if your idle callback runs basically all the time, you do not control
the loop.

Cheers and bonne chance,
-Tristan




 The code that I have is more or less this one:

 #include stdlib.h
 #include gtk/gtk.h
 #include strings.h

 int flag_depart=1;
 char format_sortie[100];
 typedef struct
 {
 GtkWidget *widget1;
 GTimer *widget2;
 } MyStruct; /* a struct to pass several arguments to an callback */

 int main(int argc, char **argv)
 {
 /* declaration of widgets */
 [...]
 GtkWidget *pLabel; /* a label */
 GTimer *timer; /* a timer */
 gchar* sUtf8;  /* to format a char string */
 [...]
 MyStruct struct_tempo; /* a struct to pass several arguments to an
 callback */
 [...]
 gboolean OnExpose(GtkWidget *pWidget, GdkEvent *event, gpointer
 pData); /* function callback expose-event */
 [...]
 /* creation of the label */
 pLabel=gtk_label_new(NULL);
 (void)sprintf(format_sortie, span font_desc=\25\b00 : 00 :
 00/b/span);
 sUtf8 = g_locale_to_utf8(format_**sortie, -1, NULL, NULL, NULL);
 gtk_label_set_markup(GTK_**LABEL(pLabel), sUtf8);
 g_free(sUtf8);
 /* we put the label in the struct */
 struct_tempo.widget1=pLabel;

 /* creation of the timer */
 timer=g_timer_new();
 /* we put the timer in the struct */
 struct_tempo.widget2=timer;

 /* Connexion of signals */
 g_signal_connect(G_OBJECT(**pWindow), expose-event,
 G_CALLBACK(OnExpose), (gpointer )struct_tempo);

 [...]

 return EXIT_SUCCESS;
 }
 gboolean OnExpose(GtkWidget *pWidget, GdkEvent *event, gpointer pData)
 {
 /* updating the label */
 char tempo[1000],h[3],m[3],s[3];
 int heures=0, minutes=0;
 GTimeSpan secondes=0;
 gchar* sUtf8;
 MyStruct *struct_tempo2;
 struct_tempo2= (MyStruct *)pData;
 float convertir(GTimeSpan *secondes, int *minutes, int *heures);
 if (flag_depart)
 {
 secondes=(GTimeSpan)g_timer_**elapsed(struct_tempo2-**widget2, NULL);
 convertir(secondes, minutes, heures);
 if (secondes9)
 (void)sprintf(s, %d,secondes);
 else
 (void)sprintf(s, 0%d,secondes);
 if (minutes9)
 (void)sprintf(m, %d,minutes);
 else
 (void)sprintf(m, 0%d,minutes);
 if (heures9)
 (void)sprintf(h, %d,heures);
 else
 (void)sprintf(h, 0%d,heures);
 (void)sprintf(tempo, span font_desc=\25\b%s : %s :
 %s/b/span,h, m, s);
 sUtf8 = g_locale_to_utf8(tempo, -1, NULL, NULL, NULL);
 gtk_label_set_markup(GTK_**LABEL(struct_tempo2-widget1), tempo);
 }
 g_free(sUtf8);
 return FALSE;
 }
 float convertir(GTimeSpan *secondes, int *minutes, int * heures)
 {
 /* convert seconds into hours, minuts and seconds */
 while (*secondes59)
 {
 *minutes=*minutes+1;
 *secondes=*secondes-60;
 }
 while (*minutes59)
 {
 *heures=*heures+1;
 *minutes=*minutes-60;
 }
 }

 This codes works well but crashes avec about 30-35 minutes. I code in
 Windows 7 with CodeBlock. I've tried to use a debugger, but I get a:

 Segmentation fault.
 In ntdll!**LdrWx86FormatVirtualImage () (C:\Windows\system32\ntdll.**dll)

 as soon as the gtk_main() is launched. I have really no idea about how I
 can solve this now.

 Any help 

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 GtkFileChooserDefaultClass *GtkFileChooserDefaultClass;
 
 gtkfilechooserdefault.c:
 
   /* complete structure definitions */
   struct GtkFileChooserDefault {
  GtkBox parent;
  blah blah;
   }
 
 ?
 
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

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 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 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 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 style attributes were not being parsed properly for GtkColorScale.

This turned out to be a bug in GtkScale (which was failing to properly
chain up in GtkBuildableIface-custom_finished()).

I'm quite certain that this is going to fix your knob appearance.

 
 I haven't looked at the added api in detail, but I think Benjamin had
 reviewed and ok'ed that already ?

I'll let Benjamin comment to this if he likes.

But yes, Benjamin and I have gone over it quite a bit, and as of Friday,
he OK'ed it, with the exception of waiting on your review (which was
very helpful, as I did find some issues which I had previously
overlooked, thanks to your efforts).

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

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 Sun, 2013-04-07 at 10:13 -0400, Matthias Clasen wrote:
 On Sun, Apr 7, 2013 at 2:57 AM, Tristan Van Berkom
 trista...@openismus.com 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 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

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

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: 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: Baseline alignment ideas

[Tristan Van Berkom]

On Wed, Feb 27, 2013 at 8:44 PM, Alexander Larsson al...@redhat.com 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 and total
height
 2. calculate the missing height to the 

Re: Function completion for GVariant maybe types?

[Tristan Van Berkom]

On Thu, Feb 21, 2013 at 7:05 PM, Markus Elfring markus.elfr...@web.de 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
matthias.cla...@gmail.com wrote:
 On Tue, Feb 5, 2013 at 3:49 PM, Morten Welinder mort...@gnome.org 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 s.felt...@gmail.com 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 kaffeeti...@gmx.de
 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 s.felt...@gmail.com 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 s.felt...@gmail.com 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 t...@gnome.org
 wrote:

 On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna
 scampa.giova...@gmail.com 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: is this correct way to open file in buffer?

[Tristan Van Berkom]

On Wed, Jan 30, 2013 at 8:39 AM, Rudra Banerjee
rudra.baner...@aol.co.uk wrote:
 Dear friends,
 I am trying hard to get rid of file reading and editing (as evident from
 my previous post)
 Here is a small code where I tried to open my file in a buffer and scan.
 Its small, 50 line code.
 I will be grateful if anybody kindly have a look and tell if this is
 really opening the file from buffer or still using the file. Please
 help.

I can't tell you what it is 'still' doing, however in the code portions
which you've posted here, you are first reading the contents of the
file into a buffer using g_file_get_contents(); and then parsing
that buffer afterwards.

I assume this is what you're after, however I should point out
that naming your allocated buffer 'fd' is thoroughly confusing
to the reader.

At first glance, it would appear that your scanner is operating
on an fd, i.e. a file descriptor, not an allocated buffer.

Cheers,
-Tristan



 void open_file(GtkWidget *widget, gpointer data){
   GScanner *scanner;
   GHashTable *table;
   char* fd;
   gsize length;
   GError* error=NULL;
 GtkWidget *dialog; //, *entry;
 GtkFileFilter *filter;
 dialog = gtk_file_chooser_dialog_new(Open File, NULL,
 GTK_FILE_CHOOSER_ACTION_OPEN,
 GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
 GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
 NULL);

 filter = gtk_file_filter_new();
 gtk_file_filter_set_name(filter, All files (*.*));
 gtk_file_filter_add_pattern(filter, *);
 gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dialog), filter);

 filter = gtk_file_filter_new();
 gtk_file_filter_set_name(filter, Bibtex file (*.bib));
 gtk_file_filter_add_pattern(filter, *.bib);
 gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dialog), filter);
 gtk_file_chooser_set_filter(GTK_FILE_CHOOSER(dialog), filter);

 if (gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT) {
 filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
 gtk_list_store_clear (store);
 g_file_get_contents(filename, fd, length , error);
 g_assert(!error);

  scanner = g_scanner_new (NULL);
  g_scanner_input_text (scanner, fd, CHAR_BUFF);

  table = g_hash_table_new_full (g_str_hash, g_str_equal, g_free,
 g_free);
  do
{
  g_hash_table_remove_all (table);
parse_entry (scanner, table);
output_entry (table);

  g_scanner_peek_next_token (scanner);
}
  while (scanner-next_token != G_TOKEN_EOF 
 scanner-next_token != G_TOKEN_ERROR);


   /* finsish parsing */
  g_scanner_destroy (scanner);
  g_hash_table_destroy (table);

 gtk_label_set_text(GTK_LABEL(flabel), filename);
 gtk_widget_destroy(dialog);
 }
 else
 gtk_widget_destroy(dialog);
 }

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

Re: Incorrect number of columns in GtkIconView

[Tristan Van Berkom]

On Sat, Jan 19, 2013 at 9:11 PM, rastersoft ras...@rastersoft.com wrote:
 Let's try again, without PGP signing...
 https://bugzilla.gnome.org/show_bug.cgi?id=692063

Yup, I got the url each time ;-)

Thanks for doing this, this is most certainly a verifiable bug (I've tried it
on my machine with the installed GTK+ version where it works fine,
and with GTK+ master where I see the breakage).

FWIW, normally it's better not to attach tarballs, just the vala code
would have been enough. I'm only saying this because it means
developers have an easier time seeing what code is problematic
without needing to download a tarball, untar it and all before viewing
it and compiling it (sometimes you can guess what went wrong
by looking at your test code without even compiling, as specially
if you recently made changes to GtkIconView code).

That's just a minor recommendation though, it's very appreciated
that you took the time to write an isolated test case proving there
is a problem, it will most certainly be helpful in addressing/fixing
the bug.

Cheers,
-Tristan


 El 19/01/13 13:00, rastersoft escribió:

 Ok, I don't know what happened to the URL, this is the right one:
 https://bugzilla.gnome.org/show_bug.cgi?id=692063

 El 19/01/13 12:15, rastersoft escribió:

  Hi:

  Well, it seems that Ubuntu 12.10 has Gtk 3.6.0, not 3.6.4, so I
  installed in a virtualbox a Fedora 18 and tested it inside.

  I created a test case, took some screenshots, and filled a bug report:
  https://bugzilla.gnome.org/show_bug.cgi?id=692063 . Hope I did it
 right O:)

  El 18/01/13 06:32, Tristan Van Berkom escribió:
  On Fri, Jan 18, 2013 at 8:49 AM, rastersoft ras...@rastersoft.com
 wrote:
 
  Hi all:

  I'm having an odd problem with GtkIconView. In Ubuntu 12.04, with Gtk
  3.4, all worked fine, but now, in Ubuntu 12.10 and Gtk 3.6, there's
 this
  curious problem.

  I set a GtkIconView inside a GtkScrolledWindow, and set to -1 columns,
  so it should autoadjust the number of columns to ensure that never will
  be needed to use the horizontal bar. As I said, in Gtk2 and in Gtk 3.4
  it worked fine, but with Gtk 3.6, when the number of rows is big
 enoughtr
  to force vertical scroll, the number of columns is set to 30; but the
  vertical scroll is kept, so I have to scroll horizontally to be able to
  see all the icons, but also I can scroll vertically (but there's just a
  lot of blank space).

  How can I fix this?

  Sounds like a legitimate regression, you should not have to change
  your code at all between stable GTK+ releases.

  It would be a great help if you can:
  a.) Create a small test case with only a window/scrolled window/icon
  view
  that reproduces this problem (just a small self contained program that
  shows the problem).
  b.) File a bug here[0] and attach the small test case

  It would also help if you can be sure that you indeed have the latest
  version of GTK+ 3.6.x

  Cheers,
  -Tristan

  [0]: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B


  Thanks.

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



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



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


 --
 Nos leemos
  RASTER(Linux user #228804)
 ras...@rastersoft.com  http://www.rastersoft.com


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

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
scampa.giova...@gmail.com 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: Incorrect number of columns in GtkIconView

[Tristan Van Berkom]

On Fri, Jan 18, 2013 at 8:49 AM, rastersoft ras...@rastersoft.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all:

 I'm having an odd problem with GtkIconView. In Ubuntu 12.04, with Gtk
 3.4, all worked fine, but now, in Ubuntu 12.10 and Gtk 3.6, there's this
 curious problem.

 I set a GtkIconView inside a GtkScrolledWindow, and set to -1 columns,
 so it should autoadjust the number of columns to ensure that never will
 be needed to use the horizontal bar. As I said, in Gtk2 and in Gtk 3.4
 it worked fine, but with Gtk 3.6, when the number of rows is big enoughtr
 to force vertical scroll, the number of columns is set to 30; but the
 vertical scroll is kept, so I have to scroll horizontally to be able to
 see all the icons, but also I can scroll vertically (but there's just a
 lot of blank space).

 How can I fix this?

Sounds like a legitimate regression, you should not have to change
your code at all between stable GTK+ releases.

It would be a great help if you can:
  a.) Create a small test case with only a window/scrolled window/icon view
   that reproduces this problem (just a small self contained program that
   shows the problem).
  b.) File a bug here[0] and attach the small test case

It would also help if you can be sure that you indeed have the latest
version of GTK+ 3.6.x

Cheers,
-Tristan

[0]: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B


 Thanks.

 - --
 Nos leemos
  RASTER(Linux user #228804)
 ras...@rastersoft.com  http://www.rastersoft.com

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with undefined - http://www.enigmail.net/

 iEUEARECAAYFAlD4jhUACgkQXEZvyfy1ha8zzACXXlSHhlZxHNQqb1TvD6jYJU4n
 LwCgpNBlhktrM3s3RA5lpXnV3x9/lS0=
 =Z6sf
 -END PGP SIGNATURE-

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