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: Bug in gobject-introspection

[Colomban Wendling]

Le 06/05/2018 à 09:05, Nicola Fontana a écrit :
> Il Sat, 07 Apr 2018 06:25:52 +0200 Arun Gurung  scrisse:
> 
>> Hi,
>>
>> I have gobject-introspection-1.50.0-1.el7.x86_64 and gobject-
>> introspection-devel-1.50.0-1.el7.x86_64. I tried to use a program like
>> "menulibre" and "devedeng" and the developers say there is a bug in
>> gobject-instrospecition. Thanks for any help!
> 
> Hi,
> 
> gobject-introspection is Python2 based.

GI works fine with Python 3 here, at version 1.50.0 as well (Debian 9
here).  So I guess it's either that upstream GI doesn't support Python3
and Debian has a patch, or that the OP's version is incorrectly
installing a Python2 GI version in Python3's directories.

Anyway, it looks like the OP's distro is messed up for installing a
Python2 module in Python3's libraries.  Or maybe it's a leftover from a
manual installation?

And for more details on @Nicola's answer: the issue is that in Python
3.x 'print' became a function so has to be used with the syntax
'print(...)', while in Python2 it was a keyword that could be used like
'print ...' (i.e. without parentheses around what to print).  The issue
you see is that use of the Python2 syntax with Python3.

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: laptop, OS recommendations for gtk work

[Colomban Wendling]

Hi,

Le 10/06/2017 à 02:17, Karan Ahuja a écrit :
> I am looking to purchase a new laptop to work with gtk.
> 
> Please recommend good laptop, operating system based on your experience.
> 
> Thinkpad vs macbook?

Either work just fine, it really doesn't matter much wrt GTK, and I know
people happily working with both.  Just note that ThinkPad has several
lines of laptops (X series, T series, L series, E series, W series…) and
they are not equivalent.  I know people happy with some X and T series,
no idea about the other ones.

> Fedora vs osx vs ubuntu ?

Unless you want to target OSX, I'd recommend a GNU/Linux OS because GTK
is primarily targeting GNU/Linux, so it's your best bet if you want
things to "just work".  However, if you're targeting OSX for your apps,
I'd obviously recommend at least having a machine to test there, if it's
not your primary environment.

Apart from that, I don't think the distro matters much.  Using
widespread ones like Fedora or Ubuntu is probably a good idea if you
want your environment to be as close as the users', but apart from that
you should be fine with whatever you pick.  I myself use Debian (stable
and unstable), but many dev are on Fedora and Ubuntu.  My choice is
based on my OS preference and because I'm used to it, but either of
those is a good choice, probably just as openSUSE, Mint, Arch, Gentoo or
whichever has your preference.  The only point I'd check is which
version of GTK the distribution ships with: you might either want
something very recent for latest features, or something more
conservative to be able to easily target older versions shipped with
more conservative distros.
If you really don't know and just want the most obvious choice, I'd say
Fedora (even though it's not my personal favorite), because it's
probably the most up-to-date/stock/GNOME distro, and possibly the one
most GTK authors use themselves.

But again, that's mostly a personal or target choice you can make and
that won't change that much.  I'd rather say, pick whichever distro
you're most efficient with.

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: GtkSocket/GtkPlug accessibility

[Colomban Wendling]

Le 27/01/2017 à 15:32, Mario Sanchez Prada a écrit :
> […]
> 
> I know I arrive tremendously late to this thread, and I'm not even sure if
> this is going to be helpful for your situation, but just in case this is a
> small test application I wrote long ago to understand how the whole thing of
> AtkSocket & AtkPlug works:
> 
> https://github.com/mariospr/atksocket-atkplug-example

I did found your test app when searching info about that, looked helpful
if I happened to need implementing something :)

> Also, in case it also helps, this is a (long) rant I wrote a while ago too
> explaining how we implemented accessibility support in the multiprocess
> architecture of WebKit2, also using AtkSocket and AtkPlug:
> 
> http://mariospr.org/2013/02/03/accessibility-in-webkitgtk
> 
> Now, feel free to dismiss all this if it's totally irrelevant :-)

No, that looks interesting, esp. as you have included some info about
Socket/Plug.  Maybe not technical enough, but the example you linked
above covers that :)

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

a11y: Unwanted deactivate/activate window events upon X grabs

[Colomban Wendling]

Hi,

I'm trying to tackle https://bugzilla.gnome.org/show_bug.cgi?id=776854
down, and it seems that the unwanted events are originating from
gtkaccessibility.c's window_focus().

The problem here is that those AT events get emitted for e.g. global
keyboard shortcuts from the WM, even though no logical window focus
changed.  This leads to e.g. Orca re-announcing the current window for
no good reason -- or worse if the events get dispatched out of order
(likely because they come from different sources?).

As I understand it, it's getting some of the grab-triggered
FocusOut/FocusIn events, because although GDK does some fairly complex
filtering on that already, it lets some through in some cases --
probably for a good reason I guess, as it seems to be done on purpose.

After a lot of searching, I found a relevant thread on wm-spec-list:
https://mail.gnome.org/archives/wm-spec-list/2007-May/msg0.html.
But it's not very clear to me now what something like a11y in GTK should
do then:

* Listen to _NET_ACTIVE_WINDOW changes? (how?)
* Listen to FocusChange and ignore *all* but NotifyNormal? (how?)
* Something else?  Does that client message mentioned in the thread
exist by now?

I'm not quite sure, esp. as I'm not very knowledgeable about X or WM
stuff, so the possible implication of each of those probably elude me.

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

Re: GtkSocket/GtkPlug accessibility

[Colomban Wendling]

Hi,

Thanks for those answers.

Le 29/12/2016 à 11:51, Alejandro Piñeiro a écrit :
>>> But fact is things like MATE-Panel make heavy use of those, so it'd be
>>> nice to have it work properly.
> 
> Then perhaps it is about using AtkSocket/AtkPlug on MATE-Panel. But that
> is an advice given without looking at all that code.

Okay, I'll see then.  If it's not something that should be done at the
GtkSocket/Plug level and would profit everyone, I might investigate a
different hackish solution that might be good enough for the MATE-Panel
specific problem.  Or see to use AtkSocket/Plug in MATE-Panel's side if
needed, we'll see.

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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

GtkSocket/GtkPlug accessibility

[Colomban Wendling]

Hi,

It seems that GtkSocket and GtkPlug aren't tied together at the
accessibility level: e.g. the ATSPI tree from Accerciser shows them
separately, and atspi_accessible_get_application() returns the embedded
application rather than the embedding one.

This leads to e.g. Orca finding them being part of separate applications
and generally announcing some extra stuff.  And it technically makes
sense as nothing seems to tie them up at the ATSPI level.
Maybe Orca could hack something up to work around it, but I would think
it's not the proper place to change this.

So I'm wondering what should be done here.  Should GtkSocket and GtkPlug
have accessible implementations making use of AtkSocket and AtkPlug, and
this just hasn't been done yet, or is something else required?  Would
that solve the issue?

I know some people would like to forget about GtkSocket and GtkPlug :)
But fact is things like MATE-Panel make heavy use of those, so it'd be
nice to have it work properly.  I'd be willing to work on that, but I'm
first trying to see if I'm heading in the right direction or if I'm
totally off track.
Also, if it's the right thing to do, I guess the question of how to
communicate the socket ID arises, so that it could potentially work
outside GTK itself for other plugged windows to work.

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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+, WM, desktops and CSD

[Colomban Wendling]

Le 06/03/2015 02:12, Matthias Clasen a écrit :
 On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com wrote:
 
 […]
 
 Ideally, GTK should be able to use CSD even without a compositor. The
 only reason it requires a compositor is because it uses the shadows as
 resize handles. Ideally, it should use a larger border width when
 there is no compositor - But that would another set of patches as not
 directly related to the hint proposed.
 
 Yes, I've been thinking that myself recently: We should fall back to
 having 'fat borders' instead of 'invisible borders+shadow' if the
 environment can't support them. A patch to do so would be most welcome
 (I'm well aware that gtkwindow.c is not the easiest place to add new
 functionality like this...)

Hum, I'm not certain of what means what, but I though I had to mention
it:  I don't use a compositor (Metacity with compositing disabled), but
apps using CSD work just fine (Epiphany, GEdit, …).

And while, yes, the handle for resizing is pretty small with those
(maybe 1px wide, but taller), it doesn't wasting screen space and I can
always use metaMMB to resize my windows (or whatever my WM's shortcut
is for this).
BTW, my non-CSD windows have an equally small handle everywhere but on
the top left corner (and on top, where it has 3px instead of 1), so it
doesn't really change much.  (I actually use Metacity with the default
window theme -- Adwaita?)

That's all, just mentioning I myself at least don't consider this to be
a real problem even today -- and I don't really want to see fat borders
around my windows if I can avoid it, so if it happens I'd love a way to
define its width :)

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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 `ArrayValue?`,
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: 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

Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?

[Colomban Wendling]

Le 23/12/2014 14:02, jcup...@gmail.com a écrit :
 I'm looking for the rational of using 'gint' instead of 'guint' in the
 call:

 g_ptr_array_set_size (GPtrArray *array, gint length);


 I imagine that the use of a signed integer was an oversight at the time
 which can now not be corrected without breaking API. It's not worth
 that.

 
 I remember (a long, long time ago) there was a dislike for uint.
 Mixing uint and int can be fiddly and produce a range of bugs, some
 more subtle than others, and the extra bit of range you get is
 unimportant. int-only code is usually simpler and safer.

It's far from being that simple.  There is for example a whole history
of out of bound buffer access triggered by signed integer wraparound [1]
and missing checks for  0.  With unsigned you can't suffer from this
(directly).  But OK, unsigned integer overflow can also lead to
infinite loops or under-allocations in some special cases.

But well, this is C, it's a tricky language.  But IMO, yes, unsigned has
a lot of benefits when it comes to sizes, and is overall safer than the
signed version.  And in the large majority of cases, a correctly
designed code that always uses unsigned sizes won't suffer from mixed
signedness.

size_t (or gsize) TFW :)

Colomban


[1] as while signed integer overflow is technically undefined behavior
(which is bad enough), it generally ends up in a wraparound to MIN_INT
due to the machine integer representation.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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 arkkim...@gmail.com 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

Desktop performances (was: Re: GTK+ scene graph)

[Colomban Wendling]

Hi,

Le 18/08/2014 19:55, Emmanuele Bassi a écrit :
 [...]
 
 when we introduced GL in the pipeline through the compositor 5 years
 ago, stuff that was 5 years old *at the time* already could run
 decently.

Not completely, no.  I had (and still have) a really decent '07 card
(non-integrated 6600GT on a desktop) that always was largely sufficient
for everything I wanted -- desktop, development, multimedia, even most
3D Linux games would run smoothly.  It worked like a charm for
everything when I ran non-compositing WM (I used GNOME2/Metacity at that
time), and it was able to perform accelerated video decoding through
VDPAU, which was very nice as my CPU of that time couldn't really cope
with full-HD decoding -- and my current one is just barely able to keep up.

But when using GNOME3/Mutter, my graphic card quickly runs out of its
256M of VRAM and could not perform hardware decoding anymore whenever I
have like a dozen windows open (which is basically always, mail,
browser, IM, IDE, a few terminal windows, audio player, ... it grows
quickly), rendering it impossible for me to e.g. watch HD videos without
closing other apps.

This sounds a little crazy, but it's a decent '07 card, not even some
integrated chip of that time.  And I believe my setup to still be
completely relevant today, even if more modern similar cards probably
ships with 2-6 times as much VRAM.  I don't plan to invest in a new
graphic card for my *desktop* to run.

So even though compositing WMs looked like a nice idea originally, I'm
really not convinced anymore (or at least the X11/mutter impl is wrong,
I didn't try anything else seriously).  The only real benefit is visual
effects, for which I don't care.  They are nice and all, but they don't
help me using my computer any more efficiently or more comfortably.  I
wouldn't care if it didn't get in my way, but as explained above, it
does as a side effect.


Sorry if this somewhat strikes as a rant, but please, don't assume
everyone updates their hardware every 3 years.


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

Re: A Gtk's build system ?

[Colomban Wendling]

Le 06/08/2014 21:30, Krzysztof Kosiński a écrit :
 [Waf] does not require silly lists of files to work

If that refers to using globs in the build system files, don't.  Glob
showed on many a situation to be the source of various build problems,
including, but not limited to, a file to be missing from the source tree
(which would not be easily noticeable and would work on the author's
setup), or unexpected files to be included in a build.

Also, FWIW patterns can generally be used just fine in Autotools -- but
again, please, don't use them.

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

Re: A Gtk's build system ?

[Colomban Wendling]

Le 06/08/2014 22:01, Krzysztof Kosiński a écrit :
 2014-08-06 21:43 GMT+02:00 Colomban Wendling lists@herbesfolles.org:
 Le 06/08/2014 21:30, Krzysztof Kosiński a écrit :
 [Waf] does not require silly lists of files to work

 If that refers to using globs in the build system files, don't.  Glob
 showed on many a situation to be the source of various build problems,
 including, but not limited to, a file to be missing from the source tree
 (which would not be easily noticeable and would work on the author's
 setup), or unexpected files to be included in a build.
 
 I am not really convinced by this.
 
 1. If there are any uncommitted files, version control will tell you about 
 this.
 2. If you have 'unexpected files' in the source tree, you are doing
 something wrong.

Even if both are more or less true, they still happen no matter what,
experience shows this.

Having files that should not be built is even something that might be
desired in situation where e.g. one is in the step of adding a new file
but has to quickly work on something else (say, an important fix).  A
Git user will probably stash his changes to get back to it later, but a
stash won't affect the not-yet-added files.  Result is a build failure
requiring to temporarily and manually get the files out of the glob match.

Same problem happened when installing unwanted files that were only
supposed to be used for building purpose but happened to match an
obscure pattern hidden somewhere and went unnoticed for a long time as
it didn't have a real impact apart from clobbering the installation.

All this happened to me and others using globs, where it didn't when
using explicit lists.

Adding a file to a list on the other hand is really trivial and hard to
forget (as the build won't include it otherwise), and I believe this
little hassle is nothing compared to the eventual issues a glob might
induce at unexpected times.

 [...]
 
 Also, FWIW patterns can generally be used just fine in Autotools -- but
 again, please, don't use them.
 
 Autotools can't correctly use patterns / wildcards, because it
 requires manually re-running automake whenever a file is added or
 deleted.
 http://www.gnu.org/software/automake/manual/html_node/Wildcards.html

OK sorry for that, I guess the wildcards I saw with Autotools were only
in list of files to install (maybe with manual expansion), not to build.

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

Re: Some question about GLib

[Colomban Wendling]

Le 25/07/2014 23:46, Ameen Sayegh a écrit :
 [...] and I'm interested in C Language and its simplicity

I'm afraid that's not completely true :)

 [...]
 
 I have some question about the source code that I don't know what it
 does mean for example:
 gmem.h:120: (void) (0 ? (gpointer) *(pp) : 0);

That's a hack to catch misuses of the g_clear_pointer() macro.  See
https://bugzilla.gnome.org/show_bug.cgi?id=674634#c34

The idea is that if pp is a pointer and not a pointer to pointer, each
branch of the conditional expression will have a different type and this
is invalid -- hence the compiler will error-out.

To take Xavier's example, imagine the following code:

struct { gpointer x; } test;
g_clear_pointer(test);

The first static assertion in g_clear_pointer() (which is (sizeof *(pp)
== sizeof (gpointer))) won't catch it as the struct has the size of a
gpointer, so it would go unnoticed.  Therefore, there is this second
hack to make sure to catch this.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Colomban Wendling]

Le 24/06/2014 02:03, Jasper St. Pierre a écrit :
 I can't reproduce any issue in scrolling with evince locally -- does it
 only happen with certain documents? Can you point to a document where
 you have problems?

I doubt it's document-related, as it worked with the first three PDFs
I tried with.  Anyway, I can reproduce with e.g.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf   Note however
that you have to scroll *aggressively*, meaning I'm was assaulting my
mouse wheel for several seconds, or take the scrollbar grip and shake it
quick.  Also it's less directly visible with Evince itself which seems
to have a very cheap scroll draw (yet you probably notice something),
but other apps gets slow-slow (for example gedit's gear menu takes like
5s to open).

I also just tried to enable Metacity's compositing as I was using it
without, and I can reproduce with and without compositing.

 I also just built Scintilla and SCiTE from source, but they both appear
 to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or
 port, or did I do something wrong when building Scintilla/SCiTE?

you need to set the GTK3 make variable to 1:

$ cd gtk
$ make GTK3=1

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Colomban Wendling]

Le 24/06/2014 03:03, Jasper St. Pierre a écrit :
 Thanks, I managed to reproduce the issue with this. It only happens with
 thumbnails visible, though, which suggests that evince is doing
 something funny for the thumbnails view.

It happens with no sidebar at all here, so I don't think that's it.
Though, as for me scrolling heavily this very PDF with thumbnails is
already very slow no matter what (I guess the thumbnails are not cached
as well as the real view or something, but large page range change eats
lots of normal CPU time), it can just be stressing the drawing a little
more.

Also, I can't seem to reproduce with any older revision, like
240daf55a193efd5cc83bb838a14e57ad4ce90ab works just fine, and I bisected
since 0ec00ffbb04796546785fcd4fa8df092b8564e43;  so I don't think it's
really the application's fault here.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Colomban Wendling]

Le 24/06/2014 03:03, Jasper St. Pierre a écrit :
 Thanks, I managed to reproduce the issue with this. It only happens with
 thumbnails visible, though, which suggests that evince is doing
 something funny for the thumbnails view. I'll also check out Scintilla
 later.

OK, it's fairly obvious after looking at the diff: there's a missing
cairo_surface_destroy() in the new version of gdk_cairo_create(), hence
the surface will probably be leaked and God knows what happens on the
server side.  Patch attached.

Regards,
Colomban
From fe2dfe2d85163ac6e04c212402836cd75609948e Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Tue, 24 Jun 2014 03:37:59 +0200
Subject: [PATCH] Don't leak the surface in gdk_cairo_create()

---
 gdk/gdkwindow.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gdk/gdkwindow.c b/gdk/gdkwindow.c
index 4e4ec98..68a75df 100644
--- a/gdk/gdkwindow.c
+++ b/gdk/gdkwindow.c
@@ -3058,6 +3058,8 @@ gdk_cairo_create (GdkWindow *window)
   cairo_region_destroy (region);
   cairo_clip (cr);
 
+  cairo_surface_destroy (surface);
+
   return cr;
 }
 
-- 
2.0.0

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Colomban Wendling]

Le 21/06/2014 03:00, Jasper St. Pierre a écrit :
 To better support Wayland with fewer copies and less drawing artifacts,
 I've pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.
 
 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e
 
 With these changes, it is now illegal to call gdk_cairo_create outside
 of a begin_paint / end_paint. [...]
 
 Please double-check to make sure your apps still work fine. If you have
 a problem with any of this or I broke your apps by accident, please
 reply and I'll try to fix it.

For the record, this makes Scintilla (http://www.scintilla.org/) emit
tons of warnings.  However, it seems relatively easy to fix and don't
seem to actually break it, the triggering call being only due to the
same code path being used in drawing and non-drawing contexts.  So,
fixing this would add complexity to the application code, but would
avoid creating some unused contexts.

All in all, it is a bit annoying to have to fix stuff again and again
(the 3.9 drawing model change broke it also, because Scintilla has a
somewhat bizarre toolkit usage as it has platform layers), but it should
be fairly easy this time.


Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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 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: [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: 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 18:07, Chris Vine a écrit :
 On Wed, 05 Mar 2014 09:44:48 -0500
 Chris Moller mol...@mollerware.com 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: 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: 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:
 
 object class=GtkTreeViewColumn id=tvcol_button
 property name=title translatable=yesButton Label/property
 property name=clickableTrue/property
 property name=reorderableTrue/property
 child
 object class=GtkCellRendererText id=cr_button/
 /child
 /object

Actually the patch should look like this:

 --- button-actions.glade
 +++ button-actions.glade
 @@ -122,6 +122,17 @@
  property name=search_column0/property
  property 
 name=show_expandersFalse/property
  property 
 name=enable_grid_lineshorizontal/property
 +child
 +  object class=GtkTreeViewColumn 
 id=treeviewcolumn1
 +property name=titleTest/property
 +child
 +  object class=GtkCellRendererText 
 id=cellrenderertext1/
 +  attributes
 +attribute name=text0/attribute
 +  /attributes
 +/child
 +  /object
 +/child
/object
  /child
/object


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

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 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 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 gtk/gtk.h
 #include cairo.h
 #includemath.h
 
 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 gtk/gtk.h

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: 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: 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: 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 https://developer.gnome.org/goocanvasmm/stable/ 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...
 
 http://pastebin.com/6LEzFk8A

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: 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: 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: 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: Composite GtkBuilder template

[Colomban Wendling]

Le 09/05/2013 15:15, Nicola Fontana a écrit :
 Il Sun, 7 Apr 2013 23:50:10 -0400 Matthias Clasen matthias.cla...@gmail.com 
 scrisse:
 
 Here is a patch that seems to work ok.
 
 The build fails during cross-compilation with:
 
 ./extract-strings.exe 
 /home/aur/archlinux/fedora-mingw-w64-gtk3/src/gtk+-3.9.0/gtk/gtklockbutton.ui 
  gtklockbutton.ui.h
 /bin/sh: ./extract-strings.exe: cannot execute binary file
 
 Is it possible to include .ui.h files in dist just to avoid this?

I'm not sure how to do this, but the right fix would rather be to build
extract-strings as a host (rather than target) executable;  including
.ui.h in the distribution would only fix cross-compiling from a tarball,
not e.g. directly from a repo clone.

Regards,
Colomban


PS:

 Patch attached.

Apparently the patch is missing ;)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Test failing after recently updating glib (from git)

[Colomban Wendling]

Le 28/04/2013 09:32, John Emmas a écrit :
 The last time I updated glib (from git) was around a fortnight ago. I'm
 building using MSVC but up until now, everything's been building and
 running okay.
 
 This morning I updated to the latest git sources and re-built (after
 adding a new source module, 'gio/gbytesicon.c').  Everything still
 builds fine but I now get an error if I build and run
 'tests/testgobject.c'.  It now fails at line 404:-
 
 dobject = g_object_new (DERIVED_TYPE_OBJECT, NULL);
 
 Strictly speaking, it actually asserts at line 211 (in
 'test_object_init') :-
 
 g_assert ((gchar *)priv = (gchar *)tobject + sizeof (TestObject));
 
 Could someone test this in an official build and let me know if a
 general problem's been introduced - or if it's something specific to my
 build?  'gobject.c' was one of the changed files, in case that's
 significant.  Thanks.

Apparently this isn't a test run by make check (make check passes just
fine here, Linux x86-64), but indeed tests/testgobject doesn't work
anymore as of master.

31fde567a95ff8f50b6b0e75d4010da9b73514ed broke it, but this looks very
legitimate, so probably the test simply has to be updated.

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

Re: Test failing after recently updating glib (from git)

[Colomban Wendling]

Le 28/04/2013 16:03, Colomban Wendling a écrit :
 Le 28/04/2013 09:32, John Emmas a écrit :
 [...]
 
 31fde567a95ff8f50b6b0e75d4010da9b73514ed broke it, but this looks very
 legitimate, so probably the test simply has to be updated.

Proposed patch fixing the test attached.

Regards,
Colomban
From 1807888294d46b8f6bee4150f1f8255496cf416c Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Sun, 28 Apr 2013 16:29:54 +0200
Subject: [PATCH] Fix tests/testgobject for new object private allocation
 layout

Since 31fde567a95ff8f50b6b0e75d4010da9b73514ed, objects private data
is allocated before the object rather than after:

  [TypeBPrivate] [TypeAPrivate] GTypeInstance] GObject] TypeA] TypeB]

So, fix the test case to check for the new layout and not the old one,
which obviously fails.
---
 tests/testgobject.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/testgobject.c b/tests/testgobject.c
index 39e10d1..d3f6528 100644
--- a/tests/testgobject.c
+++ b/tests/testgobject.c
@@ -208,7 +208,7 @@ test_object_init (TestObject *tobject)
   priv = TEST_OBJECT_GET_PRIVATE (tobject);
 
   g_assert (priv);
-  g_assert ((gchar *)priv = (gchar *)tobject + sizeof (TestObject));
+  g_assert ((gchar *)priv + sizeof (TestObjectPrivate) = (gchar *)tobject);
 
   priv-dummy1 = 54321;
 }
@@ -361,12 +361,12 @@ derived_object_init (DerivedObject *dobject)
   derived_priv = DERIVED_OBJECT_GET_PRIVATE (dobject);
 
   g_assert (derived_priv);
-  g_assert ((gchar *)derived_priv = (gchar *)TEST_OBJECT_GET_PRIVATE (dobject) + sizeof (TestObjectPrivate));
+  g_assert ((gchar *)derived_priv + sizeof (DerivedObjectPrivate) = (gchar *)TEST_OBJECT_GET_PRIVATE (dobject));
 
   test_priv = TEST_OBJECT_GET_PRIVATE (dobject);
   
   g_assert (test_priv);
-  g_assert ((gchar *)test_priv = (gchar *)dobject + sizeof (TestObject));
+  g_assert ((gchar *)test_priv + sizeof (TestObjectPrivate) = (gchar *)dobject);
 
 }
 
-- 
1.7.10.4

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

Re: Test failing after recently updating glib (from git)

[Colomban Wendling]

Hi John,

Le 28/04/2013 18:30, John Emmas a écrit :
 On 28/04/2013 16:37, John Emmas wrote:
 The only obvious difference I can see between your patch and my others
 is that you seem to be using Git v1.7.10.4 whereas I'm still on v1.7.10.1.

 I'll ask on the TortioseGit mailing list to see if that really is the
 problem.

 
 Hi Colomban,
 
 I posted a query on the TortoiseGit mailing list - but in the meantime I
 noticed that the very first character in your patch file is a forward
 facing chevron.  So whereas I normally see something like this as the
 first line:-
 
 From NNN Mon Sep 17 00:00:00 2001
 
 I see this in your patch:-
 
 From NNN Mon Sep 17 00:00:00 2001
 
 Could you check to see if that's intentional or if something's gone
 wrong in the email transfer?  Thanks.

That's not normal, and I'm afraid it's your email client that did
something wrong.   If I fetch the attachment from my mail I get the
exact patch Git generated, which doesn't include this weird character.

I just put it online if you can't get the emailed one:
http://pastebin.geany.org/9b1dU/

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: 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: Reg. modifying GTK+ to add menu option

[Colomban Wendling]

Hi,

Le 10/04/2013 19:52, Sindhu S a écrit :
 [...]
 
 Can you please answer my following questions:
 
 1. Do you feel this is functionality is useful? (regardless of the path
 I proposed to accomplish it)

Maybe, but I don't personally find it particularly useful for me at first.

 If yes, is there a more appropriate way of adding this functionality?

I think there is, yes.

 2. Do you have any suggestions or ideas on how this functionality could
 be achieved alternatively that is, without having to modify GTK+?

I'm no expert on the matter, but I think a GTK module would be better.
AFAIK a module can be whatever they want (see e.g. Ubuntu's thing that
exports menus through DBus), and they are external things -- just happen
to be loaded by GTK.


Hope it helps,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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]

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: 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
 lists@herbesfolles.org 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: 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: Enabling Network locations by default in File Chooser

[Colomban Wendling]

Le 16/11/2012 23:53, Timothy Arceri a écrit :
 Hi Guys, I'm after feedback on whether you guys think this is a good
 idea. For background I have been investigating bug
 https://bugzilla.gnome.org/show_bug.cgi?id=586367
 
 Basically what I've found is that gtk_file_chooser_set_local_only()
 is set to TRUE by default. This makes sense if file_chooser is
 returning uri that points directly to the network locations e.g.
 smb:///blah, afp://blah, etc as you can't be sure that the
 application can handle these protocols. I'm assuming that these uri's
 are what was returnedback with gnome-vfs. However, my testing shows
 that with gvfs file_chooser returns local locations (that I believe
 are FUSE mounted) to the network locations meaning that the
 applications are always given a local location and should have no
 problem with handling the location. Hence I would assume it would be
 safe to set local only to FALSE by default.

I'm not 1% sure, but I'd say:

1) it requires gvfs-fuse;
2) what about non-Linux platforms?  Do they also have local mount for
remote locations?

Regards,
Colomban

 
 
 I guess what I'm after is the GLIB/gvfs guys to tell me if I'm
 missing something here? And whether this is a good idea or not.
 
 Thanks for your time, Tim
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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]

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]

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
synchronizations issues 

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: Introducing a kqueue backend for GIO (GSoC)

[Colomban Wendling]

Hi,

Le 22/06/2011 01:42, Dan Winship a écrit :
 On 06/19/2011 04:25 PM, Dmitry Matveev wrote:
 My project includes writing a kqueue file monitoring backend for GIO, in
 order to provide fast file monitoring to Glib/GIO-powered applications
 on BSD systems.
 
 Cool. I took a quick look. It mostly looks good. (Or at least, as good
 as the inotify backend, which is pretty ugly in places :)

I did the same yesterday just for the sake of it, and have a few
additional remarks:

 - initialized in _kh_startup() needs to be volatile or it's not
   guaranteed to behave the way you want...

Yes, and as far as I understand the code correctly, I think the use of
g_once_init_enter/leave() would be better appropriate here than the
plain lock and initialized var.

   The use of a g_ prefix on static/global variables seems very
   wrong to me (especially in files where nothing else is
   g-prefixed).

Same here.

Also there is G_N_ELEMENTS() for calculating the size of a static array
(e.g. in convert_kqueue_events_to_gio()).

Finally, I think the implementation of convert_kqueue_events_to_gio() is
a bit overkill for what it really does, and would probably be cheaper
with a simple if() list. It's about 4 ifs, it's not like there were
plenty of them.  But that's not important, and the compiler maybe even
optimizes this out to get rid of the static array and the loop.

Regards,
Colomban
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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: I have a problem

[Colomban Wendling]

Le 29/05/2011 01:06, Paul Davis a écrit :
 On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte o...@gnome.org wrote:
 
 so lets take this particular point as an example of what i think the
 basic problem is here:
 
 * There's button(s) that say  ( Notes | Edit )
 How are these buttons different from notebooks? Is it just visually
 different or is it a completely different interaction? Because from
 the interaction described it looks like a notebook to me, just with a
 different UI. But I can't really pinpoint what's missing from
 GtkNotebook for this. Also, should we try to get rid of notebooks and
 replace it with buttons like these in other places?
 
 this is a cart vs. horse problem.
 
 i think you're absolutely correct that functionally, this is identical
 to a notebook. but there's function, and there's design.
 
 this design calls for an alignment of UI elements that isn't possible
 to accomplish with the current widget set (how would you get that More
 combo/menubar/button into the tab list?). 

What about gtk_notebook_set_action_widget()[1]? OK it doesn't look
exactly the same as the tabs, but it's positioned at the very suggested
place.

A few ¢
Colomban

[1]
http://developer.gnome.org/gtk/stable/GtkNotebook.html#gtk-notebook-set-action-widget
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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 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: 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 lists@herbesfolles.org 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: 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: g_remove

[Colomban Wendling]

Le 19/02/2011 15:06, Jaroslav Šmíd a écrit :
 #include glib.h
 
 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
 craigbakal...@verizon.net wrote:
 Hi David and KC,

 The glib/gstdio.h did the trick.  But it is odd behavior.

 #include stdio.h 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 glib/gstdio.h 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 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

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

[Colomban Wendling]

Martyn Russell a écrit :
 On 17/03/10 22:03, Andrew Cowie wrote:
 in gtk/gtkbutton.c which after wading through several macros ends up as
 a call to g_type_check_instance() in glib/gtype.c with some if/else
 blocks around it.
 
 [snip]
 
 So I'm wondering: can we [C, GTK] do away with one of the code paths
 entirely? It'd be nice to do away with the checks in the internal
 accessors, of course, but that isn't going to happen because the
 internal code is now using the public accessors.

 So maybe we can at least not check in the cast macros?

 Again, I haven't profiled a C only applcation in a while, so this may be
 out of date. Someone with a GUI heavy C app would need to check. But
 this used to be really expensive for C apps. And meanwhile we're using
 GTK for some years now without using the cast macros at all, and things
 are working. So that's at least a datapoint.
 
 Isn't this why we have G_DISABLE_CAST_CHECKS ?
 
And G_DISABLE_CHECKS for g_return*s.

If enabling them really worth it in terms of performances, builders
(users, distributors, etc) may want to do so.
But if G_DISABLE_CAST_CHECKS does only affect the program that is built
with (it changes only the internal casts), G_DISABLE_CHECKS have more
impact: the functions would no longer check their arguments, even when
called from applications.

So I think that using G_DISABLE_CAST_CHECKS may be a good idea if it
have an impact on performances, but G_DISABLE_CHECKS is more
questionable, and should probably not be the default.


My 2 cents..
Colomban W.

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

Re: GtkNotebook scrolling usability

[Colomban Wendling]

Shaun McCance a écrit :
 On Wed, 2010-03-10 at 17:25 -0600, Jason D. Clinton wrote:
 On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org
 wrote:
  He
 suggested that maybe there's a use for it in the case that you
 have a
 ton of notebook tabs open, but I'm not quite convinced.  Just
 wanted to
 post on the lists and see if people have thoughts on this,
 otherwise I'm
 probably going to file a patch to either rip the feature out
 or at the
 very least make it so we can disable it. :)


 I don't recall where but I'm fairly sure I saw someone using that to
 flip through open tabs in Epiphany. 
 
 You might have been watching me.  I do it all the time.
 But I don't think I ever do it in preference dialogs or
 other places where there's a static set of tabs.
Same for me. I make heavy use of this (wonderful) functionality, with
browser(s), editor(s) (I think about Geany, Gedit and so on),
gnome-terminal, etc. As said, mostly where tabs aren't static (even
tough I probably used it with static tabs as well, but less often).

IMO, it would be a dramatic regression to completely drop this feature.
And I don't think a preference or so worth it, but if it please anyone,
I won't complain either.

Regards,
Colomban

PS: Sorry Shaun for the duplicate, I did something wrong with my e-mail.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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 ^^):
toolitem action=menufile:save
  menu action=menufile:menuexport
menuitem action=menufile:menuexport:latex/
menuitem action=menufile:menuexport:man/
!-- and more... --
  /menu
/toolitem

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

Re: What gives us the macro GSEAL()?

[Colomban Wendling]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Grzegorz Kuczyński a écrit :
 Colomban Wendling pisze:
 Ok I understand the idea, but... how work it? for example:
 --- struct _GtkWindow { GtkBin bin;

 gchar *GSEAL (title); --- void gtk_window_set_title
 (GtkWindow   *window, const gchar *title) { char *new_title;

 g_return_if_fail (GTK_IS_WINDOW (window));

 new_title = g_strdup (title); g_free (window-title); window-title
 = new_title; // I don't know property title!!! ---
 So, when define GSEAL_ENABLE code in gtkwindow.c must change in
 window-_g_sealed__title = new_title; //??

 Well… you must understand that the mean is to broke *user's* source
 that use members directly if the user wants, not to use when compiling
 GTK+. See it as a smooth way to 3.0 feature.
  
 I understand, it OOP philosophy, GTK+ simulates it
 But you're right: it is impossible to compile GTK+ with GSEAL_ENABLE
 enabled. But as GTK+ is used to be compiled separately from the code
 that use it, there is no problem: just define GSEAL_ENABLE when
 compiling user's code and not when compiling GTK+.
  
 I understand that define GSEAL_ENABLE will be placed eg file gtk.h
 after compiling GTK+,
 but what when user will alone compiling GTK+?
 I mean this is the symbolic protections for direct access members of
 struct.
No, AFAIK, GSEAL_ENABLE is not meant to be put in any GTK+ header,
only to be added by hand to your programs' compiling options (e.g.
- -DGSEAL_ENABLE to a GCC's command line) in order to check your program
for compatibility with upcoming releases.
 But it could be possible (even if it is useless and needs hard work to
 find places to update) to update the source to use the sealed names,
 simply by using GSEAL(name) instead of name. But what's the point
 to do that? Nothing, I think.
  
 I also do not know what? :)
 I don't want write stupidity in Wikibooks. Because I want write
 analize for struct GtkWindow AND I myself want understand :)

 Explaining the meaning of GTK's structure members is not a good idea
 IMO since they may are going to change and perhaps become opaque. The
 right way to access object's properties is to use accessors, and that
 will become the only way.
  
 unless you are right, but this is not change this that I must be know
 (and I want) know what is going in GTK+ sources
 I think about this...
I don't really understand what you mean here, sorry :/

Regards,
Colomban

PS:
sorry for the private mail, I forget to update recipient list :/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknjMHIACgkQyqbACDEjVWjE7ACcDynJzLWhthoJcYYlbvJ3cfiZ
0L4AnRzh2gNRX/0ERf6DXt6TTIb1jMFD
=cYiy
-END PGP SIGNATURE-


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

Re: What gives us the macro GSEAL()?

[Colomban Wendling]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Grzegorz Kuczyński a écrit :
 A. Walton pisze:
 2009/4/12 A. Walton awal...@ubuntu.com: ...

 gtk_window_set_title() is inside of gtk+ and won't need to
 change. The macro is to prevent external applications from doing
 window-title = whatever; and instead applications should (and
 will be forced to use) gtk_window_set_title().

 will be forced to use  - how?
Simply because access to window-title will not be possible any more,
as I explained in another mail.
For now, if you define GSEAL_ENABLE when compiling an application
accessing window-title, it will fail since window-title doesn't
exist: it is renamed window-_g_sealed__title. But you have not to
know this other name, as you haven't to know window-title: you
should, must, [insert here the strongest word you want] use accessors,
then in window's title case, gtk_window_[set|get]_title().
And in future releases, all private members may become really private,
meaning there will not be any other way than accessors to access
private members.

All this is because the object can't be notified of a modification of
one of it's properties if it is not done by the GObject's mechanism,
or at least an object's function. And if an object is not notified of
a change, it can't do the work it should do when this change happen,
e.g. for the window's title example, update the window's titlebar.
And using only GObject's property mechanism allows a lot of nice
features like use of the notify::property-name signal and so on.

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

iEYEARECAAYFAknjNqsACgkQyqbACDEjVWjMYwCdHJD8iKtgRZmOSE3xqzp3gZJ0
yTAAoLFBSCzgofmkcvxoj/jjIGh3jY6S
=3hOZ
-END PGP SIGNATURE-


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