Re: GTK+, WM, desktops and CSD
On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote: It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD. That would work as well, why not. As long as I can set up my DE to pretend not to support CSD, whatever the actual state is. Because this is, at the end, user's preference. But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create... This is sad. Once your mission becomes creating certain types of experience, instead of enabling them, everything else gets destroyed, whether the types of experience it enables are also good or not. And there does not seem anything capable of stopping the destructive mindset at this moment... Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Missing file in gtk build?
On Fri, Feb 20, 2015 at 09:40:25AM -0500, R. Victor Klassen wrote: I found a version of gtkversion.h elsewhere, but it was quite old. Presumably there should be a gtkversion.h in gtk/include/gtk after the git checkout implicitly run by jhbuild? It's a generated file (from gtk/gtkversion.h.in). You need to build gtk+ (or at least configure it) to get gtkversion.h. I can't comment on jhbuild but it's generally a bad idea to put generated files to a revision control system. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Multithreaded application freezing
On Thu, Feb 05, 2015 at 12:28:02PM -0500, Paul Davis wrote: threads can use all the same mechanisms as processes, but don't have to use OS provided APIs to share address spaces. that's really the only difference. This is false. Threads within one process share much more properties and state. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: a new combo box
On Sat, Dec 27, 2014 at 08:02:44AM -0500, Matthias Clasen wrote: over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png ... I'm off for a few days now - would be great to hear some feedback when I come back. Judging from the mockups, it eats precious vertical screen space and goes against Fitt's law by making it necessary to move the pointer far in order to select even an adjacent value (which, if the values are sanely organised, is a more likely change than selecting a distant value). Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bind GtkTreeView row to some object
On Wed, Nov 26, 2014 at 10:59:01PM +0100, John Tall wrote: I have a GtkTreeView that is used to display some data. Let's say that I have a class that defines a person, and that I have a number of objects representing different persons. I want to display the name of each person in the tree view so I add a row for each person and set the value of the first column to the name of the person. GtkTreeIter iter; GtkListStore *store = ...; gtk_list_store_append (liststore, iter); gtk_list_store_set (liststore, iter, 0, x_person_get_name (person), -1); This works fine. But let's say that I want to select a row in the tree view and show a dialog with more information on the person. So I connect to the row-activated signal and implement the callback. But this is where I need a way to get that person object back. I can't look up the object based on the name of the person, because there can be multiple persons with the same name. Is it possible to bind a row in the tree view, or I guess technically the list store, to my object so that I can figure out which object the row represents? Don't store the name in the list store; instead, put the object there. Use a G_TYPE_POINTER or G_TYPE_OBJECT column (note you need to unref the object after each time you fetch it with gtk_tree_model_get() in the latter case). The name, or any other property, can be rendered using a cell data function set with gtk_tree_view_column_set_cell_data_func(...); The cell data functions fetches the object with gtk_tree_model_get() and sets some properties (e.g. text) of the provided GtkCellRenderer accordingly. For selection, there is then no problem as you again fetch the object directly with gtk_tree_model_get(). This is how most my treeviews work anyway. The direct binding of values in the model to the things displayed in the view is IMO useful only in the simplest cases. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: sprite map issues using gdk_pixbuf_composite()
On Wed, Oct 29, 2014 at 09:11:07PM -0500, Greg Donald wrote: I'm having problems trying to chop sprites out of a sprite map. I can get my first sprite from the top left corner with this: gdk_pixbuf_composite( sprite_src, sprite_buf, 0, 0, sprite_w, sprite_h, 0.0, 0.0, 1.0, 1.0, GDK_INTERP_HYPER, 255 ); But then I cannot get my second sprite that is just to the right of the first one: gdk_pixbuf_composite( sprite_src, sprite_buf2, sprite_w, 0, sprite_w * 2, sprite_h, 0.0, 0.0, 1.0, 1.0, GDK_INTERP_HYPER, 255 ); The first one looks great but I get a black rectangle and a failed assertion on the second one: GdkPixbuf-CRITICAL **: gdk_pixbuf_composite: assertion 'dest_x = 0 dest_x + dest_width = dest-width' failed I have tried everything I can think of. Any idea what I'm doing wrong? You must change offset in the source, not position in the destination. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: glib/gdataset.c (quarky / stringy stuff)
On Mon, Oct 20, 2014 at 10:39:54AM +0100, John Emmas wrote:
Hi guys - please forgive me if this isn't the right mailing list for
glib questions. I'd like to ask a question about a recent change in
'glib/gdataset.c'. Up until a week or so ago, the code around line
1031 looked like this:-
if (strcmp (g_quark_to_string (data-key), key) == 0)
{
res = data-data;
break;
}
Some time in the dim and distant past (to fix a problem which I
can't remember any more) I changed my local copy to look like this:-
if (g_quark_to_string (data-key) != 0) /* This line added by
me !!! */
if (strcmp (g_quark_to_string (data-key), key) == 0)
{
res = data-data;
break;
}
but after an update this morning I noticed that the official code
has recently been changed to this:-
if (g_strcmp0 (g_quark_to_string (data-key), key) == 0)
{
res = data-data;
break;
}
Is that change effectively equivalent to what I did locally?
No. As far as I can tell you can pass NULL key to g_datalist_get_data()
after this change. If you do so and g_quark_to_string(data-key)
returns NULL (for whatever reason), the two NULLs will be considered
equal by g_strcmp0(). Whereas your change makes a NULL not-equal to
everything, even another NULL.
Regards,
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkFileChooserDialog question
Please reply to the list. On Tue, Sep 16, 2014 at 12:47:26AM -0700, Igor Korot wrote: Yes, you need to right-click in the file list. Unfortunately, the discoverability of Gtk+ file dialog features is poor. And there is no such option on the dialog itself? You need to right-click in the file list *in the dialog itself*. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Custom Titlebar
On Mon, Aug 11, 2014 at 11:28:34PM +0200, Florian Müllner wrote: That is not quite true - since GTK 3.10, there's gtk_window_set_titlebar (GTK_WINDOW (window), titlebar_widget); Unless you are running someting like Gnome 3(?), this will add a strangely looking thing to the top of your window, but inside. It will not change the title bar which is controlled by the window manager. I've never seen it actually do what is advertised. Admittely, I didn't test it much because I consider it broken by intent (not even getting to broken by design). Yeti ___ 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 connect focus-out-event of a grid?
On Wed, Jul 16, 2014 at 11:49:52AM +0800, Gang Chen wrote: A grid contains an entry and several buttons. I connected my callback function to focus-out-event of the grid. But no focus-out-event was received even if I called gtk_widget_add_events(grid, GDK_FOCUS_CHANGE_MASK). I tried to put the grid in an event box and connected the callback to focus-out-event of the event box. Still no focus-out-event was received. Could anybody please help me? focus-out-event is emitted when a widget that can take keyboard focus loses the focus. It makes no sense for containers to have keyboard focus because they do not take input from keyboard. A particular input widget inside the container should have the focus. You can make an event box to take keyboard focus using gtk_widget_set_can_focus() but this is useless. It will prevent the user from tabbing to the child widgets of the event box. Instead he will be able to tab to the event box which will look to him like mysteriously losing focus because the event box is not an input widget. So just connect to signals of the actual input widgets. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to connect focus-out-event of a grid?
On Wed, Jul 16, 2014 at 05:30:28PM +0800, Gang Chen wrote: Thank you. The purpose is when the focus is moved out of the container, ‘Focus is moved out of the container’ has IMO meaningful interpretation only as ‘focus is moved outside any of the focusable widgets in the container’. This seems like playing with words but it is important to think about the problem in well-defined terms. I'll destroy the container and its child widgets. How can I achieve this? By connecting to set-focus of the parent window and tracking the focus and tracking when the top-level window loses focus. Note the focus may be also set to no-widget during the tabbing wraparound. But usually when something should be destroed when it loses focus (various search boxes and menus, etc.) it is a transient GdkWindow and you also want to destroy it when the user switches to another toplevel window. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Segmentation fault in creating basic app using GTK+ (with C)
On Tue, Jul 01, 2014 at 01:39:03AM -0700, Anoop Neem wrote: p-one = textEntry; p-two = label; Here the unititialised textEntry and label pointers are assigned to the struct fields. textEntry = gtk_entry_new(); calButton = gtk_button_new_with_label(Calculate); And here, much laters, they are actually initialised. Regards, Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: UTF-8 error in GtkTextView while decoding base64
On Mon, Apr 14, 2014 at 02:22:00PM -0400, a wrote: const Glib::ustring str = Glib::Base64::decode(YmJi3A==); YmJi3A== represents the four bytes 0x62 0x62 0x62 0xdc. This is not valid UTF-8. So, you get an assertion error because you must pass valid UTF-8 to essentially all Gtk+ function. If you take untrusted strings use g_utf8_validate() to validate them and reject those that do not pass. So my question is how can I get Gtk::TextView to display the decoded base64? This is nonsensical question. Base64 does not have anything to do with it. Your text is the sequence of four bytes above and it is invalid. Why it is invalid? Hard to tell. Base64 is just a change of representation of the same invalid sequence of bytes. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib hash table - unkown key in table
On Sun, Mar 23, 2014 at 07:09:41PM +0100, Ervin Hegedüs wrote:
int utype_inc(char udatakey[15], int udata) {
...
g_hash_table_insert(datastore, udatakey, utype_rec_udatas);
This is certainly wrong. The string key must exist during the lifetime
of the hash table, so stack storage won't do it. You need to allocate
the string on the heap (or use GStringChunk, quarks or whatever). Using
g_hash_table_new_full() and passing a free-function can take care of
clean up when the table is destroyed.
Regards,
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: How ot remove the minimize and maximize button of GtkWindow
On Fri, Feb 21, 2014 at 03:29:07PM +0800, Wiky wrote: The default GtkWindow has a minimize , a maximize and a close button in the right or left top coner. But I want a window which only has a close button. How can I remove the minimize and maximize button? You can't. In my window manager the windows may have a completely different set of buttons. Or no title bar at all. Or whatever. And the window manager has the last word. You can override the decoration-button-layout style property, but you need 3.10+ and it will only work in something like GNOME 3 anyway. The meaningful thing you can do is setting the window type hint with gdk_window_get_type_hint() (and possibly other hints) to specify what the window *is* instead, and let the window manager treat it appropriately and consistently with other widows with the same role. Yeti ___ 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 locate the 'Gtk-WARNING' line number
On Mon, Feb 17, 2014 at 04:44:53PM +0800, Wiky wrote: Hi,all. I'm currently writing a program based Gtk+-3.0. When it runs, I get '(a.out:10874): Gtk-WARNING **: Failed to ...' in the terminal. I know the problem is about GtkLabel, but I really don't know which GtkLabel. Is there a way to locate the line numer that give the warning? Run it with G_DEBUG=fatal-warnings, let it dump core and look at the stack trace. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Populating A Combo Box With Integers In Hex
On Sat, Dec 07, 2013 at 05:54:23PM +, Tristian Celestin wrote:
I have a GtkListStore that contains 4 columns of unsigned integers
(G_TYPE_UINT). I would like to display the second column of integers
in a GtkComboBoxText widget, and I would like the integers to be
displayed in Base 12.
I would stop here and use normal GtkComboBox with a cell data function
(gtk_cell_layout_set_cell_data_func()) such as
static void
render_base12(GtkTreeViewColumn *column,
GtkCellRenderer *renderer,
GtkTreeModel *model,
GtkTreeIter *iter,
gpointer data)
{
guint value;
gtk_tree_model_get(model, iter, 1, value, -1);
/* format the value here in base 12 */
g_object_set(renderer, text, formatted_value, NULL);
}
It may be possible to do this with GtkComboBoxText too. I don't know.
If I want something non-default I just use the real thing instead of
studying what is and what isn't allowed with GtkComboBoxText.
Regards,
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind is grinding my gears
On Tue, Nov 05, 2013 at 09:47:13AM -0800, David Buchan wrote: But when I invoke Valgrind at runtime, I get a lot of errors which I can't make any sense of. I have grabbed a small sample of them here: http://pdbuchan.com/valgrind.txt I don't like ignoring errors and warnings, but I don't know what to do with these. Has anybody else come across these types of Valgrind notifications? Yes, everyone. You must understand that all the GObject type registration machinery is, under normal circumstances, only ever used to create structures that will exist during the entire program lifetime. So although things such as class reference leaks can exists, eveything inside g_type_class_ref() should be ignorable – and you can clearly see from the log that these allocations happen once, not a thousand times. The same for g_thread_init(), gtk_init(), etc. Create a suppression file or google one... Regards, Yeti ___ 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
On Mon, Oct 28, 2013 at 04:22:38PM +0100, Borja Mon Serrano wrote: The point here is: how can I know what button was pressed in order to remove a row? (a) by passing something that identifies the button within user_data when you do g_signal_connect... (b) using something along the lines of g_object_set_data(button, id, ...) to give each button an identifier and retrieving it in the signal handler (c) by keeping the buttons in some data structure (list, hash table,...) and identifying them by the object address in the signal handler There are other methods, but these are probably typical. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: disable mouse click
On Thu, Oct 17, 2013 at 09:10:30AM +, Andrea Zagli wrote: i want to disable mouse click on every widget of a window when i change the cursor to GDK_WATCH gtk_widget_set_sensitive(window, FALSE); Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Delaying redraws?
On Sat, Oct 05, 2013 at 08:18:58PM -0400, Rena wrote: I have a window with a large number of GtkEntry and GtkCheckButton displaying stats, ‘Displaying stats’ sounds a bit suspicious because entry and check button are input widgets. Is it possible to speed this up, maybe by asking GTK not to redraw the widgets until I'm done updating them all? Anyway, this is what happens normally. When you change the widget state/content a redraw is queued. The redraws are then processed when the Gtk+ main loops gets to run. Regards, Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Developing a widget - help with introspection and feedback
On Tue, Oct 01, 2013 at 09:08:12PM -0400, Rena wrote: Hi all, I'm developing my first GTK widget. I have it working OK, but I can't get g-ir-scanner to cooperate. Since you don't use libtool to build the library (which I strongly recommend against but it's your fight) pass --no-libtool to g-ir-scanner. It seems to work then. Regards, Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk Text View Question
On Sun, Sep 29, 2013 at 11:22:12AM -0700, Thomas Dineen wrote: The following symbol seems to be missing or deprecated form the Gtk+-2.0 library. I suppose you mean Gtk+ 2.x in general, not exactly version 2.0. gtk_text_view_get_vadjustment The symbol is present in both Gtk+ 2.x and 3.x. It is deprecated *only* in 3.x where it is superseded by a method of the GtkScrollable interface. Can you please post a simple example of Gtk Text View with scrollbar that will compile in Gtk+-2.0. Your own example compiles fine with gcc -Wall -o example example.c $(pkg-config --cflags --libs gtk+-2.0) Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Invisible GtkImage
On Sat, 22 Jun 2013 15:30:34 -0700, Kip Warner wrote: 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. So how exactly does the behaviour of my simple example differ from what you want? The widget fills the allocated space and the image scales, keeping the aspect ratio. Yeti ___ 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
On Sun, Jun 23, 2013 at 11:05:00AM -0700, Kip Warner wrote: When the parent window is resized, I'd like the image to scale to fill the allocated space as much as possible, maintaining the aspect ratio. My code draws the image correctly, but it doesn't resize as the parent window is resized: http://pastebin.com/6LEzFk8A Well, as it has already been suggested, this is a matter of packing. If you request that the widget does not expand page.pack_start(page._bannerAspectFrame, False, False, 0) then the containing box will not expand the widget when it is enlarged itself. You have to pass expand=True, fill=True. Yeti ___ 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
On Sat, Jun 22, 2013 at 01:09:17PM -0700, Kip Warner wrote:
I can't believe resizing a widget in Gtk+ is this difficult.
Frankly, I don't quite understand what you are trying to achieve since
you have never posted anything runnable and your examples have never
included any actual drawing code. Anyway, it is trivial to create a
scaleable widget (whether it draws an image or anything else):
---
from gi.repository import Gtk, GdkPixbuf, Gdk
class ScalableImage(Gtk.DrawingArea):
def __init__(self, filename):
super(ScalableImage, self).__init__()
self.pb = GdkPixbuf.Pixbuf.new_from_file(filename)
def do_get_preferred_width(self):
pw = self.pb.get_width()
return (pw, pw)
def do_get_preferred_height(self):
ph = self.pb.get_height()
return (ph, ph)
def do_draw(self, cr):
alloc = self.get_allocation()
pw, ph = self.pb.get_width(), self.pb.get_height()
aw, ah = float(alloc.width), float(alloc.height)
r = min(aw/pw, ah/ph)
cr.scale(r, r)
Gdk.cairo_set_source_pixbuf(cr, self.pb, 0.0, 0.0)
cr.paint()
return False
w = Gtk.Window(Gtk.WindowType.TOPLEVEL)
w.connect('destroy', Gtk.main_quit)
b = Gtk.Box(orientation=Gtk.Orientation.VERTICAL)
w.add(b)
b.pack_start(Gtk.Label(label='Test'), False, False, 0)
d = ScalableImage('/usr/share/icons/HighContrast/48x48/stock/gtk-ok.png')
b.pack_start(d, True, True, 0)
b.pack_start(Gtk.Label(label='Somewhat longer test'), False, False, 0)
w.show_all()
Gtk.main()
---
This might not be exactly what you need but as I noted I don't get where
the problem is...
If you need your widget to be a GtkImage subclass things will likely
turn hairy because GtkImage is not scaleable, all its methods think it
is not scaleable so you will end up fighting the implementation of the
widget.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can I install both GTK+2 and GTK+3?
On Fri, May 17, 2013 at 11:40:10AM +0100, Emmanuele Bassi wrote: it's maintained only for critical bugs, or for platform support; no new feature, and no new API is *ever* going in to the gtk-2-24 branch. And that's what many 3rd party developers like. Absolutely no changes except critical bug and platform support fixes. All the small bugs and peculiarities are known, are not replaced with a different set of small bugs and peculiarities in the next release and we've learned how to work around them. Actually, I do target Gtk+3 with a program which has a number of its own widgets. And I'm constantly anxious and wondering whether it was a good decision... Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Compile Pango1.32.6 on micro itron
On Wed, May 01, 2013 at 02:37:56PM -0400, Jasper St. Pierre wrote: config.h is generated by automake. Actually, config.h is generated by running ./configure. You will need to use autoconf / automake No, you will not need them for normal compilation from tarballs. The GNU build system is constructed precisely with that goal that such special tools are only needed on the developer's system, *not* on the target system where you compile the programs or libraries. On Mon, Apr 29, 2013 at 11:41 PM, Phyllis yihsun...@gmail.com wrote: And because compile environmet setting, I should build it without using Makefile.in and Makefile.am. What exactly prevents you from running configure? You don't have anything like a POSIX shell there and can't have anything like that there? So I put all *.c and *.h of Pango source code into a folder and compile them with gcc. This approach might go smoothly for hello-world. But the build process of most packages is much more complex. If you want to replicate it you must study very carefully what the original Makefiles do. Where is this config.h? which one I should include? config.h is generated by configure from config.h.in and contains all kinds of information gathered about the system. You have to fill the information manually. It is likely you will need handle similarly a number of other files. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: gdk_cairo_get_clip_rectangle and DrawingArea in ScrollableWindow
On Sat, Mar 30, 2013 at 11:22:29PM +0100, pec...@gmail.com wrote: I have simple scrollable window, which has DrawingArea within it. So before I draw anything, I take gdk_cairo_get_clip_rectangle, as I want to get width of actually visible area. Then I use it to do drawing to surface and then applying it to cairo context. However, there's problem. When windows open first I get proper value of returned area from gdk_cairo_get_clip_rectangle. However when I do a scrolling, it starts to return ten times smaller width, t.i. at the size of scrolling step. And every time I scroll it keeps getting this ten times smaller width than initial value. What's more interesting, when windows lose focus or gets resized, it gets correct width. I tried to isolate code and tried not to draw anything on DrawingArea - it still returned smaller values. What did I miss, what's could be wrong in this case? Probably nothing is wrong. You get the rectangle that you actually need to draw, i.e. the newly uncovered area. The rest does not need to be redrawn. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: parsing bibtex using gscanner
On Mon, Feb 18, 2013 at 05:15:56PM +, Rudra Banerjee wrote:
I am trying to parse a bibtex file using gscanner.
The problem is that, due to many formats accepted by bibtex, it seems
bit hard to parse it.
What I mean is as long as the bibtex is of the form key=some value,
then g_scanner_get_next_token can get the string.
But it fails if it is in the format key={value}.
And it fails even before escaping literal TeX code using braces within
entries or string macros have come to play...
I am attaching my code. Some help (outside using btparse/ bison )is
needed.
Don't do it this way. GScanner is a lexical scanner, it just tokenizes
the input but it does not help with grammar.
The best approach to parse a grammar is, you know, using a parser.
If you insist on writing one manually realise that you need to formally
keep state, eg. the nesting level of braces at which you are now, etc.
Construct the parser similarly you would if you did if you just wrote
the BNF and let the parser be generared, e.g. write subroutines to parse
balanced braces, string, etc. possibly recusrively calling each other.
Attempting to write code for all the cases that can occur using
sequences of hardcoded ifs will only result in buggy mess. You have
been warned.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkhruler in gtk3
On Sun, Feb 17, 2013 at 11:37:28PM +0900, Tristan Van Berkom wrote: If you take the ruler widget code from GTK+2, you should be able to very easily use it compiling against GTK+3... You'll need to change -expose_event() and -size_request() appropriately (for ruler code, you should only need to implement -get_preferred_width()/-get_preferred_height() since there's no complex height-for-width stuff to do in there). Perhaps, if you port the widget (as I mentioned it should be quite easy), we could then add the ported version to libegg, where people (if any) need it they can easily copy it into their sources. I forked GtkRuler a long time ago because I needed stuff such as different units, scientific number format, etc. I have a Gtk+3 version now (not much theming support), you can see how it looks here http://gwyddion.net/gwyddion-3/libgwyui/GwyRuler.html and the code is https://sourceforge.net/p/gwyddion/code/HEAD/tree/branches/GWYDDION-3/libgwyui/ruler.c but it's much more dependent on other Gwyddion stuff than GwyScroller I linked couple of days ago so it's probably difficult to reuse. Concerining the requirement to implement GtkOrientalble, that's mostly frameworkish rubbish. Rulers can be placed on *four* possible sides of some area. So they have up/down/left/right looks and orientations, not two. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Difference between Gtk2 and Gtk3 output
On Sat, Feb 16, 2013 at 10:04:31PM +0900, Tristan Van Berkom wrote: Unfortunately there is no feature that let's you hide the scrollbars of a GtkScrolledWindow I created a simple scrollbarless widget: https://sourceforge.net/p/gwyddion/code/HEAD/tree/branches/GWYDDION-3/libgwyui/scroller.c The point is not just that you may want to hide the scrollbars, you may also want the scrolling controls elsewhere, represented by different range-type widgets, etc. GtkScrolledWindow is relatively complex but essentially all the complexity is related to placing scrollbars inside the widget area. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On Mon, Feb 04, 2013 at 04:44:02PM +0900, Tristan Van Berkom wrote: On Mon, Feb 4, 2013 at 11:39 AM, Simon Feltman s.felt...@gmail.com wrote: [...] However, it also adds a leak for the most basic (and useless) case: for i in range(10): Gtk.Button() This could arguably trigger a compiler warning, or even an error. This is nonsense. Since Gtk.Button() is not guaranteed *not* to have any side effects it is perfectly valid to run it without doing anything with the return value. In fact, since we talk about a dynamic language, the interpreter does not know, in general, what Gtk.Button will mean at the time the code is actually executed. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK app development for windows.
On Thu, Jan 31, 2013 at 12:32:48AM +0700, Ardhan Madras wrote: One thing you should know that most version of GTK+ in today Linux system is using version 3.x. This is somewhat inaccurate. All major Linux distributions contain Gtk+3 packages and the number of Gtk+3 programs grows. But if you look outside core Gnome3, at third-party programs, the number of Gtk+2 programs is huge. Some will be never ported. After all, even though they are quite rare nowadays, some Gtk+1 programs still have not been ported to Gtk+2... I recommended you to use also GTK+ 2 in Linux, and you can build it with no or less efforts in Windows compared if you use GTK+ 3 in Linux but build it with GTK+ 2 in Windows. For new projects, I would not recommend using Gtk+2 unless you are quite conservative or it is a small project using only stock widgets (in such case porting to Gtk+3 will not be a big deal). For larger projects, it is more likely that Gtk+3 will be fine on MS Windows and Gtk+2 obsolete everywhere when you get to releasing a stable version... Yeti ___ 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
On Fri, Jan 25, 2013 at 04:25:53PM -0500, Liam R E Quin wrote: That it's easier for the programmers to create and read application-specific binary files is a problem that would be worth fixing. Probably you mean replacing it with the problem of application-specific hodge podge XML... I have implemented the import of ~80 data formats of varying complexity and style to one program. I have seen both utterly mad binary formats and binary formats that were well thought out and pleasure to implement. But XML was crap quite invariably. It appears to be used as an excuse for not thinking about data representation at all. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: edit and use treeview cell
On Thu, Jan 24, 2013 at 09:41:20AM +, Rudra Banerjee wrote: g_object_set(cell, editable, TRUE, NULL); but I have no idea of how to connect the edited flag to file/buffer. It will be very helpful if someone kindly show the way...a very short example may be. Have you read the tutorial? http://scentric.net/tutorial/sec-editable-cells.html Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
On Wed, Jan 23, 2013 at 10:41:54AM -0600, Edscott Wilson wrote: I conclude this is a gtk memory leak. It occurs when calling gtk_combo_box_new_with_entry(), Apparently, when the dialog that contains the combo box is destroyed, the GList visible_children in file gtkcombobox.c is not being cleansed of the pointer to the child widget, entry. The leak does not occur if plain gtk_combo_box_new() is used instead. Correct me if I'm wrong. Whether gtk_combo_box_get_path_for_child() can be called with a visible child different from those enumerated there (the only way a leak can occur) I cannot tell. In any case, any suspected leak that goes through GSlice should be first reproduced with G_SLICE=always-malloc -- and you find it real, a bug report is much better than suppression... Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib-mkenums in glib 2
On Mon, Dec 31, 2012 at 05:24:09PM +, John Emmas wrote: which should either be in gio/gioenums.h or alternatively, gio/gregistrysettingbackend.h. It's the absence of this enum that's causing 'g_registry_backend_get_type()' to not get auto-generated when glib-mkenums gets processed. This all goes to a strange direction. First, GRegistryBackend is not an enum, it is a subclass of GSettingsBackend. glib-mkenums will not generated g_registry_backend_get_type() for you. The get-type function g_registry_backend_get_type() is provied by gio/gregistrysettingsbackend.c. Which is built only on MS Windows (using the standard Makefiles, see the if OS_WIN32 condition there). So might it be that you do not compile it into gio? Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Sat, Dec 29, 2012 at 07:13:56AM +, John Emmas wrote: 2) Along a similar vein, it looks like I need to process the module 'gio/gdbus-2.0/codegen/gdbus-codegen.in' but I don't know what program / script I need for processing it. Anything ending with .in is usually processed by configure (config.status) which you obviously don't have so you must replace @VARIABLE@s with the corresponding values using whatever you have. But the only two variables present there are unused on MS Windows anyway – MS Windows neither recognise shbangs nor is the fixed datadir code path useful there. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject Destruction
On Wed, 19 Dec 2012 18:55:40 +0100, Nicola Fontana n...@entidi.it wrote: By exposing only dispose() and internalizing finalization in libgobject. How can you do this without one of the following: (a) Requiring that objects must not have any data, even internal, that cannot be NULL[*] during the object lifetime. I.e. all data would require the NULL protection, even those that do not require it in the current scheme. (b) Teaching GObject how to free the internal data of your object. But wait, there is already a method that lets GObject do this: it is called finalize(). [*] Or, in general, unset in some other manner. We are saying the same thing: if a dynamic string is protected against NULL throughout your code (no special protection intended here), freeing and nullifying it in dispose() or freeing in finalize() gives the same final result. Yes, here we are saying the same thing. Where we differ, is that you seem to propose that all member data should be like this. In many cases, internal data can be assumed to just exist in all public methods *and* during the reference-cycle breaking stage. So no NULL protection is necessary, they are just plainly freed in finalize(). Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject Destruction
On Mon, Dec 24, 2012 at 06:22:02PM -0200, Ian Liu Rodrigues wrote: I was wondering if this GObject destruction scheme allows destroying an object in a callback for a signal of itself. Yes and no. You can do this g_signal_connect(object, signal, G_CALLBACK(g_object_unref), NULL); and it will unref the object when the signal is emitted. However, an object cannot just go poof! during the signal emission (so, no destruction *in* the callback). Before the actual emission starts a reference is taken within GLib; after it is done the reference is released. A signal handler such as above can thus cause that at this moment, i.e. after all handlers are run, the reference count drops to zero and the object is destroyed. Subsequent handlers can be prevented from running with g_signal_stop_emission() if necessary. I hope this is sufficient. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: one function to go...
On Sun, Dec 23, 2012 at 02:35:31PM -0800, Gary Kline wrote: in this popup dialog I would have a few words that the file does not exist and want a button WITH the Enter-key icon that gives an iconic clue that all the user need do is hit the enter key. I suppose if the users could, if they wished, mouse-click on the button. I cannot speak for your target audience but according to my experience (a) if people see a message box with a single button (probably with some visual clue that it has focus) they will just press Enter or Esc to make it go away, or (b) if people see a button they will always use the pointer to click on the button no matter what other, possibly much simpler, means may be available to activate it. This is a strict division with little between. There is no way to migrate people from (b) to (a), you can try for years with no effect. So targetting those between you may find you are targetting a group of size zero. Just my 2 eurocents... Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Focus vs Sensitivity
On Fri, Dec 21, 2012 at 07:16:07PM -0200, Ivan Baldo wrote:
What happens is that the Tab handler runs before the value-changed
handler
This is the wrong view what happens. The adjustment value is not
updated during user's editing of the entry. If the spin button is not
set to numeric its entry can contain any text during the editing
(whereas setting numeric ensures the entry contents always parses as a
number, making impossible to enter numbers in the scientific format, for
instance). The value is updated when editing finishes, for which one
possibility is that the entry loses focus. So *first* the focus leaves
the entry then *in consequence* the adjustment value is updated.
However, this does not seem to be entirely the core of your problem.
The CRITICAL errors are printed becuase in gtk_window_real_set_focus()
this:
if (priv-has_focus)
do_focus_change (priv-focus_widget, TRUE);
g_object_notify (G_OBJECT (priv-focus_widget), is-focus);
assumes that do_focus_change() cannot make priv-focus_widget become
NULL. IMO there may be sane use cases when this can occur (like yours)
so I would try to report a bug.
How to work around it? Instead of connecting to value-changed monitor
all changes to the entry text:
g_signal_connect(spin_button, changed, G_CALLBACK(spin_entry_changed),
spin_button2);
...
static void
spin_entry_changed(GtkEntry *entry, GtkWidget *target)
{
gtk_widget_set_sensitive(target, g_strtod(gtk_entry_get_text(entry),
NULL) != 0);
}
This will *also* make the second entry insensitive when the content of
the first does not parse as a number at all (which is likely a good
thing though perhaps not).
Regards,
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GObject Destruction
On Tue, Dec 18, 2012 at 08:45:42PM +0100, Nicola Fontana wrote: I always wondered if this double step finalization is hystorical craft. Why not drop finalize() altogether and avoid double dispose calls directly from libgobject? The purpose of dispose() is to break reference cycles, i.e. to ensure the object stops holding references to other objects. You can free other stuff there if it does not cause troubles but that is not the purpose. While you are breaking reference cycles all the object involved must still be alive. I'm not sure whether multiple executions of dipose() can occur in a single-threaded program (see the source if you can understand). But how would break reference cycles when, for instance, a GtkWindow is destroyed in a single-step finalisation method? (Disclaimer: I'm not a GLib developer neither I can read the mind of any.) You'd need to protect your code from NULLs But I don't need to, that is the point (or, almost never need). In my obects I find that, normally, members unreferenced and nullified in dispose() are those that can be NULL anyway so there is no special protection against NULL related only to destruction. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject Destruction
On Tue, Dec 18, 2012 at 05:37:08PM -0500, Jasper St. Pierre wrote: The call for freeing a block of memory is free(void *data); And the call for freeing a GSlice-allocated block of memory is void g_slice_free1(gsize block_size, gpointer mem_block); And the call for freeing a memory-mapped region is int munmap(void *addr, size_t length); I missed the start of the thread and can't comment on that, but freeing memory may require all kinds of knowledge. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: [Newbie] When to use *_IS_* macro?
On Wed, Dec 12, 2012 at 02:09:09PM +0100, Guilhem Bonnefille wrote: My understanding is these macro allow safe down-casting. They are meant both for up-casting and down-casting and also casting to interfaces (whatever you call that). They do two things: 1) type-cast pointer to one C struct to pointer to another C struct 2) (if not disabled with G_DISABLE_CAST_CHECKS) check that this typecast is valid in the GLib type system In the other hand, GTK_IS_DIAL seems not necessary in gtk_dial_get_adjustment as C compiler will ensure (gruik cast excepted) that argument is in the right type. The C compiler will not ensure anything because it cannot. In C, all the different GLib types are just pointers and can be typecast freely to each other (possibly with a warning if the types do not match exactly). The C compiler does not know that GLib implemented some class hierarchy using plain C structures; it has no notion of up-casting or down-casting or whatever, it just sees pointers to different structs. That's not sufficient for any type check with respect to the GLib type system. So, the user can pass whatever pointer to gtk_dial_get_adjustment() and if you want to offer some sanity checking for people using gtk_dial_get_adjustment() you use GTK_IS_DIAL(). You can make assumptions about the GLib type in your internal functions because you know (hopefully) what arguments they receive. Can I consider to remove *_IS_* in codes like gtk_dial_get_adjustment or is it a best practice to always call such macro? You can, of course, remove it if you do not want to offer the sanity check. It is a best practice to always call it. This is not a contradiction. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkCheckMenuItem needs double click?
On Sun, Dec 09, 2012 at 12:57:43AM +1300, Perdie Perduta wrote: Using glade with GtkBuilder to create my application GUI. I'm developing testing on Windows 7 using Microsoft C++. Trying to add a record button to my menu bar. Note: Ideally I would have liked a nice red record button that lights up while my application is recording, however just to get it working I put in GtkCheckMenuItem. It is all working but inexplicably I have to click my GtkCheckMenuItem *twice* to for each toggle. Is this a known common mistake? Any advice or reference to previous thread on the subject would be appreciated. Adding *buttons* to *menubars* is certainly very odd. It may be that to activate the button the menu item must get focus first, hence the two clicks. My advice is to use a toolbar instead. It seems to fit what you are trying to do better and you can have tool items that act like plain buttons, toggles, radio button, that pop up menus, etc. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Fri, Dec 07, 2012 at 05:53:57AM -0500, Matthias Clasen wrote: See https://bugzilla.gnome.org/show_bug.cgi?id=679683 g_test_trap_fork is just a bad idea, doubly so with threads (and every glib program is using threads nowadays)a Thanks, somehow, I missed that bug. Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Fri, Dec 07, 2012 at 08:44:01PM +, Chris Vine wrote: ... So for your scheme to work, the parent before forking must be single threaded. As I have learnt the hard way, this is not something I can ensure even the program does not use any multi-threading itself because libraries may. Even apparently very innocent programs can exhibit weird threading-related bugs. And while it is a sort of gray area, starting to use threads internally is rarely considered an ABI breakage. So, unfortunately, the conditions you listed can be reduced to ‘it will never work’ in practice. Anyway, I do not attempt to do this kind of fork not-exec in real Gtk+ applications. So I'm looking forward to a better solution for unit tests which is discussed in the bugzilla bug mentioned by Matthias. Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Forks, slices and threads: Can you make GSlice deadlock?
Hello, can g_slice_alloc() be made to deadlock simply by some bad sequence of GLib function calls, considering the calling program does not, of course, hold any GLib lock explicitly? (Without a GLib bug, that is.) I am starting to suspect a problem in GSlice interaction with threads. But I cannot report anything to bugzilla because I am unable to get to the core of the problem. My program (test program for a library) does g_test_trap_fork() and the child creates worker threads with g_thread_new(), sends them tasks with GAsyncQueue and cancels the tasks using GCancellables. Occasionally, a seemingly innocent g_thread_new() call deadlocks in g_slice_alloc(), see the backtrace below for how and where exactly. If it happens, it happens in the child soon after forking. I canNOT reproduce any deadlock if: - G_SLICE=always-malloc is set, - g_test_trap_fork() is not used and the test is run directly in the main program, - under valgrind (also, it reports no errors), - I print anything to stderr in g_slice_alloc() – infuriating, but so it works. When it deadlocks the main thread looks: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x003451009c8c in _L_lock_1024 () from /lib64/libpthread.so.0 #2 0x003451009c35 in __pthread_mutex_lock (mutex=0x25442e0) at pthread_mutex_lock.c:105 #3 0x7fe496b01fb6 in g_mutex_lock (mutex=0x7fe496d9f8e0) at gthread-posix.c:208 #4 0x7fe496adef29 in magazine_cache_pop_magazine (ix=4, countp=0x2544368) at gslice.c:718 #5 0x7fe496adf235 in thread_memory_magazine1_reload (tmem=0x2544310, ix=4) at gslice.c:794 #6 0x7fe496adf4df in g_slice_alloc (mem_size=72) at gslice.c:992 #7 0x7fe496adf572 in g_slice_alloc0 (mem_size=72) at gslice.c:1032 #8 0x7fe496b02981 in g_system_thread_new (thread_func=0x7fe496ae8fc9 g_thread_proxy, stack_size=0, error=0x7fffb1ded5a0) at gthread-posix.c:1101 #9 0x7fe496ae9207 in g_thread_new_internal (name=0x491da9 canceller, proxy=0x7fe496ae8fc9 g_thread_proxy, func=0x461790 cancel_cancel, data=0x25822f0, stack_size=0, error=0x7fffb1ded5a0) at gthread.c:884 #10 0x7fe496ae90d5 in g_thread_new (name=0x491da9 canceller, func=0x461790 cancel_cancel, data=0x25822f0) at gthread.c:835 #11 0x00461667 in master_cancel_one (nproc=1) at master.c:232 #12 master_cancel_one (nproc=1) at master.c:208 #13 0x7fe496ae792d in test_case_run (tc=0x2555c90) at gtestutils.c:1679 #14 g_test_run_suite_internal (suite=suite@entry=0x2557c80, path=optimized out, path@entry=0x7fe496b5c2be ) at gtestutils.c:1732 #15 0x7fe496ae7aa6 in g_test_run_suite_internal (suite=suite@entry=0x2557c60, path=optimized out, path@entry=0x7fe496b5c2be ) at gtestutils.c:1743 #16 0x7fe496ae7aa6 in g_test_run_suite_internal (suite=suite@entry=0x2557c40, path=optimized out, path@entry=0x7fffb1deef4d /master) at gtestutils.c:1743 #17 0x7fe496ae7aa6 in g_test_run_suite_internal (suite=suite@entry=0x2545c20, path=optimized out, path@entry=0x7fffb1deef43 testlibgwy/master) at gtestutils.c:1743 #18 0x7fe496ae7e0b in g_test_run_suite (suite=0x2545c20) at gtestutils.c:1788 #19 0x7fe496ae7e55 in g_test_run () at gtestutils.c:1308 #20 0x00412e11 in main (argc=1, argv=0x7fffb1dedae8) at testlibgwy.c:88 There is also a worker thread waiting on my own GConf with my own lock at the moment: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:166 #1 0x7fe496b02575 in g_cond_wait (cond=0x258b5a8, mutex=0x258b5a0) at gthread-posix.c:746 #2 0x7fe496a9b09b in g_async_queue_pop_intern_unlocked (queue=queue@entry=0x258b5a0, wait=wait@entry=1, end_time=end_time@entry=-1) at gasyncqueue.c:421 #3 0x7fe496a9b546 in g_async_queue_pop (queue=queue@entry=0x258b5a0) at gasyncqueue.c:455 #4 0x7fe4973b60e3 in worker_thread_main (thread_data=optimized out) at master.c:190 #5 0x7fe496ae9082 in g_thread_proxy (data=0x258e850) at gthread.c:797 #6 0x003451007d14 in start_thread (arg=0x7fe49534c700) at pthread_create.c:309 #7 0x0034508f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 and several threads are in the following state: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x003451009c8c in _L_lock_1024 () from /lib64/libpthread.so.0 #2 0x003451009c35 in __pthread_mutex_lock (mutex=0x25442e0) at pthread_mutex_lock.c:105 #3 0x7fe496b01fb6 in g_mutex_lock (mutex=0x7fe496d9f8e0) at gthread-posix.c:208 #4 0x7fe496adf163 in private_thread_memory_cleanup (data=0x7fe4740008c0) at gslice.c:774 #5 0x003451007b12 in __nptl_deallocate_tsd () at pthread_create.c:157 #6 0x003451007d22 in start_thread (arg=0x7fe495b4d700) at pthread_create.c:316 #7 0x0034508f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 That's all the threads. So, they are all trying to lock allocator-slab_mutex in
Re: GTK Question
On Thu, Dec 06, 2012 at 11:42:41AM -0800, Thomas Dineen wrote: 1) My implementation runs as expected on the native Solaris platform and the native Windows platforms, BUT when I run it on the native Fedora platform the application opens with giant buttons which are totally distorted! The implementation is built from the GTK toolkit functions taken from your webpage tutorials. If gtk-demo and other Gtk+ programs show similarly giant buttons, something is wrong with your display DPI settings, theme settings, ... If it does not then your program does something differently than normal programs. It is difficult to say what exactly. 2) When I rlogin to Fedora I sincerely hope you meant to write ‘when I ssh -X to Fedora’. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Resolving cross-references among components
On Sun, Nov 18, 2012 at 09:44:27PM +0100, Stefan Sauer wrote: I can't add anything here. Do you have a case where this happens? It should happen everywhere. For instance, Gdk references Gtk+ symbols dozens of times. Why almost no one observes it? Most of the time if you build Gtk+, even from a fresh checkout, you already have *some* Gtk+ installed. So gtkdoc-fixxref takes index.sgml from the system directory. Occasionally, you miss a couple of new symbols, but who notices it... I run into this during nightly builds of Gwyddion (too complex to serve as a clear example) that are done in a relatively clean environment. Certainly it is not installed anywhere where it could be picked up during the build. It would suffice to split the fixxref stage off the normal HTML building stange and run it once that is done in all subdirectories. But this is not possible within gtk-doc.make, it requires the introduction of some HTML-has-been-built stamp on the package level (or at least inside some docs subdirectory). Yeti ___ gtk-doc-list mailing list gtk-doc-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-doc-list
Re: Lack of gtk_application_get_window_by_id function despite of documentation
On Sun, Nov 18, 2012 at 12:05:51AM +0100, Jakub Kucharski wrote: Can you tell me what's wrong? The documentation for gtk_application_get_window_by_id says ‘Since: 3.6’. Sid has Gtk+ 3.4. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Bug 687752 - work with theme authors
On Sun, Nov 11, 2012 at 05:17:56PM +, Benjamin Otte wrote: The first conclusion from that is that it is (and has been for a few years) a bit disingenuous if people say we're not using GNOME, we're just using GTK. But that is exactly what I say – as a third-party program developer and someone who occasionally contributes patches to GLib or Gtk+. Should I sort the target environments of ‘my’ programs by user count, it would likely look like - MS Windows - OS X - anything else Should I list the environments the developers of ‘my’ programs use it would likely be - XFce - KDE - anything else Yes, what is obviously missing in both lists is GNOME. The good thing about Gtk+ used to be that it was truly cross-platform, *NOT* a GNOME-only thing. Where this all gets interesting is the transition in mentality and behavior (for lack of a bettter word) of the GNOME development community in the transition from GNOME 2 to GNOME 3. GNOME 2 development was a steady process with a clearly defined goal. Almost everything was static. As such, nothing ever really got different. If anything, it gained more features or changed a default value. Sure, occasionally there was a hickup, but in general everything was obvious. Well, not really. Making programs compatible with older and, at the same time, newer versions of Gtk+ has never been particulatrly easy. But somehow, we (third-party developers) have managed. It seems some Gtk+ developers cannot even imagine that programs might want to be compatible with Gtk+ versions so old as (in my case) 2.8. Simply because that is how the thing was originally written, it is in maintenance mode now itself, and does not need any newer Gtk+ features. If anything, *more* stability in Gtk+ would be appreciated. Things keep changing. You can't just write something for 3.0 (be it an application, a shell plugin or a GTK theme) and expect it stay working that way forever. Instead you need to constantly improve on your work. Yes, I perceive this is a serious problem. There's one important thing to note about this however. If you participate in this process - like a bunch of applications do - you get two things: (1) You get the help of the GNOME developers. People are generally interested in your use cases and want to make your life easier and better. (2) You get to influence the direction of development. You can request features that you are missing and can expect help to get them implemented. But what if I am just a bloody conservative and want things that used to work to work in the newer version too? Maybe my feeling is wrong, but my feeling is that people with a *vision* might be welcome but people who just want to keep things working and compatible will be seen as hindering the progress. I would be glad proven wrong. Anyway it is good that this topic is discussed at all. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkTreeIter assignment
On Tue, Oct 30, 2012 at 05:05:37PM +0400, Vlasov Vitaly wrote:
Is that normal, to assign one GtkTreeIter to another?
For example:
void add_new( ... , GtkTreeIter *iter)
{
GtkTreeIter *default_iter;
if(iter != NULL)
{
default_iter = iter; -- is that noraml??
This is pointer assignment: default_iter will denote the same chunk of
memory as iter. What exactly should be abnormal here?
}
gtk_tree_store_append(default_iter);
This is invalid code: wrong number of arguments of wrong type. And, of
course, default_iter is possibly being used uninitialised.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeIter assignment
On Tue, Oct 30, 2012 at 06:53:18PM +0400, Vlasov Vitaly wrote: GtkTreeIter *default_iter -- GtkTreeIter default_iter; It's question about: default_iter = *iter; -- is that normal? Yes. It is explicitly specified that tree iters can be copied by value. See for instance here http://developer.gnome.org/gtk/stable/GtkTreeModel.html#gtk-tree-iter-copy Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: question on gtk+
On Fri, Oct 19, 2012 at 01:34:02PM +0200, belal medhat wrote: i wanna ask a question to work with gtk+ for c i should learn c89 or c99? Gtk+ is C89-compatible and you can use it with either standard (or C11). So learn whatever the toolchain(s) you target support. Nowadays C99 should be mostly fine. If you stay away from Microsoft Visual C++ that is. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
gtk-vim-syntax for gtk3
Hello, I have finally released gtk-vim-syntax (Gtk+ syntax highlighting Vim addon) with a gtk3 syntax file, see http://www.vim.org/scripts/script.php?script_id=1000 Normally, I do not announce new versions here but I've been getting e-mails asking when a gtk3 version will be available so here it is... Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: understanding GtkRGBA
On Thu, Oct 11, 2012 at 11:14:00AM +0100, Rudra Banerjee wrote:
So, I am trying to use:
gtk_widget_override_background_color (Hbutton, GTK_STATE_NORMAL,
GdkRGBA(0,0,0,1.));
ofcourse, this is not the way to use RGBA.
What is the correct way of using it?
GdkRGBA is a plain C struct and is used as any other plain C struct,
please see your C reference guide for the syntax and use of structs.
In C89 you need to create it on stack (or on heap) if you want to take
its address.
In C99 you can also use (GwyRGBA){0.0, 0.0, 0.0, 1.0}.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: understanding GtkRGBA
On Thu, Oct 11, 2012 at 12:56:36PM +0200, David Nečas wrote:
In C99 you can also use (GwyRGBA){0.0, 0.0, 0.0, 1.0}.
I mean (GdkRGBA){0.0, 0.0, 0.0, 1.0}, was thinking about something
else...
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: link treeview with file
On Thu, Oct 11, 2012 at 06:58:04PM +0100, Rudra Banerjee wrote: As the treeview is loaded from a file, in my program, new entries can also be entered. It writes to the Treeview, as well as in a file using: strAuth = gtk_entry_get_text(GTK_ENTRY(e-entryAuth)); /*Entering the data in Treeview */ gtk_list_store_append(store, siter); gtk_list_store_set(store, siter, COL_BIB_KEY, strkey, COL_BIB_TYPE, strcombo, COL_BIB_NAME, strAuth, COL_BIB_YEAR, strYear, COL_BIB_PUB, strTitle, -1); /*Entering the data in file */ if( strlen(strEditor)!=0) g_fprintf( fop, \tEditor=\%s\,\n, strAuth); ...etc... Now, my question is, can this two entry be linked such that if I delete an entry from treeview, it will also delete the entry from file(fop). In principle, certainly: by loading the entire file, parsing it, finding the corresponding line, deleting it and saving the file again. Or, if the file ‘cannot’ change on-disk meanwhile, just by re-generating the file from the treeview and saving it. For a saner use you need an API for handling of these files, similar to GKeyFile for .ini files. Apparently you are trying to process BibTeX files. Although there is no shortage of tools working with BibTeX files and even a few attempts to create a reusable BibTeX file handling library have been made (btOOl, ...), I cannot really recommend any parser. Maybe others know some. Regards, Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_tree_model_get end of Line marker
On Sun, Oct 07, 2012 at 05:43:52PM +0200, Arne Pagel wrote: because of my lazy programming style I sometimes forget or overwirte the comma before the -1 end of line marker for the gtk_tree_model_get or gtk_tree_store_set function. This error can usually not be detected by the c-compilers, so that I had to spend some really unnecessary time to fix this typo. Now I defined a makro for this, and in the case I forget the comma again at least I get a compiler error: #define TREE_MODEL_EOL (int)-1 gtk_tree_model_get(model,iter,STUFF,stuff,TREE_MODEL_EOL); I think something like this would be integrated officially and also the all the examples would be updated, at lot of headache of many people could be avoided. Errors related to the -1 sentinel could be avoided by much more straightforward means: defining gtk_tree_model_get() with column id and value pointer reversed, i.e. first comes the value pointer (presumably non-NULL), then comes the column id. Then gtk_tree_model_get() could just carry __attribute__((sentinel)) a.k.a. G_GNUC_NULL_TERMINATED. But the Gtk+ devs decided otherwise. It would be nice (also in other cases) if gcc had an attribute for arbitrary constant-value sentinels. Unfortunately, it has not. The corresponding bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28319 seems to be stale. I'm not sure about LLVM but it does not seem to support this either. While I've never forget the comma before -1 I have forgetten the -1 entirely a few times so something that prevents all sentinels errors would be quite useful. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Sortable Treeview
On Sun, Oct 07, 2012 at 12:25:22AM +0100, Rudra Banerjee wrote: What I am looking for, is make my header clickable to get the sorting, with initial view completely unsorted. Then look at List Store in gtk-demo. It demonstrates this clearly. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Error while building GTK+-3.4.4
On Sun, Oct 07, 2012 at 03:01:28AM +0530, Aditya Nag wrote: I get an error while running the configure script for gtk+-3.4.4 while building in linux. It says configure: error: *** XInput2 extension not found. I have no idea how to add this extension. Please help. Install libXi-devel or how it is called in your distribution. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Handle Enter pressing at GtkEntry
On Wed, Oct 03, 2012 at 08:19:39PM -0700, Andrew Potter wrote: On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry gtk_entry_set_activates_default() is probably what you want. If you actually want what it does. Usually, I do not want that at all. I want to recalculate and update something once user has finished editing the value there (but not during the editing). This means namely when the entry loses focus, however, it should be also possible to invoke the update without leaving the entry, by pressing Enter. So, instead of gtk_entry_set_activates_default() I use something like set-activate-on-unfocus and then just handle activate. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Thu, Oct 04, 2012 at 06:55:08PM +0900, Tristan Van Berkom wrote: I'm curious about this, out of my own personal interest... do we have a workable solution for this commit-on-focus-out paradigm ? As I understand, it's not very stable to use focus-out events and, I recall reading a detailed blog about this I can't seem to find at the moment (but it seems the problem is not at all limited to GTK+, just broken by design). Note in many cases validation/apply/commit user input on focus-out does work but... here is a case where I expect it to break: ... Validation is a different problem. For validation, the user should have an instataneous visual clue whether the input would be considered valid (but no blocking of non-conforming inputs, of course). In the second case you mentioned, loading of new values must not happen when there are uncommited changes and that should be also easy to achieve – except it may come a bit too late from the user's perspective if validation needs also be performed. However, if the GUI is constructed so that the user expects immediate commit, as it seems from your description, then it should be probably really immediate. Imagine the case I was talking about as function plotting. You may attempt to plot the function as the user types the expression but (1) the ‘plotting’ thing is not something really instanteneous and so doing it after each keystroke would interfere with typing (2) the user is essentially never interested in displaying the intermediate rubbish, in fact, he may be strongly intereseted in seeing the last meaningful, i.e. commited, output while editing. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib branched
On Wed, Oct 03, 2012 at 12:35:57AM -0400, Matthias Clasen wrote: I have now created a glib-2-34 branch, so master is now open for ... GTask ... Is this also intended, at least in the future, for things like long-running calculations that need some monitoring/reporting of progress not just the final result? I mean, some monitoring can be always implemented on top of GTask but once I get my hands dirty with explicit asynchronous communication I can implement that directly on top of GThread as well. I always look hopefully at the asynchronous interfaces in GLib with hope, however, the intended use cases do not seem to match mine... Thanks, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: PATHBAR written using GTK 3
On Tue, Oct 02, 2012 at 03:42:53AM -0300, Mariano Gaudix wrote: Excuse me . For my the question .. someone have or seen a PATHBAR written with gtk 3 . You can tell me the page address where you can download the code for this widget . I suppose typing ‘dowload Gtk+’ to Google is not that difficult so the question is where in the source code you can find GtkPathBar – and that is gtk/gtkpathbar.c and .h (if grep is not your friend). Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: PATHBAR written using GTK 3
On Tue, Oct 02, 2012 at 04:19:06AM -0400, Jasper St. Pierre wrote: However, due to what looks like a fluke, the documentation for the widget is not built. It's a private widget. So it's unlikely you would it find described in the public API documentation. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Synchronization of gtk_tree_store add/remove events
On Wed, Sep 19, 2012 at 09:44:28PM +0200, Arne Pagel wrote: I have an application where I use a tree-view to display some data from an external hardware. Different Objects can be added or removed to the treestore, each existing object in the treestore has a specific id which is used to get data over some communication interface. It can easily happen, the the user deselects an object in the treestore while this communication is ongoing. This means that my treepath or iter which I rembered befor is not valid anymore after the communication has finished (*1). Did you mean deletes instead of deselects here? The rest of the description would make much more sense to me then. Anyway, I think GtkTreeRowReference is what you need – a thing that points to a specific row that may not exist anymore and it had a method to tell whether the row still exists. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_tree_view/store, best way to select all nodes of a branch
On Wed, Sep 12, 2012 at 10:40:11AM +0200, Arne Pagel wrote: My current simple solution is as follows: I use the gtk_tree_model_foreach() function and pass some user data with the current major number of the tree-path. Inside the foreach-function I use gtk_tree_path_to_string, where I check if the first number is identical to the user data. This works, but I have to use a lot of string functions. Is there a smarter way to do that with less overhead? Use gtk_tree_selection_select_range(). You already have the start path, so, how to get the end path? Use gtk_tree_model_iter_n_children() and gtk_tree_model_iter_nth_child() recursively to always move to the last child in the branch. If your tree is only two-level (as it seems to be) you do not even need to recurse. Regards, Yeti ___ 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 get entry from GtkComboBoxEntry?
On Tue, Sep 11, 2012 at 03:29:10PM +0400, Vlasov Vitaly wrote: I wanna use some ComboBox/Entry widget: It should contain tree model with language names and hidden ISO 639-1 codes, for example English(en) German(de) Russian(ru) or other. And, in addition, it should allow to user write ISO 639-1 language code from keyboard. So, with tree i can get selected value and respectively get lang code from tree. When in ComboBox is not selected values, it could mean: 1) User set it from keyboard 2) Entry is empty. It is possible to create ComboBox with tree model and separate entry, but i don't like that way. How to check, whether the user has entered a value from the keyboard or entry is empty? May be i should use other Entry/ComboBox widget? I used before GtkEntryCompletion. It work's, but it uncomfortable with two-letter ISO codes. Now i use gtk-2.0, but later will switch to 3.0. As i can see, in gtk-3.0 GtkComboBox and GtkComboxEntry is same thing. But i still can't get entry widget from gtk-3.0 ComboBox. I don't quite get the difference between empty entry and user-typed text (she could type something and then delete it, for instance). Anyway, I will try to answer the simple part: Use gtk_bin_get_child(comboboxentry) to get the GtkComboBoxEntry's GtkEntry widget. Regards, Yeti ___ 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 get entry from GtkComboBoxEntry?
On Tue, Sep 11, 2012 at 04:14:52PM +0400, Vlasov Vitaly wrote: Is gtk_bin_get_child() always return GtkEntry widget? For a GtkComboBoxEntry? Yes. But in general, it returns the only child of a GtkBin container, whatever it is for that container. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: write to a file using g_print
On Tue, Aug 21, 2012 at 11:42:53PM +0100, Rudra Banerjee wrote: Is it possible to write to a file using g_print? g_print() is not an interface to print things to *a specific destination*. Quite the opposite. It sends messages to the print handler. Depending on the print handler stup, it do anything with them (print to stdout, save to some file, display somewhere, discard, ...). Any solution? Don't do that then. Use g_fprintf(). Or, in most cases, just fprintf(). Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList strange behavior
On Thu, Aug 16, 2012 at 06:49:25PM +0400, Vlasov Vitaly wrote: I need to save newly created list poiner. No. Many operations change the list head (by adding, removing, reordering, ..., elements). In general, if an operation returns the new list head you *must* save and use that in subsequent operations. So, i need to use g_list_last() to save it? Is there another method to save created list pointer? *Every* operation that may change the list head returns the new list head. That's the pointer to use. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk question.
On Thu, Aug 16, 2012 at 01:00:17PM +0200, prio...@tp-srl.it wrote: Hi all this is Federico from Italy, I am working on two opensource projects one is a debugger for Opencobol and another is a Gui for opencobol. Both projects are on sourceforge and some documents are also available at www.tp-srl.it (site of mine). This is the question. For the GuiCobol I must define some new events for widgets (typically GTK-Windows). In particular I need to add one that is emitted when the form is created (first time only). Can you be more specific what you mean by ‘created’? There are various things that can be considered creation, with corresponding signals, such as realize (see gtk_widget_realize() that corresponds to creation of widget's window if it has one) but they can occur repeatedly. Connecting something to creation of the object from the outside does not make much sense: // Here we do not have anything to connect to. GtkWidget *widget = gtk_window_new(...); // Here the object has already been created. If you want to run some code whenever an object of specific type is created, you can *subclass* it, i.e. create some MyWindow derived from GtkWindow and then run the code for example in the MyWindow instance init() method. Or, if the windows are created via some wrapper (don't know how GuiCobol works) then this wrapper can run whatever is necessary when creating them. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: next steps for touch support in GTK+
On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote: one implies a soft action (GtkToggleButton), whereas the other implies something similar of a hardware switch (GtkSwitch). As every user knows, widgets relay wishes to magic pixies. I wonder if that is soft or hard action, maybe it depends on how hard you need to beat the pixies to do what you want. Do you actually expect different kinds of on/off controls to be mixed wildly because each was selected based on how soft is the action it implies? they both have their use cases which are not interchangeable: https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget the page above should become part of the new Human Interface guidelines/design patterns. not every application should use switches, nor existing applications should be mindlessly migrated to moving from toggle and/or check buttons to switches. All cases listed there as good use cases of GtkSwitch would be – for me – improved by using a plain toggle button. It would take less horizontal space, it would be less wordy, it would not leave me wondering whether it shows ON when it is on or whether I should move it to ON if I want it ON (yes, I still do not remember it), it would not look trendy, and it would not have translation issues. In fact, even the ‘wrong’ checkbuttons would represent an improvement for me. I would also say the widgets are completely interchangeable, but forced to interpret the statement ‘their use cases are not interchangeable' somehow I would have to conclude that GtkSwitch has no meaningful use case at all. Could the page be improved to include this? In my opinion it could lead to a considerable simplification of the guidelines. the short takeaway is that the switch should be used in specific cases, and that the way its been defined as a widget does not allow inheritance from GtkToggleButton or GtkButton (no label, no children, styling of trough and handle). I am sorry but, again, this is just a recapitulation of the status quo. Stating it a hundered times does not make problems vanish magically even if you beat the pixies really hard with a switch. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Passing structure with a callback
On Tue, Jul 24, 2012 at 12:27:41AM -0600, Frank Cox wrote: Is my understanding of how this actually works correct? Yes. Now please read my reply to your first e-mail... If so, what is the recommended way to deal with structures like this? ...that already answered this too. https://mail.gnome.org/archives/gtk-app-devel-list/2012-July/msg00057.html Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Passing structure with a callback
On Tue, Jul 24, 2012 at 08:43:08AM +0200, David Nečas wrote: Now please read my reply to your first e-mail... I see. So, in case you read the mailing list archives: It's a bit pointless to ask questions in a mailing list if your mailserver blocks all answers. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Passing structure with a callback
On Sun, Jul 22, 2012 at 11:22:07PM -0600, Frank Cox wrote: My widgetshare structure gets passed from main() to MainMenu with no apparent problem, but using the same scheme to pass emailshare from MainMenu to Clear segfaults. This is elementary C. Both structures are created on stack so they cease to exist upon return from the corresponding functions. While main() is never exited while the program is running, MainMenu() is particularly short-lived. Use heap-allocated data. Yeti ___ 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 check if a GtkWidget exists?
On Fri, Jul 20, 2012 at 12:50:45AM -0600, Frank Cox wrote: How can I check if a GtkWidget exists? By keeping track of it (either when you create and destroy the widgets or using weak references/weak pointers/destroy callbacks/...). ‘Checking the existence of a widget’ is, essentially, a meaningless phrase. If the widget has been destroyed you do not have any means to *refer* to it. You cannot ask ‘does this widget exist’ because there is no way to say ‘this widget’. Using the pointer to the memory the widget used to occupy for anything is a programming error. Yeti ___ 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 check if a GtkWidget exists?
On Fri, Jul 20, 2012 at 10:15:54AM +0200, Miroslav Rajcic wrote: Not sure, but perhaps GTK_IS_WIDGET(widget) macro would help. If you have the pointer to a GObject instance and want to know whether it is an instance of GtkWidget (including subclasses) then GTK_IS_WIDGET() is the right thing to use. But if you use this macro with a random pointer (e.g. one pointing to a memory location where some GObject might be some time ago) do not expect anything more useful than a CRITICAL error/crash. To deal with objects that may or may not exist use one of the several mechanisms (weak pointers/weak refs/destroy callbacks/...) for keeping track of the object existence. And, generally, use these mechanisms to avoid even the possibility of dangling pointers in your code. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Open file from menu
On Mon, Jul 09, 2012 at 03:40:11PM -0400, Liam R E Quin wrote: also check that the free() was OK I wonder how you do that (apart from not getting any glibc MALLOC_CHECK_ error message or similar). Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Behaviour of g_utf8_to_utf16
On Tue, Jun 19, 2012 at 10:28:56PM +0100, Weeble wrote: As far as I can tell by experimentation, g_utf8_to_utf16 always stops at the first nul in a string, even when a positive value is passed for the len argument. If I have a UTF8 string with embedded nuls (of known length, of course), is there a good way to convert it to UTF16 with GLib? I would just write a wrapper around g_utf8_to_utf16() that would use it in a cycle until the full length is reached and handle the nul characters. I thought at first that passing a positive len would have this effect because I read If len 0, then the string is nul-terminated The string is terminated by a nul character or explicit length, whichever comes *first* – this is the standard behaviour of all libc and glib string functions. Passing len 0 simply means that the second condition never realises. Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: High Quality Icon For GtkWindow
On Wed, Jun 20, 2012 at 12:49:32PM -0400, Jasper St. Pierre wrote: I don't think it's a good idea to try and transfer a 96x96 and 48x48 icon over the wire, either. Do you have any data comparing the transfer of 96×96 icon with the data that programs already do transfer over the wire? Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: High Quality Icon For GtkWindow
On Wed, Jun 20, 2012 at 01:09:28PM -0400, Jasper St. Pierre wrote: So. In order to carry a 16x16, 22x22, 24x24, and a 32x32 icon, we have: ... 55k for an icon is stretching it. That depends on the data I asked about: If programs send 500k over the wire anyway then 50k for the icon can be fine. Are such data available? We already have a way to load a high-quality icon for an application. I don't think punting 96x96 icons across the wire is worthwhile. Application matching has a lot of other benefits, so it's worthwhile just to create a .desktop file. Application matching is a serious information locality violation, i.e. maintenance hell. As the OP demostrated... Yeti ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: multiple GTKentry inside a GTKnotebook
On Mon, Jun 18, 2012 at 11:28:48PM +0530, Rudra Banerjee wrote: pasted is a minimal layout of my trial to create a bibliography maker. The problem is, in Authors tab inside notebook, I want to edit 3 more entry, as Editor an example. But its taking only the first entry. Please show me where I am making the error. GtkFrame is a GtkBin which means it can contain a single widget. If you want more you need to use packing container (GtkTable, GtkVBox, GtkGrid, ...), put it to the frame and then pack widgets to this contaner. Yeti ___ 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 a multi-threaded application. Spot a crash.
On Thu, May 31, 2012 at 07:11:10AM +0100, Osmo Antero wrote: Now learned that it's a POD, Perl Object. I meant Plain Old Data, but of course in C. Nothing in GLib (as opposed to GObject and GIO) is an GObject. Yeti ___ 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 a multi-threaded application. Spot a crash.
On Wed, May 30, 2012 at 08:30:40PM +0100, Osmo Antero wrote: I have a multi-threaded application that filters data practically while user types text in an entry-field. But this applications regularly crashes. GRegex is not a GObject, it's just POD. So if (G_IS_OBJECT(search-regex)) will surely attempt to read some bogus memory location and crash. I cannot see why such code is there at all but anyway set search-regex to NULL if it does not exist and then just use if (search-regex) if necessary. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: wide characters in label
This is the wrong mailing list, dedicated to development of Gtk+. Your e-mail does not contain any question. So I suppose you want to know why your code is broken. On Tue, May 29, 2012 at 09:18:38AM -0700, jessCPP wrote: setlocale(LC_CTYPE, UTF-8); A bit strange and not actually influencing anything else in your code. wchar_t wide[]=Lthis is wide; Gtk+ works with UTF-8 encoded strings (i.e. sequences of bytes), *not* wide characters. wchar_t is an arbitrary poorly-defined platform-dependent type, making difficult to write a portable code. Do not use wide characters unless you have to. And if you have to then convert them to UTF-8 for use with Gtk+, e.g. using iconv with WCHAR_T as the source encoding. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: compile gtk with libcurl
On Thu, May 24, 2012 at 10:37:01PM +0530, Rudra Banerjee wrote: $ gcc curlgtk.c -o cpan `pkg-config --cflags gtk+-2.0` `pkg-config --libs libcurl gtk+-2.0` /usr/bin/ld: /tmp/ccZN7P8Q.o: undefined reference to symbol 'g_thread_init' If you use gthread you must link with it. Simple. Use pkg-config --cflags --libs gtk+-2.0 gthread-2.0 libcurl Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_filename_to_uri() issue in glib-win32
On Wed, May 23, 2012 at 06:48:31AM +0100, John Emmas wrote: But whatever that (second) character looked like, it's decimal value would always be 246 (because the UTF-8 sequence C3 B6 translates to decimal 246). The URI translation of decimal 246 is %F6. This is nonsense. Percent-encoding consists of % followed by *two* hexadecimal digits and encodes *bytes*, see http://tools.ietf.org/html/rfc3986#section-2.1 If things worked as you suggest you would not be able to encode any codepoint larger than 255 and the entire thing would be pretty useless. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: probable gtk_window_present and pango help
On Fri, May 18, 2012 at 09:12:45PM +0530, Rudra Banerjee wrote:
Here is a minimal example of a program, where if i click the button, a
pop up window appears. I am posting both the call back function and the
main routine (table.c).
I am facing 2 problem.
Unfortunately, you are facing much more problems.
For start
gtk_container_add(GTK_CONTAINER(window1), vbox1);
is called with an unitialised variable window1 (i.e. no window1 is ever
created). This leads to a CRITICAL message to console and/or crash.
And if window1 existed then vbox1 would be packed into two different
containers (window1 and window) which is not possible. So I'm ignoring
that part altogether.
The callback should look like
void
callback_it(GtkWidget *button, gpointer user_data)
{
...
}
where in user_data the callback receives the last argument you passed to
g_signal_connect(). It is rarely useful to pass a constant such as
Call there.
The callback is *not* another main() function; it should *not* call
gtk_init() again, etc. Please read the signals section in the Gtk+
tutorial
http://developer.gnome.org/gtk-tutorial/2.90/x159.html
There are several other highly suspicious things:
- redeclaration of global variables (such as window) inside a function;
are you aware this creates a new local variable window that has nothing
to do with the global one?
- inclusion of .c files instead of separate compilation + linking them
together
- calling gtk_widget_show() on individual widgets and then again showing
everything using gtk_widget_show_all()
- not terminating the Gtk+ main loop when the main window is destroyed;
this is usually the first thing to set up in a Gtk+ program, see
http://developer.gnome.org/gtk-tutorial/2.90/c39.html#SEC-HELLOWORLD
etc.
1) The problem is evry time I click the button main, a new window
appears(obviously). What I want to achive is, if the window is already
present, it should not open again; rather it should focus that window. I
believe, this can be achived by gtk_window_present(may be I am wrong).
But I don't know how to use it.
You use it just by calling gtk_window_present() on the window object.
To that meaningfully you need not only to keep the window object around
but also get notified when the window is destroyed. Either by
connecting to the destroy signal or, if you just want to set a pointer
to NULL once it is gone, by using g_object_add_weak_pointer().
2) In the callback function, I have C_1 and C_2. What I want to achive
is Csub1/sub etc via pango(or any other).
For simple things you can sometimes just use UTF-8. But generally, you
need to use Pango markup. If the widget does not have function to set
the markup it has a function to obtain the label widget so that you can
use gtk_label_set_markup() on that.
See the attached code with main problems fixed (and merged to one file).
Please go through the Gtk+ tutorial farther that you perhaps have done.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: G_PARAM_SPEC_VALUE_TYPE() question
On Tue, May 15, 2012 at 08:39:12AM +0200, Marc Balmer wrote:
I want to set properties of an object using the g_value_set_type()
functions and to cast my value (which I get from a Lua script, which
e.g. does not differentiate between integers and floats) I need to know
the type of the property.
Ideally something like the following:
switch (G_PARAM_SPEC_VALUE_TYPE(prop)) {
case G_TYPE_INT:
g_value_set_int(...);
break;
case G_TYPE_STRING:
g_value_set_string(...);
break;
}
You get the idea... This works for basic types, but not for e.g.
GParamEnum, i.e. when G_PARAM_SPEC_TYPE_NAME() returns GParamEnum,
above scheme seems not to work. There is a type G_TYPE_ENUM, but it is
not returned in case of GParamEnum.
You need to use g_type_is_a(...) on the type obtained from
G_PARAM_SPEC_TYPE_NAME(), not direct comparison to some explicit GTypes.
Then it will work also with subclassable types such as enums.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: pango or any other way to format text
On Mon, May 14, 2012 at 08:20:26PM +0800, Rudra Banerjee wrote: Can anybody please take some time to show me simple way of implementing pango formatting to get greek letters, subscripts and superscripts in gtk2+? What do you mean by ‘implementing Pango formatting'? I suppose you are not writing a Pango backend, i.e. you are not *implementing* any text rendering yourself. If you just want to use Pango to render Greek text, subscripts, superscripts, Cyrillic, math symbols or whatever, use UTF-8: GtkWidget *label = gtk_label_new(ἀπὸ τοῦ ἡλίου μετάστηθι); or GtkWidget *label = gtk_label_new(a² + b² = c²); That's it. Function gtk_label_set_markup() with Pango markup http://developer.gnome.org/pango/stable/PangoMarkupFormat.html can be used for more complex indexes and exponents and other stuff in labels. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GRegex regular expression failing to match
On Mon, May 14, 2012 at 01:36:02PM -0800, Christopher Howard wrote: Is there anything wrong with the regexp, Sure. Two things. It should be ^/[0-9]+$ not ^/d+$ First, it lacks the backslash to make \d a digit atom. But, second, since \d matches a digit (possibly whatever Unicode may say is a digit), not 0-9, you should really use [0-9] to match ASCII digits. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: clarification: GErrors and GQuarks
On Thu, May 10, 2012 at 04:45:09PM -0800, Christopher Howard wrote:
Quick glib question here: I've been getting into glib's error reporting
system and trying to integrate it into some code. (My code is using
glib, but not GTK+ itself.) Overall it seems rather straightforward, but
there was one point I was hoping for clarification on:
In the g_set_error() parameters, the domain parameter is a GQuark.
Does this mean that I am supposed to use something like
g_quark_from_string (MODULE_ERROR_DOMAIN_NAME) for that parameter each
time I call g_set_error?
That would make sense, from what I've read in the GQuark part of the
API. But I'm a little confused because the example given in the API for
g_set_error() usage does not do this. (In the example, they just pass in
some mysterious constant of unexplained origin.)
The mysterious constants follow the common usage pattern. For Bar in
package Foo, header:
#define FOO_BAR_ERROR foo_bar_error_quark()
GQuark foo_bar_error_quark(void) G_GNUC_CONST;
typedef enum {
FOO_BAR_ERROR_BAD_WHATEVER...
} FooBarError;
and code:
GQuark
foo_bar_error_quark(void)
{
return g_quark_from_static_string(foo-bar-error-quark);
}
You then do
g_set_error(error, FOO_BAR_ERROR, FOO_BAR_ERROR_BAD_WHATEVER, ...);
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: RHEL 6.2 and gtk+ dependency hell
On Tue, May 01, 2012 at 07:44:56PM +, Sarah Duncan wrote: I'm trying to install at least gtk+-2.0 on my redhat enterprise linux 6.2 server so that I can run gadmin-proftpd there. I've been undergoing dependency hell for the past 3 days. You mean yum install gtk2-devel does not work? (Assuming gadmin-proftpd is something you want to compile from sources.) Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to generate event explicit (through code) ?
On Mon, Apr 23, 2012 at 05:16:52PM +0530, Leena Chourey wrote: I want the focus to move selection/focus from one icon to another automatically on single key press. I have tried to just run key_press event code in a loop, but the selection is not moving from one to another, it is directly coming to the last item. it requires a h/w interruption (key_press) . As I understood, I need to generate the event key_press explicitly in the loop every time. How to generate gtk_event explicitly without any (h/w) key press? I must admit that I do not actually understand what you are trying to achieve (namely why you try to emulate key events). Anyway: Common keyboard control is usually defined by bindings, see GtkBindingSet for start. Maybe you just need to define bindings for the required keys to make them move the selection. If you want something special that does not correspond to the common movements then register a key-press-event callback for the widget and in that callback run gtk_widget_grab_focus() to move the focus where you want, gtk_icon_view_select_path() to set the icon view selection, etc. Return TRUE from the callback (most likely). You might also want to manipulate the selection/focus by invoking action signals of the wiget, e.g. the move-cursor signal for GtkIconView. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
