Re: GNOME GitLab instance slow?

[Tristan Van Berkom via gtk-devel-list]

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

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

Cheers,
-Tristan

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

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

Re: compiling glade

[Tristan Van Berkom]

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

Ok, in that case, I recommend the following:

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

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

Or directly:

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

Then once you have installed BuildStream, do the following:

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

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

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

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

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

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

Cheers,
-Tristan

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

Re: compiling glade

[Tristan Van Berkom]

Hi,

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

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

But I'll just answer you here anyway :)

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

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

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

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

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

Cheers,
-Tristan

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

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

[Tristan Van Berkom]

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

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

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

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

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

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

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

Cheers,
-Tristan

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

Re: Two issues with librsvg

[Tristan Van Berkom]

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

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

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

Cheers,
-Tristan

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

Re: Locale switch on the fly

[Tristan Van Berkom]

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

Hi Igor,

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

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

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

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

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


Cheers,
-Tristan

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

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

[Tristan Van Berkom]

Hi

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

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

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

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

Cheers,
-Tristan

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

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

Re: Floating references

[Tristan Van Berkom]

On Tue, 2017-06-06 at 23:32 +0200, Rafal Luzynski wrote:
> > 6.06.2017 22:28 Chris Vine  wrote:
> > 
> > [...]
> > GObjects not derived from GInitiallyUnowned are indeed weird, as I think
> > you are suggesting. They start with a reference count of 1 but without
> > an owner.
> 
> As far as I understand owned object were supposed to be the widgets
> contained inside the containers. Not all widgets are contained (toplevel
> windows are not), also not all objects are widgets.

No.

Owned objects are objects which one owns a reference to, the concept of
ownership is a bit hard to explain and follow, because it's hard to
differentiate (there is no real material difference, except in how you
write your code) from other references.

For instance, under the hood, g_signal_emit() will retain a reference
to the emitting object during signal emission, because it requires that
object to stay alive during the course of signal emission, but emitting
a signal can cause callback cycles to occur which result in releasing
the (otherwise) final references to the object.

I would say that g_signal_emit() holds a temporary reference, but there
is *usually* somewhere in a program where ultimately the calling code
expects to be the one who has the final reference to an object, this is
the ownership ref. If the program has no ref count imbalance bugs, then
releasing an ownership reference will *eventually* result in
finalization, once any other temporary references have gone away.

That said, ownership is not always a requisite, but strong references
are; I.e. programs can be constructed where some object is created and
given to a chain/group of objects or code segments, this is not a
regular case for normal OOP patterns.

So yes, container widgets own their children.

Other non-container widgets may also own delegate objects for doing
work, like completions and such.

Non widget / Non UI objects can create and own other delegate objects
for other reasons, completely unrelated to widget hierarchies.

Also, at the most basic level, when you do:

   foo = g_object_new(MY_TYPE_FOO);

You *own* the object, in the sense that ultimately that object is your
responsibility until you either give it away (by passing it as a
parameter and subsequently calling g_object_unref()) or, until you just
decide to dispose of that object by calling g_object_unref() without
ever sharing the object.

Ownership of objects is a requirement for garbage collection in
general, it is not exclusive to the case of GtkWidgets at all.

Cheers,
    -Tristan

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

Re: Floating references

[Tristan Van Berkom]

On Tue, 2017-06-06 at 21:28 +0100, Chris Vine wrote:
> On Tue, 6 Jun 2017 22:10:39 +0200 (CEST)
> > Rafal Luzynski  wrote:
> > 
> > > > 6.06.2017 21:41 Chris Vine  wrote:
> > > 
> > > [...]
> > > No one is suggesting reworking. This is no more than intellectual
> > > interest in the original design choice.  
> > 
> > I wasn't around when this design choice was made so I can only
> > guess. I can only repeat what Tristan has already said:
> > this is a feature of GInitiallyUnowned and its descendants
> > rather than all GObject instances. At least that was originally,
> > maybe it was changed later but remained to avoid breaking the
> > backward compatibility.
> 
> GObjects not derived from GInitiallyUnowned are indeed weird, as I think
> you are suggesting.  They start with a reference count of 1 but without
> an owner.

Ok wait a second... this conversation started out with "why is the
initial ref count not 0 instead of 1 for initially unowned objects".

For the weird case of initially unowned objects, the initial ref count
being 0 or 1 is immaterial, initially unowned objects are already a
"hack", in _any_ case some state must exist on the object to denote
that it is floating, regardless of whether initial count is 0 or 1.

The normal case of an object is initial ref count of 1.

The weird case is initially unowned objects.

Initially unowned is a hack to allow programmers (_exclusively_ C
programmers) to avoid writing out g_object_unref() many times when
constructing a hierarchy of objects, manually in code.


I can see that this discussion is happening from the point of view of
programmers who use GObject directly in C code, and normally use
GObject with GTK widgets, please try to think more generally and beyond
this; the GType system in the abstract is a type system written in C,
here we have to do manually many things which OOP languages do
automatically (when using GObject directly in C).

In a code block in C, you write out:

  {
     /* You now ask for some resource, you own it */
     void *ptr = malloc(...);

     /* Use pointer */

     /* Done with pointer, you can free it */
     free(ptr);
  }

This is the same for a GObject, if you do not free the pointer, then it
is a memory leak.

Calling g_object_new() means that you absolutely *must* own the return
value, initially unowned objects are *weird* because they are a data
type which says:

   "Once I exist, I am not really owned, until something owns me"

This is already error prone because at least in C, if the pointer which
refers to an unowned object leaves scope, that unowned object is
*anyway* going to be leaked; so the caller of g_object_new() on an
initially unowned type *still* has some implied responsibility of
giving it away.

This is different when using GObject from languages which do have OOP
features directly in the language. Language bindings can do garbage
collection on your allocated resources when variables (which normally
consume/release an object reference under the hood) go out of scope, so
there is never any need to call g_object_unref() on an allocated
GObject from Vala or Python.

Today there would mostly be no need for any initially unowned objects,
then come from a time when we used to do:

  /* Creating the UI tirelessly in C code */
  label = gtk_label_new("foo");
  entry = gtk_entry_new();
  box = gtk_box_new(...);

  gtk_box_pack_start(GTK_BOX(box), label, ...);
  gtk_box_pack_start(GTK_BOX(box), entry, ...);

  /* Lets write out 1000 more lines like this because we have
   * not yet discovered GtkBuilder or UI templates...
   */

This kind of stuff was painful to write, painful to maintain, and
painful to see.

Adding an extra explicit g_object_unref() call (which would be
unnecessary in Vala or Python anyway) after each line of
gtk_container_add() or gtk_box_pack_start(), turns your already messy
1000 lines of UI construction code into 1200 lines.

That's why we have the really weird thing that is GInitiallyUnowned,
the regular case of a GObject is ref count of 1 at creation time, and
last reference release causes the dispose() cycles to occur and then
finalize().

Today we have GtkBuilder and UI templates compressed and encoded into
GResources, so there is really no need to invent GInitiallyUnowned
anymore, but it's there because of historical reasons.

Sorry for the long winded reply, as you can see, I really wish we never
had initially unowned objects in GObject :)

Autorelease pools on the other hand make more sense, because it does
not matter whether an object is initially unowned or not, you can
always push one onto an autorelease pool and express the semantic of:

   "I'm giving you this object temporarily, it's up to you to take a
    reference if you want one, otherwise it will be garbage collected
    later, automatically"

Cheers,
    -Tristan

___
gtk-list mailing list
gtk-list@gnome.org

Re: Floating references

[Tristan Van Berkom]

On Tue, 2017-06-06 at 11:50 +0200, Stefan Salewski wrote:
> Some years ago I read about floating references as described in 
> 
> https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html
> 
> Of course that makes sense.
> 
> Newly created objects get ref count 1, but are floating. If they get
> put into a container element, floating ref is converted to ordinary
> ref, and ref count stays at 1.

First, note that this is _only_ for initially unowned objects, which
GtkWidgets and some others happen to be; and this is mostly convenience
to avoid having to type extra g_object_unref() lines in C code.

To be honest I dont feel like this approach really makes sense, I much
prefer the autorelease pool approach taken by NextStep's objective C
implementation, where the semantic of giving away ownership is
expressed by pushing an object onto the nearest autorelease pool on the
call stack; usually as a part of a return statement.

A new object is always on an autorelease pool, and if ownership is not
claimed by the time you exit the nearest autorelease pool stack frame,
it gets cleaned up automatically.

This way you generally communicate through a return statement whether

  A.) You are granting access to an object you retain ownership of

or

  B.) You are giving the object away through your return statement,
      by pushing it onto the nearest autorelease pool on the stack

However, floating refs are what we had with GtkObject and now that
these floating initially unowned things found their way into GObject,
theres not really any way to turn back the clock and change it.


> But I was wondering, why for newly created objects ref count is not
> just zero, so when the element is put into a container it is just
> increased to one.

In a way, it already is.

Whether it is the actual ref_count that is zero, or whether there is
just a separate floating flag I think is quite immaterial; you need to
have some state to mark the floating object after g_object_new()
returns otherwise it is in an invalid state until the first call to
g_object_ref().

The fact that the count itself is 1, is mostly irrelevant.

Cheers,
    -Tristan

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

Re: Functional programming with GLib

[Tristan Van Berkom]

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

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

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

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

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

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


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

Cheers,
    -Tristan

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

Re: Best practise inheritance

[Tristan Van Berkom]

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

This describes a bit of what you're after:

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

The key points here are that:

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

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

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

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

Cheers,
    -Tristan

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

Re: Best practise inheritance

[Tristan Van Berkom]

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

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

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

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

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

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


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

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

struct _MyType {
    GtkWidget *parent_instance;

    ... anything else...
}

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

struct _MyType {
    GtkWidget parent_instance

    ... anything else ...
}

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

Cheers,
    -Tristan

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

Re: Best practise inheritance

[Tristan Van Berkom]

Hi

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

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

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

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

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

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

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

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

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

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


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

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

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

Cheers,
-Tristan

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

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

Re: Signal emission from an object thread

[Tristan Van Berkom]

On Sat, 2017-03-18 at 14:29 +0900, Tristan Van Berkom wrote:
> On Fri, 2017-03-17 at 14:26 +0100, Emmanuel Pacaud wrote:
> > 
> > Le ven. 17 mars 2017 à 9:52, Emmanuel Pacaud <emman...@gnome.org>
> > a 
> > écrit :
> > > 
> > > 
> > > Le ven. 17 mars 2017 à 6:43, Tristan Van Berkom
> > > <tristan.vanber...@codethink.co.uk> a écrit :
> > > > 
> > > > 
> > > > On Thu, 2017-03-16 at 10:42 +0100, Emmanuel Pacaud wrote:
> > > > > 
> > > > > 
> > > > >  I have an issue related to the use of g_signal_emit called
> > > > > from an
> > > > >  object thread.
> > > > > 
> > > > 
> > > > I have used GWeakRef for references that threads make to
> > > > objects 
> > > owned
> > > > 
> > > > 
> > > > by parent thread which may finalize with parent, to solve
> > > > similar
> > > > problems, but I dont believe I've tried using signals belonging
> > > > to a
> > > > thread spawning object from the thread itself.
> > > > 
> > > > Another approach, if you want to keep using GSignal, would be
> > > > to
> > > > create
> > > > a different object that is owned completely by the thread.
> > > 
> > > I think I will use this solution.
> > 
> > I have just had a go at implementing something like that, but
> > failed
> > to 
> > find the right way to do it. May be what I want to do is not
> > possible:
> > 
> > Currently, the 'new-buffer' signal is emitted by a ArvStream
> > object, 
> > which leads to the thread join issue I have described. What I
> > would 
> > like to do is to define a signal in ArvStream, but with a signal 
> > callback that doesn't have ArvStream as the first parameter, but
> > an 
> > ArvBuffer. Do the signal callbacks always have the object emiting 
> > instance in their parameters ?
> 
> No.

Hah.

Sorry but this was supposed to be:

Yes.

Signals are entirely bound to the object on which they were declared,
there is no backing out of that :)

Cheers,
    -Tristan


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

Re: Signal emission from an object thread

[Tristan Van Berkom]

On Fri, 2017-03-17 at 14:26 +0100, Emmanuel Pacaud wrote:
> Le ven. 17 mars 2017 à 9:52, Emmanuel Pacaud <emman...@gnome.org> a 
> écrit :
> > 
> > Le ven. 17 mars 2017 à 6:43, Tristan Van Berkom
> > <tristan.vanber...@codethink.co.uk> a écrit :
> > > 
> > > On Thu, 2017-03-16 at 10:42 +0100, Emmanuel Pacaud wrote:
> > > > 
> > > >  I have an issue related to the use of g_signal_emit called
> > > > from an
> > > >  object thread.
> > > > 
> > > 
> > > I have used GWeakRef for references that threads make to objects 
> > owned
> > > 
> > > by parent thread which may finalize with parent, to solve similar
> > > problems, but I dont believe I've tried using signals belonging
> > > to a
> > > thread spawning object from the thread itself.
> > > 
> > > Another approach, if you want to keep using GSignal, would be to
> > > create
> > > a different object that is owned completely by the thread.
> > 
> > I think I will use this solution.
> 
> I have just had a go at implementing something like that, but failed
> to 
> find the right way to do it. May be what I want to do is not
> possible:
> 
> Currently, the 'new-buffer' signal is emitted by a ArvStream object, 
> which leads to the thread join issue I have described. What I would 
> like to do is to define a signal in ArvStream, but with a signal 
> callback that doesn't have ArvStream as the first parameter, but an 
> ArvBuffer. Do the signal callbacks always have the object emiting 
> instance in their parameters ?

No.

I took a brief look into your code, your thread it calling:

    arv_stream_push_output_buffer()

Which is emitting a gsignal. I'm not going to get a full handle on what
your code is trying to do, but I can only presume that you intend for
that to let your parent thread know that a buffer is ready ?

Ok, well, here are a few tips I think you can use to correct your code.

  o The `gboolean cancel` is wrong, setting this is not a guaranteed
    atomic operation.

    There are some facilities for atomic integers which you can use,
    such as g_atomic_int_set/get(), which act as a memory barrier which
    is less overhead than using mutexes.

  o Whenever sharing data with your thread, always protect it with
    g_mutex_lock() / g_mutex_unlock(), (there are also reader/writer
    locks available but I dont see you needing this here).

    The case of the boolean cancel is a bit exceptional, it can be
    set with an atomic operation. You may also consider using
    GCancellable for this.

  o If you want to communicate something back to the thread in which
    your main object was created, from the child worker thread, use
    the GMainLoop for this, that is easiest.
    
    So, in your object initializer or constructed() method (which
    is where the bulk of your code that is currently in
    arv_uv_stream_new() should ideally be instead), you want to take
    note of the active thread context (the GMainContext).

    This makes sure that if some program decides to use your object
    in a mainloop which they created in a *different* thread, your
    code does not blindly assume it was created in the main thread
    but will still work.

    You just make the assertion that "The user which created this
    object did so in a thread with a GMainContext where they are
    running a GMainLoop".

    Once you've got this far, you'll want to share that parent thread
    context with your worker thread, so that ArvUvStreamThreadData
    now has a GMainContext pointer to the thread context of the parent.

    In order to deliver some notification to the calling object, you
    will now use:

        source = g_idle_source_new()
        g_source_set_callback(source,
                              parent_receive_func,
                              data,
                              free_data_func)
        g_source_attach(source, parent_thread_context)

    The object which created the thread, will then handle the
    'data' you sent in parent_receive_func the next time that
    that main thread is not busy and tries to go to sleep in
    it's GMainLoop.

  o There is something relatively new called GTask which has appeared,
    and it might take care of some of the above for you so that there
    are less lines of code overall, I have not really tried working
    with GTask since it's creation.


Please note that GSignal by itself is _only_ a means for marshalling of
callbacks via it's implicit invocation mechanism, and asides from
protecting itself and being "thread aware", it does not care what
thread was active when somebody called g_signal_connect().

In other words, any handlers connected to a GSignal will be called
_right now_ when g_signal_emit() is called, in the active thread where
g_signal_emit() is called.

I hope this was helpful :)

Cheers,
    -Tristan

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

Re: Signal emission from an object thread

[Tristan Van Berkom]

On Thu, 2017-03-16 at 10:42 +0100, Emmanuel Pacaud wrote:
> Hi,
> 
> I have an issue related to the use of g_signal_emit called from an 
> object thread.
> 

Hi Emmanuel,

I dont think there is an easy way out of that.

I have used GWeakRef for references that threads make to objects owned
by parent thread which may finalize with parent, to solve similar
problems, but I dont believe I've tried using signals belonging to a
thread spawning object from the thread itself.

Another approach, if you want to keep using GSignal, would be to create
a different object that is owned completely by the thread.

Cheers,
    -Tristan

> The object has a 'new-buffer' signal. It receives data in a thread
> it 
> owns, and emits this signal from this thread. When the object is 
> finalized, it sets a 'stop' gboolean to TRUE, that tells the thread
> to 
> stop. It then joins the thread, then proceed to ressource
> deallocation.
> 
> The problem is g_signal_emit increases the reference count of the 
> object. That means if the user unref the object from the main thread 
> (thinking he releases the last reference) during the call to 
> g_signal_emit, the object is now owned only by the thread. When 
> g_signal_emit unref the object, the finalization happens on the
> object 
> thread, which will lead to the thread trying to join itself.
> 
> Hence my question: is it possible to emit a signal without
> increasing 
> the reference count of the object ? I'd really like to avoid adding
> an 
> explicit 'stop-the-thread' or 'inhibit-signal' function, to be used 
> before g_object_unref.
> 
> The code is here:
> 
> https://github.com/AravisProject/aravis/blob/7a024607f812d03ff87a906c
> e7f99a1a3bc13b9f/src/arvstream.c
> https://github.com/AravisProject/aravis/blob/7a024607f812d03ff87a906c
> e7f99a1a3bc13b9f/src/arvuvstream.c
> 
> A fix proposal with an explicit inhibit signal function:
> 
> https://github.com/AravisProject/aravis/pull/51
> 
> Cheers,
> 
>   Emmanuel.
> 
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
> 

___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: Glade architecture change

[Tristan Van Berkom]

On Sat, 2017-03-04 at 07:11 +0300, LRN wrote:
> On 04.03.2017 6:20, Michael Torrie wrote:
[...]
> No, actually, forget preview. It was a mistake to bring it up, as
> people get
> the wrong idea.
> My limited understanding of how Glade currently works is that it does
> some OOP
> magic to fool GTK widgets (including toplevels) into drawing
> themselves into
> glade UI design surface, and to have them react to input in unusual
> ways (which
> allows the user to, for example, select widgets and call up context
> menus on
> them, but at the same time press buttons, check checkboxes and scroll
> scrollbars).

I dont think it's as bad as you perceive it to be, however as I
mentioned in my other mail, the tight coupling of widgets and the data
model makes things a bit hard to read and a bit spaghetti.

What is actually happening in the workspace however is correct and
pretty good, we rely on only one behind-the-scenes feature that is not
advertised as supported by the GTK+ API, which is the ability to
reparent toplevel GTK+ widgets (however this is supported in GTK+, but
only specifically for Glade).

Other than this, widgets are created in the normal way using normal
GTK+ supported API, similar to that which GtkBuilder internally
implements (using generic GtkContainer and GtkWidget and GObject
property APIs as much as possible, resorting to case specific hackery
only where generic APIs dont exist). We do however require something
beyond regular GtkBuilder usage which is we need to know at all times
that the widget's property values are syncrhonized with project state,
that is vital to ensure a consistent experience and support undo/redo
properly.

In the workspace, we _used_ to have a plethora of hacks to hijack
various signals (I think some of that remains), but this has been
conveniently replaced with the birth of GdkOffscreenWindow, which
allows us to:

  o Instantiate the hierarchy and redirect it's draws to an offscreen
    window

  o Draw to the workspace surface both below and above widgets rendered
    therein at will, providing a much more robust and potentially 
    powerful UX than we had before when we needed to draw selection
    directly on top of widgets.

  o Handle events on the workspace in one event handler, and marshal
    the user events to a specific widget so that Glade can decide to
    handle the event before a widget does, and can optionally never
    send the event to a widget (first click drives selection and next
    click is given to the widget, is an example of this).

[...]
> > 
> > > 
> > > P.S. This proposal was not well-received on #gtk+, so there's
> > > that.
> > 
> > How was it presented and why was it not well received?
> > 
> It was presented as a three messages sent by me to the channel while
> at least
> two GTK+ developers were present. I do not know why it was not well-
> received.
> No one replied (except for some guest who was asking unrelated
> questions about
> listview alternating row background colors, and thought that Glade
> had
> something to do with that).

Nobody saying anything is not really a sign of something not being well
received.

However, if you had led with "My organization-or-employer has decided
to commit to funding a 3 to 6 month project to solve these problems in
Glade", you might have sparked greater interest :)

Cheers,
    -Tristan

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

Re: Glade architecture change

[Tristan Van Berkom]

Hi,

Before getting into detail I should lead with the fact that on one
hand, a program like Glade is complex, more so than most would expect,
on the other hand; Glade has never really been a funded project, we've
had a couple of brief sponsorships mostly thanks to Murray and
Openismus but the bulk of the work has been done years ago in my
downtime between contracts.

There is still huge potential for Glade to become better and there are
also some really nasty bits which desperately need refactoring & re-
architecture, this is all however very expensive.

On to your proposal...

On Fri, 2017-03-03 at 17:16 +0300, LRN wrote:
> Yet another report of Glade crashing prompted me to think about a way
> to fix
> this, as i've experienced something similar. I've also looked at
> Glade source
> code, and didn't really understand it all that well (which prevented
> me from
> fixing a bug that i wanted to fix).
> 
> Here's my pitch: take the "preview" functionality (where Glade runs a
> separate
> process that constructs the UI based on current project) and take it
> up to 11.
> Base the whole Glade around that idea, and instead of running a live
> preview
> manually, on request, just have a slave process running all the time,
> and have
> it do everything with the widgets, the same way a real GTK
> application would.
> Obviously, it will have to render that into some kind of buffer owned
> by Glade,
> and there will have to be a protocol to communicate with it, to make
> it capable
> of receiving input, for example. This would probably require to use
> GI more
> than it is used already, and baking some of the formerly-Glade
> functionality
> either into GTK itself, or into the slave process.

The instability of Glade is mostly due to two things:

a.) Glade's data model is tied to GTK+, which is wrong. This is the
    single point which is most desperately in need of a refactor.

    To clarify: Glade has forever relied on GTK+ for the widget
    hierarchy, while wrapping GladeWidgets around a GtkWidget instance,
    this means that whenever we do gtk_container_add(parent, child),
    we have always relied on "gtk_widget_get_parent(child) == parent"
    to be a TRUE statement. GTK+ is no longer abiding by this rule.

    Another source of bugs tied to this design problem relates to
    cut/copy and paste, especially when these copy/paste activities
    happen on a cross project level (You might have 2 different glade
    files open and when copying a hierarchy over, we need to make sure
    that it does not have object property references referring back
    to the source project you copied from).

    This design flaw also makes things tightly coupled in a nasty way,
    untangling this will open the door to better stability and to
    doing workspace features more cleanly and independently of the
    data model.

b.) As you mention, there is a huge vector of non-mitigable crashes
    which stem from GTK+ bugs which would never occur under normal
    usage of GTK+.

    This include crashes where widgets end up crashing when their
    properties are explicitly set to their default values, also some
    side effects generally occur due to GTK+ failing to report
    properly introspectable default values (often this is the case
    for derived widgets which do property settings at _init() time
    without ever overriding the corresponding GParamSpec for their
    class).

So, yes; after years of suffering (b) it has always been desirable to
me to run the workspace out of process, pretty much as you suggest, but
without gutting the workspace and it's features or potential features;
the way a user can interact with widgets in the workspace, aside from
the editor widgets, is Glades greatest opportunity to shine and be
useful to the user (we should by now, at _least_ have workspace support
for editing text labels directly in the workspace, without ever making
the arduous journey all the way to the property editor).

I'm pretty certain that reconstructing the workspace UI on every change
is a bad idea, though, because then we add some huge complexity in
maintaining superfluous UI state between rebuilds (if it were even
found to be performant enough). I.e. one example is the size of a
widget that is toplevel in the workspace is usually not encoded into
the data model, bits and pieces like this would have to be recorded and
restored across reconstructions.

Now, before we even start considering running an out of process
workspace with which we can at least (1) try to reconstruct in the case
that the process crashes and (2) forcefully revert the project to the
last known working state in cases where (1) fails, we _have_ to address
the tight coupling mentioned in (a) above.

Doing (a) is not a big deal in the scope of things. I would hazard a
guess that as the primary author of Glade, it might take me 2 or 3
weeks of full time work to refactor and hopefully have something more
stable and without regressions as a result, 

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: CSS # selectors and UI IDs

[Tristan van Berkom]

Hi Chris,

Unfortunately no, the id in the gtkbuilder xml is only useful in apis such as 
gtk_builder_get_object(), one must actually set the "name" property of the 
widget before addressing it as #name in the css.

This is at least partly because css parsing does not strictly enforce a policy 
that every widget have a unique #name.

Cheers,
-Tristan

> On Apr 8, 2016, at 9:11 PM, Chris Larsen  wrote:
> 
> Hello Everyone,
> 
> Forgive the cross-posting. I originally asked this in the language-bindings 
> mailing list, but I don't think anyone actually uses that one.
> 
> Working on the Ruby bindings for GTK, and a question came up regarding the 
> relationship between CSS selectors and UI elements. On the Gnome developer 
> page for GtkCssProvider, it says:
> 
> Selectors work very similar to the way they do in CSS, with widget class 
> names taking the role of element names, and widget names taking the role of 
> IDs. When used in a selector, widget names must be prefixed with a '#' 
> character. The '*' character represents the so-called universal selector, 
> which matches any widget. 
> 
> I take that to mean that when the GtkBuilder object parses the UI file, the 
> name property of the created widget object should be identical to the ID in 
> the UI file. Can someone please confirm if this is the case?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: How to grey out menu items

[Tristan van Berkom]

> On Sep 20, 2015, at 8:05 AM, Stefan Salewski  wrote:
> 
> OK, gtk_widget_set_sensitive () will do it.
> 
> But I wonder how to do it for menu items that change sensitively often,
> for example COPY menu item. I can set it sensitive whenever something
> is selected in my application, for example a word in a text editor, and
> make it insensitive if nothing is selected. Of course this generates
> much noise. May it be better, and is it possible to do that on the fly,
> when the pulldown menu pops on? Maybe a signal which is emitted before
> the item becomes visible? Can not find something like that
> unfortunately.
> 

This really shouldn't be a concern at the application level, as setting the 
sensitivity of a widget that is not currently visible should do no more than 
updating some internal state, the appearance of the given widget should then be 
computed at display time.

Best,
-Tristan


> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: What to use on GTK+3

[Tristan Van Berkom]

On Sun, Aug 9, 2015 at 10:09 PM, Igor Korot ikoro...@gmail.com wrote:

Hi,

On Sun, Aug 9, 2015 at 8:00 AM, Thiago Bellini Ribeiro
hackedbell...@gmail.com wrote:
 On Sun, Aug 9, 2015 at 1:46 AM Daniel Kasak 
d.j.kasak...@gmail.com wrote:


 No no no. Everybody is wrong. What we need is:

 [ Actually, now that I come to think about it, this is not the 
action

 I would like to take at this time. Thankyou all the same]
 [ This is precisely the action that I require, and I thank you for 
the
 explicit dialog and verbose text in the buttons; it really makes 
sure

 I know what it about to happen, and possibly makes the rest of the
 text of the dialog redundant, but hey, at least there is zero scope
 for confusion]



 The whole point here is to _be redundant_. Why? For some reasons, 
but a

 major one is: Users don't read dialogs!


Why people think this? Was there a statistical analysis about it?
How many people do read them comparing to how many people don't?




I understand the curiosity, but if your goal is to develop 
applications, I'm unsure you are asking the right questions.


A.) Microsoft and Apple both have long standing documentation in their 
human

   interface guidelines to discourage dialog response buttons that
   dont have their own context (i.e. Yes or Go ahead), most UX 
experts
   seem to agree on this, for close to a decade. I would not take it 
on myself

   to try to prove them wrong.

   In other words, in absence of proof, either you spend enormous time 
yourself
   doing these studies, or, the practical thing is follow current 
recommended

   practices.


B.) As Thiago mentioned, this need not be about whether users read all 
the text
   or not, but you reduce the user's memory load, this in itself is 
a very
   good argument, your software is easier to use, the appropriate 
response

   can be 'gleaned'.

   I.e., Even if you assumed everyone read dialog text, it would 
_still_

   be worth the effort to make your application more user friendly, by
   reducing what they have to remember from session to session.




Where can I see it? And who did it?




Some have provided links, but I think the best source of the 
documentation
you are asking for will be in the (probably private) bug tracking 
repositories
and tech support history and documentation for companies with large 
user bases,

who had to learn this from experience (I can only imagine how many disks
have been completely wiped just because your common grandmother 
followed her

grandson's advice to just say yes to all that complicated stuff).


That said, there is another interesting point which nobody has brought 
up, and that is translatability of your application.


Consider the phrase: Don't you want to go home ?

English: No, means no I dont want to go home
Korean:  No, means no, I do want to go home

Especially in the majority of cases, where application developers use 
GTK_STOCK_YES, and the translation actually comes from GTK+, there is no

way for translators to read the question, and put an appropriate word
for the response, instead they are stuck with a translated Yes. Even
if you did not use the stock GTK+ Yes and translated your own Yes 
string,

it will be more work for translators to cross-check the dialog string
and make special exceptions for scattered occurrences of Yes 
throughout

your application.

A translated Yes without context becomes meaningless in many 
languages.


Regards,
   -Tristan



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

Re: What to use on GTK+3

[Tristan Van Berkom]

On Sun, Aug 9, 2015 at 3:11 AM, Igor Korot ikoro...@gmail.com wrote:

Emmanuele,

On Sat, Aug 8, 2015 at 1:52 PM, Emmanuele Bassi eba...@gmail.com 
wrote:
 Use Yes, but please: consider using a more descriptive label and 
icon than

 just yes.

The Yes, No and Cancel are legitimate button labels, especially 
if used

in one dialog.




In some very few cases you may find yourself with no better option than 
yes, no or cancel as button labels in a dialog, however, probably 
99% of the time you can do better, and you do a disservice to your 
users by choosing GTK_STOCK_OK just because you were too lazy to search 
for a proper verb which describes the consequent action properly.


This is a point which has been thought of and discussed to death, I 
suggest you google around for blog posts on the subject which can be 
enlightening as to why its pretty much universally agreed by usability 
experts that yes / no dialogs are just really undesirable and 
should be avoided.


Here's one random post I've seen before which happened to float to the 
top of my search results:

http://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box

Cheers,
   -Tristan






Could you please update the documentation to let people know about it?

Thank you



 Ciao,
  Emmanuele.


 On Saturday, August 8, 2015, Igor Korot ikoro...@gmail.com wrote:


 Hi, ALL,
 It looks like all GTK_STOCK_XXX have their replacemewnts in GTK+-3.

 However, GTK_STOCK_YES does not. And it is very useful item.

 Is there a replacement I can use?

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




 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]


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



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

Re: Need help in debugging glib crash

[Tristan Van Berkom]

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

Hi Alexander,

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

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

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

Cheers,
-Tristan

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


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


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

Re: Memory leak in gdbus-codegen generated code

[Tristan Van Berkom]

On Mon, 2015-02-09 at 15:05 +, Norman, Anders wrote:
[...]
 But the application ends up leaking the signal generated in 
 `dbus_foo_default_init()` which looks like this:
 
 static void
 dbus_foo_default_init (DbusFooIface *iface)
 {
   /* GObject signals for incoming D-Bus method calls: */
   /**
* DbusFoo::handle-bar:
* @object: A #DbusFoo.
* @invocation: A #GDBusMethodInvocation.
*
* Signal emitted when a remote caller is invoking the link 
 linkend=gdbus-method-com-example-foo.BarBar()/link D-Bus method.
*
* If a signal handler returns %TRUE, it means the signal handler will 
 handle the invocation (e.g. take a reference to @invocation and eventually 
 call dbus_foo_complete_bar() or e.g. g_dbus_method_invocation_return_error() 
 on it) and no order signal handlers will run. If no signal handler handles 
 the invocation, the %G_DBUS_ERROR_UNKNOWN_METHOD error is returned.
*
* Returns: %TRUE if the invocation was handled, %FALSE to let other 
 signal handlers run.
*/
   g_signal_new (handle-bar,
 G_TYPE_FROM_INTERFACE (iface),
 G_SIGNAL_RUN_LAST,
 G_STRUCT_OFFSET (DbusFooIface, handle_bar),
 g_signal_accumulator_true_handled,
 NULL,
 g_cclosure_marshal_generic,
 G_TYPE_BOOLEAN,
 1,
 G_TYPE_DBUS_METHOD_INVOCATION);
 
 }
 
 Am I using the generated code wrong or is it a bug in glib/gdbus-codegen?

This is not considered a leak, a signal connection leaking would be a
leak, but a signal declaration as such, is expected to be kept with the
statically registered GTypeInstance.

Once you register a type (as a consequence of calling g_object_new()
the first time, or however), it's signals will never go away.

Cheers,
-Tristan


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

Re: Memory leak in gdbus-codegen generated code

[Tristan Van Berkom]

On Tue, 2015-02-10 at 00:32 +0900, Tristan Van Berkom wrote:
 On Mon, 2015-02-09 at 15:05 +, Norman, Anders wrote:
 [...]
  But the application ends up leaking the signal generated in 
  `dbus_foo_default_init()` which looks like this:
  
  static void
  dbus_foo_default_init (DbusFooIface *iface)
  {
/* GObject signals for incoming D-Bus method calls: */
/**
 * DbusFoo::handle-bar:
 * @object: A #DbusFoo.
 * @invocation: A #GDBusMethodInvocation.
 *
 * Signal emitted when a remote caller is invoking the link 
  linkend=gdbus-method-com-example-foo.BarBar()/link D-Bus method.
 *
 * If a signal handler returns %TRUE, it means the signal handler 
  will handle the invocation (e.g. take a reference to @invocation and 
  eventually call dbus_foo_complete_bar() or e.g. 
  g_dbus_method_invocation_return_error() on it) and no order signal handlers 
  will run. If no signal handler handles the invocation, the 
  %G_DBUS_ERROR_UNKNOWN_METHOD error is returned.
 *
 * Returns: %TRUE if the invocation was handled, %FALSE to let other 
  signal handlers run.
 */
g_signal_new (handle-bar,
  G_TYPE_FROM_INTERFACE (iface),
  G_SIGNAL_RUN_LAST,
  G_STRUCT_OFFSET (DbusFooIface, handle_bar),
  g_signal_accumulator_true_handled,
  NULL,
  g_cclosure_marshal_generic,
  G_TYPE_BOOLEAN,
  1,
  G_TYPE_DBUS_METHOD_INVOCATION);
  
  }
  
  Am I using the generated code wrong or is it a bug in glib/gdbus-codegen?
 
 This is not considered a leak, a signal connection leaking would be a
 leak, but a signal declaration as such, is expected to be kept with the
 statically registered GTypeInstance.

Err, I should have just said GType, the GTypeInstance is indeed instance
data and freed with every object, sorry for the confusion.

Cheers,
-Tristan


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

RE: Memory leak in gdbus-codegen generated code

[Tristan Van Berkom]

On Tue, 2015-02-10 at 06:59 +, Norman, Anders wrote:
 Well, I consider it a leak and need it cleaned up.
 

Yes, some people stubbornly think that, however it's entirely unfounded.

In languages with OO features built in, the data attached to a type
definition (a class) is loaded with the binary generally, in C there is
no such thing, so this data which defines a type is initialized
once-off, the first time you register a type.

 In gobject.c g_object_base_class_finalize() there is a call to 
 _g_signals_destroy() but I don't see exactly how this ties into the type 
 system of glib.

Yes, classes can be finalized, by way of a convoluted thing which is
types which are defined to be 'dynamic' and not static, there is even
a the GTypePlugin or GTypeModule API which is intended to unregister
dynamic types when a 'plugin is unloaded'.

However it turns out that this practice is just more headache than
it's worth, if an application requires plugins, instead performing
the dlopen once and never closing it, even when the plugin is
virtually 'unloaded' is a better practice all around (simply
disposing any plugin *instances* at unload time and keeping the
actual module loaded and ready for the next time it's 'loaded').

In any case, as the dbus object skeletons are most probably
registered as static types, as most type are, you will not
be able to free the memory you want to free (and even if you
did, you would still have the interned strings as a result of
signal and property declarations in memory which cannot be
'uninterned').

Your best bet is to add the appropriate suppressions to your
valgrind setup and focus on catching the leaks with are, in
fact, actually leaks.

Cheers,
-Tristan


 
 Anders
 
 -Original Message-
 From: Tristan Van Berkom [mailto:tris...@upstairslabs.com]
 Sent: 9. februar 2015 16:35
 To: Norman, Anders
 Cc: gtk-list@gnome.org
 Subject: Re: Memory leak in gdbus-codegen generated code
 
 On Tue, 2015-02-10 at 00:32 +0900, Tristan Van Berkom wrote:
  On Mon, 2015-02-09 at 15:05 +, Norman, Anders wrote:
  [...]
   But the application ends up leaking the signal generated in 
   `dbus_foo_default_init()` which looks like this:
  
   static void
   dbus_foo_default_init (DbusFooIface *iface)
   {
 /* GObject signals for incoming D-Bus method calls: */
 /**
  * DbusFoo::handle-bar:
  * @object: A #DbusFoo.
  * @invocation: A #GDBusMethodInvocation.
  *
  * Signal emitted when a remote caller is invoking the link 
   linkend=gdbus-method-com-example-foo.BarBar()/link D-Bus method.
  *
  * If a signal handler returns %TRUE, it means the signal handler 
   will handle the invocation (e.g. take a reference to @invocation and 
   eventually call dbus_foo_complete_bar() or e.g. 
   g_dbus_method_invocation_return_error() on it) and no order signal 
   handlers will run. If no signal handler handles the invocation, the 
   %G_DBUS_ERROR_UNKNOWN_METHOD error is returned.
  *
  * Returns: %TRUE if the invocation was handled, %FALSE to let 
   other signal handlers run.
  */
 g_signal_new (handle-bar,
   G_TYPE_FROM_INTERFACE (iface),
   G_SIGNAL_RUN_LAST,
   G_STRUCT_OFFSET (DbusFooIface, handle_bar),
   g_signal_accumulator_true_handled,
   NULL,
   g_cclosure_marshal_generic,
   G_TYPE_BOOLEAN,
   1,
   G_TYPE_DBUS_METHOD_INVOCATION);
  
   }
  
   Am I using the generated code wrong or is it a bug in glib/gdbus-codegen?
 
  This is not considered a leak, a signal connection leaking would be a
  leak, but a signal declaration as such, is expected to be kept with
  the statically registered GTypeInstance.
 
 Err, I should have just said GType, the GTypeInstance is indeed instance data 
 and freed with every object, sorry for the confusion.
 
 Cheers,
 -Tristan
 
 
 This message is subject to the following terms and conditions: MAIL 
 DISCLAIMERhttp://www.barco.com/en/maildisclaimer
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list


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

Re: charts on gtk+

[Tristan Van Berkom]

On Fri, 2015-02-06 at 16:27 -0600, zeta wrote:
 Hi there I am new on the community, I am a bachelor student at BUAP, I
 love gome since I meet it, and know I want to contribute in something,
 I was writing an application with gtk and when I want to create some
 cool charts I see that there isn't a library for do it, or I don't
 find one that has native integration with gtk, so I decide to write
 one, but first I want to know If anyone is doing one, or if someone
 can guide me where to start, I think that I should do with the gtk
  draw area widget and cairo, but I'm not sure. Regards Miguel Angel

You mean something like MathGL but for the GTK+/cairo stack ?

I can't think of anything off hand which exists that does that, and I
would see myself using it at one point or another.

I would suggest that you do this with cairo directly, and not have a
hard GTK+ dependency in your library, i.e. you could provide a GtkWidget
as a separate thing, but have the main library only depend on cairo,
this would allow one to plug it into a GTK+ application easily, but also
use it directly with cairo on a wide variety of cairo rendering backends
(can be interesting for directly rendering charts onto a PDF surface for
example).

Cheers,
-Tristan


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

Re: glade3, how to get the response of GtkFileChooserDialog somwhere in my code and open a file?

[Tristan Van Berkom]

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

Hi Nicolas.

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

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

Cheers,
-Tristan

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


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

Re: a new combo box

[Tristan Van Berkom]

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

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

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

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

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

Best wishes for the new year,

  -Tristan

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


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 18:05 +0100, Sébastien Wilmet wrote:
 On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
  In any case, I think this misses the point I was trying to make, I think
  someone had to raise the obvious question: is it justified to bring in a
  whole new combo API ? Or can we / should we get the most out of the API
  we have ?
 
 Yes, it was more a side note.
 
 As a comment says at the top of gtkcombobox.c:
 /* WELCOME, to THE house of evil code */
 

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

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

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

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

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

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

Cheers,
-Tristan


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

Re: a new combo box

[Tristan Van Berkom]

On Sat, 2014-12-27 at 11:44 -0800, Christian Hergert wrote:
 On 12/27/2014 07:50 AM, Tristan Van Berkom wrote:
  In any case, I think this misses the point I was trying to make, I think
  someone had to raise the obvious question: is it justified to bring in a
  whole new combo API ? Or can we / should we get the most out of the API
  we have ?
 
 Can I style combobox items with CSS?

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

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

Cheers,
-Tristan


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

Re: a new combo box

[Tristan Van Berkom]

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

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

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

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


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

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

 We've later tried to patch up that mistake by adding the simplified
 GtkComboBoxText. But since it is a subclass, it inherits all of the
 api problems of GtkComboBox. Lastly, there's a number of ill-advised
 APIs in GtkComboBox that make it very hard to do any new
 implementation of the same api: tabular menus, spanning columns, etc.
 Almost as if to prove the last point, your last major refactoring of
 GtkComboBox already broke a bunch of those APIs (e.g. col-span-column
 is not working anymore).
 
 You'll be happy to learn that the buildable API of GtkCombo is
 pretty close to compatible with GtkComboBoxText (I should probably
 rename the active property to active-id to get even closer), so for
 most users, switching from GtkComboBoxText to GtkCombo should be as
 simple as s/GtkComboBoxText/GtkCombo/ in their ui files.
 
 Since you are asking about discussions and conclusion, I'll state that
 in my opinion, combo boxes should not use (even less expose in the
 api) cell renderers and tree models. I believe that is pretty much
 agreed upon between most people who regularly touch GTK+ code

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

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

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

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

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

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

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

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


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

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

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

This should work consistently yes.

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

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

Cheers,
-Tristan


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

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

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

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

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

Best,
-Tristan

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


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

Re: GtkWidgets, Who owns what?

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan

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

Re: Widget sizing?

[Tristan Van Berkom]

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

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

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

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

Cheers,
-Tristan


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

Re: Flowbox: widget expanding

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan


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

Re: Can put a GtkLayout in a GtkListBox

[Tristan Van Berkom]

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

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

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

Cheers,
-Tristan

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


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

Re: Flowbox: widget expanding

[Tristan Van Berkom]

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

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

Cheers,
-Tristan


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

Re: Struggling to understand how to render to GtkLayout in a GtkScrolledWindow

[Tristan Van Berkom]

On Mon, 2014-10-06 at 16:44 -0400, Paul Davis wrote:
 
 
 On Mon, Oct 6, 2014 at 4:05 PM, Oliver Charles ol...@ocharles.org.uk
 wrote:
 On Mon, Oct 6, 2014 at 7:11 PM, Paul Davis
 p...@linuxaudiosystems.com wrote
 
 
 GtkLayout is NOT a canvas.
 
 You need a canvas widget. Unfortunately, there is no
 blessed canvas widget. 
 
 
 
 Ok, then I think I was mislead by the documentation for
 GtkLayout, which states:
 
 
 GtkLayout is similar to GtkDrawingArea in that it’s a
 “blank slate” and doesn’t do anything but paint a
 blank background by default
 
 
 GktLayout is intended to layout other GTK widgets in a scrollable
 space. This has a useful purpose all of its own.
 
 
 Unlike a canvas order, it has no notion of z-axis order, so if any of
 your widgets overlap, the result is not well defined (for either
 drawing or event handling). Obviously something will happen, and it
 may be the right thing. But that will be mostly an accident.
 
 In addition, if you just draw on it, the things you draw are not
 event-sensitive in the way that widgets would be.
 
  
 
 
 And the synopsis:
 
 
 GtkLayout: Infinite scrollable area containing child
 widgets and/or custom drawing
 
 
 So if GtkLayout isn't the way to go for a large, scrollable
 canvas... what is?  
 
 
 Once upon a time, there was GnomeCanvas. Discontinued. Other people
 created foocanvas, goocanvas and various others. For Ardour, we've
 recently (within the last year) implemented out own canvas (which does
 *not* handle child widgets, by design).
 
 What you need depends a great deal on what you actually to do. If you
 want a bunch of non-overlapping widgets with non-event-handling drawn
 elements between them, then GtkLayout should be fine. If you want
 event-sensitive drawn elements or want a defined z-axis order for
 overlapping elements (widgets or otherwise),then it will probably
 prove problematic.


Honestly I have never used goocanvas for any serious project, but
played around with the demo and I still *intend* to use it to replace
something I used clutter for (no it's not similar to clutter, I just
made a bad choice and should have used a canvas all along).

Anyway, I would recommend you at least checkout the goocanvas code
and try it out... depending on the state of GTK+3 the demo might be
rough around the edges (I recall some weird glitches that turned up
in later versions of GTK+3, maybe it was a passing bug), but giver her
a spin and see what you think :)

Cheers,
-Tristan



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

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

[Tristan Van Berkom]

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

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

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

Cheers,
-Tristan

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

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

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


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

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

[Tristan Van Berkom]

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

Hi,

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

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

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

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

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

Cheers,
-Tristan

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


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

Re: nuts!

[Tristan Van Berkom]

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

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



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




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

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

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

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


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

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

Cheers,
   -Tristan

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




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

Re: gtk_widget_set_size_request stopped working with GTK3

[Tristan Van Berkom]

Hi Mike,

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

not in GTK+3.

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




... And this is precisely the issue.

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

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

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

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

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

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

Cheers,
   -Tristan

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



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

of the list adjust to the minimum size.

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




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

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



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

Re: GtkWidget:halign and GtkSizeGroup

[Tristan van Berkom]

Hi Murray,

On 2014-07-17, at 5:25 PM, Murray Cumming murr...@murrayc.com wrote:

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

Not in this way it cannot work.

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

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

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

Cheers,
-Tristan


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

Re: How to do backend-per-process with GDBus properly

[Tristan Van Berkom]

Hi Milan,

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

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

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

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

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

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

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

So while currently we have this pattern:
~~~

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

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


We should instead have this pattern:
~~~

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

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


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

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

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

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

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

Hope this is of some help,

Cheers,
   -Tristan

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

Re: How to convert text with GtkTextTag from a GtkTextBuffer to Pango markup

[Tristan Van Berkom]

On Sat, 2014-05-03 at 00:17 -0300, Andrés Fernández wrote:
 Hi! this is my first message to this list. I don't know if is correct to
 ask this in this mailing list or in vala mailing list. I think this I
 more related with Gtk+ than with vala.
 
 I'm writing a gtk app in vala. I'm trying to let the user to format some
 text on a GtkTextView save that text on an sqlite db converted to Pango
 markup, so then I can show it later on a GtkLabel formated.
 
 I have to say that I'm not sure if I understand how all this things
 works. Where I'm stuck is trying to handle the uint8[] data that I get
 from Gtk.TextBuffer.serialize (...).
 
 var serialized = buffer.serialize (buffer,
 buffer.register_serialize_tagset (null), start, end );
 
 Then when I try to convert that unit8[] to string I only get one line
 with this text GTKTEXTBUFFERCONTENTS-0001. Searching a on the web I
 realize that is the header of a XML. But I didn't get how to get tho
 other lines to parse that data to Pango markup.

These links should help you understand:
https://developer.gnome.org/gtk3/unstable/GtkTextBuffer.html#gtk-text-buffer-register-serialize-format
https://developer.gnome.org/gtk3/unstable/GtkTextBuffer.html#gtk-text-buffer-register-serialize-tagset

GtkTextBuffer does not have any feature to serialize into pango markup
format, I suppose it would be possible to create such a serialization
but it would probably be lossy (I'm not sure pango markup can express
everything that can be expressed with GtkTextTags in a GtkTextBuffer,
notably transparency in text foreground/background colors).

The above two links should give you the means to serialize into an
internal GTK+ format which can later be used to deserialize it into
another GtkTextBuffer.

Cheers,
-Tristan

 
 I hope I made my issue clear. My English is quiet limited.
 
 Best regards!
 
 
 Andres Fernandez
 Software Peronista
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list


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

Re: When to free GtkBuilder

[Tristan van Berkom]

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

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

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

Cheers,
-Tristan


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

Re: Redistribution of GTK DLLs

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan


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


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

Re: GTK signals question.

[Tristan Van Berkom]

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

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

Cheers,
-Tristan

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


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

Re: GTK signals question.

[Tristan Van Berkom]

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

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

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

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

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

Cheers,
-Tristan


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


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

Re: some mistake in the GtkCellRenderer design

[Tristan Van Berkom]

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

There is a fourth choice:

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

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

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


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

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

[Tristan Van Berkom]

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

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

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

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

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

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

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

Cheers,
-Tristan

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


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

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

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan

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


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

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

[Tristan Van Berkom]

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

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

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

Cheers,
-Tristan

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


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

Re: Who knows ANYTHING about broadway / HTML5 backend?

[Tristan Van Berkom]

On Thu, 2014-01-23 at 08:55 +0100, Tarnyko wrote:
 Hi Daniel, 
 
 I guess that if I wanted it to work in its current state, I would have a CGI 
 (or other) app handling authentication, and if successful spawning the GTK+ 
 application on a new IP port and redirecting the user to this port. 
 
 Subsequent connections to this IP port should be protected by some web 
 server magic (reading a password database). 
 
 But I agree that it would be nice if such a feature was supported 
 out-of-the-box.

I've done a lot of reading on this subject in the last few weeks
(being that I don't exactly have a web background), it would seem
that such an out-of-the-box solution would be unrealistic - given
the stateless nature of HTTP and the ever-evolving state of the
art in web security and authentication (you have various forms
of authentication with various tradeoffs you would make for different
types of web sites/services).

But I would be really interested in understanding how this backend
works, perhaps one could run the web server with libsoup and perform
authentication there, passing a session identifier directly to the
broadway backend - routing all traffic relevant to that given session
to the appropriate application UI instance (perhaps one
GtkApplicationWindow could be used for each active session ?
and a special GtkWindow could be used for any unauthenticated user,
just to display a splash / login page ?).

Somehow I think using a separate port for each active session is
unrealistic (what if you have many active sessions, can you really
just allocate that many ports ?).

Anyway, I'm no expert in web/http but learning about it, and would
be really interested in a solution for this as well... perhaps I will
dig into this in the coming months.

Cheers,
-Tristan

 
 Regardsn
 Tarnyko 
 
 Daniel Kasak writes: 
 
  Fair enough. Good to see someone answer ;) The other question I posted to
  an app-devel list or something like that. I can deal with not being able to
  resize / maximise for now. What I'm not clear on is security. The way I
  assumed it would work was this: 
  
  - I write a simple login page that checks credentials in a DB
  - If login is successful, an authentication key is generated, an instance
  of broadwayd is spawned on a new port, an instance of the app is spawned,
  and pointed ( somehow ) at the correct instance of broadwayd, and the key
  and port is returned to the client's browser 
  
  What happens from here on is less clear. The browser would have to keep
  passing this key back to broadwayd or the app? Can we use https or tunnel
  through ssh? Is anything like this implemented already? 
  
  From what I've seen with my limited testing, the default setup basically
  allows anyone to hit the IP / port that broadway is running on, and take
  over control of the app. 
  
  Any thoughts? 
  
  Dan 
  
  
  On Thu, Jan 23, 2014 at 11:07 AM, Jasper St. Pierre
  jstpie...@mecheye.netwrote: 
  
  Hi Daniel, 
 
  I can only find one email to this list about this, which is about
  maximizing windows on Broadway. I'm sorry I didn't reply, but I was busy
  that day. I do remember investigating the question before getting poked to
  do something else instead. 
 
  Broadway is indeed not officially supported, in that it's not ready for
  production. 
 
 
  On Wed, Jan 22, 2014 at 6:55 PM, Daniel Kasak 
  d.j.kasak...@gmail.comwrote: 
 
  Hi all. Unfortunately, my last couple of posts to various gtk lists on
  this topic have had ZERO replies :( 
 
  This is giving me the impression that broadway is not officially
  supported, and possibly developed and maintained by a single person. Is
  this the case? Does anyone know who I'd contact who does know about
  broadway status? 
 
  Dan 
 
  ___
  gtk-list mailing list
  gtk-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-list 
 
 
  
 
  --
Jasper 
 
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: Strange behavior of my program

[Tristan Van Berkom]

On Tue, 2013-12-10 at 06:31 +0100, onetmt wrote:
 Il 01/12/2013 21:01, Alberto Zichittella ha scritto:
  This message dialog causes a strange behavior on my program. It seems
  that the call to gtk_message_dialog_new() change the value of the const
  gchar* pointer, last parameter. 
  
  Furthermore, the value of the const gchar* variable message change
  from Il risultato e' -number- to Il risult(, I don't know why. 
  I know that the call changes the value (and the address) of message
  because I use gdb.
  
  I develope on ubuntu gnome 13.10 using Code::Blocks , on a 64bit system,
  with gtk+-3.0
  
  
  const gchar* message;
  /*the function risolviFormat() create a gchar* pointer, using malloc
  to allocate memory */
  message = espressione-risolviFormat();   //message is, for example,
 
 Try this substitution:
 
 gchar *message;
 
 message = g_strdup_printf(Il risultato e': %f, result);
 dialog = gtk_message_dialog_new(NULL,
 GTK_DIALOG_DESTROY_WITH_PARENT,
 GTK_MESSAGE_INFO,
 GTK_BUTTONS_OK,
 (const gchar *)message);
 

You really should not be passing a literal string as a format.

What you really want is:

dialog = gtk_message_dialog_new(NULL,
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_MESSAGE_INFO,
GTK_BUTTONS_OK,
Il risultato e': %f,
result);


   Il risultato e' 789
  dialog = gtk_message_dialog_new (NULL,
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_MESSAGE_INFO,
GTK_BUTTONS_OK,
message);
 /*now message is Il risult( 
 gtk_window_set_position(GTK_WINDOW(dialog),GTK_WIN_POS_CENTER_ALWAYS);
 gtk_dialog_run (GTK_DIALOG (dialog));
 gtk_widget_destroy (dialog);




 /*this call causes a segfault because message pointer changed his
  value */
  free(message);

This causes a segfault cause you're freeing glib memory with 
libc 'free()'


 return;
  
  -- 
  
  
  Mio blog: http://newbufferedwriter.blogspot.com/
  http://prodigious.altervista.org/Scrobblit/index.php
  
  
  ___
  gtk-list mailing list
  gtk-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-list
  
 
 


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

Re: glib vs. gdbus-codegen: file collision

[Tristan Van Berkom]

Hi Grant,

The problem is really that you are trying to install two packages which
are just not parallel installable.

The solution is to not install the gdbus-codegen package.

For a bit of clarification, the gdbus-codegen package was a
rather short lived module, and it's unfortunate that people might
have installed it on their system, also unfortunate that it was
not created as egg-dbus-codegen or using some non-glib
invasive namespace.

However nothing can be done about that now, just use
gdbus-codegen from glib.

Cheers,
-Tristan



On Sat, Nov 16, 2013 at 3:22 AM, Grant emailgr...@gmail.com wrote:
 The latest glib from git (glib- on Gentoo) wants to install 2
 files which are also installed by gdbus-codegen:

 /usr/share/man/man1/gdbus-codegen.1.bz2
 /usr/bin/gdbus-codegen

 glib- also has a failed patch which might be related:

 * Failed Patch: glib-2.35.x-external-gdbus-codegen.patch !
 * ( 
 /var/lib/layman/gnome-next/dev-libs/glib/files/glib-2.35.x-external-gdbus-codegen.patch
 )

 Does anyone know what's happening with this?

 Problems with Gentoo packages should be reported to Gentoo, please.

 Of course, but I mean to report a problem with compatibility between
 the latest versions of glib and gdbus-codegen.  They both install the
 same files:

 /usr/share/man/man1/gdbus-codegen.1.bz2
 /usr/bin/gdbus-codegen

 The Gentoo info was just extra context.

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

Re: FW: Question About Creating Composite Widget Template

[Tristan Van Berkom]

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

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

This looks like a good reason to crash:

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

struct _HRChannelListClass
{
GtkBoxClass parent_class;
};

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

Re: flow box

[Tristan Van Berkom]

Hi Matthias,

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

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

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

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

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

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

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

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

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

To see it in action, try running:

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

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

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

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

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

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

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

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


Cheers,
-Tristan



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


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

Re: Stock Items Deprecation

[Tristan Van Berkom]

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

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

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

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

Is it too late to reverse this deprecation for 3.10 ?

Cheers,
 -Tristan


On Thu, Jul 25, 2013 at 11:37 AM, phil p...@philandanna.no-ip.org wrote:

 On 02/07/13 14:41, William Jon McCann wrote:

 Hi,

 As some of you may have noticed we have recently deprecated Stock Items
 in master.

 Some details on this change may be found here:

 https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub

 Please let us know what you think.


 The document doesn't mention anything about stock icons with rtl variants. I
 just changed some code from using the stock-id property of a
 GtkCellRendererPixbuf to icon-name and I only see the ltr versions of the
 media-playback-start icon on a rtl locale. Is it now the applications
 responsibility to take care of this by changing the icon name or is it just
 a bug? If it is now up to the application then I think that is (a) not a
 good idea as people will forget to do it and (b) it also needs a prominent
 mention in the migration guide.

 As others have mentioned it is unfortunate eliminating the #defines for
 stock items also eliminates all compile-time checks for valid icon names 
 makes errors in common menu items more likely.

 One other thing, I'm wondering why the migration guide and rationale are on
 goggle docs which tracks who is viewing what and which links they click on
 in the documents. It seems a bit incongruous as GNOME is currently fund
 raising for privacy enhancements and has it's own wiki.

 Best Wishes

 Phillip Wood


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

Re: Expander question

[Tristan Van Berkom]

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

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

Cheers,
-Tristan



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

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

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

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

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

[Tristan Van Berkom]

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

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

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

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

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

Cheers,
-Tristan



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

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

 Thanks for any help!

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

Re: Simulate mouse/button presses?

[Tristan Van Berkom]

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

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

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

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

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

Cheers,
-Tristan


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

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

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

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

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

 Any advise would be appreciated.

 Thank you,
 Jim


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

Re: Expand the child in the GtkHeaderBar

[Tristan Van Berkom]

On Fri, Jul 5, 2013 at 10:55 PM, Yosef Or Boczko yosef...@gmail.com wrote:
 Good afternoon!

 I wrote a program that uses in GtkHeaderBar [1].
 In the GtkHeaderBar I put a buttons (GtkButton) and also entry (GtkEntry):
 entry-without-expand.png [2]:
 || |--- entry ---|   | X

 I tried to expand the entry which is in haderbar, see something like this:
 entry-with-expand-gimp-editor.png [3]:
 || |- entry -| | X

 To expand, I tired use the following functions:
 gtk_widget_set_vexpand (entry, TRUE); /* It does nothing, not expand! */
 g_object_set (entry, expand, TRUE, NULL); /* It also does nothing, not
 expand */
 It does not work!

Why are you using GtkHeaderBar ?

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

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

Cheers,
-Tristan


 There is a way to expand the entry in headerbar?

 I do it so that to port the toolbar in nautilus (NautilusToolbar) to
 headerbar.

 [1] attached: main.c or:
 https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/main.c?at=master

 [2] attached: entry-without-expand.png or:
 https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/entry-without-expand.png?at=master

 [3] attached: entry-with-expand-gimp-editor.png or:
 https://bitbucket.org/yoseforb/expand-header-bar/src/80a2af720bbc0ef487887d859dcf74410f786267/entry-with-expand-gimp-editor.png?at=master

 Regards,
 Yosef Or Boczko

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

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

Re: gtk_print_operation_run() blocks and ignores callback

[Tristan Van Berkom]

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


 GtkPrintOperation *op;

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

I think what you are missing here is
   gtk_print_operation_set_allow_async()

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

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

Cheers,
-Tristan


 draw_page() of course exists as well:

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

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

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

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

Re: Stock Items Deprecation

[Tristan Van Berkom]

On Tue, Jul 2, 2013 at 10:41 PM, William Jon McCann
william.jon.mcc...@gmail.com wrote:
 Hi,

 As some of you may have noticed we have recently deprecated Stock Items in
 master.

 Some details on this change may be found here:
 https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub

 Please let us know what you think.

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

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

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

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

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

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

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

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

Cheers,
-Tristan


 Thanks,
 Jon

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

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

Re: Insert Various GTKWidgets into a dlg_window

[Tristan Van Berkom]

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

Hi Rui,

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

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

Here are the basic rules which apply to a GtkTable

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

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

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

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

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

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

Example:

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

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

Cheers,
-Tristan


 Thanks in advance,
 Rui

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

 Cumprimentos,
 Rui Pedro Caldeira


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

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

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

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

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

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

Re: Minimum height for minimum width - reprise

[Tristan Van Berkom]

On Wed, Jun 19, 2013 at 10:13 PM, Pietro Battiston
m...@pietrobattiston.it wrote:
 Il giorno mer, 19/06/2013 alle 20.03 +0900, Tristan Van Berkom ha
 scritto:
 On Wed, Jun 19, 2013 at 6:19 PM, Pietro Battiston m...@pietrobattiston.it 
 wrote:
 [...]
  This is, to my eyes, the clearest example of height-for-width space
  management... and as far as I understand, it is currently impossible.
 
  Am I missing something?

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

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

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

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

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

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

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

 Does this answer your question ?


 Well, this did suggest to me that my question was maybe not well
 formulated - in fact, I have a problem with the layouting algorithm, not
 with the working of a widget on its own. So consider this simple
 example:

 1) in my widget_get_preferred_width(), I set
*minimum = 50
*natural = 200

 2) in my widget_get_preferred_height_for_width(), I set
*minimum = *natural = 1/width

 3) I pack_start this widget into a Gtk.VBox()

 4) I add the VBox in a Gtk.Window, and show_all() it

 Result: a window that's 200x200 (and the user can't shrink vertically).

 Now repeat the steps above, adding, between 3 and 4:

 3a) I pack_start into the VBox an additional 60x17 GtkLabel (or
 GtkImage, that's irrelevant).

 Result: a window that's 200x183!

 So to resume: what annoys me - in both cases - is that the window is
 much too tall, and the user cannot even shrink it vertically.
 But what I really find inconsistent is that by adding a widget below,
 the resulting window may become smaller!

 Anyway, I don't have a better algorithm in mind - if you tell me that
 there is nothing I'm missing and there is no obvious solution to such
 problem, I'll just make things work reasonably in reasonable contexts.

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

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

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

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

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

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

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

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

Re: gobject across network

[Tristan Van Berkom]

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

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

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

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

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

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

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

Cheers,
-Tristan


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

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

 ciao,
  Emmanuele.

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

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

Re: GUI freeze and long blocking operation

[Tristan Van Berkom]

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

 Hey John,

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

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

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

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

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

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

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

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

What you currently have is:
~

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


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

What you need to do instead is:
~~~

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

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

}
}

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

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

Cheers,
-Tristan


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

 # Update GUI...
 (...)

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

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

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

[Tristan Van Berkom]

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

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

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

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

 What are you monitoring, and how ?

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


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

For more fine grained memory profiling you should use valgrind.

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

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

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

[Tristan Van Berkom]

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

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

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

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

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

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

 What are you monitoring, and how ?

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

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

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

 Chris


 You can have the whole source code:

 http://pastebin.com/4a5DiMsQ

 I'd been distributing it around to fix issues.

dE,

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

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

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

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

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

Re: Prevent sort of GtkListStore.

[Tristan Van Berkom]

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

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

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

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

Cheers,
-Tristan


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

Re: glade and C code

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan


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

Re: GTK+3 motion events and is_hint

[Tristan Van Berkom]

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

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

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

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

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

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

Cheers,
-Tristan

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


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

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

[Tristan Van Berkom]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Tristan Van Berkom]

[branching thread here]

On Fri, May 17, 2013 at 8:20 PM, Alexander Larsson al...@redhat.com wrote:
[...]
 This branch doesn't precisely reinvent the wheel, there's just a few API
 additions to current components to have this work as seamlessly as
 possible. As choosing an icon must be postponed till rendering time, the
 preferred way to hold this information is GtkIconSet and GtkIconSource,
 as these already do a few things we want here:

   * It may already hold multiple sources for an image
   * GtkIconSize works as a scale-independent size abstraction

 This has implied making GtkIconSets more prominent, so the matching
 properties have been added to GtkEntry and GtkCellRendererPixbuf.

 GtkIconTheme has been regarded as a lower level file-pixbuf abstraction
 and mainly a few *_for_scale() calls have been added there so
 GtkIconSets can resolve rendering to the bes3t pixbuf.

 Ugh. I hate GtkIconFactory. Mainly due to the GtkIconSize abstraction.
 Any time i use it I have to fight that crap, because what you really
 *do* want is a (possibly scaled) pixel size. In fact, GtkIconFactory has
 been mostly deprecated due to this and all modern code use icon names
 and GIcons.

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

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

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

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

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

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

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

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

[Tristan Van Berkom]

On Sat, May 11, 2013 at 8:56 PM, Fabian Keil
freebsd-lis...@fabiankeil.de wrote:
 Fabian Keil freebsd-lis...@fabiankeil.de wrote:

 Emmanuel Thomas-Maurin manutm...@gmail.com wrote:

  On 04/21/2011 02:44 PM, Fabian Keil wrote:

   I haven't filed a bug report yet as it wasn't clear to me
   if the behaviour is actually considered a bug. If there's
   an agreement that the behaviour is a bug, I wouldn't mind
   filing one.
 
  IMHO, it's definitely a bug and it's worth beeing reported so that it
  can be reviewed, along with your patch, by a maintainer, then finally 
  fixed.

 I filed https://bugzilla.gnome.org/show_bug.cgi?id=648381

 And two years later this bug still exists ...


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

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

 Fabian

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

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

Re: CSS Transitions

[Tristan Van Berkom]

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

 Indeed.

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

This way one could specify:

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

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

Cheers,
-Tristan

 If I was handling this on the web, I'd probably do something like,
 in setup:

   $(button).transitionEnd(
function() {
$(this).removeClass('pressing');
});

 When pressed:

  $(button).addClass('pressed').addClass('pressing');

 In CSS:

  .button.pressed { background: red; }
  .button.pressing { transition: background 1s; }

 I think we possibly should do something similar here. We could do
 something like:

  gtk_style_context_add_temporary_class(button,
 GTK_STYLE_CLASS_PRESSING);

 With the semantics of temporary meaning removed when last transition
 finishes. I don't think you'd need many of these style classes to allow
 most of what the designers want.

 If you want to get an idea of how many transitions there might be, I'd
 be happy to write up what I'd like to happen in terms of behaviour.

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

Re: capture changed signal for the cell of treeview

[Tristan Van Berkom]

On Sat, May 4, 2013 at 12:37 PM, yu wu vanii.wa...@gmail.com wrote:
 I am using the followed to renderer text in cells:

 

   renderer = gtk_cell_renderer_text_new();
   column = gtk_tree_view_column_new_with_attributes((local = char_to_utf8
 (weight(kg/m))), renderer, text, MEM_SEC_WEIGHT_PER_METER, NULL);
   g_free(local);
   gtk_tree_view_append_column(treeview, column);

 

 I don't set `editable' attribute for the renderer. The value for specified
 cell is set by

 other sub-function. Then how can I get the `changed' signal for the
 specified cell when its
 value is changed? My purpose is to update other widget when text value in
 cell is changed.
 For the text cell renderer, it only has edited signal that is not useful for
 my case

How come the edited signal is not useful ?

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

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

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

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

Cheers,
   -Tristan

 (or maybe I misunderstand some points). When some cell is changed, it might
 have no
 any selection. That's, the `changed' signal for selection has no use here.

 Please help.

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

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

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

[Tristan Van Berkom]

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

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

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

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

Re: capture changed signal for the cell of treeview

[Tristan Van Berkom]

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

This is only more or less true.

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

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

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

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

Cheers,
   -Tristan

 This is why I want to know if it is possible to
 know which column is changed in other email. But from your reply to my other
 email, there is no way to know which column to change when row-changed is
 emitted. Then I have to update widgets when cell of column 0 is edited or in
 other functions which result in the change in column 1~3 mentioned above.

 As to GtkCellView, I have never used it. I have to read it first and then
 see.


 2013/5/4 tristan.van.ber...@gmail.com


 On 2013-05-04, at 7:00 PM, yu wu vanii.wa...@gmail.com wrote:

 As I wrote in my original email, the renderer is ** not ** set editable.
 Therefore, it can't be connected to ** edited ** signal.

 Here is the situation for example. Renderer 1 -- column 0 is set editable.
 Renderer 2-4, i.e., column 1-3, is not set editable. When column 0 is
 edited, the value of column 1 is set. As to the values for column 2-3, they
 are set by other functions. Then I would like to capture the changes of
 column 1-3. After I get the changes, some other widgets (inside treeview or
 outside treeview) will be updated.


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

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

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

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


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


 在 2013年5月4日星期六，Tristan Van Berkom 写道：

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

 How come the edited signal is not useful ?

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

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

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

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

 Cheers,
-Tristan

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


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

Re: capture changed signal for the cell of treeview

[tristan . van . berkom]

On 2013-05-04, at 7:00 PM, yu wu vanii.wa...@gmail.com wrote:

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

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

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

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

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

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

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

Re: Conventions for Error Logging

[Tristan Van Berkom]

On Sat, May 4, 2013 at 10:22 PM, אנטולי קרסנר tomback...@gmail.com wrote:
 Hello,

 I'm writing a desktop application using Gnome technologies. I added
 support for some operations which may fail or produce useful errors, so
 I decided I want the app to record the warnings and errors in a log
 file, allowing me to see the report later, and find bugs.

 I tried to find any conventions for GNU software logging, and for Gnome
 apps, but I found nothing.

 Is there a convention for that? A standard location for log files in
 filesystem/home directory? A common standard for naming them and filling
 the contents?

System daemons would generally dump logs somewhere like:
$(localstatedir)/log/$(daemonname)/$(daemonname).log

Apps don't really log AFAIK, as they don't really have write permissions
to /var/log, instead I would think it more appropriate for the app launcher
(something integrated in the window manager, like a springboard) to direct
logging of an apps' stdout/stderr to some directory *it* controls (however
I don't know if WMs or gnome-shell actually do this, just think it would
be the 'right way').

If your app must write somewhere, it would be safe to write in XDG_CACHE_HOME
(g_get_user_cache_dir()).

Cheers,
-Tristan


 And does Gnome have a log viewer app for reading log files produced by
 applications?


 Anatoly

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

Re: glib: processing events in multiple threads

[Tristan Van Berkom]

On Tue, Apr 30, 2013 at 8:26 PM, richard boaz ivor.b...@gmail.com wrote:

 [...]
 I've heard from quite a few people in particular in the GNOME camp who
 believe that everything should be asynchronous and that multithreading
 is evil.


 i don't know who these GNOME people are (very short?), but going with
 multi-threading is evil is an unbelievable statement: i'm gobsmacked.
 (and the hardware guys wonder why we're such idiots.)  all those extra CPU's
 are only intended for multiple app execution and not to be used
 simultaneously by the same program where possible?  i can only conclude one
 thing here: it must be simply too difficult for them to implement.

I should mention this, because this seems to be a misinterpretation of
something I probably mentioned to Patrick myself.

Now, there are probably a multitude of reasons for implementing an
asynchronous API, but let's stick to two very popular and probable
reasons:

   a.) The actual work is done in another process, which means generally
 that calling an Async API consists of writing some bytes to a socket
 (D-Bus most popularly) and adding a file descriptor to a poll() call,
 awaiting your reply.

   b.) The actual work is CPU intensive, and probably already executed
as a separate thread or process.

Now, let's say you already have access to an Async API, is there any
reason, other than the desire to play with fire, to actually execute the
Sync API *in a separate thread* manually ?

I know this sounds like a ridiculous question, but people have been doing
just that, and this is the kind of thing I would like to discourage; i.e.
playing with threads when it is absolutely uncalled for.

The temptation to do this stems from the apparent simplicity of calling
a Sync variant of an Async API, coupled with overconfidence of
playing with threads manually (which honestly, should be left to the
grown-ups, no offence intended to anyone really, but threading correctly
is just not trivial).

Basically, for D-Bus at least, a Sync variant of a method call is a matter of:

  o Creating an isolated GMainContext/GMainLoop (isolated in the sense
 that the only GSource which can occur while running the encapsulated
 mainloop is the D-Bus method reply... *everything* is blocked while
 making a synchronous D-Bus method call).

  o Issuing an Async call

  o Waiting for only the Async method call to return in encapsulated
main context

  o Collecting the return value when the call completes (or times out)
and destroying
 the temporary GMainLoop  GMainContext.

So essentially, if there is an Async variant of a D-Bus method, the Sync variant
is only a way to call the Async variant of the same API and block execution.

But, we run into situations (like in EDS) where the user facing APIs never call
the Async D-Bus methods under the hood, but instead run a thread, and call the
Sync method *from a thread*, where it will essentially just block
while performing
a method call, not buying you any cycles on your separate CPU/cores, but adding
a lot of complexity to your code.

I hope this clarifies things a bit, if there are Async APIs, it's
better to just use
them, if you have CPU intensive code to run, then you have justification for
threading, of course, by all means run that workload in another thread.

Cheers,
-Tristan


 in some vain attempt (pun intended) to restore some street cred, i offer up
 a different attitude a programmer can have where hardware advances are
 concerned and how these can be exploited to maximum benefit.

 what my GUI program is required to do, very briefly, is to read any number
 of multiple files sitting on disk, each to be displayed on a separate line
 (seismic data files).  where this is all multi-threaded in the following
 manner:

 at start-up, query the computer to determine the number of CPU's available
 to my program
 on request to display data files, start a separate thread to:

 place all files to display on a single Q
 start up numCPUs threads, where each thread queries the Q (call is mutexed)
 for the work details, until nothing left on Q
 return to display for rendering

 and what this means is: as hardware advances and more and more CPU's become
 available, because of this design, program execution will get faster and
 faster without one line of code having to be adjusted in the future.  i
 don't even need to recompile.

 and this is just one example of how i maximize having multiple CPU's
 available to me.  the possibilities become endless when this concept is
 wholly embraced, as it should be.  do not be afraid...


 To be more specific: what I wanted to avoid was the need to protect data
 with mutices by ensuring that the only code ever touching it is from the
 same thread. That is easier to enforce than correct mutex locking.


 this, of course, comes down to your requirements' details.  only one
 recommendation here: when using mutexes, make sure that you surround
 absolutely the 

On regressions and carelessness

[Tristan Van Berkom]

Dear fellow hackers,

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

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

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

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

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

Which was signed off by Benjamin Otte.

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

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

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

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

commit b164df74506505ac0f4559744ad9b59b5ea57ebf
Author: Tristan Van Berkom trista...@openismus.com
Date:   Sat Apr 20 17:52:16 2013 +0900

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

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

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

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

commit b8e4adfff9ba62330a71ea7498595227979bb4f0
Author: Benjamin Otte o...@redhat.com
Date:   Mon Apr 22 08:23:08 2013 -0400

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

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

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

  This is called too cool for school.

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

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

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

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

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

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

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

Re: 3x3 dungeon representation

[Tristan Van Berkom]

On Wed, Apr 24, 2013 at 11:36 PM, marco ferrari pacom...@gmail.com wrote:

 Hello everybody,
 first of all I apologize in advance for any grammatical errors, but
 english is not my first language.
 I'm trying to develop a small videogame in c++ as a university project.


Sounds fun ;-)


 In this project the main character tries to escape from a dungeon made of
 9 rooms disposed in a 3x3 grid. Between each room there is a door that can be
 opened with keys scattered throughout the map. The core of the project is
 already made and the game is playable via terminal.
 I'm thinking about the best way to represent this graphically with GTK
 libraries (rooms, charachter, doors, keys and eventually other object
 disposed random through the map), with a minimal interface and a top view
 of the dungeon like this (but not so minimal):
  __ __ __
 |   |   |  |
 |**|  |
 |____|__|__|
 |   |   |  |
 |**   |
 |__|__|__|
 |  |   |   |
 |  |**|
 |__|__|__|

 (** = key, blank space = door opened, | or __ = door closed)

 My idea was to create a window with multiple containers/boxes (a grid of
 about 7x7 boxes, not sure already), then:
 - In the rooms boxes place an image with the room and the oblect in it
 (and eventually reload the image with the character move in or without the
 objects when the player picks themp up).
 - In the doors boxes place an image with the opened or closed door and
 reload it when the pre-existing condition changes.
 - In the rooms's divider boxes place an image to represent the wall
 between the rooms.


I think you're complicating things a bit, I recommend that you ditch the
idea of
a room being a box, and the wall being a sort of separator... everything
occupies space.

Instead, it's probably better to think in terms of tiles everywhere...
some tiles
can be empty space, some of them might be a vertical or horizontal piece of
a wall, some of them might be an intersection of walls, some of them could
be doors or other object.

On top of that, you could render a background image before painting anything
else, which could be the floor... the character which moves around in space
could derive from the same 'tile' object which paints things layed around in
space, but have the added attributes such as, collision detection (avoid
walking through walls, unless the 'ghost' power up was eaten ;-)),
interaction
with other objects such as doors and keys.

Finally, you probably want to just do this all inside a single drawing area
widget instead of actually using GtkGrid to lay things out... use cairo
for drawing and queue redraws on the areas which might need to be
redrawn because of some input (like the character moved).

Have fun !

Cheers,
 -Tristan



 Any suggestions or better ideas?
 Thanks for your help!
 Marco F.

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


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