Re: Copywrite protection and source-code distribution

[Colomban Wendling]

I am not a lawyer, but…

Le 31/07/2018 à 15:41, Roger Matthews via gtk-app-devel-list a écrit :
> I have developed an application using GTK+3.10. What copy-write
> protection can you (GTK+) provide for me.

GTK+ doesn't "provide copyright protection" for software using it, and
no library does.  GTK+ is licensed under the LGPL license, which
basically means you can use it as a dynamic library from software
distributed in any license (basically, it being free software or
proprietary software).

> I have been told that
> copywrite is free and automatic and that to protect the software from
> piracy I need sufficient money to prove prior usage in a court of
> law.

Yes, the simple fact you wrote the software is enough.  The concept of
"proving prior usage" is only when there's actually litigation, and you
need to prove you're actually the original author, so it's indeed yours.
 I have no idea what's legal in which countries, but some people
mentioned sending yourself a copy of the software through snail mail
(with the post office stamp on it) and keep it unopened as evidence, but
I guess any method that can tie a legal date with your software is fine.

> I don't see how the requirement of including my source code in
> the package will allow for successful commercialisation when someone
> can just simply copy the source-code.

What requirement?  You're not *required* to distribute your software
under an open source kind of license, GTK+'s license allows you to
dynamically link it to a closed source software.  You're the one to
decide here, you just need to make sure you follow the clauses of the
licenses of the libraries you're using, but in the case of GTK+ you can
still select a proprietary license for your software if you really want.
 Not that I think it's a good idea, but I guess it's irrelevant :)

However, if you're distributing GTK+ yourself, you're required to
provide the sources for it, but if it's just upstream it might be OK to
just link to the upstream sources.  But that only applies to the parts
that *are* under a free software license -- well, under any license
telling you you have to do that.

You're also confusing copyright and making money.  Pretty much any
source code has a form of copyright on it, the copyright is basically
the rules that control how it can be copied.  Free software licenses,
even if often referred as "copyleft" for the wordplay, is a form of
copyright: it states the rules for redistributing, it just happens to
require openness (in case of e.g. GPL and cousins) instead of
disallowing it.

> I have no problems about
> acknowledging GTK+ for providing the GUI development platform and for
> helping with problems in coding, etcetera.

I'm not sure what's the rule about acknowledgment in case of using a
library.  I guess it's customary to mention you're using it, but it
might not be required to do so at a user level.

> Without adequate
> protection this requirement (including the source-code) renders GTK+
> useless as far as any kind of commercialisation is concerned, please
> enlighten me on this matter.

I guess you misunderstood the GTK+ license, that *does not* state that
you have to distribute the sources of your application [1].  You do have
to distribute the sources of *changes made to GTK+* in case you did
some, but that's it.

This said, there are plenty of successful companies making money out of
free and open source software, they just don't sell the code itself
usually -- although they *could*, so long as people will buy it.

Regards,
Colomban


[1] well, I don't wanna confuse you, but it's a little more subtle than
that: you're only required to distribute *derivative* work under the
same license (LGPL for GTK+).  What is a *derivative* work is the
question here, and dynamically linking your application to GTK+ does not
make your application a derivative work of GTK+.  Statically linking it
would, though.  You can find an enormous amount of info on that on the
Internet, and you can obviously carefully read the GTK+ license.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [PyGObject] Drag & Drop in a TreeView

[Colomban Wendling]

Le 27/07/2018 à 23:05, c.buhtz--- via gtk-app-devel-list a écrit :
> Dear Reuben
> 
> On 2018-07-23 08:03 Reuben Rissler  wrote:
>> This is how I have done it in the past. Note, I do not proclaim 
>> spectacular or Pythonic code, and would humbly accept any corrections 
>> and/or better ways to accomplish this. It seems to me there should be
>> a way to let the TreeView do this work itself, but alas, I have not
>> found it yet.
> 
> Your code works for me - thank you very much. But I also have the
> question if anyone here could improve it or show a more easier and
> elegant way.

If it's only for reordering the elements in the tree view, you can use
the built-in Gtk.TreeView.set_reorderable() method [1], and you're all
set.  You get inserted/deleted signals for moved rows so you can know
when and how things changed if needed, and the underlying model is also
changing accordingly.

Regards,
Colomban

[1]
https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-reorderable
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk3 CSS classes for Custom Widgets - Help!

[Colomban Wendling]

Hi,

Le 16/02/2018 à 12:12, Randall Sawyer a écrit :
> I have devised a custom widget which is intended to appear and react to
> user input as if it were a button (without the overhead of inheriting
> GtkButton).

This sounds a fairly odd way to proceed, as if it has all the properties
of a GtkButton it would seem a whole lot easier to use a GtkButton as a
basis and just react to its various changes… and you wouldn't have to
extensively try and pretend being a GtkButton which you are not. But
well, maybe I don't know your code.

> […]
> 
> Whether or not this actually results as desired depends upon which theme
> I am using. Specifically, whether CSS button styles are defined using
> the /type selector/ "button" or the /class selector/ ".button".
> 
> I never get the button style if the theme has been composed using the
> /type selector/ "button"; for example, in Adwaita.
> 
> I always get the button style if the theme has uses the /class selector/
> ".button".
> 
> I have done extensive searches to see if anyone else has brought this to
> the attention of the Gtk community. So far I have found nothing about it.

That's unlucky, because there is just gtk_widget_class_set_css_name()
[1] which seems to be exactly what you are looking for -- e.g. set the
CSS node name, not *class* name.

[1]
https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-class-set-css-name

> As I see it there are two possibilities to remedy this inconsistency:
> […]

It's not an inconsistency, it's just the difference between a CSS node
and a CSS class name.  In CSS you got node name, classes and ID, so you
do in GTK, which maps them to widget class' CSS name
(gtk_widget_class_set_css_name()), classes on the style context, and
widget name (gtk_widget_set_name()) respectively.

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

Re: Error unknown type name ‘GtkSearchEntry’

[Colomban Wendling]

Le 27/02/2017 à 10:51, Rúben Rodrigues a écrit :
> Hi guys,
> 
> Someone who knows this error?
> 
> DescriptionResourcePathLocationType
> unknown type name ‘GtkSearchEntry’ConsolaGraficaline 39, 
> external location: 

Too old GTK?  GtkSearchEntry is new in 3.6:
https://developer.gnome.org/gtk3/stable/GtkSearchEntry.html  Many of its
useful stuff is new in newer versions, 3.10 and 3.16, too.

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

Re: Programatically activate menu like a mouse click

[Colomban Wendling]

Le 24/02/2017 à 10:24, John Lane a écrit :
> On 23/02/17 21:02, Colomban Wendling wrote:
> 
>>
>> Sounds odd to do that manually.  Do you know about mnemonic keys?
>> Basically if you mark some part of the label to be the mnemonic letter,
>> you'll be able to trigger that element with Alt+letter.
>>
>> Additionally, F10 already pops up the first menu of the window's menubar.
>>
> 
> I sent a reply to Eric's message with an example of what I am doing.
> Whay you suggest is valid for a "window" application that has the input
> focus but I am trying to write a "dock" application that isn't focussed.
> Sorry I should have made that clearer.

OK.  But it's also actually what e.g. MATE's panel (which is a dock too)
uses:
https://github.com/mate-desktop/mate-panel/blob/master/mate-panel/panel-menu-bar.c#L415

>> self.menubar1.select_item(self.menuitem1)
> 
> Thanks for that tip - I tried it and (see my other msg) it selects the
> first menu item but the app doesn't respond after that.

There really seems to be something funky in relation to that Keybinder.
GTK emits warning when poping up the menu, I guess because it doesn't
see the "current event".

Initially:
> (menu2.py:24105): Gtk-WARNING **: no trigger event for menu popup

And then, if playing with arrows:
> (menu2.py:24105): Gdk-CRITICAL **: Window 0x55a411e7d660 has not been made 
> visible in GdkSeatGrabPrepareFunc
> 
> (menu2.py:24105): Gdk-CRITICAL **: Window 0x55a411e7d660 has not been made 
> visible in GdkSeatGrabPrepareFunc
> 
> (menu2.py:24105): Gdk-CRITICAL **: Window 0x55a411e7d660 has not been made 
> visible in GdkSeatGrabPrepareFunc
> 
> (menu2.py:24105): Gdk-CRITICAL **: gdk_window_get_window_type: assertion 
> 'GDK_IS_WINDOW (window)' failed
> 
> (menu2.py:24105): Gtk-CRITICAL **: _gtk_widget_captured_event: assertion 
> 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
> 
> (menu2.py:24105): Gtk-CRITICAL **: _gtk_widget_captured_event: assertion 
> 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
> 
> (menu2.py:24105): Gtk-CRITICAL **: _gtk_widget_captured_event: assertion 
> 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

I can't help with that, but I think it's related with the issue ;)

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

Re: Programatically activate menu like a mouse click

[Colomban Wendling]

Le 23/02/2017 à 15:57, John Lane a écrit :
> […]
> 
> The UIManager provides the menu bar, a few items in the bar each leading
> to menus containing a few items. The user can click operate the menu
> with a mouse and selecting a menu item triggers a callback that prints
> the name of the selected item. Nothing special thus far, but it works.
> 
> Once the user has clicked on a menu bar item with the mouse, she can
> then navigate the menu with the keyboard (or continue using the mouse).
> 
> I have wired up a global key binding using the 'keybinder' module and
> receive a callback when a mapped key is pressed.

Sounds odd to do that manually.  Do you know about mnemonic keys?
Basically if you mark some part of the label to be the mnemonic letter,
you'll be able to trigger that element with Alt+letter.

Additionally, F10 already pops up the first menu of the window's menubar.

> […]
> 
> How can I trigger the menu activation (like a mouse click does) ?

Read https://developer.gnome.org/gtk3/stable/GtkMenuShell.html and use
Gtk.MenuShell.select_item().  As menubars and menus are shells, assuming
Eric's sample, use:

self.menubar1.select_item(self.menuitem1)

instead of manually poping the menu up.

But still, you should consider using memnonics

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

Re: caret-color (and caret-width?)

[Colomban Wendling]

Hi,

Le 26/01/2017 à 16:57, Richard Shann a écrit :
> I see at
> 
> https://developer.gnome.org/gtk3/stable/chap-css-properties.html
> 
> that there is a caret-color property. Is it possible to change the
> thickness of the text caret?

Yes:
https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--s-cursor-aspect-ratio,
that is "-GtkWidget-cursor-aspect-ratio".

> 
> and, how exactly is caret-color supposed to be set I have:
> 
> str = "GtkTextView {caret-color: rgb(255,0,80);}";

Which GTK version do you use?  this property is new in 3.20, before that
you had to use "-GtkWidget-cursor-color" instead.

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

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Le 30/12/2016 à 18:25, Jim Charlton a écrit :
> If one does want to draw into a cairo_surface_t, one can create a cairo
> context for drawing? E.g.
> 
> cairo_t   *
> cairo_create (/|cairo_surface_t
> 
> *target|/);
> 
> That use of cairo_create() is not deprecated... (I assume).

cairo_create() is not deprecated, only gdk_cairo_create() is.
And yeah, that use is perfectly valid and fine.

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

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Le 30/12/2016 à 15:09, Sergei Kolomeeyets a écrit :
> Hi, Colomban
> Thanks a lot for you hint! I realised the idea of wrong event hanling.
> Do you mean that I SHOULD DO NOTHING to create a cairo context BECAUSE
> IT IS in the draw event callback function obligatory parameters? And, if
> yes, I could think as if GTK+ itself prepares it for me BEFORE emmit
> that event?

Yes, GTK prepares it for you.  Don't create it, don't destroy it, just
use it.

> Thanks again and Happy New Year!

Thanks, to you too!

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

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Hi,

Le 30/12/2016 à 12:20, Sergei Kolomeeyets a écrit :
> Hi, everyone
> […]
>
> {draw_callback}
> 
> gboolean draw_callback(GtkWidget *area, GdkEventExpose *event, GArray
> *ptLinePoints) {

That's not the right signature for the GtkWidget::draw signal: it takes
a cairo_t* as the second parameter, not a GdkEventExpose like did
::expose.  And here you have your Cairo context :)

See
https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw [1]

Also, read
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11, and
more generally
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

So basically you don't need gdk_cairo_create() at all.  If you want to
draw outside of the ::draw() handler and paint the cached thing then,
use a cairo_surface_t as the offscreen surface, and paint it then.

Hope this helps.

Cheers,
Colomban

[1] which says "CairoContext", but that's a weird lie on the API… not
sure why, maybe the GType has this name so introspection is confused.
Anyway, it's cairo_t.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkEntry placeholder in GTK2

[Colomban Wendling]

Hi,

Le 14/11/2016 à 14:30, Gabriele Greco a écrit :
> I know GTK 3.2+ has a nice gtk_entry_set_placeholder_text() method, but I'm
> wondering if there is some clever method to do something similar with GTK2,
> I've not found anything googling around, but placeholder texts are a so
> common interface concept today that I doubt that someone has not yet
> "emulated" it in gtk2...

I wrote something like that ages ago, you can find it there:
https://github.com/b4n/gvg/blob/master/src/gvg-entry.c

I haven't touched this for ages though, but IIRC it worked nicely.

Hope it helps,
Colomban
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How can I retrieve gtk style context information from textview widget class without a textview widget?

[Colomban Wendling]

Hi,

Le 12/06/2015 14:04, Friedrich Beckmann wrote:
> I would like to use the style information from the textview widget in
> another context. I want to retrieve the text foreground color and the
> background color as it would be used in a textview widget and use
> this style information for rendering inside a drawing area. […]
> 
> […]
>
> Is there a way to retrieve this information of the background-color
> similar to the class mechanism? I would need the same style context
> as if I was in a textview widget.

Don't take my words as gospel, but there's something:

First, realize that you can't reliably achieve the same look as the
theme by simply picking background and foreground colors: the theme
might be using gradients, images and whatnot.
If you want to paint it like a text view, you should probably use the
GTK rendering functions, like gtk_render_background() and
gtk_render_layout().

Then, if you don't have an actual GtkTextView to get the style context
from, you'll need to create it yourself faking the one a true text view
would have.  You can probably do that relatively easily with
gtk_style_context_new() and then setting an appropriate widget path with
gtk_style_context_set_path() -- and possibly appropriate classes, as you
already figured out.

Regards,
Colomban


https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-render-background
https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-render-layout
https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-new
https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-set-path
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: IA__gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

[Colomban Wendling]

Le 12/03/2015 16:20, Rui Pedro Caldeira a écrit :
> Hello guys, I once again seek your guidance.
> 
> I have a series of GtkWidget* that then take the form of GtkButton,
> GtkComboBoxText,...
> 
> And when I close a window, I first want to destroy the widgets.

Why?  Widgets are automatically destroyed when their parent container is
destroyed, and the default action taken when closing a window is to
destroy it.  This is likely to be the reason why they are already
destroyed by the way.

Generally you only need to explicitly destroy widgets if you want to
change the UI layout dynamically (e.g. if you remove a widget when the
user clicks on a button).

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

Re: Scrolled window child contents showing on other widgets when resizing window in scrolled state

[Colomban Wendling]

Hi,

Le 09/03/2015 08:41, Pramathesh Ambasta a écrit :
> […]
> 
> The ui consists of a main window, a grid in which are packed a File
> ChooserWidget (above) and a scrolled window below. The scrolled window
> has a layout or a drawing area with a viewport as a child.
> 
> In the layout or the drawing area, a cairo context is obtained by making
> a call to gdk_cairo_create.
>
> […]

In GTK3 you should *never*¹ have to call gdk_cairo_create() to draw on
the screen.  Just use the cairo_t received as argument of the :draw signal.

All your problems most probably come from this.  I recently fixed an
application that had similar issues, and all I had to do was remove the
various gdk_cairo_create()/cairo_destroy() pairs in :draw handlers.  I
guess the author had those for GTK2 and didn't remove them when porting
to GTK3 or something.

Note that a change in GTK 3.9.2 (IIRC) changed these kind of calls from
"useless junk" to "oh my god why is my app broken", so maybe your
application worked with earlier versions.  However, it never was right
to do it with 3.x, and if it ever worked it was only a mere
implementation detail that happened to let you do it.
AFAIK, the technical reason behind this is that each widget used to have
its own surface, but now GTK tries and use only one surface² and
properly prepares the context passed to each widget's :draw signal to
have clip and everything setup for them.  If you create a new context
yourself, it won't get this clipping and friends, leading to possible
off-widget drawings.

Regards,
Colomban

¹ ok maybe there are very corner cases where it might make sense, but
that's really not the norm.
² well, that's not entirely true, there are some widgets that will use
their own, but not every ones like it used to.
___
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 GtkCellRendererPixbuf: pixbuf vs. icon-name

[Colomban Wendling]

Hi,

Le 14/02/2015 01:18, Roland Koebler a écrit :
> I would like to render either an icon or a pixbuf at the same place in
> a TreeView. So, I tried to use a CellRendererPixbuf and either set the
> pixbuf- or icon-name-property:
> 
> - Use a liststore with two columns, one for the pixbuf, one for the
>   icon-name.
> - Set only one of pixbuf or icon-name, and the other to None.
> 
> But in my tests, the pixbuf is always ignored, and either the icon-name-
> image is shown or nothing.
> […]
> 
> Am I doing anything wrong?
> Or is the documentation wrong?
> Or do I have to only use pixmaps, and therefore create a pixmap from
> every icon-name I want to use?

I don't know if there is a simpler way to do what you want but I would
imagine that every time one of the properties is set it takes precedence.

Anyway, you could use gtk_tree_view_column_set_cell_data_func() to
manually set the appropriate property.  I'm not very used to do this in
Python, so it might not be the cleanest possible (like I don't know if
set_property() is the wait to go), but it works:

...
col = Gtk.TreeViewColumn("Image", renderer)

def cell_data(col, cell, model, iter, data=None):
name, pix = model.get(iter, 0, 1)
if pix is not None:
cell.set_property('pixbuf', pix)
else:
cell.set_property('icon-name', name)

col.set_cell_data_func(renderer, cell_data)
...

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

[GI] Generic array type

[Colomban Wendling]

Hi,

I'm trying to generate a gobject-introspection binding for a library,
and am facing some problems I couldn't find the answer to.

First, no, the library isn't really GObjec-based.  However that was not
the problem, I added appropriate boxed GTypes, and the GIR mostly works
[1][2].  So, my GIR works mostly as expected from Vala [3], Python and
GJS.  Great.

However, here comes the tricky problem:  my library has a custom generic
value type, which supports integers, reals, strings, and arrays.  So, I
wanted to add wrapping API that take GValues to integrate seamlessly
with the languages:

..._push_gvalue(..., GValue *value, ...);

so that the higher level language using the GIR could pass natural types:

...push(..., 42);
...push(..., "hello");
...push(..., [1, 2, "hello", [2, 3, 4]]);

It works just fine with integers, reals and strings.  But it doesn't do
anything good with arrays.
The problem is, I guess, because GI doesn't have a canonical generic
array type [4], so language bindings don't know what they should do when
trying to pass an array as a GValue.

Python passes in a boxed PyObject (what am I supposed to do with that?),
GJS basically errors out complaining it can't convert the array, and
Vala doesn't compile code passing in a native array (`int[]` for
example, nor even `GValue?[]`).

With Vala I can make it work by explicitly giving a `Array`,
which properly gets boxed, and that I can read (of course, it's plain C
after all), but I can't even find these APIs in Python or GJS.

Of course, I could add separated API for arrays like this:

..._push_gvalue_array(..., GValue **values, gsize n_values, ...);

It works, but of course only for a single-level array (fails the same
with an array containing array members) -- and having separate API for
the array case is also not very nice.

I also gave GVariant a quick shot, but while it works quite well with
Vala (well, similarly to GValue, with the addition it knows about
arrays), it doesn't seem to have any kind of magic integration for
creating variants with Python or GJS [5] -- and then becomes extremely
verbose.
Also, I'm not quite sure GVariant is meant to be used that way, so maybe
it's abusing the API?


Anyway, my question is:  is there a way to pass generic arrays
implicitly as GValue (e.g. a GArray of GValue*, but I'm open to anything
usable from C), or is this a lost cause?

And if my only way is to manually build arrays, does Python and GJS have
a way of building a GArray, or some other similar GLib array type?
There is no constructor for GLib.Array in GJS apparently, and I didn't
find any in Python either.


BTW, I similarly need to be able to return an array and this array be
usable by the calling language.  Returning a GArray boxed in a GValue
"works", but that array is not really usable (not interface to access it
in Python, and GJS tells me without surprise that it is "Unable to
introspect element-type of container in GValue").  GVariant seems a
little more usable there.


Thanks for reading through :)

Regards,
Colomban


Notes:

[1] though, while it works with GJS and Python, apparently Seed doesn't
allow boxed types of unknown size and asserts out when calling the
constructor.

[2] but apparently boxed type constructors can't have arguments, which
is somewhat problematic -- but that's not important for me, at least not
now.

[3] Vala is a bit annoying because of
https://bugzilla.gnome.org/show_bug.cgi?id=670167, but I get it and it
can be worked around.

[4] there is GValueArray, but it's now deprecated.

[5] but Python seems to have some support for reading them, as they are
iterable, printable, and (to some extent) usable as a value
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Documenting properties and signals with gtk-doc

[Colomban Wendling]

Hi,

Le 20/12/2014 13:39, Wouter Verhelst a écrit :
> [...]
> 
> I wrote a library to deal with joysticks in a GObject/GTK-like way. It
> works (including a GTK-based tester tool, although the UI could use some
> improvement), and I now want to do the API documentation and also make
> sure that glib-introspection works.
> 
> However, I do not seem to be able to get the documentation that I wrote
> for the few signals and properties to actually show up in the gtk-doc
> output. It just isn't there.
> 
> I'm sure this must be something obvious to someone more experienced with
> gtk-doc than me, but I don't see it.

The problem you have is that your GType type names don't match your
class names.  You have JoyStickType and JoyModelType, but your classes
are name JoyStick and JoyModel.

As the properties and signals are detected by introspecting the types
(via gtkdoc-scangobj), the GType type name has to match the one of your
actual class, otherwise gtk-doc won't know they belong to it.

What you actually need to do is rename your GTypes to the real structure
name.  This will fix the type hierarchy (as you miss it), and the
properties and signals.

Regards,
Colomban


PS: your build system has issues, like the generated files
(joy-marchallers.[ch], joy-iface.h) aren't generated automatically, and
you lack a dependency on libjoy.la and UDEV_LIBS on your libjoy-gtk
library (this breaks building with LDFLAGS=-Wl,-z,defs)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Deprecated function ed icons on button

[Colomban Wendling]

Hi,

Le 06/10/2014 18:23, Gergely Polonkai a écrit :
> [...] Creating image buttons may seem a  bit harder than before.

As far as I can read, he spoke about GtkImageMenuItem, which for some
reason I never saw explained got deprecated (possibly because GMenu
don't support icons for another reason I didn't understand) -- and for
which I don't know a reasonably usable replacement.

> On 6 Oct 2014 17:03, "arkkimede"  wrote:
> 
>> [...]
>>
>> One of these case is  gtk_image_menu_item_new_from_stock(GTK_STOK_NEW,NULL)
>> The new version is
>> gtk_menu_item_new_with_label or
>> gtk_menu_item_new_with_mnemonic.
>>
>> I made the new version, the compiler do not print any message but the final
>> result is that the icon
>> disappear.

gtk_menu_item_new_with_label() and gtk_menu_item_new_with_mnemonic()
just don't create no icon, that's expected.

BTW, if you start learning GTK with GTK3, you should probably learn the
new concepts, like GtkApplication and GMenus rather than using the older
stuff.

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

Re: volume meter widget causes crash

[Colomban Wendling]

Le 21/09/2014 12:35, Joël Krähemann a écrit :
> Am Samstag, den 20.09.2014, 14:54 +0200 schrieb Joël Krähemann:
>> Why do I get the following error:
>>
>> **
>> Gdk:ERROR:/tmp/buildd/gtk
>> +2.0-2.24.10/gdk/gdkregion-generic.c:1110:miUnionNonO: assertion failed:
>> (y1 < y2)
>> Abgebrochen

You'd need a backtrace to see from where it really comes.

>> please take a look at:
>> https://sourceforge.net/p/ags/code/HEAD/tree/src/ags/audio/recall/ags_peak_channel.c
>> https://sourceforge.net/p/ags/code/HEAD/tree/src/ags/widget/ags_vindicator.c
>>
>>
>>
> 
> Excuse me for waisting your time but I really believe it's caused by
> concurrent access.

Concurrent access? are you using GTK widgets from several threads?  If
yes, that's hardly supported and generally is a bad idea.

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

Re: any ideas for a fix?

[Colomban Wendling]

Le 21/08/2014 22:30, Gary Kline a écrit :
> [...]
> {
>   printf ("For-Loop():  main with tt = (%d)\n", tt);
>   label[tt] = gtk_label_new ("1: This is the file name named talk.1.txt");
>   gtk_misc_set_alignment (GTK_MISC (label[tt]), 0, 0.5);  // left
>   label[tt] = gtk_label_new ("2: This is talk.2.txt");
>   gtk_misc_set_alignment (GTK_MISC (label[tt]), 0, 0.5);  // left
>   label[tt] = gtk_label_new ("3: File talk.3.txt file.");

You assign to the same array index three times (label[tt] = /*...*/;
label[tt] = /*...*/; label[tt] = /*...*/)

>   gtk_misc_set_alignment (GTK_MISC (label[tt]), 0, 0.5);  // left
> 
>   vbox = gtk_box_new (GTK_ORIENTATION_VERTICAL, 5);   // GTK3
>   gtk_container_add (GTK_CONTAINER (window), vbox);
>   gtk_box_pack_start (GTK_BOX (vbox), label[tt], FALSE, TRUE, 0);
>   gtk_widget_show (label[tt]);
>   gtk_box_pack_start(GTK_BOX(vbox), label[tt], FALSE, TRUE, 0);
>   gtk_widget_show (label[tt]);
>   gtk_box_pack_start(GTK_BOX(vbox), label[tt], FALSE, TRUE, 0);
>   gtk_widget_show (label[tt]);

...and pack the same widget (label[tt]) three times.  GTK widgets can
only have one parent, adding them several times is incorrect.  You need
to pack the first widget before setting the label[tt] to the new one.

Or more likely, you need to remove the loop and use 3 different
variables (or indexes), the loop seems to be misused.  A loop runs the
*same* body several times, it doesn't magically make different
assignations to the same index work like if they were different ones.

Regards,
Colomban
___
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 styles and themes

[Colomban Wendling]

Le 01/04/2014 11:49, Roland Koebler a écrit :
> [...]
> 
> Is there any documentation of this?
> Especially when to use "background-color" and when to use "background"?
> The "GtkCssProvider"-documentation only mentions "background-color".

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

The problem is the same with CSS, if you set only the background color
and there is a background image, the modified color is just not visible.
 If you override the whole background, it removes the image and thus the
color is shown.

Hope it somewhat helps.

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

Re: [Fwd: dereferencing void *]

[Colomban Wendling]

Le 24/03/2014 02:11, David Marceau a écrit :
> On 03/23/2014 08:36 PM, Joël Krähemann wrote:
>>
>> The following will compile but is it still correct?
>>
>>   g_atomic_pointer_set(&(returnable_thread->safe_data),
>>NULL);
> http://developer.gimp.org/api/2.0/glib/glib-Basic-Types.html#gpointer
> typedef void* gpointer;
> 
> http://developer.gimp.org/api/2.0/glib/glib-Atomic-Operations.html
> void g_atomic_pointer_set (volatile gpointer *atomic, gpointer newval);

That's not the signature in current GLib, but that's actually correct,
and means:

void g_atomic_pointer_set (volatile void* *atomic, gpointer newval);

hence, pointer to pointer.

> struct _AgsReturnableThread
> {
>   AgsThread thread;
>   volatile guint flags;
>   volatile void *safe_data;  // volatile gpointer safe_data
> };
> 
> safe_data holds the address pointing to a void value(unassigned type).
> By putting &(blah->safe_data), you are asking for the address of the
> address pointing to a void value.  That's not what you want.

Yes it is.  The atomic pointer functions expect a pointer to the pointer
to atomically set, not the pointer to set itself.

> Just put (blah->safe_data, NULL).
> The compiler shouldn't complain.

it shouldn't using a real function, but then it would crash at runtime.
 Anyway, GLib has various compiler-specific implementation of the atomic
operations, and the GCC one uses macros, which will detect the
dereference of that pointer to void, which is invalid C.

The macros does basically (a lot simplified):

#define g_atomic_pointer_set(ptr, valure) \
({ \
*(ptr) = (value); \
__sync(); \
})

> If it does, you could cast blah->safe_data with
> (volatile void*)(blah->safe_data)
> 
> or
> 
> (volatile gpointer)(blah->safe_data)

That's not a wise idea in case it'd hide some real issue, nor of any
use, in C any pointer is a valid void*.  And it wouldn't help here.

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

Re: [Fwd: dereferencing void *]

[Colomban Wendling]

Le 24/03/2014 01:36, Joël Krähemann a écrit :
> [...]
> 
> The following will compile but is it still correct?
> 
>   g_atomic_pointer_set(&(returnable_thread->safe_data),
>NULL);

Yes, as the atomic_int* functions expect a pointer to the integer to
atomically set, the atomic_pointer* ones expect a pointer to the pointer
to atomically set.

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

Re: g_spawn_sync and child PID

[Colomban Wendling]

Le 15/03/2014 21:19, Allin Cottrell a écrit :
> I'm reasonably familiar with the usage of both g_spawn_sync and
> g_spawn_async, but recently I've found myself wanting to do domething
> that seems to fall between the two and I can't quite work out how to do it.
> 
> Here's the task: I want to spawn an mpiexec process from my GTK app and,
> assuming all goes well, wait for the result (in itself that's a case of
> g_spawn_sync). But I also want to know the PID of mpiexec, so that I can
> give the user the option of killing that process "prematurely" if it
> seems to be going wrong. (This is based on the observation that an
> MPI_Bcast call, for example, can hang at 100% CPU if one or more of the
> processes launched by mpiexec bombs out at just the wrong moment.)
> 
> Any suggestions on how to achieve this using g_spawn* (or judgements on
> whether it's even possible) would be gratefully received.

If you need any user interaction, you probably need an asynchronous
spawn anyway, so you need to use g_spawn_async() and use
g_child_watch_add() to get notified when the child quits.  But since
this is asynchronous, your program have to handle the case stuff happens
when the process is running (like click on a cancel button, but also
anything else).

Also, how complex it'd be will depend on whether you need to write to
the child's stdin and/or read from its stderr/stdout.
If you open the pipes, you *have* to make sure none ever gets full,
which would block the child.  This means you have to also asynchronously
read and write to the child.
If you don't communicate with the subprocess however, it's only a matter
of waiting for the child asynchronously to let the UI interact with the
user, and that's pretty easy as explained above.

BTW, GLib spawn API also lacks a portable way to kill the subprocess, so
one has to manually use platform-specific API like kill() or
TerminateProcess() -- not hard to do, but has to be done.


Anyway, since all this can be tricky, I suggest you to try and use the
brand new GIO GSubprocess API if you can, it does all the tricky job
itself (and has API to kill the subprocess :) -- but it's still
unreleased https://developer.gnome.org/gio/unstable/GSubprocess.html.

Regards,
Colomban
___
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.

[Colomban Wendling]

Le 05/03/2014 19:43, Chris Moller a écrit :
> [...]
> 
> gcc supports nested functions as an extension to standard C.  I tend to
> use them a lot because they operate within the stack frame of the
> enclosing function, thereby minimising the amount of information you
> have to pass.  This is especially valuable in GTK callbacks where you
> can only pass one pointer/int.

Well, yes, but beware: the parent function's stack is not valid if the
parent function exited.  So for asynchronous callbacks, you can only use
it in the function managing the loop (e.g. main).  Otherwise they will
be called after the parent function exited, and so any access you do on
its stack will only lead to a crash in the best case.

In short, they are nested functions, but *not* closures.

Regards,
Colomban
___
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.

[Colomban Wendling]

Le 05/03/2014 18:07, Chris Vine a écrit :
> On Wed, 05 Mar 2014 09:44:48 -0500
> Chris Moller  wrote:
>> I was actually writing that testcase when I found a correlation: I'm 
>> using gcc and my callbacks were nested functions.  Pull the callbacks 
>> out and make them normal, top-level, functions, and it all works even 
>> without no blocking of any kind.  So, if this is a bug at all, I
>> suppose it could be a compiler bug.
> 
> Your question contained references to GTK+'s C interface.  If that
> means that you are using C or C++ for your program, those languages do
> not have a syntax for nested functions, so what you say does not really
> make sense.  […]

GCC does, to some extent, accept nested functions in C as an extension.
 But of course, they are not real closures so even though they have
access to the parent scope, the symbols from there will not be valid
after the parent returned.

http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

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

Re: "Can't link to Pango"

[Colomban Wendling]

Le 13/02/2014 18:37, Bric a écrit :
> [...]
> GEN gtkresources.c
> 
> (glib-compile-resources:6887): GLib-GObject-CRITICAL **:
> /build/buildd/glib2.0-2.24.1/gobject/gtype.c:2706: You forgot to call
> g_type_init()
> 
> [...]

This looks like you managed to link glib-compile-resources to a too old
version of GLib (2.24).  g_type_init() is not needed since 2.36, and I
assume glib-compile-resources is not calling it manually.

Anyway, you need latest GLib to build latest GTK in general, so just try
building everything against latest GLib.

Cheers,
Colomban
___
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

[Colomban Wendling]

Le 07/01/2014 22:48, Jordan H. a écrit :
> 
> Man, sorry, but I guess I'm still not getting this.
> 
> I've added a GtkTreeViewColumn and GtkCellRenderer to the GtkTreeView:
> 
> 
> Button Label
> True
> True
> 
> 
> 
> 

Actually the patch should look like this:

> --- button-actions.glade
> +++ button-actions.glade
> @@ -122,6 +122,17 @@
>  0
>   name="show_expanders">False
>   name="enable_grid_lines">horizontal
> +
> +   id="treeviewcolumn1">
> +Test
> +
> +   id="cellrenderertext1"/>
> +  
> +0
> +  
> +
> +  
> +
>
>  
>


> [...]
> 
> tree_view = GTK_TREE_VIEW( gtk_builder_get_object(builder,
> "treeview_button_order"));
> list_store = GTK_LIST_STORE( gtk_builder_get_object(builder,
> "liststore_button_list"));
> cell_renderer = GTK_CELL_RENDERER_TEXT(gtk_builder_get_object(builder,
> "cr_button"));
> column = GTK_TREE_VIEW_COLUMN(gtk_builder_get_object(builder,
> "tvcol_button"));
> 
> gtk_tree_view_column_pack_start(column,
> GTK_CELL_RENDERER(cell_renderer),
> TRUE);

why do you need to do all this?  Normally you add the column as a child
of the tree view so it works directly, no need to do it manually again.

> gtk_list_store_set(list_store, &iter, 0, last->title, -1);
> gtk_list_store_append(list_store, &iter);

This is wrong, you need to append to the store *before* setting the
values.  "iter" is only a mean of representing a position, nothing
holding your data.  So first, you append(), which sets the iter to the
newly added row, and then you set that row's data using set().

> g_object_set(G_OBJECT(cell_renderer), "text", last->title, NULL);

That's not correct.  The cell renderer object is used to *render* cells,
and only that.  The same will be used to render all rows, so setting the
property like that changes the one use to display all rows.  What you
should do is set up the column to set a particular property of the
renderer to the value of the cell it will render.

https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#gtk-tree-view-column-add-attribute

But if you had followed exactly what I told you, it should have been all
setup, to use the value of your "label" column.

> g_object_set(G_OBJECT(cell_renderer), "sensitive", TRUE, NULL);
> 
>
> gtk_tree_selection_set_mode(gtk_tree_view_get_selection(GTK_TREE_VIEW(tree_view)),
>   GTK_SELECTION_NONE);
> }
> 
> +++
> 
> But I get odd behavior when I add stuff to the list. I know for a fact
> that last->title is being incremented (from "Button 1" to "Button 2",
> etc.). However, when the GtkTreeView is updated I get ["Button 1"] on
> the first click, ["Button 2", "Button 2"] on the second click, etc.

That's because you set the property on the cell renderer directly.  You
shouldn't do that for a property that should display a column's value.
Only do that for a property that should always be the same.

> I've followed the example at
> http://scentric.net/tutorial/sec-treeviewcol-renderer.html. From what I
> can tell GtkCellRenderer controls the entire GtkTreeView (I think the
> article says so, too). So then there doesn't seem to be any way to set
> individual elements.

That's right.  To set individual elements, you bind a column to a cell
renderer through the TreeViewColumn.

> Again, sorry for asking this question. Are GtkTreeViews supposed to be
> difficult or am I just not understanding something?

They are not so simple, because they try to be generic MVC, that's right.

___
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

[Colomban Wendling]

Le 06/01/2014 22:10, jorda...@fastmail.fm a écrit :
> I suppose an attachment would be helpful (weird that it didn't send).

OK, better now indeed.

So, your problem is that you don't add columns to your tree view.  A
TreeView [1] displays TreeViewColumns [2], which itself contain
CellRenderer [3].  Your UI definition lacks the columns and cell
renderers, so it effectively displays nothing, although the data is there.

You need to add a TreeViewColumn child to your TreeView widget, and a
CellRendererText to your column.

In Glade, right click on your tree view, go to the Hierarchy tab, and
click Add.
Now, right click on the column, and choose "Add a child Text" (or
something else, depending on what you want to display).
Finally, you need to define what that renderer displays, so you change
its "Text" property to your label column (change the "unset" dropdown to
"label - gchararray").

Now you should be all set and see your content.  You can of course add
several columns, and cells in each columns.  That will only depend on
your needs.


Regards,
Colomban


[1]
https://developer.gnome.org/gtk3/stable/GtkTreeView.html#GtkTreeView.description
[2]
https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#GtkTreeViewColumn.description
[3]
https://developer.gnome.org/gtk3/stable/GtkCellRenderer.html#GtkCellRenderer.description
___
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

[Colomban Wendling]

Hi,

Le 06/01/2014 17:26, Jordan H. a écrit :
> Attached is the Glade file. The GtkListStore ("liststore_button_list")
> is assigned the GtkTreeView ("treeview_button_order").

Looks like the attachment is missing.

> The GtkTreeView doesn't seem to reflect the changes made to the
> GtkListStore.

No idea if it could be this, but someone recently had a similar issue
because he's TreeView wasn't inside a ScrolledWindow, and GTK3 TreeView
has a resizing bug in this case (so the value where there but the view
was too small to show them).  So, is your TreeView in a ScrolledWindow,
or does it help?

> I iterated through the GtkListStore itself and found that
> values were being added.
> 
> if (gtk_tree_model_get_iter_first(GTK_TREE_MODEL(list_store), &iter)){
> gtk_tree_model_get(GTK_TREE_MODEL(list_store), &iter, 0,
> &test_value, -1);
> g_debug(" - Value: \"%s\"", test_value);
> }else{
> g_warning("GtkTreeModel contains no elements!");
> }
> while (gtk_tree_model_iter_next(GTK_TREE_MODEL(list_store), &iter)){
> memset(test_value, 0, sizeof(gchararray));
> gtk_tree_model_get(GTK_TREE_MODEL(list_store), &iter, 0,
> test_value, -1);
> g_debug(" - Value: \"%s\"", test_value);

Wow, I don't know what you are trying to do here with the memset() and
stuff.  "gchararray" in this context actually means "a C string",
`gchar*`.  Also, gtk_tree_model_get() *duplicates* the data, so you want
to free the memory afterwards.

gchar *str;
gtk_tree_model_get(model, &iter, 0, &str, -1);
// ...
g_free(str);


Not to duplicate code you also probably would rather implement iteration
like this:

if (gtk_tree_model_get_iter_first(...)) {
do {
...
} while (gtk_tree_model_iter_next(...));
}

> I'm wondering if the mutilated strings is what's causing my problem. I'm
> expecting the values to be "Button 1", "Button 2", etc., and the button
> labels reflect this change (as expected).

This may be a reason if the data is actually wrong (I mean, if it's not
your fetching when printing that is), because GtkCellRendererText
requires UTF-8-encoded text.  But if this was the error, you'd see a lot
of warnings in the terminal.

I see 3 possibilities:

1) the tree model is not properly connected to the tree view;

2) you didn't add CellRenderers;

3) your tree view isn't packed in a ScrolledWindow and you experience
the above-mentioned bug.


Hope it helps.  Regards,
Colomban
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkTreeView doesn't refresh

[Colomban Wendling]

Le 27/11/2013 12:57, Jarosław Sobieszek a écrit :
> Hello,
> 
> I'm trying to dynamically modify list based on some action. Program below
> should add 3 rows at the top and 3 rows at the bottom of the list for every
> click of the button. For some reason it doesn't work - I'm seeing partial
> updates with random amount of data (only 2 top rows on first click, then 5
> at the bottom, on 3rd click the list looks ok (9 rows added at the top and
> 9 rows added at the bottom)). I've tested this under gtk2 and it works ok.
> Am I missing something or is it a bug in gtk3 (gtk3-3.8.6 under Fedora 19)?

I'd say it's a bug in tree view sizing in GTK3.

Actually, the list is correctly updated, but the view only request space
for the initial data, and not for the newly added.  And since in your
case you don't pack it in a ScrolledWindow, the view should grow its
size request.

You can see what really happens by making your tree view expand
(gtk_box_pack_start(GTK_BOX(box), tree, TRUE, TRUE, 0) instead of
container_add(box, tree)): you will see that if you resize the window
manually you see the "missing" rows.

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

Re: Signal of a button dynamically created

[Colomban Wendling]

Le 28/10/2013 16:22, Borja Mon Serrano a écrit :
> [...]
> 
> The point here is: how can I know what button was pressed in order to
> remove a row?

When you connect a handler to a signal, there is a "data" parameter,
just pass in some info identifying the row through it:

g_signal_connect(button, "clicked", G_CALLBACK(your_handler),
GUINT_TO_POINTER(row_id))

Alternatively, you can add arbitrary data associated with a widget,
using ::set_data(), so you could pass the row info through this too:

g_object_set_data(button, "row-id", GUINT_TO_POINTER(row_id));

Regards,
Colomban
___
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 label a cairo drawings in gtk+-2.0

[Colomban Wendling]

Hi Mahesh,

Le 04/10/2013 07:41, Mahesh Chaudhari a écrit :
> Hi List,
> I have drawn five circles in GtkDrawingArea as below :
>  
> #include 
> #include 
> #include
> 
> GtkWidget* window;
> GtkWidget* darea;
> static gboolean on_expose_event(GtkWidget *widget, GdkEventExpose *event, 
> gpointer data)
> {
> cairo_t *cr;
> cr = gdk_cairo_create(darea->window);
> cairo_arc(cr,50,60,20,0,2*M_PI);
> cairo_arc(cr,110,60,20,0,2*M_PI);
> cairo_arc(cr,170,60,20,0,2*M_PI);
> cairo_arc(cr,230,60,20,0,2*M_PI);
> cairo_arc(cr,300,60,20,0,2*M_PI);
> cairo_set_source_rgba (cr, 0.5, 0, 0, 0.5);
> cairo_fill(cr);

You need to return a boolean here, see
https://developer.gnome.org/gtk2/stable/GtkWidget.html#GtkWidget-expose-event

You also should destroy the cairo_t you created at the start of the
function using cairo_destroy().

> }
> int main(int argc, char **argv)
> {
> gtk_init(&argc, &argv);
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_window_set_default_size(GTK_WINDOW(window), 400, 100);
> darea = gtk_drawing_area_new();
> gtk_container_add(GTK_CONTAINER(window), darea);
> g_signal_connect(darea, "expose-event",
>   G_CALLBACK(on_expose_event), NULL);
> 
> gtk_widget_show_all(window);
> gtk_main();
> return 0;
> }
>  
> I want to put label(text) above each circle,

Use Pango and its Cairo rendering capabilities:
https://developer.gnome.org/pango/stable/pango-Cairo-Rendering.html

A very basic example could be:

PangoLayout *l = pango_cairo_create_layout (cr);
PangoFontDescription *font = pango_font_description_from_string ("sans
42");
pango_layout_set_text (l, "hello world", -1);
pango_layout_set_font_description (l, font);
pango_font_description_free (font);
pango_layout_set_width (l, width_you_want * PANGO_SCALE);
pango_layout_set_height (l, height_you_want * PANGO_SCALE);
pango_cairo_show_layout (cr, l);
g_object_unref (l);

Check the Pango docs for more details and features
https://developer.gnome.org/pango/stable/index.html

> Also colour should be change after few seconds

Put a timeout (g_timeout_add()) and when it fires change the color and
queue a redraw (gtk_widget_queue_draw()).

> How can I do this ? I have to use CentOS-5.3 which has gtk+-2.10.0 
> ___
> 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+ 2: Hide ComboBox item

[Colomban Wendling]

Le 24/09/2013 10:17, Alessandro Francesconi a écrit :
> Hello, I’m using a GTK+ 2.16 ComboBox and I wondering if there is a
> way to set the visibility of a given element programmatically.
> 
> For example, having a ComboBox with 10 elements I want to hide (so
> more than setting it to inactive) the 3rd element, so I need a
> function like
> 
> gtk_combo_box_set_visible (mycombo, 2, false)
> 
> Does it exist?

Not like this, I'm afraid.  The only way I know to do that is to use a
GtkTreeModelFilter to filter out the elements you want to hide, e.g. by
adding a "visible" column to your model and using
gtk_tree_model_filter_set_visible_column() -- or set_visible_func() with
your function handling the logic whether or not to show a row.

Of course GtkCellRenderer has a "visible" property, but it doesn't
remove the row, it only hides the renderer itself.

Hope it helps.

Regards,
Colomban



/* Little example */

#include 

enum {
  COL_TEXT,
  COL_VISIBLE,
  N_COLS
};

int
main (int argc,
  char  **argv)
{
  GtkWidget*window;
  GtkWidget*combo;
  GtkListStore *store;
  GtkTreeModel *filter;
  GtkCellRenderer  *renderer;

  gtk_init (&argc, &argv);

  /* data */
  store = gtk_list_store_new (N_COLS, G_TYPE_STRING, G_TYPE_BOOLEAN);
  gtk_list_store_insert_with_values (store, NULL, -1,
 COL_TEXT, "First row",
 COL_VISIBLE, TRUE,
 -1);
  gtk_list_store_insert_with_values (store, NULL, -1,
 COL_TEXT, "Second row",
 COL_VISIBLE, FALSE,
 -1);
  gtk_list_store_insert_with_values (store, NULL, -1,
 COL_TEXT, "Third row",
 COL_VISIBLE, TRUE,
 -1);

  /* filter */
  filter = gtk_tree_model_filter_new (GTK_TREE_MODEL (store), NULL);
  gtk_tree_model_filter_set_visible_column (GTK_TREE_MODEL_FILTER (filter),
COL_VISIBLE);

  /* combo */
  combo = gtk_combo_box_new_with_model (filter);
  renderer = gtk_cell_renderer_text_new ();
  gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (combo), renderer, TRUE);
  gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (combo), renderer,
  "text", COL_TEXT,
  NULL);

  /* window */
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL);
  gtk_container_add (GTK_CONTAINER (window), combo);

  gtk_widget_show_all (window);

  gtk_main ();

  return 0;
}
___
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.10 released

[Colomban Wendling]

Le 23/09/2013 21:07, Matthias Clasen a écrit :
> GTK+ 3.10.0 is now available for download at:
> 
> [...]
>  - Support for multiple screens per display has been removed. This
>was only ever supported on X11, and is an exceedingly rare setup
>nowadays. The display-screen relation is now 1:1

That's sad, I was already unpleasantly forced to drop a setup using 2
separate screens that used to work like a charm on gnome 2.x because
gnome-shell couldn't seem to start with it and gnome-panel 3.x was buggy
with it's panel management with such setup, but the user wasn't pleased
to do so -- I didn't chose separate screens by accident.

So I find it sad to hear that now GTK also drops support for it…

Regards,
Colomban
___
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 set link-color on Label

[Colomban Wendling]

Le 27/08/2013 18:52, Ondrej Tuma a écrit :
> Oh, yes, sorry, in GTK 2.

…then you can use gtk_widget_set_name() and use custom RC styles:

label.set_name("mylabel");

...

style "mylabel-style" { ... }
widget "*.mylabel" style "mylabel-style"

checkout the GtkRC docs.

Regards,
Colomban

___
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 set link-color on Label

[Colomban Wendling]

Le 27/08/2013 17:31, Ondrej Tuma a écrit :
> Hi all,
> 
> i want to change link-color on some Label widgets, but only on some.
> 
> I can't find how i can do that. I will use in vala, but never mind, if
> the example will be in python or C ;)

The GTK3 way would be either adding a style provider to you label
widget, roughly like this:

var css = new Gtk.CssProvider();
css.load_from_data("""
GtkLabel {
-GtkWidget-link-color: yellow;
-GtkWidget-visited-link-color: green;
}
""", -1);

/* ... */

var label = new Gtk.Label("""http://gnome.org";>Link""");
label.use_markup = true;
label.get_style_context().add_provider(css,
Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION);


Or adding a style class to your label widget and add a custom provider
for the whole application:

var label = new Gtk.Label("""http://gnome.org";>Link""");
label.use_markup = true;
label.get_style_context().add_class(css, "mylabel");

After having added a global style provider (e.g. with
Gtk.StyleContext.add_provider_for_screen()).



You also always have the dirty-oh-god way that will only affect the base
color, not the :hover or :visited:

var label = new Gtk.Label("""http://gnome.org";>Link""");

But some kittens would probably die if you do this.



Regards,
Colomban

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

Re: Aligning ToolItem To Right in Toolbar

[Colomban Wendling]

Le 27/08/2013 08:07, Joshua Strobl a écrit :
> [...] and set to expand horizontally (set_hexpand(true)).

Tip: you could use the Vala-style property setter, toolbar.hexpand=true

> As my Pastebin (link below) shows, the second
> (exampleGlobalMenuContainer) ToolItem is left aligned, which is
> completely understandable as it hasn't been set to do otherwise.
> 
> LINK: http://pastebin.com/M2nnuynk My question is, how on earth do I 
> set it (the exampleGlobalMenuContainer ToolItem) to horizontally 
> align to the right? I looked into using set_halign to GTK_ALIGN_END 
> and was contemplating using margin-left (although I'd have to have
> an event listener that'd evaluate the window width and change the 
> margin-left otherwise). What would the appropriate method be to
> align the ToolItem?

AFAIK the correct solution is using a separator item set to be invisible
and to expand.  I didn't do Vala for at least a year so excuse the maybe
crappy style, but:

var sep = new Gtk.SeparatorToolItem();
sep.draw = false;
toolbar.add(sep);
toolbar.child_set(sep, expand:true);

This way you have the items after the separator pushed to the right[1]
-- and as a bonus you see a nice separator in the overflowing items menu
if the toolbar has to show it.

https://developer.gnome.org/gtk3/stable/GtkSeparatorToolItem.html#GtkSeparatorToolItem.description
https://developer.gnome.org/gtk3/stable/GtkToolbar.html#GtkToolbar--c-expand


Regards,
Colomban


[1] or to the left if locale is RTL
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Mouse events on a Cairo Context

[Colomban Wendling]

Le 30/06/2013 21:10, Borja Mon Serrano a écrit :
> Hi all,
> 
> [...]
> 
> 1 - I think the best way is to create a signal to the cairomm context, but
> I didn't see anything to do that. Maybe the way would be to create a cairo
> surface or something like that.

I don't think Cairo has this kind of thing.  It's a library for drawing,
not interacting with the drawing.

> 2 - Every time I click to create a circle, I would have to create a gtk
> widget in which I can handle mouse events. The problem here is that I think
> it is impossible to put a widget on a DrawingArea, is it possible?

No you can't.  And no stock widget will give you a circular event area.

> 3 - Use goocanvasmm. The problem here is that goocanvasmm has a little
> documentation  and I think
> this is not the best solution, I prefer to use cairomm.

This is probably the simplest solution, it's meant for this kind of things.

4 - Handle the events yourself:  listen to the
button-press-event/button-release-event of your DrawingArea and do the
math to know whether the click is on your circle or not.  Maybe Cairo
has this kind of thing, like "is that point in that shape", not sure.


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

Re: Invisible GtkImage

[Colomban Wendling]

Le 23/06/2013 00:30, Kip Warner a écrit :
> On Sun, 2013-06-23 at 00:08 +0200, David Nečas wrote:
>> [...]
>> This might not be exactly what you need but as I noted I don't get where
>> the problem is...
> 
> Yes, your code is similar to what I had tried before with GtkImage,
> only you're subclassing the DrawingArea instead which is probably a
> better idea, except it still doesn't work properly either. My code
> draws the image correctly, but it doesn't resize as the parent window is
> resized...
> 
> 

1) you don't need an AspectFrame if the drwaing takes care of not
messing up the ratio.

2) you say it doesn't expand: check your packing flags.  You have:
page.pack_start(page._bannerAspectFrame, False, False, 0)
   the 2 False mean "don't expand and don't fill the available space".
   Change this to True, True and you'll be happy.


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

Re: help with "about" and "help" in gtk-app

[Colomban Wendling]

Le 10/06/2013 17:53, Rudra Banerjee a écrit :
> Dear friends,
> I am writing a code with gtk+3.
> I am facing problems with linking the icons and help files with the
> code.
> 
> [...]
> 
> GtkWidget *window;
> void help_about (GtkMenuItem *helpabout, GtkWidget *window)
> {
>   [...]
>   gchar *hstr=g_strdup_printf("%s/mkbib.svg", PIXMAP);
>g_print("%s",hstr);
>   g_return_if_fail (GTK_IS_WIDGET (window));
>   
>   gtk_show_about_dialog (GTK_IS_WINDOW (window) ? GTK_WINDOW (window) : NULL,
>  [...]
>"logo-icon-name",hstr,
>  [...]
>
> The problem is:
> 1) while the icon is shown in the topbar, as any gnome3 application, in
> "About" window, the icon is missing. but the pathe shown by 
> 
> g_print("%s",hstr);
> does exist.

You set the icon-name property.  This expects an icon *name*, not path,
to be automatically searched in configured the icon directories.

If you want to manually load the icon, you need to set the "logo"
property of type GdkPixbuf, so you need to load it manually.

The other (recommended) solution is to install your application icon in
a standard directory, or add your application's specific icon directory
to the icon search path, and set the "logo-icon-name" property to the
basename of the icon (e.g. without path or extension).

See https://developer.gnome.org/gtk3/stable/checklist-named-icons.html
and more specifically
https://developer.gnome.org/gtk3/stable/GtkIconTheme.html


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

Re: GtkScrolledWindow containing GtkTextView containing a TextBuffer can't keep at bottom of Buffer

[Colomban Wendling]

Hi,

Le 10/06/2013 12:26, Thomas A. Moulton a écrit :
> On 06/09/2013 05:21 PM, Thomas A. Moulton wrote:
>> Ok here is a single file example of my code... it works the same way
>> it does in my larger project
>>
>> Any suggestions would be GREATLY appreciated!
>>
>> tom
>>
> What happens is when you enter enough lines of text to fill the window
> the scrolled window does not scroll up
> when the "eob" mark is not visible (eob=last line of text buffer)

The problem you have is that you insert the TextView in the
ScrolledWindow through a Viewport.  This results in a widget hierarchy
like this:

...
+ GtkScrolledWindow
  + GtkViewport
+ GtkTextView

This means that the TextView doesn't get to control the ScrolledWinodw,
its the Viewport that does.  So when you ask scroll_to_mark() the
ScrolledWindow won't get the request, and so won't scroll.

What you need it NOT to add a Viewport, so you get a hierarchy like this:

...
+ GtkScrolledWindow
  + GtkTextView

Like this, the thing that gets scrolled is the TextView, not a kind of
proxy.  GtkViewport is only useful if you want to add a non-scrollable
widget (e.g. boxes, grids, etc) to a scrolled window: it acts as a proxy
that implements the scrolling.  On the other hand, if the widget you
want to add IS scrollable (implement the GtkScrollable interface), it
must NOT be in a Viewport: if it does, it will expect scrolling requests
and alike, but never get them since its the Viewport that gets them.

In practice, just replace

gtk_scrolled_window_add_with_viewport(scroll, GTK_WIDGET(text));

with

gtk_container_add(GTK_CONTAINER(scroll), GTK_WIDGET(text));

and it will work as you expect.  Not that
gtk_scrolled_window_add_with_viewport() is even deprecated nowadays,
simply adding a child to a ScrolledWindow is enough (it will
automatically add a Viewport for you if required -- which is NOT the
case for GtkTextViews).

Regards,
Colomban


PS:

you do:

char line[512];
const gchar *cmd;

cmd = gtk_entry_get_text(entry);
strcpy(line, cmd);
gtk_entry_set_text(entry, "");

...
gtk_text_buffer_insert_with_tags(buf, ..., line, -1, ...);

Why do you copy the line in a static buffer (that might be too small,
and cause a crash since strcpy() doesn't have a max size parameter)?
You could just put the line into the buffer:


const gchar *line;

line = gtk_entry_get_text(entry);
...
gtk_text_buffer_insert_with_tags(buf, ..., line, -1, ...);
gtk_entry_set_text(entry, "");

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

Re: VTE questions

[Colomban Wendling]

Le 27/05/2013 08:19, Kip Warner a écrit :
> Hey list,
> 
> I have a VTE widget. In order for it to be scrollable, should it be
> nested within a GtkViewport or a GtkScrolledWindow? I couldn't tell from
> its documentation.

The VteTerminal widget implements GtkScrollable, so the answer is
"GtkScrolledWindow".  GtkViewport is only useful to make unscrollable
widgets scrollable, and normally any widget that would be expected to
scroll (text view, tree view, icon view, etc.) should be scrollable, so
a first guess at GtkScrolledWindow would have been fine.  Also, it's
harmless to try it ;)

> Secondly, how do I add a sunken border to the VTE widget? I tried adding
> a GtkFrame as its parent with different styles, but none of them appear
> to be sunken.

GtkScrolledWindow::shadow-type

> 
> Thank you,
> 

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

Re: Updating GUI during long operation

[Colomban Wendling]

Le 26/04/2013 03:59, Kip Warner a écrit :
> On Sat, 2013-04-20 at 18:54 +0200, Colomban Wendling wrote:
>> Just never do something time consuming in the main loop thread.  If you
>> don't there should not be any lag.  
> 
> Hey Colomban. The time consuming task is in its own separate thread, but
> it's making a GIF animation lag and user interface responsiveness as
> well.

That's weird.  However, although I don't know much about Python
threading (and another guy in this thread suggests it's not really
good), I'm wondering whether your thread couldn't be simply locking
stuff used by both GUI and worker thread, effectively blocking the GUI one.

For example, your idle callback _updateGUI() uses the thread's self, so
I guess Python would lock it.  And this would mean that the callback and
the thread functions could not run concurrently.  And even worse, if the
Python thread model is based on simple functions locks (e.g. the lock is
held at the function entrance, and only released on function leaving),
this would mean the callback could never run before the thread as
finished.  I don't know, but this is an idea from where the issue might
come from.

BTW, in VerificationThread.run, which I believe is run in the thread,
right?, there are access to GTK widgets (self._assistant).  This either
requires a lock (which may be the reason why your thread would block the
main one), or it may crash (since GTK is NOT thread safe).  Anyway, I
think this should rather be done in the idle callback.  BTW, you
actually mark the page as complete in both run() and _setQuitOk() which
is called by run().

> [...]
> 
>>> I could have tried this aforementioned event pump from outside the
>>> updateGUI callback and done it from within the worker thread, but I
>>> didn't know if that was thread safe to do.
>>
>> I think the main loop is completely thread safe, event with this, but
>> again *do not do this*.  If the even loop freezes, it's that you do too
>> much work in it's thread, nothing else.  Check what you do in the main
>> thread and that takes time, and try either optimizing it or movie it to
>> another thread.
> 
> I think what I'll have to do is try optimizing the thread to give the
> event pipeline a chance to "breath", but then that still begs the
> question of the best way to do that. I thought of manually flushing the
> event queue, but I don't think you can do that from the worker thread
> and you mentioned it is not a good idea to do even if you could.

I don't think optimizing the worker thread is the solution for the GUI
issue.  If everything worked as it should, the worker thread could take
as much time as it wanted, and it still wouldn't block the main thread.
 That's the point of threads: doing tasks in parallel.  Of course
reducing the time the worker thread takes would reduce the UI freeze
duration, but it wouldn't solve it.

However, if most of your thread's time is lost in IO rather than
computation time (e.g. if the MD5 runs faster than the IO), you could
perhaps avoid a thread using asynchronous IO calls and computing the sum
by packets.  Something like this (in Vala pseudo-code):

async string sum(File file) {
var sum = new MD5();
while (true) {
/* read by blocks of 2048 bytes (or whatever) */
var data = yield file.read_async(2048);
if (data) {
sum.push(data);
} else {
break;
}
}
return sum.hash();
}

Here yield would work like in Vala, which basically means calling a
implicit callback which will perform the following instructions when the
asynchronous work is done.

But this doesn't explain why your program blocks the main thread, and
may very well not be practical in your case (or even, on Python, I don't
know).


Hope this could help in some way.  Regards,
Colomban

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

Re: regarding IconView use

[Colomban Wendling]

Hi,

Le 23/04/2013 15:01, Tristan Van Berkom a écrit :
> It's not the expected behaviour.
> 
> GtkIconView lays out it's icons based on the available/allocated width,
> unless the "columns" property is explicitly set, it always has.
> 
> It's possible that there was a bug earlier on in 3.x (3.2 ? 3.4 ?), but
> if you see ./tests/testiconview you will find icons that layout properly
> (and I'm sure GtkIconView was working properly in 3.0.0, since I made
> sure of that).

There is indeed an issue on (Debian's) 3.4.2.  gtk2-demo (2.24.10)
reflows just fine, but gtk3-demo don't.

Though on a somewhat unrelated topic, while trying (in gtk-demo, GTK
2.24) to resize the icon demo toplevel back and forth to see it
reflowing properly, I made if freeze.  Apparently it's quite easy to
make it enter some kind of infinite loop by just resizing the toplevel
quite rapidly, and that's a bug I guess :)  No idea where it comes from
though, the backtrace shows some signal emission, some icon view layout
and alike.  It looks something like if the layout code went into a state
where it can't succeed or something, and always tries to recompute
something.  Not quite sure though.

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

Re: Updating GUI during long operation

[Colomban Wendling]

Hi,

Le 20/04/2013 18:10, Kip Warner a écrit :
> Hey list,
> 
> I have a separate thread from the main loop that performs some long and
> resource intensive operation. The GUI displays an animated GIF while
> this process takes place via Gdk.PixbufAnimation. 
> 
> Sometimes the animation and the rest of the GUI is very slow to repaint
> and respond to other event messages. What is the best way of giving the
> message pipeline a breather every now and then from outside of the main
> thread?

Just never do something time consuming in the main loop thread.  If you
don't there should not be any lag.  And to communicate with the main
loop from another thread, the common technique is to add an idle handler
(that runs only once).  The GLib main loop is thread safe so you can
simply call g_idle_add() from the worker thread.

> I was using GObject.idle_add(self._updateGUI, ...) within the worker
> thread to specify a function to be called regularly that could provide
> some other GUI related update tasks, including the following within
> it...
> 
> # Pump the Gtk+ event handler...
> while Gtk.events_pending():
> Gtk.main_iteration()

That's a bad idea.  Forcing flush of pending events never is a real
solution, since at most it will perform everything that was queued, but
certainly not what will come.  And as you see yourself, it doesn't work
that well anyway.

> However, my application will crash if I do this with a stack overflow
> within updateGUI. I'm assuming that since idle_add posted the message to
> call the updateGUI callback, when the callback is invoked and tries to
> pump the message pipeline, the method is invoked again because it still
> hasn't cleared itself from the queue.

That's weird, but yeah, since main_iteration() tells the main loop to
perform an iteration and you do this from an idle event I could imagine
your idle event calls itself recursively.  Again, just never use this
"workaround" method of forcing main loop iterations.

> I could have tried this aforementioned event pump from outside the
> updateGUI callback and done it from within the worker thread, but I
> didn't know if that was thread safe to do.

I think the main loop is completely thread safe, event with this, but
again *do not do this*.  If the even loop freezes, it's that you do too
much work in it's thread, nothing else.  Check what you do in the main
thread and that takes time, and try either optimizing it or movie it to
another thread.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Confused about GDKPixBuf/Cairo interaction

[Colomban Wendling]

Le 19/02/2013 01:45, Rena a écrit :
> On Mon, Feb 18, 2013 at 9:24 AM, Colomban Wendling
> [...]
> 
> Well, my emulator gets the pixel data from gdk_pixbuf_get_pixels() and
> writes into that buffer directly; that way it doesn't have to know
> anything about GDK and can draw pixels by just writing directly into
> memory, which saves a lot of overhead when it's rendering roughly 1.5
> million pixels per second.
> The emulator also supports Lua extensions which give scripts an object
> wrapping the pixbuf and lets them draw on it.

OK I see.

> If I use Cairo to draw shapes in the ::draw handler, that means I'd be
> painting the pixbuf to the GtkDrawingArea's surface, then drawing
> those shapes onto it? So the actual pixbuf contents wouldn't be
> modified.

Yes.

> That could lead to complications if a script wants to e.g.
> produce a screenshot or read pixels back from the pixbuf, as it
> wouldn't see anything it had drawn itself.

Indeed, nothing would be on the pixbuf but the original image.

> I guess at best I'd need to
> keep a separate surface around for scripts to draw on, and paint both
> of those onto the GtkDrawingArea.

I guess that's 1 of 4 possibilities:

*) use Cairo directly, e.g. instead of creating a buffer compatible with
GdkPicbuf (or actually the GdkPixbuf buffer), create your own buffer
that uses a Cairo-compatible format and just write to that.  Then, you'd
just have to create a CairoImageSurface for that buffer and could
happily write to your buffer with Cairo.  That's probably the faster
solution.
Note that apparently Cairo don't have any 3-bytes format, even RGB24 has
a 4th unused byte.

*) convert (manually) data back and forth to and from Cairo (Edscott
Wilson pointed you a code doing this).  This has the overhead of 2
conversions each time you want to draw on the pixbuf (not counting the
conversion performed by GDK in the ::draw handler).

*) implement a Cairo surface that can draw directly to the pixbuf (e.g.
that does whatever conversion when performing drawings).  I don't know
how to do that but I guess it's feasible since Cairo already provides
various kinds of surfaces (and have a GObject layer).

*) handle 2 layers, the pixbuf and what's drawn on.  It may show som use
case (e.g. one could take a shot with or without additions) but probably
only makes things more complex.

> Mainly I'm just confused at how GDK is using Cairo to do its painting,
> but they use two different pixel formats.

I'm not 100% sure, but I guess they use the specific Cairo surfaces for
their targets (e.g. XLib surfaces on X11, Win32 surfaces on Win32 and
Quartz surfaces on OSX).  And when drawing pixbuf, they convert it
(using gdk_cairo_set_source_pixbuf()).
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Confused about GDKPixBuf/Cairo interaction

[Colomban Wendling]

Le 18/02/2013 14:50, Rena a écrit :
> On Mon, Feb 18, 2013 at 8:35 AM, Colomban Wendling
>  wrote:
>> Hi,
>>
>> Le 18/02/2013 11:10, Rena a écrit :
>>> Hi, just joined the mailing list, been using GTK and related projects
>>> for a while now. Recently I've been developing a Game Boy emulator
>>> that uses GtkDrawingArea and GdkPixbuf to display the game screen.
>>>
>>> In addition to the game output I want to also be able to draw text and
>>> shapes on the display window, and Cairo seems to be the ideal way to
>>> draw shapes. I'm already using Cairo to copy the Pixbuf to the
>>> GtkDrawingArea, so that seems like a good sign that Cairo and
>>> GdkPixbuf should interact nicely.
>>>
>>> [...]
>>
>> I don't really get it.  You say you already use Cairo to draw your
>> pixbuf, but also that you can't see how to use a GdkPixbuf with Cairo?
>> This seems contradictory to me.
>>
>> Anyway, what you want is gdk_cairo_set_source_pixbuf()[1] that does the
>> appropriate conversions to create a Cairo pattern from a GdkPixbuf.
>> Then you can use this pattern like any other Cairo pattern (e.g.
>> cairo_paint()), and you're done.
> 
> Well, in the GtkDrawingArea::draw signal, I receive a cairo_t* that
> Gdk has created for me, and draw my pixbuf to it:
> 
> gboolean draw_callback(GtkWidget *widget, cairo_t *cairo) {
> gdk_cairo_set_source_pixbuf(cairo, pixbuf, 0, 0);
> cairo_paint(cairo);
> }
> 
> but if I want to draw a shape on the pixbuf, I would need to create a
> cairo_t* of my own for that purpose, and I don't see how to create one
> that's compatible with the pixel format GdkPixbuf uses. i.e. I want
> the destination to be my pixbuf, not the source.

First, you could very well draw directly on the Cairo context straight
in the ::draw handler, give then you don't need caching for decent
performances.  E.g., just continue drawing stuff in the ::draw handler
after you painted the pixbuf.

But if you want to draw everything on your own surface and then paint
that surface in the ::draw handler, just create a surface with whatever
format you need, gdk_cairo_set_source_pixbuf() should be able to do the
conversion.

The other solution is to use cairo_surface_create_similar(), but this
requires a surface to be similar to -- but there is no much reason for
that other surface to have a format better suitable to your pixbuf.  The
Cairo context passed to the ::draw handler is appropriate to draw on the
screen, not particularly to draw your pixbuf.


But you can very well do this:

def prepare_suraface(pix):
  # use whatever format you need, e.g. ARGB32 or RGB24
  surface = Cairo.Surface(cairo.Format.ARGB32, pix.width, pix.height)
  cr = Cairo.Context(surface)
  Gdk.cairo_set_source_pixbuf(cr, pix, 0, 0)
  cr.pain()

  # and continue drawing stuff
  cr.move_to(0, 0)
  cr.line_to(pix.width, pix.height)
  cr.stroke()

  return surface

and then your simply paint the created surface in your ::draw handler.
Of course, doing this is only useful if you need caching the drawn
surface, otherwise it'd be faster do directly perform the draws on the
::draw handler.


Or maybe I got you wrong and you'd like to *draw* on your GdkPixbuf?
I'm afraid this just isn't possible directly.  If you really want to do
that, you'll probably have to manually do some pixel conversion.  You
can create a Cairo surface of the pixbuf's size, draw on that, and then
get the surface's pixels which you'd convert manually to the pixbuf
format, and push those pixels to the pixbuf.  But again, why would you
need to draw specifically on a GdkPixbuf?

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

Re: Confused about GDKPixBuf/Cairo interaction

[Colomban Wendling]

Hi,

Le 18/02/2013 11:10, Rena a écrit :
> Hi, just joined the mailing list, been using GTK and related projects
> for a while now. Recently I've been developing a Game Boy emulator
> that uses GtkDrawingArea and GdkPixbuf to display the game screen.
> 
> In addition to the game output I want to also be able to draw text and
> shapes on the display window, and Cairo seems to be the ideal way to
> draw shapes. I'm already using Cairo to copy the Pixbuf to the
> GtkDrawingArea, so that seems like a good sign that Cairo and
> GdkPixbuf should interact nicely.
> 
> However, it doesn't look like they should be able to interact at all,
> as they don't seem to be able to agree on a pixel format:
> http://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-data
> "Currently only RGB images with 8 bits per sample are supported."
> http://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#image-data
> "p[0] = red; p[1] = green; p[2] = blue; p[3] = alpha;"
> That seems to suggest that GdkPixbuf supports only RGB (24-bit) and
> RGBA (32-bit). But...
> 
> http://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t
> CAIRO_FORMAT_ARGB32 is ARGB ("each pixel is a 32-bit quantity, with
> alpha in the upper 8 bits..."). CAIRO_FORMAT_RGB24 is xRGB ("each
> pixel is a 32-bit quantity, with the upper 8 bits unused..."). Neither
> of those are RGB or RGBA. So, how can Cairo operate on a surface
> provided by GdkPixbuf?

I don't really get it.  You say you already use Cairo to draw your
pixbuf, but also that you can't see how to use a GdkPixbuf with Cairo?
This seems contradictory to me.

Anyway, what you want is gdk_cairo_set_source_pixbuf()[1] that does the
appropriate conversions to create a Cairo pattern from a GdkPixbuf.
Then you can use this pattern like any other Cairo pattern (e.g.
cairo_paint()), and you're done.

Hope it helps.
Colomban

[1]
http://developer.gnome.org/gdk/stable/gdk-Cairo-Interaction.html#gdk-cairo-set-source-pixbuf
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: open an existing file in buffer and write on it

[Colomban Wendling]

Le 25/01/2013 17:02, Damien Caliste a écrit :
> [...]
> 
> The idea when you want to change a file on disk is (not too big) :
> - generate a buffer of the full content of the file in memory, using
>   GString for instance
>   (http://developer.gnome.org/glib/unstable/glib-Strings.html) since
>   they are automatically expending in size but can be used with
>   equivalent printf() convenient functions ;

Not exactly in this case I think.  If the file represents structured
data, as OP's file seem to do, what you wanna do is read the file into a
data structure representing that content, e.g. a list of something like:

struct LibraryEntry {
gchar *author;
gchar *editor;
gchar *title;
/* whatever */
};

And when writing, serialize that data back to the file's format.  This
makes it easy to manipulate the data in your program, because a buffer
is nothing like easy to deal with.

Regards,
Colomban

> - copy atomicaly the buffer in the file with g-file-set-contents()
>   
> http://developer.gnome.org/glib/unstable/glib-File-Utilities.html#g-file-set-contents
> - delete the buffer.
> 
> Damien.

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

Re: Gtk.RecentManager doesn't flush updates

[Colomban Wendling]

Le 21/12/2012 16:02, Kerrick Staley a écrit :
> Hello,
> 
> I'm trying to modify the recent files list from a Vala program. I construct
> a Gtk.RecentManager and call its remove_item() and add_full() methods, but
> neither has any effect; the recent files list is unchanged (and
> ~/.local/share/recently-used.xbel is unmodified). I notice in strace that
> it opens ~.local/share/recently-used.xbel as read-only:
> open("/home/kerrick/.local/share/recently-used.xbel", O_RDONLY) = 8
> meaning it can't possibly modify the file. What am I doing wrong?
> 
> My code follows:
> using Gtk;
> 
> void main(string[] args)
> {
> var rm = RecentManager.get_default();
> 
> string uri = "file://" + Environment.get_current_dir();
> Gtk.RecentData data = Gtk.RecentData();
> data.mime_type = "inode/directory";
> data.app_name = "gnome-terminal";
> data.app_exec = "gnome-terminal";
> rm.add_full(uri, data);
> }

GTK3 delays recent list writing for performance reason, so I guess the
behavior you see is not that surprising.

2 points here I guess:

1) question: is GtkRecentManager supposed to work without a main loop?
It probably would be convenient, and useful if GIO/GLib doesn't provide
the feature.

2) GtkRecentManager should make sure to flush any remaining updates when
quitting time, so none gets lost.

Regards,
Colomban

> 
> Thanks,
> Kerrick
> ___
> 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: Why doesn't my label show up in the window

[Colomban Wendling]

Le 27/08/2012 11:05, Colomban Wendling a écrit :
> Le 27/08/2012 00:20, Frank Cox a écrit :
>> On Sun, 26 Aug 2012 22:49:26 +0200
>> Colomban Wendling wrote:
>>
>>> For example, I attached a dummy program that replicates yours but using
>>> threading.  
>>
>> Thanks loads for all of the information!  Unfortunately, the dummy program 
>> that
>> you attached wasn't actually attached.  I'd love to see it, though, so I can
>> get a direct look at what I've been doing wrong here.
> 
> Woops, here it is.

...or not.  Looks like I didn't forgot it even the first time but the ML
is eating it.  OK, here you go: https://gist.github.com/3486813
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Why doesn't my label show up in the window

[Colomban Wendling]

Le 27/08/2012 00:20, Frank Cox a écrit :
> On Sun, 26 Aug 2012 22:49:26 +0200
> Colomban Wendling wrote:
> 
>> For example, I attached a dummy program that replicates yours but using
>> threading.  
> 
> Thanks loads for all of the information!  Unfortunately, the dummy program 
> that
> you attached wasn't actually attached.  I'd love to see it, though, so I can
> get a direct look at what I've been doing wrong here.

Woops, here it is.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Why doesn't my label show up in the window

[Colomban Wendling]

Hi,

I haven't read the linked program, but based on the dummy program and
the previous discussion:

Le 26/08/2012 19:13, Frank Cox a écrit :
> On Sun, 26 Aug 2012 17:36:01 +0700
> Ardhan Madras wrote:
> 
> [...]
> 
> The objective of the program is to maintain an email mailing list for my
> theatre.   I have a webpage here
> http://www.melvilletheatre.com/mailinglist.html where interested people can
> sign up to receive an email from me every time I have a new movie booked.  I
> wrote a program a few years ago using ncurses to manage the mailing list and
> send out the email and now that I want to learn to use GTK I decided to 
> rewrite
> that mailing list program as a learning project.

A GUI program should never block the GUI thread.  Blocking the GUI
thread has many kind of unwanted implications, all resulting of the GUI
unresponsiveness.  It's even worse than with a "CLI GUI" like ncurse,
because generally in "real" GUI, the GUI is responsible of drawing
itself and may need to do that at *any given time* -- e.g. after its
window have been brought back from behind another window.  If the GUI
doesn't refresh at this point, the user sees a blank window [1].

Anyway, what to remember is "never block GUI thread".  If you need to do
something that take a noticeable amount of time (e.g. > ~100ms), don't
do that in the GUI thread, or split it in steps taking less than 100ms.

The first solution is to split the long work into smaller steps and ask
the main loop to run these steps in idle time (see g_idle_add() and
friends).  This works if you can split your greedy work into small
pieces, but not all kind of work splits well like that, and it still
blocks for Xms (but in-between, all events are handled normally since we
use the main loop dispatcher).

The second solution is to use a separate thread to do the work.  This
may look simpler since you don't have to split up the algorithm, but
beware threading.  It's probably the right solution if you have a
complex algorithm or no control over what takes a long time to proceed,
but if you do anything wrong with threading, your program will blow up
faster than an A bomb.  Note that GTK *is NOT thread-safe!*  This
basically means you MUST NOT, EVER, call any GTK function from another
thread than the one which called gtk_main() (normally the application's
main thread).  To update the GUI from the worker thread you'll need to
"message" the GUI thread in some way.  Fortunately, there are some
facilities to do that.


For example, I attached a dummy program that replicates yours but using
threading.  I replaced the label with a dummy progress bar just to be a
little more realistic (although the progress bar isn't really
controlled), but you can very well put whatever widget you want here.  A
few details:

The main() is the same as yours.

The button_clicked_handler() is the callback called when the button is
clicked (like your subroutine()).  What it does it creating the second
window, then launching a second thread (worker()) to perform the
time-consuming operation.

update_progress_in_timeout() is registered as a timeout function (a
function called every Xms by the main loop) to update the progress bar
every 100ms.  This is totally dummy and don't reflect a progress (it
pulsates actually), but it shows clearly that the UI thread is responsive.

The worker() function is, as said above, launched in a separate thread.
 It first does the time-consuming operation (here a simple g_usleep()
like your sleep() to wait 5 seconds), and then registers an idle
function (a function called by the main loop whenever it has nothing
more important to do) which will update the UI
(worker_finish_in_idle()).  This is an useful trick: functions called by
the main loop (like idle or timeout functions) are, obviously, launched
in the main loop thread (the gtk_main() one then) -- and, as said above,
GTK calls MUST be done from the main loop thread.  Fortunately, the
GLib/GTK main loop is thread-safe, and so you can call
g_idle_add()/g_timeout_add() and friends from any thread, using those to
"message" the main thread (actually call a function on it).

Finally worker_finish_in_idle() stops the progress bar updates and
destroys the window.

You can also see I used a structure, WorkerData, to pass data to the
worker thread and the further.  This is needed because I wanted to pass
more than a pointer to my various functions and they only expect one
pointer argument, and so it allows me to pass as much data as I want.
If you only need one pointer, you don't need it, but you'll probably
actually need a lot more stuff than what I passed myself.  But beware
here too: don't access the data in that structure from different threads
at the same time, prefer deal with a copy when possible (or use locks,
though locks are complex and somewhat evil if they can be avoided).

Of course, if for any reason you access any data simultaneously from
worker() and an idle or timeout function, you must be aware of the
s

Re: no joy...

[Colomban Wendling]

Le 20/12/2011 23:52, Gary Kline a écrit :
> 
> thanks to those  who have tried to help, mostly off-list.  i can't
> believe how hard this is.
> 
> i want to open a  base  window:
> 
> gtk_window_set_title(GTK_WINDOW(window),"testing");
> gtk_widget_set_usize(GTK_WIDGET(window),200,300);
> 
>   ...
> 
> and then only a text window --upon button press-- and display
> some text:
> 
> 
> text = gtk_text_view_new();
> gtk_container_add(GTK_CONTAINER(window),text);
> buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(text));
> "
> and fopen some file and display the text in the buffer.  The   
> question remains: how? what am i missing to display some
> miscellaneous words in the text window?

You have the buffer, now the only needed thing is to load the data (I
assume you know how to do, right?) and add it to that buffer.  There is
some docs [1], but basically you want one of

gtk_text_buffer_set_text()
gtk_text_buffer_insert()
gtk_text_buffer_insert_at_cursor()

Also, don't forget you have to show your widgets (gtk_widget_show()).


Cheers,
Colomban

[1] http://developer.gnome.org/gtk/stable/GtkTextBuffer.html


> 
> thanks in a advance.
> 
> gary
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

Re: GTK+ TreeView: Different CellRenderers on the same Column

[Colomban Wendling]

Le 17/10/2011 13:53, Stefan Salewski a écrit :
> I am working on a configuration file editor for an graphical
> application. Configuration consists of strings, numbers and boolean
> values. About 25 values total.
> 
> I can use individual widgets for each property, but for larger
> quantities a listview is a more compact form.
> 
> It would we nice to have textentry fields for strings, spin buttons for
> numbers and check boxes for boolean values, all in one column of the
> tree view.
> 
> Of course I can pop up dialog windows whenever the user clicks on an row
> of the treeview, but that is not a nice solution when the user wants to
> change more than one value.
> 
> With Google, I found some people asking for this, but only one
> complicated solution:
> 
> http://kapo-cpp.blogspot.com/2008/05/different-cellrenderers-on-same-column.html
> 
> I think it is too complicated for me now, not being an GTK expert. (And
> I am using the Ruby GTK bindings, which may make it difficult to use the
> above solution.)
> 
> Is there a better solution or even an example available?

Not sure it's better (actually I just took a small glance at the link),
but there are other solutions.

First, the one used by gconf-editor [1], that consist of a custom cell
renderer that provides the appropriate editable depending on the type of
the value it holds.  This is not necessarily the easier way, but it's
quite interesting IMHO.

The other solution I know is to pack all CellRenderer that might be used
for editing, and only make one visible/sensitive, depending on the row's
value type.  This is what we current use in the implementation of
Geany's stash editor [2], [3].


IMHO the second solution is the easier one, nut sure it's the bast
though.  Hope it helps.

Regards,
Colomban


[1] http://git.gnome.org/browse/gconf-editor/tree/src/gconf-cell-renderer.c
[2] https://github.com/geany/geany/blob/master/src/stash.c#L910
[3] https://github.com/geany/geany/blob/master/src/stash.c#L1051
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GList empty after iteration?

[Colomban Wendling]

Le 12/09/2011 21:10, Craig a écrit :
> Hi All,
> 
> I am confused about GList. My application is parsing a file and creating
> midi data with it. I am using GList to store the midi data.  I have
> created a GtkListStore to view the parsed data (to insure I am parsing
> the data properly).  So, below I iterate through the GList and "copy"
> the data into a tree view.  But, I am shocked to see that after I
> iterate through the GList, I cannot iterate through the list again.  I
> have debugged the list after the iteration with g_list_length(events)
> which shows the list length at 0.  What is up with this?  The first
> while loop has data, the second while loop has not data. The code is
> below-->
> 
>   GtkTreeIter tree_iter;
>   events = g_list_reverse(events);
>   events = g_list_first(events);
>   while(events)
>   {
>   gtk_list_store_append (list_store, &tree_iter);
>   struct midi_event *me = events->data;
>   gtk_list_store_set(list_store, &tree_iter,
>  0, me->time_stamp,
>  1, me->event_type,
>  2, me->message1,
>  3, me->message2,
> -1);
>   events = g_list_next(events);   

You do this until events stop matching the loop's condition "(events)",
so until it becomes NULL (e.g. there are no more next).  So when you use
events below, it's NULL, and NULL is a valid empty list.

Better user a temporary iter like

GList *iter;

for (iter = list; iter; iter = iter->next) {
/* here use iter->data */
}

Cheers,
Colomban

>   }
>   /// this is where the list appears to be empty
>   events = g_list_first(events);
>   while(events)
>   {
>   g_print("midi event \n");
>   events = g_list_next(events);   
>   }
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cell rendering issue

[Colomban Wendling]

Hi,

Le 20/06/2011 19:45, Thomas Bollmeier a écrit :
> Hi GTK-experts,
> 
> currently I work on a small location finder application
> (http://www.bolles-werk.org/software-projects/quoloco.html). Basically
> the application shall allow users to search for arbitrary keywords. The
> results are displayed both in a map (a champlain view) and in a tree
> view (GtkTreeView).
> For the latter one I have to solve a problem: The tree shall consist of
> "search nodes" on the top level and "location nodes" as their children.
> Both node types have different data associated to them. The search node
> has to display the keywords of the search whereas the location nodes
> shall display a checkbox (to toggle their visibility in the map) as well
> as latitude and longitude. So the tree view has  four columns ("key
> words", "visible", "latitude", "longitude") in total. For search nodes
> the last three columns shall be empty, for location nodes the first column.
> Is it somehow possible to implement that? In the documentation I only
> find ways (using the cell data function) to have control over the
> properties of the column's renderers. However I actually would like to
> be able to set the renderer per cell (depending on the node type)
> instead of per column. Of course there would be the alternative to
> implement my own custom renderer - but at the moment I would like to
> avoid this effort. Any ideas?

The simpler solution I can think of is to set the visibility of the cell
renderer in the cell_data_func(), depending on whether the row should
display it or not.

So, for your toplevel rows keyword would be set to be visible and all
three other to be hidden, and the inverse for children rows.

That's the only other solution I know of apart writing your own "proxy"
cell renderer (note that for example gconf-editor does so, so if your
application has a compatible license you could borrow its code as a
basis). Of course perhaps there's other ways I don't know of, I'm not a
GTK god ^^

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

Re: GSource object lifetime

[Colomban Wendling]

Le 03/05/2011 20:49, Thomas Stover a écrit :
> trying to stop a memory leak (2.24.1 x86_64)... 
> 
> I'm repetitively calling g_idle_source_new(), g_source_set_callback(),
> g_source_attach() to get an idle callback to run in a separate thread. The
> callback in question always exits with FALSE. 

Don't forget to unref your source after you attached to the context,
because g_source_attach() increases the reference count of the source.

Basically you need to:

s = g_idle_source_new();
g_source_set_callback(s, func, data, notify);
g_source_attach(s, ctx);
g_source_unref(s);

Unless you need to keep a reference to the source for some other reason
of course.

The docs are a bit lacking info on the matter, but the code can tell you
(e.g. the source of g_idle_add(), which actually almost does this with
NULL as the context).

> The docs for GSourceFunc() state:
> ...
> Returns :
>   it should return FALSE if the source should be removed.
> ...
> 
> 
> Does "removed" mean "frees up the idle source", or just "undoes the
> g_source_attach()"? 

AFAIK it means "remove from the context and unref it", so if it was the
last reference to that source it'd be freed, yes.

> Should I be trying to reuse the idle source? I was destroying and
> recreating a time out source, but finally gave that up and just let it tick
> all the time. That stopped a leak in another program so that's why I was
> wondering...

I don't think you need to take care of re-using the same source again,
it'd probably be only painful for you and I doubt it has any real benefit.

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

Re: multiple tree views

[Colomban Wendling]

Hi,

Le 01/05/2011 15:03, Pavol Klačanský a écrit :
> Hi, I need in my about 5 and more treeviews. I created one using glade,
> but I don't know how can I use it multiple times, gtk says something
> like this
> 
>> (client:25913): Gtk-WARNING **: Attempting to add a widget with type
>> GtkTreeView to a container of type GtkHBox, but the widget is already
>> inside a container of type GtkHBox, the GTK+ FAQ at
>>  http://library.gnome.org/devel/gtk-faq/stable/ explains how to reparent 
>> a widget.

You cannot pack a widget at more that one place at a time, you'll need
to create 5 tree views.
Though, if you want to display the same content in more than one tree
view, you can share the TreeModel IIRC.

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

Re: GOption & friends

[Colomban Wendling]

Le 21/03/2011 17:03, John Coppens a écrit :
> On Mon, 21 Mar 2011 15:42:17 +0100
> Colomban Wendling  wrote:
> 
>>> The form (-de), frequently used, fails though it is advertised
>>> in the Command line parser description:
>>>
>>> http://library.gnome.org/devel/glib/unstable/glib-Commandline-option-parser.html#g-option-context-add-main-entries
>>>
>>> {"debug", 'd', 0, G_OPTION_ARG_STRING, &dbg, "Debug options", "opts"},
>>> why?
>>
>> This is NOT meant to work as you seem to expect, and the docs tells you:
>> "-de" is the same as "-d -e", not "-d e".
>> This is a very common thing, and most commands works this way (apart
>> perhaps cut).
> 
> Ok... But if I put d: in getopt's arg list, I do expect an argument,
> and -de is parsed as -d e. Why doesn't GOptionEntry, with a specified
> G_OPTION_ARG_STRING do the same?

Don't know why, I'm no GLib developer nor never worried about it. But
how getopt handle arguments "d:e" if you give it "-de"? Does this mean
"-d -e" or "-d e"?
I'd think that GOption behavior is at least easier to understand.

>>> 3) The reason I wanted to migrate to GOption, is that it seems
>>> gnome_program_init doesn't eliminate the recognized default arguments
>>> such as --g-fatal-warnings, if added. So, in gdb, a run
>>> --g-fatal-warnings produces an error in getopt. 
>>
>> AFAIR, --g-fatal-warnings is NOT a standard option. You're expected to
>> use the environment variable G_DEBUG:
>> G_DEBUG=fatal-warnings gdb yourapp
>>
>> See http://library.gnome.org/devel/glib/unstable/glib-running.html
> 
> http://library.gnome.org/devel/gtk/2.21/gtk-running.html
> 
> Or doesn't GNOME pass those arguments to GTK?
> 
> (BTW, gimp accepts --g-fatal-warnings)

Use gtk_get_option_group(), see
http://library.gnome.org/devel/gtk/2.21/gtk-General.html#gtk-get-option-group
and
http://library.gnome.org/devel/glib/unstable/glib-Commandline-option-parser.html#glib-Commandline-option-parser.description

>>> I've looked through numerous pages - can anyone point to an app that
>>> actually uses GOption for more than a minimal options set?
>>
>> Most GNOME programs, and let's guess: GIMP ;)
> 
> Strange that gimp didn't jump out with a google search. Isn't the code
> visible on the net?

Of course: http://git.gnome.org/browse/gimp/tree/

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

Re: GOption & friends

[Colomban Wendling]

Le 21/03/2011 15:26, John Coppens a écrit :
> Hello people,

Hi you,

> I've been trying to get GOption and friends working - but it seems
> we're not on friendly terms.
> 
> 1) I defined a GOptionEntry as:
> 
> {"debug", 'd', 0, G_OPTION_ARG_STRING, &dbg, "Debug options", "opts"},
> 
> and find that
>   -d e   works
>   --debug e
>   --debug=e  work correctly
> 
>   -degives "option parsing failed: Missing argument for -d"
> 
> The form (-de), frequently used, fails though it is advertised
> in the Command line parser description:
> 
> http://library.gnome.org/devel/glib/unstable/glib-Commandline-option-parser.html#g-option-context-add-main-entries
> 
> why?

This is NOT meant to work as you seem to expect, and the docs tells you:
"-de" is the same as "-d -e", not "-d e".
This is a very common thing, and most commands works this way (apart
perhaps cut).

> 2) The above entry should have a list of the actual debug options,
> but I haven't found a practical way to add them to the help text.
> I'd like to add options like:
> 
>   p: debug printing
>   l: debug logging
> 
> Actually, I've extended the "Debug options" string with \n's and
> looong string, but there should be a more practical way... is there?

No idea, sorry.

> 3) The reason I wanted to migrate to GOption, is that it seems
> gnome_program_init doesn't eliminate the recognized default arguments
> such as --g-fatal-warnings, if added. So, in gdb, a run
> --g-fatal-warnings produces an error in getopt. 

AFAIR, --g-fatal-warnings is NOT a standard option. You're expected to
use the environment variable G_DEBUG:
G_DEBUG=fatal-warnings gdb yourapp

See http://library.gnome.org/devel/glib/unstable/glib-running.html

> I've looked through numerous pages - can anyone point to an app that
> actually uses GOption for more than a minimal options set?

Most GNOME programs, and let's guess: GIMP ;)

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

Re: GtkSwitch — lack of specific signal

[Colomban Wendling]

Le 05/03/2011 16:36, Tadej Borovšak a écrit :
> Hello.
> 
>> I checked.   notify::active is not mentioned anywhere in any of those! 
>> (I used my browser's find  -  can you find it mentioned somewhere?)
>> Cheers,   John Lumby   
> 
> Those two links were just examples that demonstrate how signal handler's
> prototype can be obtained. Notify signal is part of GObject.
> 
> When searching for a signals that are relevant to particula widget, you
> start by examining signals listed in widget's API docs, after those
> signals you inspect signals of it's parent, ... (API docs for each
> widget have a section named "Object Hierarchy" that lists relationships
> of objects).
And the syntax of signals is "signal-name::detail" [1], with the
"::detail" part being optional (and rarely used, the only common use is
with GObjet's notify signal [2]).


Cheers,
Colomban

[1] http://library.gnome.org/devel/gobject/stable/signal.html#signal-detail
[2]
http://library.gnome.org/devel/gobject/stable/gobject-The-Base-Object-Type.html#GObject-notify
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkSwitch — lack of specific signal

[Colomban Wendling]

Le 05/03/2011 03:17, John Lumby a écrit :
> 
> A! Thank you Tadej.No,   mine had only two parameters,  the obj 
> ptr and the data ptr.I added the paramspec in between and now all works 
> perfectly.
> By the way  -  this seems a bit unpleasant,  that some callbacks have a 
> prototype of (objptr, dataptr) and others have (objptr,  paramspec, 
> dataptr).How would I know which one to use? Is it that some are in the 
> gtk layer (2 params) but other like notify::active are in the gdk layer (3 
> params)?And I kind of feel something should have alerted me although I don't 
> know what  -  I guess the compiler doesn't know.
> I suppose this is all described somewhere  -  where?(I am new to gtk 
> application programming).
Check the documentation [1] ;)
For example, for GtkWidget's signals see [2] or for GtkWindow see [3]...
and so on.

Cheers,
Colomban

[1] http://library.gnome.org/devel/gtk/stable/
[2]
http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget.signal-details
[3]
http://library.gnome.org/devel/gtk/stable/GtkWindow.html#GtkWindow.signal-details

> Cheers,   John
> 
>> Subject: RE: GtkSwitch — lack of specific signal
>> From: tadeb...@gmail.com
>> To: johnlu...@hotmail.com
>> CC: gtk-app-devel-list@gnome.org
>> Date: Sat, 5 Mar 2011 02:50:05 +0100
>>
>> Hello.
>>
>>> Thanks both. I tried notify::active and it works as well as event-after 
>>> but still the data pointer argument is bad on entry to the callback(it's 
>>> not zero but not a valid  GTK_WIDGET either). I don't know why  - maybe 
>>> something related to GtkSwitch or maybe a mistake in my code somewhere.
>>> Cheers,   John Lumby
>>
>> Are you sure your functions has the right prototype? GObject::notify
>> signal handlers should have callbacks defined like this:
>>
>> void
>> notify_callback (GObject*obj,
>>  GParamSpec *pspec,
>>  gpointer   *data)
>> {
>>   /* La la la */
>> }
>>
>> Cheers,
>> Tadej
>>
>> -- 
>> Tadej Borovšak
>> tadeboro.blogspot.com
>> tadeb...@gmail.com
>> tadej.borov...@gmail.com
>>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: treeview and scrolledwindow

[Colomban Wendling]

Le 21/02/2011 23:06, Alexander Nagel a écrit :
> Hi,
> 
> i have a question about treeview. Do i need to add a treeview in a
> scrolledwindow? I always did it this way but it seems to work without
> it. Which way is the better one? I would like to hear your
> suggestion/opinions.
If you don't pack it in a scrolled window, it will (obviously) never
have scollbars, so it'll use it's full size in the
screen/parent-window/whatever.

So in general, you want to pack it in a scrolled window, but you're not
strictly forced to do so.

Regards,
Colomban

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

Re: g_remove

[Colomban Wendling]

Le 19/02/2011 15:06, Jaroslav Šmíd a écrit :
> #include 
> 
> int main(int argc, char **argv)
> {
>   gint64 a;
>   return 0;
> }
> 
> - doesn't compile on x86-32 linux with glibc when I remove all typedefes
> and occurences of long long in header files (long long is not part of
> C89 standard and it would be unfair to leave it there even if it is some
> compiler extension of the C89 standard). Because there is no other 64bit
> integer type on such system, I cannot typedef gint64 to something else.
> I doubt this will get fixed, glib requires 64bit integer type (as stated
> in docs), C89 doesn't guarantee its existence and no C89 type is 64bit
> on x86-32 linux.
It's not that simple. GLib's configuration scripts searches for the
appropriate type, not necessarily for long long [1]. So GLib needs the
system to provide a 64bits type, not necessarily to support C99.

Regards,
Colomban

[1] actually, it seems to check for long, long long or __int64 being a
64bits integer

> On 02/19/2011 02:50 PM, David Nečas wrote:
>> On Sat, Feb 19, 2011 at 02:37:51PM +0100, Jaroslav Šmíd wrote:
>>>
>>> Maybe. Doesn't meen you didn't tell which one.
>>
>> I did not have to because everyone except you understood the context.
>> Since you did not ask the question and evidently know better your
>> failure to understand is of little concern.
>>
>>> * direct, indirect, build time or runtime ... it is depency. Don't know
>>> names, but if you want, you can find out by yourself.
>>
>> It also has dependences that require C++, GMP and Perl – and they are
>> equally irrelvant.
>>
>> Demonstrate that a C99 compiler is required to compile GLib-using
>> programs.  And I will go and fill this as a bug in Gnome bugzilla and it
>> will be fixed because the developers have repeatedly declared GLib is
>> C89-compatible.
>>
>> Yeti
>>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

Re: g_remove

[Colomban Wendling]

Le 17/02/2011 20:46, Costin Chirvasuta a écrit :
> On Thu, Feb 17, 2011 at 9:11 PM, Craig Bakalian
>  wrote:
>> Hi David and KC,
>>
>> The  did the trick.  But it is odd behavior.
>>
>> #include  was already in my includes.
> 
> Then g_remove must be a macro for a function in glib/gstdio.h, not stdio.h.

g_remove() is a macro on Unices and a function on other platforms (or if
G_STDIO_NO_WRAP_ON_UNIX is defined) that is defined in glib/gstdio.h.
There's nothing odd or strange behind this, apart perhaps that you need
to include  but the docs tells you.

And glib/gstdio.h includes all the needed stuff (apart perhaps fcntl.h
-- for open() and creat() -- and utime.h -- for utime() --, but these
have nothing to do with g_rename()). So James Morris' answer was the
one: there was simply a missing include.

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

Re: scan code for required gtk version

[Colomban Wendling]

Hi,

Le 01/01/2011 16:30, Dan McMahill a écrit :
> Is there a way to scan ones source code automatically to determine the
> minimum required version of gtk and also glib?  The reason I ask is I've
> been involved in a project that doesn't really use lots of the most
> cutting edge features and in general, we only want to bump the required
> version in cases where there is some really motivating reason to do so.
>  That said, I also don't want to maintain a whole bunch of different gtk
> installs only for purposes of trying to see how far back I can go and
> still build this other program.
I don't know any official ways, but I've mad a little script (very
hackish for now, but works quote well though) that extracts glib symbols
from C sources and check them against the version in the docs.

You can fetch them:
http://ban.free-h.net/progs/var/check_glib_dep.sh
http://ban.free-h.net/progs/var/gtkdoc-html-get-since.py

check_glib_dep.sh is the script to launch, and it expects
gtkdoc-html-get-since.py to be in ~/bin. You can of course tune as you want.

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

Re: Notebooks and page numbers

[Colomban Wendling]

Le 02/08/2010 14:50, Jeff Clough a écrit :
> On Mon, 2010-08-02 at 20:22 +0800, Gregory Hosler wrote:
> 
>> a pages page number can and will change whenever it's position in the number
>> sequence 0 to N-1 changes.
> 
> Are there situations where something internal to GTK will change this?
> To be more specific, if I'm interested in page 2 (and have that page
> number in a variable somewhere) and *I* don't make any changes to the
> page order, delete or add any pages, is it safe to assume it will
> *always* be page 2?
This never changes unless:
a) you let your users reorder the pages (e.g. by setting the reorderable
child property on a page);
or b) you insert a new page before the one you care about.

You can simply see the index as the tab's position as visible by the
user. The tab at the very left (in LTR layouts) has always index 0, the
next one 1, and so on until the tab at the very right that has index N-1.

> Does GTK perhaps have another way to represent what most people call
> "tabs" in an application?
No (AFAIK), notebook IS the tabbed UI widget.

Regards,
Colomban

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

Re: Global GList in gtk+ application

[Colomban Wendling]

Le 12/06/2010 08:03, Alexander Kuleshov a écrit :
> [snip]
>
> I have a function bulid my list:
> gboolean build_list()
> {
>Data->list = g_list_append(Data->list, "First ");
>Data->list = g_list_append(Data->list, "Second ");
>Data->list = g_list_append(Data->list, "Third ");
>
>g_list_foreach(Data->list, (GFunc)printf, NULL);
> }
>   
Using printf() as a void (*func)(void*, void*) is pretty unsafe: apart
the inexact signature[1], imagine one of your strings contains something
like a "%something" understood by printf(), what's gonna happen? Bad things.
Prefer using something like puts() or a personal function that follows
the needed semantic.

> After calling this function to display all items from the list:
>
> First Second Third
>
> ,but when i try to make it in another function - for example:
> void foreach()
> {
> g_list_foreach(Data->list, (GFunc)printf, NULL);
> }
>
> I see error in gdb:  SEGFAULT
>
> *Program received signal SIGSEGV, Segmentation fault. [Switching to
> Thread 0xb7335700 (LWP 5364)] 0xb765a7d7 in strchrnul () from
> /lib/i686/cmov/libc.so.6 *
>
> How can i create global list in my application?
>   
Global lists are probably not the problem, unless you use threads and
tries to access the list both in read an write without locks -- an even
there the problem wouldn't be the lists though.

And there's far from enough information to help you, even if as Tor said
it has more than probably little to do with GTK.

Regards,
Colomban

[1] AFAIK it doesn't matters much, at least on x86-style platforms --
but don't trust me on this.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk_button_new_from_stock () does not find icons.

[Colomban Wendling]

Le 05/06/2010 11:07, N James Bridge a écrit :
> On Sat, 2010-06-05 at 01:13 +0200, Colomban Wendling wrote:
>   
>> Le 04/06/2010 21:33, N James Bridge a écrit :
>> 
>>> I don't know if this is a fedora problem or a gtk one...
>>>
>>> I have been writing some short gtk programs, as a learning exercise. So
>>> far as I can see, I should be able to add items from stock, but the
>>> images are missing and all I get are the default items as mnemonics. I
>>> have attached a short example. It compiles with:
>>> gcc  stock.c `pkg-config --cflags gtk+-2.0 --libs gtk+-2.0`
>>>
>>> It seems that gtk can't find the directory with the images. The files
>>> needed seem to be in /usr/share/icons/gnome and show up in the gtk-demo
>>> program. However, Glade buttons selected from stock do not have the
>>> icons either.
>>>
>>> Any suggestions most welcome!
>>>   
>>>   
>> Hi,
>>
>> Isn't this simply your GTK settings that choose not to show icons in
>> menus/buttons? It's the GNOME 2.28 default not to display them IIRC.
>>
>> Regards,
>> Colomban
>> ___
>> 
> Hi
>
> probably... the compiler doesn't complain about missing images, which it
> should. But so far I have not managed to change the settings. I found
> the /etc/gtk-2.0/gtkrc file and set  gtk-button-images = 1 but it makes
> no difference even after a restart. What else can I try?
>
>
> Thanks for the help
>
> James
>   
The settings under GNOME are in GConf's /desktop/gnome/interface/, the
keys buttons_have_incons and menus_have_icons. You can change them with
gconf-editor or using gconftool-2(1).

Regards,
Colomban

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

Re: gtk_button_new_from_stock () does not find icons.

[Colomban Wendling]

Le 04/06/2010 21:33, N James Bridge a écrit :
> I don't know if this is a fedora problem or a gtk one...
>
> I have been writing some short gtk programs, as a learning exercise. So
> far as I can see, I should be able to add items from stock, but the
> images are missing and all I get are the default items as mnemonics. I
> have attached a short example. It compiles with:
> gcc  stock.c `pkg-config --cflags gtk+-2.0 --libs gtk+-2.0`
>
> It seems that gtk can't find the directory with the images. The files
> needed seem to be in /usr/share/icons/gnome and show up in the gtk-demo
> program. However, Glade buttons selected from stock do not have the
> icons either.
>
> Any suggestions most welcome!
>   
Hi,

Isn't this simply your GTK settings that choose not to show icons in
menus/buttons? It's the GNOME 2.28 default not to display them IIRC.

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

Re: GIO input/output streams for stdout, stderr and stdin

[Colomban Wendling]

Tor Lillqvist a écrit :
>>> Then, how portable applications are supposed to read
>>> and write to standard input and output through GIO streams?
> 
> Just use the C library instead?
> 
> --tml
> 

Well, no, i can't do that: I need that GMemory{In,Out}putStream GIO
feature in order to treat data that isn't attached to any file.
Before I used a custom IO layer that works only into memory, but when I
found that GIO have memory streams I switched to in order not to need to
load the whole file into memory when working on actual files. Moreover,
it brought remote streaming as well, very cool.

Of course I could use a GMemoryOutputStream to cache the data and then
dump it to stdout with C library's functions, but if I could do so
without caching the whole data into memory before, I would be really
better (i.e. in term of memory usage).

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

Re: GIO input/output streams for stdout, stderr and stdin

[Colomban Wendling]

Colomban Wendling a écrit :
> Hi,
> 
> I'm not completely sure where I should ask about this but then... let's
> try here!
> 
> I have an application that manages data through G{Input,Output}Streams,
> and I would like to be able to read and write directly from and to stdin
> and stdout in a portable manner.
> As I understand GUnix{Input,Output}Stream (that obviously address my
> problem together with fds 0 and 1), it is not portable on Windows or
> whatever, is it? Then, how portable applications are supposed to read
> and write to standard input and output through GIO streams?
> 
> Thanks by advance!
> Colomban
>

No thought on it?

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

GIO input/output streams for stdout, stderr and stdin

[Colomban Wendling]

Hi,

I'm not completely sure where I should ask about this but then... let's
try here!

I have an application that manages data through G{Input,Output}Streams,
and I would like to be able to read and write directly from and to stdin
and stdout in a portable manner.
As I understand GUnix{Input,Output}Stream (that obviously address my
problem together with fds 0 and 1), it is not portable on Windows or
whatever, is it? Then, how portable applications are supposed to read
and write to standard input and output through GIO streams?

Thanks by advance!
Colomban
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: toolbutton label not visible in gtk 2.18

[Colomban Wendling]

Hi
,
John Stebbins a écrit :
> On 10/30/2009 09:24 AM, John Stebbins wrote:
>> I just installed fedora 12 beta on one machine and ubuntu 9.10 on
>> another.  Both have gtk 2.18.3.  When I run my application on either
>> system, my toolbutton labels are not visible.  Am I missing some new
>> property that needs to be set to make them visible, or is this a gtk
>> bug?
>>
> I figured it out.  The GtkToolBar property toolbar-sytle now must be
> set to GTK_TOOLBAR_BOTH.  This wasn't necessary before.  I don't know
> if it makes a difference, but my ui is being initialized with GtkBuilder. 
GNOME has a global preference for this property (System → Preferences →
Appearance → Interface), isn't it simply that it is set too show only icons?

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

GtkUIManager toolbar menus

[Colomban Wendling]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

I'm using a GtkUIManager menu and toolbar definition (inside a
GtkBuilder UI definition, but I don't think it is related) and I would
create a drop-down menu in the toolbar, containing some of my menu elements.
What I want is something like GEdit's "recent files" drop-down toolbar
menu, but not in a such dynamic way.

But I can't find how to do this, and the web seems poor on this question.

The UI should be alike this (but working ^^):

  



  


If I use this, I got the following error:
Gtk-CRITICAL **: gtk_menu_tool_button_set_menu: assertion
`GTK_IS_MENU_TOOL_BUTTON (button)' failed

Thanks by advance!
Colomban
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoimDEACgkQyqbACDEjVWh3YwCeIWBKNeKk0VXOC1LFe4pytvRN
MIMAniyjIWs6C/WdBx7ZLwvO044bcGGG
=Q2Yh
-END PGP SIGNATURE-

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