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

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

Re: duplicating GtkBuilder created widget objects

[Tristan Van Berkom]

On Mon, Dec 3, 2012 at 3:12 PM, Joe Steeve j...@hipro.co.in wrote:
 On Sun, 2012-12-02 at 13:35 +0100, Tomasz Jankowski wrote:
 I think, that you cannot easily copy widgets. In such situation I
 usually use gtk_builder_add_objects_from_file().

 When we do this, can there be two sets of objects with the same name? I
 dont think so. Scenario: There is one top-level window (win-a). And, a
 button in win-a brings up another top-level window (win-b). Each click
 on the button should bring a win-b. There can be more than one win-b at
 the same time. If I do Builder::add_objects_from_file, wont there be a
 name clash of widgets from the new file and the ones already there?

 I am now using multiple GtkBuilder objects. I moved win-b into a
 separate glade file and load it every time I need a new window. Is there
 a better approach?

This is correct, there is no good reason to keep a GtkBuilder object
itself alive for longer than the time it takes to create some widgets
from xml, after creating your window just dispose of the builder
object.

For even better encapsulation, create the GtkBuilder object
from the -constructor() vfunc of your window, add the contents
created by GtkBuilder to your window, save any pointers to
widgets you might need (presumably as private object members
of your window) and destroy the builder object right away.

This way the builder constructs your window content implicitly
any time g_object_new() is called for your window type.

Probably you want to use GResource to store your builder
xml (or const gchar* memory) instead of scratching the HD
every time you need a new object.

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: Drag and drop, inter-widget

[Tristan Van Berkom]

On Sat, Oct 13, 2012 at 1:02 PM, John Coppens j...@jcoppens.com wrote:
 Hello guys,

 I've got DnD actually working, between a GtkTreeView and a GtkLayout. I'm 
 using it
 to make a scheduler, where the TreeView has the classes to be scheduled, and 
 the
 Layout is the actual grid.

 Though this works, I can't draw the correct size of the class period in the
 layout till I drop the wares, which is when the data exchange takes place. Is 
 there
 some way to have a data exchange earlier? Hopefully before the move_over event
 starts happening - so I can draw the box with the correct size.

 Of course it would be possible to do a parallel mechanism (say save a copy of 
 the data
 from the treeview as global info) but I'd rather use the DnD mechanism, as 
 this would
 work inter-program too.

Hi,
   I'm interested as well to hear any hacks making this possible...
one of the ideas
I've been toying with and might take up as a weekend project is to
bless GtkTreeView
with animated drop zones. currently the displaying a line approach
is... a start
but... nothing great.

In other drag'n'drop scenarios I've found that creating a custom drag
icon is enough,
the size of the icon should usually be the size which the data will use in the
drop target display... allowing the drop target display to animate
spaces which will
consume the drop data at drop time without causing any visual jumps/glitches
(see eggtoolbareditor and eggspreadtablednd for examples of that).

The problem is in some scenarios, the drop zone may represent the data
in a completely
different way than it was represented in the drag source... for
instance, imagine dragging
icons from Glade's palette into a h4w treeview with variable row
heights... you really
need to construct a treeview row with the drag source data during the
drag-motion
events in order to animate a space between rows properly.

Hopefully for you... your work is high-level enough and your drag
source is in the
same application as your drop target... that means you get to set some pointer
data and work completely around the drag-and-drop GtkSelectionData apis
in order to fetch the current drag data at drag-motion time anyway...

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: Strange behaviour of GtkCheckMenuItem with submenus

[Tristan Van Berkom]

From what I understand you have a strange expectation of menu items.

Items are either parents of groups, or are controls for some actions
in the program, but not simultaneously.

Menu items can be insensitive but usually those are because
the context of the program doesnt allow them to be valid (i.e.
you cannot 'Save' when there is no document loaded, you
cannot 'Copy' when there is no selection in context).

It would be annoying if say, you had to toggle a check menu item
for other items to suddenly become sensitive in the same menu
(because that implies anyway the user needs to popup the menu
twice, once to change some configuration, and another time to
select the items which have magically became active).

On Thu, Oct 11, 2012 at 5:52 AM, Bruce Karsh bruceka...@gmail.com wrote:
 I need a UI for letting the user limit a view of their data based on tags.
 The user needs to be able to choose to a) show all items, b) show items
 with certain tags, c) show items without certain tags.  So I made a menu
 with 3 GtkRadioMenuItems and put submenus with GtkCheckMenuItems in them
 for the two cases where the user has to select the tags.  It worked, but
 the behaviour of the menus is odd.

 When I activate the menu and move the cursor over the GtkRadioMenuItems and
 the item under the cursor has a submenu, then the item under the cursor
 becomes selected without any clicks. But if the
 item under the cursor does not have a submenu, it does not become selected.

 I think that's a problem because it's going to violate user expectations. A
 user won't expect that scrolling through the menus without clicking
 anything might cause a persistent state change.

 What could be done about it?

 1. disallow submenus on GtkRadioMenuItems
 I think this would be a bit extreme. I've presented one use case for
 GtkCheckMenuItems with submenus and there are probably lots of others.

Not all use cases are natural for the average user to understand,
and I don't believe I've seen any application do this with menu items.

Perhaps these specific configurations can be better expressed
in a preferences dialog, found under the Edit menu.

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: destroy a widget while keeping the window with Glade

[Tristan Van Berkom]

On Sun, Oct 7, 2012 at 2:57 PM, Frank Cox thea...@melvilletheatre.com wrote:
 I've just started playing with Glade and once again I'm wondering if I'm using
 the wrong approach to get stuff done, since I can't find anything that tells 
 me
 how to do this.

 So far, I've been creating a main window for the program and simply creating 
 and
 destroying boxes and widgets within that window as different menu options are
 selected.

 Here is a simple example.

 I have a window with a box in it, which in turn contains a button.

 Now I want to be able to click on that button and destroy the box without
 destroying the window, then create a new box and a new button within the
 existing window.

 I can do this easily enough by writing the code to do the layout myself, but I
 don't see a way to do a Glade layout that can accomplish this.

Just right click on any widget in Glade's palette and chose Add as toplevel

Glade/GtkBuilder do not restrict you to using toplevel GtkWindows in your xml.

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: Handle Enter pressing at GtkEntry

[Tristan Van Berkom]

On Thu, Oct 4, 2012 at 5:55 PM, David Nečas y...@physics.muni.cz wrote:
 On Wed, Oct 03, 2012 at 08:19:39PM -0700, Andrew Potter wrote:
 On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote:
  What is the right way to catch Enter pressing at the end of the text 
  input
  to GtkEntry

 gtk_entry_set_activates_default() is probably what you want.

 If you actually want what it does.  Usually, I do not want that at all.

 I want to recalculate and update something once user has finished
 editing the value there (but not during the editing).  This means namely
 when the entry loses focus, however, it should be also possible to
 invoke the update without leaving the entry, by pressing Enter.  So,
 instead of gtk_entry_set_activates_default() I use something like
 set-activate-on-unfocus and then just handle activate.

I'm curious about this, out of my own personal interest... do we
have a workable solution for this commit-on-focus-out paradigm ?

As I understand, it's not very stable to use focus-out events
and, I recall reading a detailed blog about this I can't seem to
find at the moment (but it seems the problem is not at all limited
to GTK+, just broken by design).

Note in many cases validation/apply/commit user input on
focus-out does work but... here is a case where I expect it
to break:

   a.) User is presented a form full of entries
   b.) User tabs or clicks into an entry
   c.) User modifies data
   d.) User selects another entry
   e.) Focus-out causes the previous entry to commit, yay !
   f.) User modifies data in new entry
   g.) User presses OK
   h.) Dialog full of entries is destroyed... oops... previous entry
is destroyed before
ever receiving focus-out notification.

That scenario, easy enough to deal with because you have a commit button
which can take care of things... (in which case you dont need focus-out in the
first place)... but... lets take another example:

   a.) Editor is loaded into a notebook tab because some object is selected
 (consider Glade's property editor, and a widget is selected
for instance)
   b.) Each property gets it's current value filled with new data
   c.) User modifies one of the entries
   d.) User selects a new entry, YAY we received focus-out
   e.) User modifies the currently focused entry
   f.) User selects a new object in the workspace
   g.) Entries are cleared of previous data, a new widget is loaded into
the editing context and new values are loaded into the entries
   h.) Entry receives focus-out ... OOPS... what change did I have to commit ?

As far as I know, it's an interesting, classic problem (which I knew
to exist years
ago), perhaps focus event delivery is ordered now in such a way that this wont
happen ? ... it's really hard to say.

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 apps on iOS/Android?

[Tristan Van Berkom]

On Mon, Sep 10, 2012 at 3:15 AM, Michael Torrie torr...@gmail.com wrote:
 On 09/07/2012 07:40 AM, Allin Cottrell wrote:
 I'm contemplating trying to produce a version of my gtk app
 for tablet use. Can anyone point me to relevant resources or
 examples? At this point I'm totally clueless about porting to
 tablets (though I'm able to build my app for OS X OK), and I
 haven't found googling to be very useful.

 Basically you'll want to get a book on developing android apps, download
 the sdk, and go to town.  All in Java of course.  And using the Android
 UI toolkit.  GTK+ is not available on Android or iOS, nor will it likely
 ever be.  Use the native toolkits.

interesting, wouldnt the quartz backend for osx build for iOS ?

not exactly sure but I think the NSView and highlevel cocoa stuff
is built upon the same low level windowing apis that are available
on osx...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 + python : lookup_widget

[Tristan Van Berkom]

On Mon, Aug 20, 2012 at 2:32 PM, Patrick Shirkey
pshir...@boosthardware.com wrote:

 On Mon, August 20, 2012 6:59 am, Tristan Van Berkom wrote:
The lookup_widget() paradigm comes from a very old time when we
 had very poor
 tools and actually it originates from people using generated code from
 the original Glade
 tool (Glade versions 1 and 2).

 Ideally, as specially as you are using python, your application should
 be modular.

 Perhaps you have an Application object which owns the main widgetry
 created
 by GtkBuilder after having parsed a Glade file initially, this is
 different from a global
 variable.

 Ideally you can use you object constructor as an entry point to load
 your GtkBuilder
 and assign the pointers you need later on to the members you define on
 your
 Application object.


 In this case I am programatically creating the widget.

 After that you simply have to pass your Application object to all the
 callbacks
 which originate from the user interface, giving you access to everything
 you
 need when you need it.


 This is the part I am having trouble with.

 This concept can be further extended to be more modular, for instance if
 you have a preferences dialog/window... it can be defined by a separate
 python class/GtkBuilder file and reused at will throughout your program.


 Thanks for your advice. I am planning to make this app as modular as
 possible but I am finding it hard to find a simple example that deals with
 my use case.

Look at GTK+ sources: gtkdialog.c for example, or gtkmessagedialog.c even.

Many composite widgets exist in GTK+, all of them follow the same construct:

   o Create child widgets at initialization time and assign them to your
  private data structure members which you have declared for them
  (in other words, of course you hold a private instance member for
  any composite children you need, like dialog-entry or dialog-label
  or dialog-button etc).

  o Connect signals to, for example the button, when doing so..
 supply the dialog (self) instance as user data for the callback

When the callback runs, it receives the dialog as user data, so
all of the internal composite children are always available in
those callbacks.

In theory, in this 'dialog' example, normally all composite children
are private to the dialog and the dialog has some kind of output
or modifies your program state in some way, so no user of the
dialog should ever have to access those internal widget members
and the dialog can change internally without breaking any API.

So in the context where the dialog handles a callback for any
signal originating from one of it's instance members, it always
has the dialog in context so it can always access any member
of the dialog.

How that translates to python script, I'm not exactly sure, but
I'm sure that it does indeed translate to python script ;-)

In any case it's the coding practice which is relevant, not
the language binding which you use to achieve it


Cheers,
   -Tristan


 Basically I want to be able to modify the text in a label widget from a
 Entry or EventBox signal.

 I haven't found an example of that but if anyone knows of one that would
 be very helpful.


 --
 Patrick Shirkey
 Boost Hardware Ltd



 Cheers,
  -Tristan

 On Mon, Aug 20, 2012 at 1:10 PM, Patrick Shirkey
 pshir...@boosthardware.com wrote:
 Hi,

 I'm having a little trouble finding examples online of using the
 equivalent of lookup_widget() with gtk3 + python.

 For example in the following code what is the best way to modify the
 message label after the commandline callback is sent?

 Should I be using globals or a glade file or is there a way to
 dynamically
 lookup the message widget ?



 def create_gtkEntry():

 commandline = Gtk.Entry()
 commandline.connect(activate, command_entered, 1)

 messages = Gtk.Label('TEST')



 def command_entered(self, *args):

 cmi_command = self.get_text()
 messages.set_text(cmi_command)
 print command entered: , args[0]



 --
 Patrick Shirkey
 Boost Hardware Ltd
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



 --
 Patrick Shirkey
 Boost Hardware Ltd
 ___
 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: gtk3 + python : lookup_widget

[Tristan Van Berkom]

   The lookup_widget() paradigm comes from a very old time when we
had very poor
tools and actually it originates from people using generated code from
the original Glade
tool (Glade versions 1 and 2).

Ideally, as specially as you are using python, your application should
be modular.

Perhaps you have an Application object which owns the main widgetry created
by GtkBuilder after having parsed a Glade file initially, this is
different from a global
variable.

Ideally you can use you object constructor as an entry point to load
your GtkBuilder
and assign the pointers you need later on to the members you define on your
Application object.

After that you simply have to pass your Application object to all the callbacks
which originate from the user interface, giving you access to everything you
need when you need it.

This concept can be further extended to be more modular, for instance if
you have a preferences dialog/window... it can be defined by a separate
python class/GtkBuilder file and reused at will throughout your program.

Cheers,
 -Tristan

On Mon, Aug 20, 2012 at 1:10 PM, Patrick Shirkey
pshir...@boosthardware.com wrote:
 Hi,

 I'm having a little trouble finding examples online of using the
 equivalent of lookup_widget() with gtk3 + python.

 For example in the following code what is the best way to modify the
 message label after the commandline callback is sent?

 Should I be using globals or a glade file or is there a way to dynamically
 lookup the message widget ?



 def create_gtkEntry():

 commandline = Gtk.Entry()
 commandline.connect(activate, command_entered, 1)

 messages = Gtk.Label('TEST')



 def command_entered(self, *args):

 cmi_command = self.get_text()
 messages.set_text(cmi_command)
 print command entered: , args[0]



 --
 Patrick Shirkey
 Boost Hardware Ltd
 ___
 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: gtk3 + python : lookup_widget

[Tristan Van Berkom]

On Mon, Aug 20, 2012 at 1:59 PM, Tristan Van Berkom t...@gnome.org wrote:
The lookup_widget() paradigm comes from a very old time when we
 had very poor tools and actually it originates from people using generated 
 code from
 the original Glade tool (Glade versions 1 and 2).

Correction, that didnt sound the way I intended, The original Glade was a great
tool for its time... what I mean to say is that back then our coding
practices were
very poor and we've made much improvements since then.


 Ideally, as specially as you are using python, your application should
 be modular.

 Perhaps you have an Application object which owns the main widgetry created
 by GtkBuilder after having parsed a Glade file initially, this is
 different from a global
 variable.

 Ideally you can use you object constructor as an entry point to load
 your GtkBuilder
 and assign the pointers you need later on to the members you define on your
 Application object.

 After that you simply have to pass your Application object to all the 
 callbacks
 which originate from the user interface, giving you access to everything you
 need when you need it.

 This concept can be further extended to be more modular, for instance if
 you have a preferences dialog/window... it can be defined by a separate
 python class/GtkBuilder file and reused at will throughout your program.

 Cheers,
  -Tristan

 On Mon, Aug 20, 2012 at 1:10 PM, Patrick Shirkey
 pshir...@boosthardware.com wrote:
 Hi,

 I'm having a little trouble finding examples online of using the
 equivalent of lookup_widget() with gtk3 + python.

 For example in the following code what is the best way to modify the
 message label after the commandline callback is sent?

 Should I be using globals or a glade file or is there a way to dynamically
 lookup the message widget ?



 def create_gtkEntry():

 commandline = Gtk.Entry()
 commandline.connect(activate, command_entered, 1)

 messages = Gtk.Label('TEST')



 def command_entered(self, *args):

 cmi_command = self.get_text()
 messages.set_text(cmi_command)
 print command entered: , args[0]



 --
 Patrick Shirkey
 Boost Hardware Ltd
 ___
 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: what is the preferred way to wait while polling a flag

[Tristan Van Berkom]

Ooops, forgot to CC the list:

On Thu, May 17, 2012 at 1:43 PM, Rick Berger rckb...@gmail.com wrote:
 In GTK+ 2.20, what is the preferred way to wait while polling a flag in
 shared memory every 25 milliseconds in code something like this?

The preferred thing to do is to never use polling for synchronization
of processes and threads.

Rather, use events and messages to unblock sleeping threads.

Instead of running the following loop for instance, you could simply
call `read()', the read() call will block when called on a FIFO
(named pipe) until data appears on the file descriptor.

Cheers,
-Tristan



 gint n;
 for( n=10; n  (sharedMemory-flag != 1), n--) {


 /* wait 25 milliseconds */

 }


 if( n == 0 ) {

 g_warning(Timed out while waiting for flag);

  return 0;

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

Re: GtkTable cells resizing

[Tristan Van Berkom]

Are you using GTK+ 3 ?

If so, use GtkGrid instead... possibly just that will fix things for you.

Short of that, if I understand correctly, you have a target state/configuration
of a GtkTable (or GtkGrid), if you construct the table in the target
configuration
from scratch, I take it things work as you want... but dont work properly
after performing some kind of a transformation to reach your target
state...

... perhaps it's worth trying an extra call to gtk_widget_queue_resize()
after modifying your table.

Regards,
   -Tristan

On Mon, May 14, 2012 at 9:21 PM, James Steward
jamesstew...@optusnet.com.au wrote:
 Hi,

 I have an application with a tabbed view.  On two tabs I have a table, one
 is a 2x2 table, the other a 3x1 table (3 rows).

 In each cell is a canvas that has a gtk plot.

 I want to be able to click one of the plots in the 3x1 table and change the
 canvas size to 2/3 the original, with the other two canvases being 1/6 the
 original size.

 After redrawing and resizing and mucking about, I can't get the table rows
 to be different sizes, accommodating the different sized canvases properly,
 even though I have gtk_table_set_homogeneous (table, FALSE);

 Any clues how to do this?

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

Re: GtkTable cells resizing

[Tristan Van Berkom]

On Mon, May 14, 2012 at 10:29 PM, James Steward
jamesstew...@optusnet.com.au wrote:
 On 15/05/12 11:56, Tristan Van Berkom wrote:

 Are you using GTK+ 3 ?


 Still on GTK+ 2.0.


 If so, use GtkGrid instead... possibly just that will fix things for you.

 Short of that, if I understand correctly, you have a target
 state/configuration
 of a GtkTable (or GtkGrid), if you construct the table in the target
 configuration
 from scratch, I take it things work as you want... but dont work properly
 after performing some kind of a transformation to reach your target
 state...


 That's about it.

 ... perhaps it's worth trying an extra call to gtk_widget_queue_resize()
 after modifying your table.



 I'm trying that.   I have signals connected thus;

    g_signal_connect(G_OBJECT(p-canvas), expose-event,
             G_CALLBACK(plot_expose_event), p);

    g_signal_connect(G_OBJECT(p-canvas), select-item,
             G_CALLBACK(plot_select_event), p);

 and get the plot_select_event() routine to calculate and set new canvas
 sizes with

 gtk_plot_canvas_set_size(GTK_PLOT_CANVAS(p-canvas), width, height);

 then call gtk_widget_queue_resize(GTK_WIDGET(p-table));

 This causes plot_expose_event() to get called, which calls
 gtk_plot_canvas_paint(GTK_PLOT_CANVAS(canvas));

 But the table rows seem to expand to the largest canvas and don't seem to
 take on variable heights.

 Feel I've been around and around the mulberry bush on this ;-)


Hard to say whats going on here, I wonder who is responding
to the size requests for these items which are getting drawn.

It seems you connect to a signal to draw on a widget, which
means the content is not the widget, so probably you need
to also connect a signal to override the size request of the
said widget you intend painting onto ?

Perhaps you are using forced size requests to accomplish
this (using gtk_widget_set_size_request() or such), and
have somehow mixed up the size requests while swapping
your content onto new rows/columns ?

Other than that, child 'expand' properties will be considered
by the GtkTable (if all children can expand, then it's quite
possible that after reaching a large window size the content
will be evenly  spread).

Cheers,
-Tristan

 Regards,
 James.


 On Mon, May 14, 2012 at 9:21 PM, James Steward

 jamesstew...@optusnet.com.au  wrote:


 Hi,

 I have an application with a tabbed view.  On two tabs I have a table,
 one
 is a 2x2 table, the other a 3x1 table (3 rows).

 In each cell is a canvas that has a gtk plot.

 I want to be able to click one of the plots in the 3x1 table and change
 the
 canvas size to 2/3 the original, with the other two canvases being 1/6
 the
 original size.

 After redrawing and resizing and mucking about, I can't get the table
 rows
 to be different sizes, accommodating the different sized canvases
 properly,
 even though I have gtk_table_set_homogeneous (table, FALSE);

 Any clues how to do this?

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





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

Re: learning gtk+ well: Which book to buy?

[Tristan Van Berkom]

Hi,
   I have to strongly agree with Vlad here, I think the quality of
information that
you can find in print on GTK+ pales in comparison to what you have readily
available on the internet. Of course finding the right material to read might
be staggering at first, just toy with the apis a little, doing some
experimentation
will quickly set you on the right track.

I strongly recommend that you start with getting a grip on the GObject type
system, read the material that can be found here:
   http://developer.gnome.org/gobject/2.32/

GTK+ is basically just GObject based widgetry which deals with the GDK
backend for windowing system interaction... once you get a feel for the
main virtual methods involved on the GtkWidget class then you should
have a pretty good understanding of how GTK+ works (yes, easier said
than done... I just doubt that any book on the shelf is going to get you
there any faster than just experimenting and doing it yourself).

And as Vlad also mentioned, do take a look at some of the more simple
and/or more maintained projects source code, the source code of
Devhelp is small and readable (of course most of the work is done
by the browser embedding, just take a look at how it creates the preferences
dialog using GtkBuilder and creates a widget class to encapsulate
the preferences module).

Cheers,
 -Tristan

On Wed, Mar 28, 2012 at 3:54 AM, Vlad Volodin vest...@gmail.com wrote:
 Hello Howard,

 I am afraid to disappoint you, but in this case books will not help much.
 GTK+ was changed significantly comparing to GTK+ from the 2007.
 The best way to start learning is to read a documentation, play with demos
 and tutorials, examine other non-complex projects. If you are able to find
 a copy of the book, you may read it fast and skip many sentences just to
 get a brief idea :)

 Best regards,
 Vlad

 27 марта 2012 г. 20:45 пользователь Christopher Howard 
 christopher.how...@frigidcode.com написал:

 Hi. I want to have a thorough and well-formed understanding of how to
 use gtk+, which I'm not quite getting from the API. What would be the
 best book I can buy right now? The most up-to-date book I see is
 Foundations of GTK+ Development (2007) but not having a lot of money to
 experiment with, I was hoping to get your recommendations before buying
 anything.

 --
 frigidcode.com
 indicium.us


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

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

Re: building a modular interface

[Tristan Van Berkom]

Hi.

First, please dont bluntly use a single Glade file to define your
entire interface.

I'll attach here the same tarball which I attached a couple months ago
here for demonstration:
lists.ximian.com/pipermail/glade-users/2012-January/005469.html

With the approach described in the attached tarball, you can simply
bootstrap your composite widgets into types directly so that when
you create an instance it already has it's interface sub-components
created. (such as a preferences dialog or item editor widget or
user status thingy or whatever is relevant for your application).

This is a little orthogonal to optional viewing of sub-components of your
application, typically we control what components of an application are
visible via the View menu, and we load/save this state along with any
relevant session data (possibly to a GKeyFile)

Cheers,
  -Tristan

On Tue, Mar 27, 2012 at 12:55 PM, Lachlan lachlan...@gmail.com wrote:
 hi,
 I've decided to hunker down and start developing my first gtk
 application. I have a few questions that google hasn't really been
 helpful with. I know how to create and load an interface built from
 glade but is it possible to take a more modular approach?

 For example I would like to be able to load an empty window, check
 config file that defines how the interface looks and import the
 widgets into that empty window.

 so a default config file would be something like this in yaml:

 --- FooBar
 vbox: 3
    hbox: 2
        item: menu
        item: progress
    hbox: 2
        vbox: 2
            item: filelist
            item: fileinfo
        item: preview
    item: statusbar

 What I would then like to do; is be able to load or not load parts in
 any way the user feels like using this config file. That way it can be
 arranged easily without having to edit the entire interface. My guess
 is that there would be a main ui file that has the basic window and
 then each item is loaded from it's own config file which i think can
 be done with glade's Add widget as top level.

 I'm looking to do this all in pygobject and using xml/yaml/whatever.
 Is this kind of stuff possible or am i barking up the wrong tree?
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: building a modular interface

[Tristan Van Berkom]

On Tue, Mar 27, 2012 at 2:10 PM, Lachlan lachlan...@gmail.com wrote:
 On 27 March 2012 14:39, Tristan Van Berkom t...@gnome.org wrote:
 Hi.

 First, please dont bluntly use a single Glade file to define your
 entire interface.

 I'll attach here the same tarball which I attached a couple months ago
 here for demonstration:
    lists.ximian.com/pipermail/glade-users/2012-January/005469.html

 With the approach described in the attached tarball, you can simply
 bootstrap your composite widgets into types directly so that when
 you create an instance it already has it's interface sub-components
 created. (such as a preferences dialog or item editor widget or
 user status thingy or whatever is relevant for your application).

 Thanks, grabbed that to look through now. I haven't done more than
 notifications or config menus before so it's all new to me.

 This is a little orthogonal to optional viewing of sub-components of your
 application, typically we control what components of an application are
 visible via the View menu, and we load/save this state along with any
 relevant session data (possibly to a GKeyFile)

 I don't really want to just turn widgets on or off but just trying to
 find away to make vast changes to ui using something simple like a
 conf file. although i should learn to walk before running by the looks
 of it.

For an idea, there exists a library called gdl (gnome docking library), I'm not
sure how maintained/current it is, it was used by Anjuta IDE (not sure if
Anjuta is still using/maintaining that).

The docking library exposed special widgetry that allows the user to place
portions of the user interface into Paned windows, Notebook Tabs, or floating
separately as separate toplevel windows, then that library would serialize
the current state into some kind of session data (so that a user could view the
Anjuta IDE in their own preferred setup).

I think your use case seems to be different but the general idea the same:
optionally show portions of a ui, and optionally show them in different
configurations, and allow loading/saving of current configurations.

However, you might consider using libgdl directly (not sure if it's ported
to GTK+3 but that shouldn't be too hard to accomplish...), since that seems
to be a more user friendly way to allow users to configure an application
than demanding that they edit a configuration file by hand but I'm not
entirely clear on what your requirements are...

Cheers,
  -Tristan


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

Re: [beginner] widget layout and resizing

[Tristan Van Berkom]

On Tue, Jan 24, 2012 at 8:24 AM, Axel FILMORE axel.film...@gmail.com wrote:
 Hi there,

 I'm developing an experimental panel, not something really serious
 currently, just to learn Gtk+ and Vala.

 I've done a few things yet, creating an application menu, adding some
 launchers, adding some widgets like, a pager, a window list from libwnck.

 I searched into existing panels how things work, read some docs, but
 something I still can't understand is how I can set a fixed size for my
 panel and avoid any widget or container to resize the top level window.

 I tried set_size_request or size_allocate, for some reasons, only
 size_allocate seems to work to resize a libwnck pager, but it doesn't work
 for a Button.

 I tried to use a Box, Fixed or Grid container without much success, I
 suspect that I would need to handle some particular signals to do the widget
 layout, but, I just don't know what signal I should handle.

 I would like an efficient method to resize any widget or container in order
 that it fits into the top level window and that no widget can resize the top
 level window.

A widget will always receive it's requested minimum width and minimum height.

If that minimum width/height is too big in your opinion, you should then check
how you've constructed those children, make sure that labels ellipsize and
that the font sizes/included icons etc actually fit the sizes you desire.

Bottom line is that the child widget defines how much content must be
shown, under-allocations (below the minimum width and height requests)
are not allowed.

If you want to clip out content of a child widget, then you should put it
into a GtkViewport or and possibly a GtkScrolledWindow.

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

Re: discoveries! gtk DOES dim... how can i infinite-loop?

[Tristan Van Berkom]

On Fri, Jan 20, 2012 at 8:12 AM, Gary Kline kl...@thought.org wrote:
 On Thu, Jan 19, 2012 at 11:18:22AM +0100, David Ne??as wrote:
 Date: Thu, 19 Jan 2012 11:18:22 +0100
 From: David Ne??as y...@physics.muni.cz
 Subject: Re: discoveries! gtk DOES dim... how can i infinite-loop?
 To: Gary Kline kl...@thought.org
 Cc: GTK Devel List gtk-app-devel-list@gnome.org

 On Thu, Jan 19, 2012 at 12:58:09AM -0800, Gary Kline wrote:
  i've spent the last many days tryoing [on ubuntu] anf tonight on my
  EEE-900A netbook [debian].  both dim when i go into a recursive
  loop.
 
  1.  edit with gvim
  2.  have espeak voice gvim when it is written
  3 goto 1;
 
  tonight i did everything absolutedly write in chercking various
  things, but the app still dimd if i have the function call itselg.
 
  i should have asked this list whether there there is  a gtk call
  that let's things go into  either  an infinite loop, or, would a
  for() loop work for 300-500 loops?
 
  if not, i need to rethink my algorithm.

 That is probably what you have to do.

 If I understand what your code does (and how) then while gvim is running
 your app is *not*.  Your app is blocked and waits until gvim terminates.
 The same for espeak.


        i think you have it nailed!  [g]vim creates a .SWAP file in
        the pwd; so since gvim creates .talk.N.txt.swp while the
        textfile is being types into, i do a while(!done) check on
        the .swap file.  then i do a second while loop while
        talk.N.txt exists.  finally, espeak [flags] | aplay speaks
        the words in the text file.  [ i tee the output of espeak
        and hand it off to aplay because of strange driver bugs here
        on my desktop.]



 You need to use a function such as g_spawn_async() to execute it.  Then
 it depends how you communicate with the programs.  If you just want to
 know when it terminates use waitpid().


        thanks much.  i'll check g_spawn_async() to see how it is
        used.  i hadn't thought of any of the flavors of wait;
        everything has worked: gvim//write-quit/espeak a dozen
        times.
        but the gtk app is greyed and the quit button doesn't work!

FWIW, we have g_child_watch_add() which is generally easier to
use than calling waitpid() directly (usually you don't want to
block on waitpid(), so you would have to handle the SIGCHLD unix
signal and then call waitpid() from the unix signal, which has
effectively pre-empted your process... since doing all of this
is much more complex than it needs to be, I highly recommend
using g_child_watch_add() to do this safely for you).

Cheers,
 -Tristan


        gary

 Yeti


 --
  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
           Journey Toward the Dawn, E-Book: http://www.thought.org
          The 8.57a release of Jottings: http://jottings.thought.org
             Twenty-five years of service to the Unix community.

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

Re: any easy way of having a YES/NO dialog return a 1 or 0?

[Tristan Van Berkom]

2012/1/17 David Nečas y...@physics.muni.cz:
 On Tue, Jan 17, 2012 at 04:12:51PM +0900, Tristan Van Berkom wrote:
 Even in english, these boolean YES/NO questions can seem ambiguous,

 If you use wordy and convoluted questions such as

   Are you sure you want to quit without saving

 then nothing can help the poor users.  Of course, they are also
 susceptible to mistranslation.  The fix is brevity and clarity, not
 banning Yes and No.  The question

    Does 2+2 equal 5?

 is not improved by buttons labels ‘It is five’ and ‘It is some other
 number’.

When is the last time a program asked you that question in a dialog ?


 Hence

    Are you sure you want to quit without saving ?

 Should typically have the answers: Save Quit

 is nonsense.  This question should not occur in a sensible GUI no matter
 what answers are offered.

You are arguing that sensible guis should allow you to quit without
warning the user that there is unsaved data ?

What do you propose instead ?

Are you really suggesting that we revert to unsophisticated
error prone yes/no dialogs that plagued the 90s ?

I think by 2012 we've learned our lessons about this.

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

Re: any easy way of having a YES/NO dialog return a 1 or 0?

[Tristan Van Berkom]

On Tue, Jan 17, 2012 at 10:53 AM, Gary Kline kl...@thought.org wrote:
 On Sun, Jan 15, 2012 at 10:46:21PM +0100, David Ne??as wrote:
 Date: Sun, 15 Jan 2012 22:46:21 +0100
 From: David Ne??as y...@physics.muni.cz
 Subject: Re: any easy way of having a YES/NO dialog return a 1 or 0?
 To: Gary Kline kl...@thought.org
 Cc: GTK Devel List gtk-app-devel-list@gnome.org

 On Sun, Jan 15, 2012 at 01:26:53PM -0800, Gary Kline wrote:
  is there a way of having a YES/NO dialog [that asks a qauestion]
  return a truth value? i'm looking for something like the macro
  eprint(...) that James Steward sent in late december.

 Use gtk_message_dialog_new() with GTK_BUTTONS_YES_NO buttons type.
 Your boolean is then equal to

     gtk_dialog_run(dialog) == GTK_RESPONSE_YES

 (which also runs the dialog but you can, of course, separate the
 execution and comparison).

  if i eventually figured out a similar marcro that included:
 
      GTK_STOCK_YES,1,
      GTK_STOCK_NO, 0...

 I don't understand what stock item names have to do with this.

 Yeti

        this is why i asked the question!

        thank you,

Just because, curiously nobody seems to have said this already
in this thread,

You do realize that there is a good reason why we try to discourage
people from creating YES/NO dialogs right ?

Even in english, these boolean YES/NO questions can seem ambiguous,
to the user, as specially if you start off with a macro in your code and
try to form all of your questions in a way that will have a yes or no answer.

But the moment you localize your application then this becomes a more
serious problem, translators can easily shift the words of your dialog
around to sound more natural in another language, in which case
the YES/NO answer can be even more ambiguous.

For instance:
  Are you sure you want to quit without saving
Might come out in another language like:
  Don't you want to save before you quit ?

To make things more problematic, some languages don't have
words for YES and NO, or they don't make sense in most
english contexts.

Also, in a language like Korean or Japanese, it's very confusing
because very often, the opposite word than the one in english
would be used.

For instance, if I ask it's not easy is it, in english one would
reply NO, its not, in Korean one would reply YES, it's not.

In any case, to avoid this ambiguity, what we do is try
to always use meaningful answers to the questions
we pose in dialogs.

   Are you sure you want to quit without saving ?

Should typically have the answers: Save Quit

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

Re: GTK 3 support status

[tristan . van . berkom]

On 2011-12-06, at 8:12 PM, Andrew Cowie and...@operationaldynamics.com wrote:

 On Tue, 2011-12-06 at 17:47 +0900, Tristan Van Berkom wrote:
 
 gtk_widget_set_size_request() should still succeed with the expected 
 behaviour
 of setting the minimum size of a widget,
 
 So, does it do so for GtkLabel? ie, is it acceptable to call it?
 
 [this thread has become a bit confusing]


Yes, gtk_widget_set_size_request() will
set the minimum size for a label, as it
will for any widget.

Don't confuse that with limiting a widget's size,
a label will request a minimum size based on
it's content and configuration, it may require more
width than the explicit minimum size set by the
user.

A widget's size can only be limited by limiting
what content will be displayed inside it (for label
widgets this is done using width-chars/max-width-chars
in conjunction with ellipsizing/wrapping).

Cheers,
 -Tristan


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

Re: Label resizing window, ellipsizing

[Tristan Van Berkom]

Try setting width-chars property as well as max-width-chars property.

GtkLabel apis could use a face-lift. It's possible that the default minimum
width request exceeds the 10 max-width-chars which you set (which is
what I assume is causing this problem).

Cheers,
  -Tristan

On Fri, Dec 9, 2011 at 1:39 AM, David Gomes davidrafago...@gmail.com wrote:
 Hello there,

 I was wondering if there was a way of avoiding a label (in a notebook)
 to resize the window when the text in it is too big.

 I heard of ellipsizing, and EllipsizeMode.END seems great for me, but
 if I ellipsize it, it will be ellipsized even if the label is small.

 So, I want to ellipsize it only when it becomes too big (over X
 pixels), but I only seem to be able to limit it's width in chars using
 max_width_chars. I also tried setting my label's max_width_chars to
 10, but the string could still increase a lot, so it didn't work.

 What do you recommend? Ideally, I would like to have a maximum width
 in pixels, but chars is ok too.

 /* Relevant code (vala) */
 tab.label.max_width_chars = 10;

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

Re: GtkTreeView very slow for large lists

[Tristan Van Berkom]

On Fri, Dec 16, 2011 at 10:32 PM, John Lindgren john.lindg...@aol.com wrote:
 Steve,

 I use the time shell command and wait for my CPU meter to drop back to
 idle before quitting the test program, giving something like this:

    time ./list-test

    real    0m31.719s
    user    0m29.168s
    sys    0m0.023s

GtkTreeView should definitely be usable with millions of rows in
the data model.

Remember that should is a word with many implications, things
that GtkTreeView should be doing include avoiding requesting the
size for every row in the model.

And of course your GtkTreeModel implementation should not
load all actual data but instead implement the interface in a way
that data is only loaded on demand (one should be able to tell
how large, how many rows without actually pulling the data for
every row).

A good starting point would be to open gtktreeview.c and start
figuring ways to avoid the loop which currently itterates over the
entire data store and finds the perfect size of the treeview.

A good technique for this would be to synchronously request
the size for all visible rows (which is currently done), plus request
the size of 1 or 2 visible page sizes of previous and following rows.

After that one might check the width and height requests of only
one out of every 10 thousand following rows (assuming a 5 million
row treeview or such, make a reasonable calculation), and estimate
the total size of the treeview height/width based on that.

The estimated non-visible size of the treeview is really only useful
for driving the adjustment page size and current location used for
the scrollbars.

In terms of responding to height-for-width requests, it's only
really important to report true height-for-width until you reach
gdk_screen_height(), and only in order to support treeviews which
are not placed into scrolled windows. For treeviews placed into
scrolled windows (if it were the only use case), the treeview could
simply report a height request of 1 pixel and not calculate anything
synchronously at all.

Thankyou for looking into GtkTreeView performance ;-)

Kind Regards,
-Tristan


 -- John

 On 12/16/2011 12:24 AM, Steve . wrote:
 John,

 Time to pop the window and populate. The cpu use meter (kinda real
 time, 500ms sample) shows between 500ms ans 1 second.

 Do you have a preferred timer method, if so i could throw a snip
 before gtk init, and maybe in the main loop idle?  Now that i'm
 thinking about it, what is the best way to measure gtk activity?

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

Re: no joy... with bvox into hbox

[Tristan Van Berkom]

On Mon, Dec 12, 2011 at 4:22 PM, Gary Kline kl...@thought.org wrote:

 i've tried everything i can think of--or find examples for online to
 put two vbox buttons into One hbox,Anybody else?

What's a 'vbox button' ?


 gary



 --
  Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
           Journey Toward the Dawn, E-Book: http://www.thought.org
          The 8.57a release of Jottings: http://jottings.thought.org
             Twenty-five years of service to the Unix community.

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

Re: mutex doubt

[Tristan Van Berkom]

2011/12/8 Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP -
marcelo.va...@claro.com.br:
On 6 December 2011 18:14, Tristan Van Berkom t...@gnome.org wrote:
 Or, can glib programs which don't make use of GObject use
 threads at all ?

sure.

 Out of curiosity, do you recommend me to use GObject to any glib program? Or 
 only for those I need to integrate with other languages?

Yes I do.

The learning curve for writing object oriented code in plain C with the aid
of the GType system can be a bit steep, but well worth the effort (and it's
become my preference, even if only because there is no 'black box' which
is evilly trying to manage my memory allocations on my behalf, but that
is arguably a matter of taste...).

I'm thoroughly convinced that the minutes I lose copy/pasting and
search/replacing the basic boiler plate code needed to write a
GObject pays off very very much just by allowing me to write object
oriented code.

I would think language bindings as a very very secondary advantage
to writing code with GObject, surely language bindings can even be
made for C libraries who dont leverage GObject anyway.

Cheers,
 -Tristan


 Thanks for the rest of the answers, it was very elucidative.


 Esta mensagem, incluindo seus eventuais anexos, pode conter informações 
 confidenciais, de uso restrito e/ou legalmente protegidas. Se você recebeu 
 esta mensagem por engano, não deve usar, copiar, divulgar, distribuir ou 
 tomar qualquer atitude com base nestas informações. Solicitamos que você 
 elimine a mensagem imediatamente de seu sistema e avise-nos, enviando uma 
 mensagem diretamente para o remetente e para postmas...@claro.com.br. Todas 
 as opiniões, conclusões ou informações contidas nesta mensagem somente serão 
 consideradas como provenientes da Claro ou de suas subsidiárias quando 
 efetivamente confirmadas, formalmente, por um de seus representantes legais, 
 devidamente autorizados para tanto.
 --
 Este mensaje, incluyendo sus eventuales archivos adjuntos, puede contener 
 informaciones confidenciales, de uso restringido y/o legalmente protegidas. 
 Si usted ha recibido este mensaje por error, no debe utilizar, copiar, 
 divulgar, distribuir o tomar cualquier actitud basada en estas informaciones. 
 Solicitamos la inmediata eliminación del mensaje de su sistema y el envío de 
 un informe en forma directa al remitente y a postmas...@claro.com.br. Todas 
 las opiniones, conclusiones o informaciones contenidas en este mensaje 
 solamente serán consideradas como provenientes de Claro o de sus subsidiarias 
 cuando sean efectivamente confirmadas, formalmente, a través de uno de sus 
 representantes legales debidamente autorizados a tal fin.
 --
 This message, including all attachments transmitted with it may include 
 restricted, legally privileged, and/or confidential information. If you 
 received this message by mistake or in error you are hereby notified that you 
 must not use, publicize, copy, distribute, resend, or take any action based 
 on the information contained in the message. We ask you to delete the message 
 immediately from your system and advise us by sending a message directly
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 3 support status

[Tristan Van Berkom]

On Tue, Dec 6, 2011 at 1:15 AM, John Lindgren john.lindg...@aol.com wrote:
 Hi Tristan,

 This makes a bit more sense now.


 On 12/05/2011 09:27 AM, Tristan Van Berkom wrote:

 On Mon, Dec 5, 2011 at 11:18 PM, John Lindgrenjohn.lindg...@aol.com
  wrote:

 It looks to me as though there are 3 separate problems contributing here:

 1. GtkLabel does not take into account gtk_widget_set_size_request() when
 reporting its natural size:
 https://bugzilla.gnome.org/show_bug.cgi?id=662043

 Not a bug.

 No widgets should ever peek at the explicit user set size request to
 implement the size negotiation vfuncs.

 Those are handled in GtkWidgetClass.adjust_size_request() base class
 implementation.


 So using gtk_widget_set_size_request() as a way to set the width of a label
 is no longer valid in GTK+ 3.  Fair enough.

That is true, GtkLabel in GTK+2 did do some sneaky things like peeking at
the user set size request, it no longer does this.

gtk_widget_set_size_request() should still succeed with the expected behaviour
of setting the minimum size of a widget, however it does not limit the size
of any widget.



 2. Nor does it take into account gtk_label_set_width_chars():
 https://bugzilla.gnome.org/show_bug.cgi?id=665560

 It does, width-chars, as always, only effects the minimum size, not
 the natural size.


 I get it now.  You set the minimum width of a label with
 gtk_label_set_width_chars() and the natural/default width with
 gtk_label_set_max_width_chars().

 The documentation is very misleading; actually, the entire documentation for
 gtk_label_set_width_chars() consists of the sentence fragment, Sets the
 desired width in characters of label to n_chars.  I do not think that most
 people would make the connection between desired width and minimum
 width.

 Likewise, the documentation for gtk_label_set_max_width_chars() is, Sets
 the desired maximum width in characters of label to n_chars.  I do not
 think that most people would make the connection between desired maximum
 width and natural/default width.


I couldn't agree more, and I'm sorry for lack of time and patience for
documenting
GtkLabel properties better.

Would you like to re-phrase that documentation yourself and send it back
to the list ?

I'll take that and correct anything that might be inaccurate and send
it back to this list... (perhaps we should CC gtk-devel-list in this case).

Others will have a (short) chance to interject... and if there are no objections
to the new documentation within a short time I'll go ahead and commit
that to GTK+ so that next time around the online docs will be better.

Reasonable plan ?


 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to
 its
 natural size if the window is not resizable:
 https://bugzilla.gnome.org/show_bug.cgi?id=665596

 As I mentioned in the previous mail, I believe this has *always* been the
 case,
 GtkWindow always shrinks down to minimum size (or now in GTK+3 'natural
 size')

 This is how you get the shrinking dialogs when closing the expander in
 them
 (for non-resizable windows).

 However, it could be considered a bug, one would expect GtkWindow to make
 an attempt to honor a user set default size for a non-resizable window.

 Perhaps it's even a regression from GTK+2, not so sure.


 I think it should be considered a bug; however, I do not care so much about
 gtk_window_set_default_size() now that I can set the size of the label
 directly.  Using gtk_window_set_default_size(), you might recall, was your
 suggestion from an earlier mail:

Yes, whether it is a regression or not I think it's a valid bug, apis in GTK+
should definitely make an attempt at succeeding ;-)

However, GtkWindow itself is a very tricky object to not break (on X11
platform it has to deal with this 'window constraint' api to cooperate
with the X server), it's possible that it just doesn't make sense to implement
this properly.

In which case the fix might be adding documentation to
gtk_window_set_resizable()
to indicate that the window will always be forced to the natural size
requests of its
content, regardless of any previously set default size.

 So I'm attaching my version of your test case, actually except for
 the label being somehow severely broken here, your code works
 nicely... I added a line that says gtk_window_set_default_size()
 and I think that will fix all your problems.


 Thanks for your help.  I will close #662043 and #665560 but add a comment
 that the documentation is wrong and needs to be updated.

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

Re: GTK 3 support status

[Tristan Van Berkom]

On Mon, Dec 5, 2011 at 10:56 PM, John Lindgren john.lindg...@aol.com wrote:
 On 12/05/2011 02:22 AM, Tristan Van Berkom wrote:

 On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkomt...@gnome.org  wrote:

 Hi John,

   I am responsible for a large part of your pain.

 And I'm also surprised that this code is not working for you.

 The last time I looked at size negotiation, the toplevel window
 constraints
 have always been based on the minimum-for-minimum request of the
 window contents (minimum height for minimum width).

 However, some observations while running your test:
  o The minimum size constraint of your window is correct, it's set to
 about
     20 chars of width, this is the smallest size your window can be
     (firing up your test case allows me to shrink the window to that
 size)
  o A *bad* ugly bug here is that your label does not ellipsize, what is
     up with that ? How come your label wraps when it was not asked to
 wrap ?
  o If the label were configured to wrap, then it *must* require at least
 the
     minimum height for it's minimum width, however the broken label does
     not require that width... instead when shrinking the window it wraps
     out of view
  o Heightening the window will give some random extra allocation to
     the child label, showing the wrapped text...

 So, I can observe a behavioural change here, the toplevel window is
 behaving actually quite nicely, it seems to be constraining the window
 size to the minimum-for-minimum request, and then setting a default
 size to the natural width/height request.

 So I'm attaching my version of your test case, actually except for
 the label being somehow severely broken here, your code works
 nicely... I added a line that says gtk_window_set_default_size()
 and I think that will fix all your problems.

 Actually anyway I have an outdated branch of GTK+ here so I
 suspect I'm just running into a *really bad* label bug which
 probably never made it to any production release...

 In short, the behavioural change is that the default size of a
 window is now also derived from the natural request of it's content,
 you can easily override that by adding the 2 lines of code which
 I added to your test case, no waiting for realize hacks involved.

 Clarification: in the code I sent here... I queried the minimum width
 of the label, ideally if you just want the window to show by default at
 it's minimum width, you should query the window itself, not one of
 it's children.


 This works for resizable windows.  For fixed-size windows, however, the
 label still does not ellipsize.  I am attaching another test case.
  Uncomment line 8, and suddenly the label expands to its full, unellipsized
 width again.

Interesting.

The api around non-resizable windows needs clarification/more documentation.

It should be noted that historically in GTK+2, non-user resizable
windows are the corner case where windows are actually meant to 'shrink'
down to the smallest possible size.

However in GTK+3 now we have a natural and minimum size, I dont think
it would make sense to shrink down to the minimum size on a non-resizable
window, instead non-resizable windows should always fit the natural size
(that seems to make sense).

In order to limit the GtkLabel's natural size request (separate from
it's minimum
size request), I've added the 'max-width-chars' property.

Sending you back a working test case ;-)

I'll leave it to you to close the filed bug as a non-issue.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 3 support status

[Tristan Van Berkom]

On Mon, Dec 5, 2011 at 11:18 PM, John Lindgren john.lindg...@aol.com wrote:
 It looks to me as though there are 3 separate problems contributing here:

 1. GtkLabel does not take into account gtk_widget_set_size_request() when
 reporting its natural size:
 https://bugzilla.gnome.org/show_bug.cgi?id=662043

Not a bug.

No widgets should ever peek at the explicit user set size request to
implement the size negotiation vfuncs.

Those are handled in GtkWidgetClass.adjust_size_request() base class
implementation.


 2. Nor does it take into account gtk_label_set_width_chars():
 https://bugzilla.gnome.org/show_bug.cgi?id=665560

It does, width-chars, as always, only effects the minimum size, not
the natural size.


 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to its
 natural size if the window is not resizable:
 https://bugzilla.gnome.org/show_bug.cgi?id=665596

As I mentioned in the previous mail, I believe this has *always* been the case,
GtkWindow always shrinks down to minimum size (or now in GTK+3 'natural size')

This is how you get the shrinking dialogs when closing the expander in them
(for non-resizable windows).

However, it could be considered a bug, one would expect GtkWindow to make
an attempt to honor a user set default size for a non-resizable window.

Perhaps it's even a regression from GTK+2, not so sure.

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

Re: GTK 3 support status

[Tristan Van Berkom]

On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren john.lindg...@aol.com wrote:
 On 12/04/2011 04:02 AM, Emmanuele Bassi wrote:

 the status is always the same: bugs reported will be looked at by the
 gtk maintainers depending on time.


 So the status at this moment is that no developers have time to look at bugs
 reported by application developers.  Or is there something wrong with my
 report in particular?


 the source of the issue is that gtk3 does not allow widget
 underallocations, unlike gtk2. underallocations were a huge source of
 edge cases, code complexity, and nasty bugs in gtk2 and when the time
 came to review the size negotiation implementation, and add support
 for height-for-width and width-for-height, keeping support for
 underallocations would have made the code balloon out of the
 maintainership capabilities of the gtk team - as well as introduce new
 and exciting bugs. this is why setting the minimum size using
 set_size_request() will not work in your case: the label's minimum
 size is bigger than the size you requested.

 long story short: if you want to set the minimum size on a label you
 can do it with the set_width_chars() method:


 http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars


 Thank you for the suggestion.  Unfortunately, when I tried it just now, that
 method also no longer works in GTK+ 3.x.  Accordingly, I have reported this
 problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560


Hi John,
   I am responsible for a large part of your pain.

And I'm also surprised that this code is not working for you.

The last time I looked at size negotiation, the toplevel window constraints
have always been based on the minimum-for-minimum request of the
window contents (minimum height for minimum width).

However, some observations while running your test:
  o The minimum size constraint of your window is correct, it's set to about
 20 chars of width, this is the smallest size your window can be
 (firing up your test case allows me to shrink the window to that size)
  o A *bad* ugly bug here is that your label does not ellipsize, what is
 up with that ? How come your label wraps when it was not asked to wrap ?
  o If the label were configured to wrap, then it *must* require at least the
 minimum height for it's minimum width, however the broken label does
 not require that width... instead when shrinking the window it wraps
 out of view
  o Heightening the window will give some random extra allocation to
 the child label, showing the wrapped text...

So, I can observe a behavioural change here, the toplevel window is
behaving actually quite nicely, it seems to be constraining the window
size to the minimum-for-minimum request, and then setting a default
size to the natural width/height request.

So I'm attaching my version of your test case, actually except for
the label being somehow severely broken here, your code works
nicely... I added a line that says gtk_window_set_default_size()
and I think that will fix all your problems.

Actually anyway I have an outdated branch of GTK+ here so I
suspect I'm just running into a *really bad* label bug which
probably never made it to any production release...

In short, the behavioural change is that the default size of a
window is now also derived from the natural request of it's content,
you can easily override that by adding the 2 lines of code which
I added to your test case, no waiting for realize hacks involved.

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

Re: GTK 3 support status

[Tristan Van Berkom]

On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom t...@gnome.org wrote:
 On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren john.lindg...@aol.com wrote:
 On 12/04/2011 04:02 AM, Emmanuele Bassi wrote:

 the status is always the same: bugs reported will be looked at by the
 gtk maintainers depending on time.


 So the status at this moment is that no developers have time to look at bugs
 reported by application developers.  Or is there something wrong with my
 report in particular?


 the source of the issue is that gtk3 does not allow widget
 underallocations, unlike gtk2. underallocations were a huge source of
 edge cases, code complexity, and nasty bugs in gtk2 and when the time
 came to review the size negotiation implementation, and add support
 for height-for-width and width-for-height, keeping support for
 underallocations would have made the code balloon out of the
 maintainership capabilities of the gtk team - as well as introduce new
 and exciting bugs. this is why setting the minimum size using
 set_size_request() will not work in your case: the label's minimum
 size is bigger than the size you requested.

 long story short: if you want to set the minimum size on a label you
 can do it with the set_width_chars() method:


 http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars


 Thank you for the suggestion.  Unfortunately, when I tried it just now, that
 method also no longer works in GTK+ 3.x.  Accordingly, I have reported this
 problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560


 Hi John,
   I am responsible for a large part of your pain.

 And I'm also surprised that this code is not working for you.

 The last time I looked at size negotiation, the toplevel window constraints
 have always been based on the minimum-for-minimum request of the
 window contents (minimum height for minimum width).

 However, some observations while running your test:
  o The minimum size constraint of your window is correct, it's set to about
     20 chars of width, this is the smallest size your window can be
     (firing up your test case allows me to shrink the window to that size)
  o A *bad* ugly bug here is that your label does not ellipsize, what is
     up with that ? How come your label wraps when it was not asked to wrap ?
  o If the label were configured to wrap, then it *must* require at least the
     minimum height for it's minimum width, however the broken label does
     not require that width... instead when shrinking the window it wraps
     out of view
  o Heightening the window will give some random extra allocation to
     the child label, showing the wrapped text...

 So, I can observe a behavioural change here, the toplevel window is
 behaving actually quite nicely, it seems to be constraining the window
 size to the minimum-for-minimum request, and then setting a default
 size to the natural width/height request.

 So I'm attaching my version of your test case, actually except for
 the label being somehow severely broken here, your code works
 nicely... I added a line that says gtk_window_set_default_size()
 and I think that will fix all your problems.

 Actually anyway I have an outdated branch of GTK+ here so I
 suspect I'm just running into a *really bad* label bug which
 probably never made it to any production release...

 In short, the behavioural change is that the default size of a
 window is now also derived from the natural request of it's content,
 you can easily override that by adding the 2 lines of code which
 I added to your test case, no waiting for realize hacks involved.

Clarification: in the code I sent here... I queried the minimum width
of the label, ideally if you just want the window to show by default at
it's minimum width, you should query the window itself, not one of
it's children.


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

Re: Displaying domain objects with GtkTreeView

[Tristan Van Berkom]

2011/11/28 Rafał Krupiński r.krupin...@gmail.com:
 Hi all!

 How do I display list of custom objects in GtkTreeView?
 GtkTreeView takes GtkListStore as a model, but it doesn't allow custom
 objects, only list of gobjects.

What could that possibly mean ?

If you have custom derived GObjects, you can certainly populate a
list-store with them.

If you have something-else-objects that are not GObjects, you can always use
G_TYPE_POINTER to hold them (it would be up to you to ensure that their life
cycle is somehow bound to the liststore... i.e. that those objects are
not destroyed
while cell renderers are trying to access them).

 On the other hand, when I want to read list's selection all I get is
 the GtkListStore model - list of gobjets and I have to figure out the
 actual domain object the data comes from.

You don't get a list of gobjects as far as I know, I'm not sure where you are
getting that from.

When you observe a GtkTreeSelection you get 'rows' of data, those
rows can contain any information which you put into it when you configured
the underlying list-store.

If you configured a column as a list of gobjects, then there is
probably a 'list-of-gobjects'
to be found for every row... but that would only be because you
provided those gobjects
to begin with.

 I thought of adding a hidden column with some id, but maybe there is a
 better solution?

Again not really sure what you are trying to do... remember that columns in a
GtkTreeModel are neither visible or hidden, they are just values which can be
rendered by a view.

Whether you decide to render all of the data from the liststore with
cell renderers
or to render just some of that data is up to you.

Hope this helps,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Displaying domain objects with GtkTreeView

[Tristan Van Berkom]

2011/11/28 Rafał Krupiński r.krupin...@gmail.com:
 On 28.11.2011 14:17, Tristan Van Berkom wrote:

 2011/11/28 Rafał Krupińskir.krupin...@gmail.com:

 Hi all!

 How do I display list of custom objects in GtkTreeView?
 GtkTreeView takes GtkListStore as a model, but it doesn't allow custom
 objects, only list of gobjects.

 What could that possibly mean ?

 If you have custom derived GObjects, you can certainly populate a
 list-store with them.

 If you have something-else-objects that are not GObjects, you can always
 use
 G_TYPE_POINTER to hold them (it would be up to you to ensure that their
 life
 cycle is somehow bound to the liststore... i.e. that those objects are
 not destroyed
 while cell renderers are trying to access them).

 How exactly do I do that? I only know that cell renderers can access model
 fields by index, which implies that the model must be a list (or tuple,
 since I'm using python).

The model must be a GtkTreeModel, the GtkTreeModel implementation can
be a flat list, implementations are allowed to let rows have children (i.e. it
can be a tree of data).

I don't know what API python is giving to you, if it's so very
different than the
C API than that is a good way to obfuscate code and confuse new users.


 On the other hand, when I want to read list's selection all I get is
 the GtkListStore model - list of gobjets and I have to figure out the
 actual domain object the data comes from.

 You don't get a list of gobjects as far as I know, I'm not sure where you
 are
 getting that from.

 [...]

 Ok, I'm noob with Gtk/GLib, so I might've used wrong words. Plus I'm using
 python, so I didn't have to care about GTypes/GObjects.

 Anyway, I can display ListView using list of strings as a model. That data
 is copied from my domain object. The problem is, when I read the data from
 the ListView I get those strings and I have to figure out the actual domain
 object for myself.

I suppose this domain object is another Python concept ? or a concept which
is local to your program's business logic ?


 I wanted to know how to use my domain object as a ListStore model for
 reading and writing - that chapter is missing from the Tree View Tutorial
 I've found.

 Best Regards
 Rafał Krupiński

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

Re: Is there a developer wiki for gtk?

[Tristan Van Berkom]

On Sun, Nov 27, 2011 at 11:48 AM, Stevie Griffiths
stevie.craig.griffi...@gmail.com wrote:
 Hi,
 Does such a developer wiki exist?

 (note I think the API documentation and API is good, mostly)

 I've been feeling frustrated every time I want to learn something new with
 GTK.  I write apps mostly on my own, with internet access on my mobile,
 where downloading the source of other apps to understand what they did
 feels like an unreasonable expectation.

 I want to create a visually grouped set of buttons without writing a new
 widget, similar to what's been appearing in other gtk apps and has been
 used in native mac apps for some time.

 I feel unsure if it is possible on one hand and on the other I feel it
 should be a simple matter of overwriting just a small number of style
 elements and defining a left, middle and right button and adjusting the
 padding, margins and how the corners are drawn.

 Everytime I want to learn something new with GTK I end up feeling
 frustrated at how hard I have to work to learn something simple.  I don't
 want to constantly ask people I don't know how to do things when I feel
 there responses are thoughtless, cruel, unkind and often useless (just to
 be careful I've never used this list before I think, however I still feel
 wary of it). Even when in many cases I feel I have done the hard work and
 generally know the subject matter better.

 (I love dealing with people, but you hit the internet and it feels like
 everyone becomes nasty)

 If there was an official wiki I'd want to give up hours of time, updating
 it and providing what knowlege I posess because I want something
 centralised, refined and solid to refer too learn or re-learn what I
 forget.  So far as I can tell and I may be wrong it's just not there.

 Thanks for taking the time to read and I want to be careful and say
 thankyou for any effort to improving GTK in any way you have made, I feel
 grateful and (mostly) enjoy using it.

Hi,
Please feel free to ask newbie or advanced questions on this list.

I have found this list very helpful over the years, when I started using this
list it was much much more of an elitist society of RTFM-like responses.

Remember that nobody is required to respond to questions (I dont know
of any paid positions for that sort of thing, it's all volunteer work).

If you ask a question that sounds like a demand, you will certainly get
a cold response if you get any response at all, because as I mentioned
above, anyone who answers your question is doing it on their own time.

A clear subject line is always very important, sometimes even finding
the right way to form your question will give you the answer before
sending the email (in my first years I can remember discarding almost
half of my emails which were just questions which I had not yet phrased
properly).

Showing/proving that you have done your part of the research and have hit
a dead-end helps to earn you sympathy points.

For your particular question about those MacOS button-group-thingies,
those are implemented in GTK+-3 using CSS.

I can't tell you the exact details because I have not used that exact feature
myself.

I expect that it works specifically for GtkButtons inside a GtkButtonBox,
the GtkButtonBox will apply pseudo classes to the first and last of its
children (allowing you to style them differently, i.e. with the round endings).

So, all you need to do is find out if it is indeed the GtkButtonBox which
implements this pseudo-classing of it's children, or if it can be done with
a simple GtkBox... then you need to find out the actual name of the
pseudo-class (i.e. is it called first-child and last-child ?).

Finally you need to cook up the right css to say that first-child children
of a GtkButtonBox get a specific style (probably you will provide a 9-slice
image for that).

Good luck and welcome to our friendly list.

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

Re: GtkBuilder bugs

[Tristan Van Berkom]

On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek hramr...@centrum.cz wrote:
 On 4 September 2011 12:32, Tristan Van Berkom t...@gnome.org wrote:
 Its a bug that needs to be fixed in Glade.

 You can remove the line that says n-rows safely fwiw

 I don't think that an extra property would break the widget, the
 warning should be harmless.


Anything that GtkBuilder encounters that is unrecognized (unrecognized
xml tags, properties and even unknown/inexistant GObject properties) cause
GtkBuilder to either abort or fail to parse.


 On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster
 schuster.bernh...@googlemail.com wrote:
 I am using a gtk-builder file for my application, which uses a Grid
 widget for layouting. When I run the application, I read this:

 Gtk-WARNING **: Unknown property: GtkGrid.n-rows

 and the grid is not shown (nor its contents)

 Are you by any chance using glade 3.10?

 That won't work.


No Glade earlier than 3.10 allows you to edit a GtkGrid, however
the Grid implementation is based on the old GtkTable implementation.

To remove the erronously serialized n-rows/n-columns properties from
GtkGrid in Glade we first need to add some code to the GtkGrid deserialization
routine to guess the span in row/columns based on the span of all children
and number/position of added placeholders.

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

Re: GtkBuilder bugs

[Tristan Van Berkom]

On Mon, Sep 5, 2011 at 12:43 PM, Michal Suchanek hramr...@centrum.cz wrote:
 On 5 September 2011 11:29, Tristan Van Berkom t...@gnome.org wrote:
 On Mon, Sep 5, 2011 at 10:49 AM, Michal Suchanek hramr...@centrum.cz wrote:
 On 4 September 2011 12:32, Tristan Van Berkom t...@gnome.org wrote:
 Its a bug that needs to be fixed in Glade.

 You can remove the line that says n-rows safely fwiw

 I don't think that an extra property would break the widget, the
 warning should be harmless.


 Anything that GtkBuilder encounters that is unrecognized (unrecognized
 xml tags, properties and even unknown/inexistant GObject properties) cause
 GtkBuilder to either abort or fail to parse.

 For me unknown properties are just ignored, at least in gtk 2.

Ah my bad, indeed only a warning is issued for a misplaced
property (the warnings which the Bernhard originally mentioned).




 On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster
 schuster.bernh...@googlemail.com wrote:
 I am using a gtk-builder file for my application, which uses a Grid
 widget for layouting. When I run the application, I read this:

 Gtk-WARNING **: Unknown property: GtkGrid.n-rows

 and the grid is not shown (nor its contents)

 Are you by any chance using glade 3.10?

 That won't work.


 With Gtk 2 which does not know about Grid.


 No Glade earlier than 3.10 allows you to edit a GtkGrid, however
 the Grid implementation is based on the old GtkTable implementation.

 To remove the erronously serialized n-rows/n-columns properties from
 GtkGrid in Glade we first need to add some code to the GtkGrid 
 deserialization
 routine to guess the span in row/columns based on the span of all children
 and number/position of added placeholders.

 If gtk3 cannot display the glade files made for it with glade 3.10
 that's quite odd.

Agreed, however while Glade is usually behind GTK+ in terms of features
so often times Glade chokes out on hand crafted GtkBuilder xml which might
contain tags that Glade does not yet recognize.

But the opposite should usually never be a problem, unless we introduce
features with some severe bugs then files created by Glade should always
be readable by GtkBuilder (in this case we introduced GtkGrid with a bug
that at least only causes a warning... unless there is more to this
GtkGrid story...).


 I can see them in glade-previewer just fine but that's the only gtk3
 app which I use with these.

Indeed, I'm not sure what is the story with GtkGrid not showing the content
when loaded in a preview or an application (and the preview quite litteraly
does what an application would do).

Bernhard, can you perhaps attach the Glade file in question which does
not show the contents of the GtkGrid ?

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

Re: GtkBuilder bugs

[Tristan Van Berkom]

Its a bug that needs to be fixed in Glade.

You can remove the line that says n-rows safely fwiw

Cheers,
-Tristan

On Sun, Sep 4, 2011 at 1:41 AM, Bernhard Schuster
schuster.bernh...@googlemail.com wrote:
 I am using a gtk-builder file for my application, which uses a Grid
 widget for layouting. When I run the application, I read this:

 Gtk-WARNING **: Unknown property: GtkGrid.n-rows

 and the grid is not shown (nor its contents)


 Thanks for any tips


 Regards


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

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

Re: Question on touchscreen devices

[Tristan Van Berkom]

On Wed, Aug 31, 2011 at 4:10 PM, John M Ridge j...@netseats.com wrote:

 Hello all,

 I'm tinkering with the idea of writing a GTK+ app targeted at an
 industrial touchscreen all-in-one device (like this one:
 http://www.faytech.com/product_show.php?id=52). But I first would like
 to write the app to see if works on a conventional PC (with mouse)
 and then port it to the touchscreen device. My questions:

 1) Is there (from the application's point of view) any difference
 between a (left) mouse click and a tap on the screen? That's actually
 the only action I need -- no dragging, no right or middle mouse
 buttons.

 No.

 2) I will do the developing on a Linux box, but the app may end up on
 a Windows device (this depends on what my employer will ultimately
 buy). Is the touchscreen handling on Windows different than that on
 X-Windows?

 The application will function the same on both platforms.  The difference
 will be in the device drivers.  Linux will require modification of your
 xorg.conf file and a compatible driver for your device.  Most touchscreens
 come with Windows drivers and associated utilities that make them easier
 to install and configure.

 I have had no problems using Elo or Microtouch touchscreens with Linux.

Seconded, I've used the Elo driver extensively and had no problems except:

   a.) I had to hack my own calibration routine that can work without restarting
the X server, I dont know how far xorg has come since the days I was
using the XFree86 server (my hack in this case was backwards and
not worth contributing)

   b.) I had to hack the driver to skip driver recognition phase for one of
the Elo smartset (2500 ?) controllers as that slimmed down controller
did not respond to the commands to report it's identity.

As far as actually using the GTK+ toolkit on a touchscreen, you might want to
do some custom things... I was particularly not satisfied with the
GtkScale's behavior
on a touchscreen so I needed to write my own, as well as writing a
generic onscreen
keyboard etc. (I think you should expect to have to write a couple of
custom widgets for
your app to behave the way you want on a touchscreen).

Cheers,
 -Tristan


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




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

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

Re: Compile time GTK+ 3 version check

[Tristan Van Berkom]

On Sat, Apr 23, 2011 at 4:19 PM, Ardhan Madras aj...@knac.com wrote:
 Hi All,

        I want to port my application to GTK+ 3, but I don't want to broke
 with GTK+ 2 API and ABI, what is the best way to determine GTK+ 3 version in
 compile time?

 Does

 #if GTK_MAJOR_VERSION == 3

 enough for it?

I like to use the GTK_CHECK_VERSION (maj, min, micro) macro for that
kind of check.

Depending on your project, you might not want to maintain the identical
source tree to compile for GTK+2 and GTK+3... the techniques you will
end up using for GTK+3 might be different from the techniques you used
with GTK+2, in which case it's not a matter of calling one function from
GTK+2 or another for GTK+3 (for instance, if your custom widget implements
-size_request() for GTK+2, it needs to implement a set of different functions
for GTK+3)... so you might easily end up with a big mess of #ifdef hell.

On the other hand if your application consists of a simple dialog with
a couple buttons, it might make sense to use #if statements at pre-processing
time.

Anyway, with a good VCS you should be able to easily maintain an old GTK+2
branch of your project and easily backport the fixes which apply from your new
GTK+3 branch back into the old source base (and avoid the whole #ifdef mess
easily enough).

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

Re: GtkNotebook with action on click of special tab

[Tristan Van Berkom]

On Wed, Apr 20, 2011 at 8:34 AM, Bernhard Schuster
schuster.bernh...@googlemail.com wrote:
 Hi I am trying to achieve the effect of new tab openening if one tab gets
 selected. Unfortunaltly the doc is very sparse on that:
 http://developer.gnome.org/gtk/stable/GtkNotebook.html as of using the
 select-page signal. Can anyone give me a hint how to use it properly with
 a g_signal_connect function?

 Note: I am still in a learning phase so please be patient with me :)

 What I tried so far:

 gboolean
 derived_notebook_insert_page (DerivedNotebook *obj, gboolean b, gpointer
 data)
 {
 // do page insert
 }

 and within foo_derived_notebook_init: g_signal_connect (obj, select-page,
 G_CALLBACK (derived_notebook_insert_page), NULL);

 If anybody could shed some light of what the return value is for, and how to
 achiev what I want, thanks very much

Hi,
  First of all if you are deriving the notebook, you should not connect a
signal handler but instead override the class vfunc (in this case would
be GtkNotebookClass-select_page).

Also, select-page is generally a keybinding signal used to move
focus (it's used when one of the tabs have keyboard focus and
spacebar is pressed to make that tab's page the current page,
the return value I believe is whether the notebook keeps focus or
not).

Probably you want to use the switch-page vfunc which will be
called to do the work of actually changing the current page (whether
it's done by code or by user interaction, so you might have to
be careful to avoid recursion here).

Also, I have a hard time imagining how it would be desirable
to open a new tab as a result of selecting a different tab (maybe
some more context here would let us give you better advice).

Cheers,
  -Tristan


 Regards

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

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

Re: GtkTreeView signal before row change

[Tristan Van Berkom]

On Wed, Mar 9, 2011 at 12:38 AM, Lance Zhang zhan...@hotmail.com wrote:

 Hi:

 I have a situation where I need to verify data before allowing a row change 
 in a GtkTreeView. Essentially:

 1. User requests a row change through a keyboard or a mouse;
 2. Check if data in the current row has been edited without be saved, or even 
 is complete
 and valid, and prompt the user appropriately;
 3. Depending on user request, I may need to veto the row change request (aka 
 cancel)

 What's the best practice?

 A possible way is use cursor-changed signal
 1. always remember the current row (possibly by store a GtkTreeIter)
 2. in the cursor-changed signal handler, check if on the same row and go back 
 to original row by way of
 stored GtkTreeIter if necessary.

 Is there a better way? Tell me how you would approach this please.

If you need to store the current row, the safe way is to use
GtkTreeRowReference.

If you want to step in between when a user edits a cell and before it
gets committed
to the model... then you have code already in place where that can be done.

i.e. when you receive the edited signal from GtkCellRendererText, the model
does not update by itself, it's up to you to update the underlying
store (or not)
depending on the user input from the GtkCellRenderer.

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

Re: custom gtkwidget destruction

[Tristan Van Berkom]

On Fri, Feb 25, 2011 at 7:57 AM, James Morris jwm.art@gmail.com wrote:
 Hi,

 I'm a little confused over destruction of my custom widgets. I'm
 mainly looking at existing code for how to do things as I've found the
 docs (via DevHelp) difficult to understand and to garner an idea of
 when and what is needed.

 Here's some typical code for one of the widgets which is (typically)
 just a group of GtkWidgets:

 --8--
 G_DEFINE_TYPE(EnvelopeTab, envelope_tab, GTK_TYPE_VBOX)

 static void envelope_tab_destroy(GtkObject* object);
 static void update_env(EnvelopeTabPrivate*);


 static void envelope_tab_class_init(EnvelopeTabClass* klass)
 {
    GtkObjectClass *object_class = GTK_OBJECT_CLASS(klass);

    object_class-destroy = envelope_tab_destroy;
    envelope_tab_parent_class = g_type_class_peek_parent(klass);

    g_type_class_add_private(object_class, sizeof(EnvelopeTabPrivate));
 }


 static void envelope_tab_destroy(GtkObject* object)
 {
    GtkObjectClass* klass = GTK_OBJECT_CLASS(envelope_tab_parent_class);

    if (klass-destroy)
        klass-destroy(object);
 }

 --8--

 I am wondering if in this case, as there is no extra data to destroy,
 is it really necessary for me to specify the destroy function?

 Put another way, by specifying the destroy function, am I duplicating
 by 'over-riding' the 'default destructor' and/or possibly omitting
 things which should be done?

 With regard to the docs, finalize and dispose are mentioned. Are these
 only required if I explicitly need deeper control over the destruction
 (of - in this case - the widgets my widget uses)?

  a.) You generally dont need to use -destroy, just use -dispose()
for cases where you need to unref other objects that your
object holds a reference to, and use -finalize() to free any
other data/resources.

  b.) If your widget does not allocate any resources, you dont need
to define any dispose/finalize methods

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

Re: gtk_combo_box_new_text() API

[Tristan Van Berkom]

2011/2/23 Timo Schneider ti...@hrz.tu-chemnitz.de:
 On Tue, 2011-02-22 at 08:51 -0700, Kevin DeKorte wrote:

 On 02/22/2011 08:46 AM, Allin Cottrell wrote:
 
  It seems that you are in fact OK using the GtkComboBox API for
  this purpose, as in
 
  void depopulate_combo_box (GtkComboBox *box)
  {
      GtkTreeModel *model = gtk_combo_box_get_model(box);
      GtkTreeIter iter;
 
      while (gtk_tree_model_get_iter_first(model, iter)) {
          gtk_combo_box_remove_text(box, 0);
      }
  }
 
  Allin Cottrell
  ___

 If your going to use the model, then perhaps this will work...

 gtk_list_store_clear(GTK_LIST_STORE(gtk_combo_box_get_model(GTK_COMBO_BOX(combo_box;

 Yes, I can do that. But I think it's a bug in the API if I have to rely
 on a specific implementation of an API function to do something that
 simple. Why isn't there a funtion like

 guint gtk_combo_box_text_num_elements()

Sure, there is gtk_tree_model_n_children() or such (it would
be a worse idea to add api to the combo box when a perfectly
valid method of counting the liststore elements already exists).


 which returns the number of the remaining elements in the list? Because
 as of now it would be perfectly legal to _not_ use a GtkTreeModel to
 store list entries in case the ComboBox was created with the _text_
 convenience functions.
 Or the API specs should say that a combo box created with the
 convenience functions will always result in normal combo box with a
 GtkTreeModel and thus all functions are usable.

A combo box using the text api uses an internally created
liststore to store the text, it cannot use anything else but
a treemodel.

Sure, the api docs are not so clear about this, which is why
all of your documentation patches are welcome in bugzilla (the
GtkComboBoxText class new in GTK+ 2.24 might have
better documentation, but you are welcome to improve
those docs too).

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

Re: enlarge the scrollable area

[Tristan Van Berkom]

On Wed, Feb 16, 2011 at 1:49 AM, Stefano Facchini
stefano.facch...@gmail.com wrote:
 Hi,

 I'm trying to build a scrolled window in a such a way that the child widget
 has always the same size, regardless of the size of the scrolled window
 itself. I tried gtk_scrolled_window_set_min_content_width, but this also
 sets the minimum size of the scrolled window. Basically, I need something to
 force the size of the child widget (for example a TextView), or to enlarge
 the scrollable area without enlarging the scrolled window. Is it possible to
 have this behavior?

Sounds like you should be able to get away with just
gtk_widget_set_size_request()
on the child textview, that should ensure the child text view always
receives at least
the size you set for it's minimum request without restricting the size
of the parent
scrolled window.

Note: In GTK+ 2.x setting the size request of the child widget was acting like
gtk_scrolled_window_set_min_content_width/height() as a sort of implied hidden
feature, in GTK+ 3.x you can choose to force the size of the scrolled window
by using the new api or just force the size of the child by using
gtk_widget_set_size_request().

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

Re: gtk3: behavior of gtk_widget_set_size_request

[Tristan Van Berkom]

On Sun, Feb 13, 2011 at 5:49 AM, Allin Cottrell cottr...@wfu.edu wrote:
 I'm using gtk_widget_set_size_request on a GtkTreeView that gets
 embedded in a scrolled window which in turn is embedded in a
 larger window -- setting the width to 120 and leaving the height
 unset.

 This works as expected in gtk2, but in gtk3 the treeview's window
 is much narrower (doesn't look like 120), and its width doesn't
 respond even if I double the request. Am I missing some change in
 the widget-sizing code?

Yes that has changed, setting the size request now only effects
the widgets requested size.

We added gtk_scrolled_window_set_min_content_width() specifically
for your purposes.

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

Re: Horizontal TreeView?

[Tristan Van Berkom]

On Tue, Feb 8, 2011 at 8:29 PM, Gabriele Greco gabriele.gr...@darts.it wrote:
 There is a way to populate a GtkTreeView so that it grows horizontally?

 I want to setup cell columns so that physically they are ROWS of the
 GtkTreeView and obviously in a fixed number and to make the list grow
 horizontally as long as I add elements to my GtkListStore.

 I've looked in the GtkTreeView documentation but I didn't find anything that
 hints that this is possible (something like
 gtk_tree_view_set_orientation(widget, GtkOrientation) would be optimal :) ),
 but I wonder if it's possible at rc/style level since GTK already support
 right/left or top/bottom writing styles maybe it also can support
 left-right lists :)

 Otherwise I fear I'll have to build a custom widget, or try to see if adding
 widgets that rapresent my elements inside a GtkHBox within a
 GtkScrollingWindow is good looking enough :)

Currently treeview code does not allow this, however it's not a very difficult
feature to add in GTK+ 3.x... (so it may be a feature on the horizon, somebody
might contribute a patch that does this...).

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