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: 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: GtkFileChooserDialog question
On Tue, Sep 16, 2014 at 12:29:39AM -0700, Igor Korot wrote: > On Windows I can display File/Open or File/Save dialog with the a > checkbox which will say "Show Hidden Files" so that the user can > decide whether to turn it on or off. > > Is something like this available for GtkFileChooserDialog? Yes, you need to right-click in the file list. Unfortunately, the discoverability of Gtk+ file dialog features is poor. 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: 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: 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: Button events
On Tue, Feb 18, 2014 at 09:44:10AM +, Bill Vyzas wrote:
> I have created a couple of interfaces I want for my project, two gtk tree
> view and two gtk list store. In all these interfaces the view and the model
> changes, some have less columns and rows than the others. I want to be able
> to interact with all the interfaces with a series of buttons I created.
> What is the best way to do that? Apparently callback function don't work
> properly in this case.
Why exactly they should not work?
> In my experience from Java I could use the ActionPerformed method and have
> the button respond to any events happening. Can I do something similar in
> gtk? Like
> if(button1 == clicked){
> call_function1();
> }else{
> call_function2();
> }
What is the else part? Something else happened with button1, some other
button was clicked, anything whatsoever happened like the pointer was
moved, ...?
Instead of writing ifs, attach one callback function to "clicked" of
button1 and another callback to whatever signal is the else part.
If handing of some signals is so generic that you really want a common
handler passing the specific info in the callback data when you connect
the handlers. If you need to distinguish the widgets that have received
the signa, this can be done by using their name or by attaching extra
info to them using g_object_set_data().
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-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: 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 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: 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: 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: GObject Destruction
On Wed, 19 Dec 2012 18:55:40 +0100, Nicola Fontana 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 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: 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 07:19:33PM +0100, Nicola Fontana wrote: > I always free dynamic stuff (included allocated memory) in > dispose(), not in finalize(), protecting it from double calls. > There you should have a still valid instance to query. GObject gives the following, somewhat contradictory, requirements for dispose(): When dispose ends, the object should not hold any reference to any other member object. The object is also expected to be able to answer client method invocations (with possibly an error code but no memory violation) until finalize is executed. dispose can be executed more than once. dispose should chain up to its parent implementation just before returning to the caller. If you free everything in dipose() you may have troubles with the ‘able to answer client requests’ part. All members that can be set and get by object users must be freed in dispose() in order to break reference cycles, that is clear. If these members can be NULL also during normal object operation it is perfectly safe and the object can be expected to still operate normally (otherwise you may be on a somewhat thin ice). Internal data members that cannot be set from outside are, IMO, better freed in finalize() because then you do not need to worry about the ‘able to answer client requests’ part in case they were already freed. The best protection against double-freeing things is the simple rule: a pointer may be only valid or NULL. Never free anything (or release your reference that may be last) and leave the pointer set. Regards, 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Experimenting with no gtk_main()
On Thu, Apr 19, 2012 at 09:58:37AM -0400, Patrick wrote: > I am trying to control gtk from a specific thread in another > language, I don't want a blocking call like gtk_main() because I > want the thread to interact with other threads periodically. Blocking gtk_main() and periodic interaction are not in conflict. If a single iteration of the Gtk+ main loop, i.e. gtk_main_iteration(), does things that take too long for your requirement of periodicality then you are in trouble anyway and running gtk_main_iteration() explicitly buys you nothing. You will still get too long delays due to gtk_main_iteration(). If a single interation of the main loop does not take too long then you can just run gtk_main() and perform the regular inter-thread interaction in a source registered to the Gtk+ main loop, e.g. using g_timeout_add(). Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to install GTK+3.2.0 correctly
On Thu, Feb 23, 2012 at 10:38:39AM +0800, 周龙 wrote: >Recently I install GTK+3.2.0 according the GTK+3.2.0 installation guide If any installation guide *recommends* installation of manually compiled Gtk+ into a system location the author of such guide should be hanged at dawn on the nearest plane tree. > in ubuntu 11.04. When I finished the install and reboot the computer, I > found that system interface has changed and file can't open by mouse. And I > think the question is GTK 2.x and GTK+3 in the same process is not support. > When I uninstall GTK 2.x, a new question is coming.The GNome is can't work > normally and I can't enter the system interface. >So how I should do next? Here My GNome version is 2.32.1.If I should first > put the GNome upgraded to 3.2. > I very much look forward to someone can help me,and to express my > heartfelt thanks. > > Gtk+3 has differently named libraries and is parallel installable with Gtk+2. But you might have rebuilt other libraries along the way, hard to say. So I don't know what precisely went wrong in your case but you have learned a lesson not to install random manually compiled stuff info system locations. If you installed everything into /usr/local it should be possible to just unistall it all (using make uninstall). Then configure, build and install again it to a non-system location. In case you have already scre^H^H^H^H damaged your system beyond reasonable repair it may be best to just reinstall it with Ubuntu 11.10 which already comes with Gtk+ 3.2. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Creating custom GTK+ widget using C++ -- Ctor/Dtor not called
On Thu, Feb 16, 2012 at 04:05:19AM +0530, Agnel Kurian wrote: > I have implemented a custom GTK+ widget which relies on a C++ object > internally. i.e. the widget structure contains an instance of a C++ class. > My concern was that the constructor and destructor of the contained object > were not being called. I had assumed that merely compiling as C++ would > make it work... but now I realize it need not be so when allocated via > g_object_new. It will not work if you embed the C++ class within the GObject struct because the GObject struct is simply allocated as a block of memory from the heap (using GSlice or whatever but anyway no C++ new operator is involved). You can create C++ objects in the instance-init method of the GObject and then, for example, put pointers to them to the GObject struct and destroy them in the the GObject finalize method. If you just want this and not any of the fancy stuff cxx-gtk-utils does then it is quite trivial and you do not need any extra library. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to know my GTK+ version?
On Tue, Jan 31, 2012 at 11:31:59AM +0100, Manuel Ferrero wrote: > I downloaded the all-in-one bundle for Win32, version 2.24.8, > unzipped it and copied it in my disk, then I added the bin path to > PATH variable. > Now I can compile and run a simple program. > > I read on some webpage how to know my GTK version with the following > command line: > pkg-config --variable=gtk_binary_version gtk+-2.0 > > but the output I get is: > 2.10.0 > > So now I'm confused, do I have the 2.24.8 or the 2.10.0? Gtk binary version defines the ABI version for extension modules. So it does not increase unless the ABI changes. Run pkg-config --modversion gtk+-2.0 to get the Gtk+ version. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: errors regarding the code
On Tue, Jan 31, 2012 at 12:53:18PM +0530, manjunath rgm wrote: > The shell script alone is working fine, but if I give more inputs through > the text entry then it's not getting passed form Gtk program to shell > program The code does not contain anything that would fetch the contents of the entry after editing or when the button was clicked. So it always executes system() with the initial content of the entry. The compound command sh st1.sh 1-10;20-30;40-50;60-70 consists of 4 commands: sh st1.sh 1-10 20-30 40-50 60-70 which is a nice illustration why you should not use system() but instead a function from the g_spawn() family. Also, using fixed-size buffers with no overflow checking and then asking why something does not work for larger input is asking to be flamed... Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: combined mouse and button event in a drawing area
On Thu, Jan 05, 2012 at 10:04:01PM -0500, Paul Davis wrote: > > 2) I use the GDK_BUTTON_MOTION_MASK option because I want the mouse motion > > to be considered only when the mouse button is pressed; in my case, EVERY > > mouse motion is reported... > > not sure why you think this mask does this. Probably because the description of this mask says receive pointer motion events while any button is pressed so it is up to one's imagination whether the missing qualifier is ‘also’, ‘only’ or what. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkBuilder and widget names
On Fri, Dec 23, 2011 at 03:44:56PM +0900, Tristan Van Berkom wrote: > There is a way to access the name of the widget key in the builder file, > however I've always been a little ticked about that. > > Can you name me one use case of how that would be useful ? To avoid widget identification using g_object_set_data() etc. since you already have identified them. And yes, you can avoid identification by explicitly storing things in various structures and carrying these structures around but why if it makes the code more complicated? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: My *.tyoes file remains empty
On Fri, Dec 02, 2011 at 09:10:46AM +0100, David Boesner wrote: > I cannot declare something in my Gtspi.types file, because make doesn't > create my html-documentation then. I cannot even include files that I can > include in my other .c files in the .types file. Did you try to put the dclarations to the .type files??? That's not what I meant. gtk-doc should *recognise* the foo_get_type() declarations in your headers and, if you pass --rebuild-types, create the corresponding .types file. If it does not recognise your .types declarations something is wrong with them (note gtk-doc does not include a full C parser so wrong can mean an unusual coding style). That's why I asked if your foo_get_type() declarations look as is usual. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: My *.tyoes file remains empty
On Thu, Dec 01, 2011 at 05:01:14PM +0100, David Boesner wrote: > http://developer.gnome.org/gtk-doc-manual/stable/metafiles_types.html.de > > What have I done wrong? Apart from building software as root? (Which is quite wrong.) It is hard to tell. But if no non-empty .types file is produced then gtk-doc does not recognise your GType my_foo_get_type(void); declarations. Do they look as usual? I.e. as in Gtk+ or other common packages? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: No method description displayed
On Wed, Nov 30, 2011 at 05:28:20PM +0100, David Boesner wrote: > I have a problem. I'm using gtk-doc to produce a documentation of my > program. > > My functions are documented like that : > > /* > * GTspi_Context_Get_TPM_Context: > * @self: A GTspiContext > * > * This method returns the hContext of the GTspiContext > * > * Returns: The TSS_HCONTEXT > */ > > The text: "This method returns the hContext of the GTspiContext" > is not displayed in my html-file produced by gtk-doc. > > Can you please help me? If this is the exact comment then it is not recognised by gtk-doc at all. The comments needs to look like /** * GTspi_Context_Get_TPM_Context: .* .. **/ Note the double asterisks that differeniate comments to be consumed by gtk-doc from normal comments. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to get rid of "recently used" entry in file chooser
On Fri, Nov 25, 2011 at 04:52:04PM +, jcup...@gmail.com wrote: > Federico wrote an interesting blog entry about this change: > > http://people.gnome.org/~federico/news-2011-07.html#01 > > It doesn't answer your question, but it does give some background and > recommends a way to use the chooser. Unfortunately, it does not recommend. It decribes how you are forced to perform an extra operation before you are permitted to save a file even if you sequentially save 1000 of them to the same folder (unless the application developers were enlightened enough to work around it). I have already seen people (normal users) to complain about this misfeature. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkHScale: Jump-to-position by left-click instead of middle-click?
Was it really necessary to cross-post this question to *four* mailing
lists?
On Sat, Nov 19, 2011 at 07:55:59AM -0500, Phong Cao wrote:
> I use GtkHScale for the progress bar, which is responsible for
> updating the track progress & allow user to move to different time position
> in the track.
>
> Everything works fine until now, except that I can not use left-click
> button to snap (or jump) to random position in the GtkHScale. Instead, I
> have to either drag or right-mouse-click.
The following is a kluge, but I suppose if you want the first button to
invoke the same response as the middle button it should be all right
(written in Python for brevity):
from gi.repository import Gtk
def button1to2(scale, event):
if event.button == 1:
event.button = 2
return False
adj = Gtk.Adjustment.new(0.0, 0.0, 1.0, 0.001, 0.01, 0)
scale = Gtk.Scale.new(Gtk.Orientation.HORIZONTAL, adj)
scale.set_round_digits(3)
scale.connect("button-press-event", button1to2)
scale.connect("button-release-event", button1to2)
window = Gtk.Window()
window.add(scale)
window.set_default_size(400, -1)
window.show_all()
window.connect("destroy", Gtk.main_quit)
Gtk.main()
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: libffi problems when compiling glib-2.31.0
On Mon, Oct 31, 2011 at 10:06:15PM -0700, Jonathan Greenberg wrote:
> Thanks -- I got a bit farther (and did what you suggested), but now
> I'm getting this:
>
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_pointer'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_float'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_void'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_sint64'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_prep_cif'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_uint32'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_double'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_call'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_sint32'
> ./.libs/libgobject-2.0.so: undefined reference to `ffi_type_uint64'
>
> Thoughts?
It is not linking with libffi. Did you unset LIBFFI_{CFLAGS,LIBS} and
re-configured? What
pkg-config --libs libffi
prints? Is it the same as the value of LIBFFI_LIBS in Makefile?
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Tue, Oct 25, 2011 at 04:22:16PM +0200, Stefano Facchini wrote: > > > Maybe you can find this link interesting ;-) > https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition Oh, great. Another distro forcing --as-needed in a one-size-fits-all manner. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Mon, Oct 24, 2011 at 01:49:05PM -0700, David Buchan wrote: > I tried pkg-config from the command line and here's what we get: > > $ pkg-config --cflags gtk+-2.0 gmodule-2.0 > -pthread -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 > -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > > $ pkg-config --libs gtk+-2.0 gmodule-2.0 > -pthread -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 > -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 > -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt > -lglib-2.0 This looks good. So, (1) Are these flags actually used in the compilation – check the actual command printed by make. I can see your Makefile variables are called CCFLAGS and LIBS instead of the more usual CFLAGS and LDFLAGS, however, if they are consistently called like this it is not a problem. (2) What are the *first* errors you get after cleaning the source tree and running make? Failing to link is often caused by some previous problems; do you really get only linker errors and no errors from earlier compilation stages? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Mon, Oct 24, 2011 at 08:09:39AM -0700, David Buchan wrote: > Trying to make now gives over 1700 errors, ALL of which are like this small > sample: > > /x.c:43: undefined reference to `g_threads_got_initialized' > /x.c:44: undefined reference to `g_thread_init' > /x.c:46: undefined reference to `gtk_init' > /x.c:49: undefined reference to `g_malloc0' > /x.c:57: undefined reference to `gtk_builder_new' > /x.c:60: undefined reference to `g_free' > /x.c:98: undefined reference to `gtk_entry_get_type' > etc etc... > collect2: ld returned 1 exit status > make: *** [x] Error 1 A typical symptom of empty CFLAGS and LIBS due to a pkg-config error. Run the pkg-config commands manually and see what they print. Fix the problems (probably something missing). I cannot give any Ubuntu-specific advice but the problem is usually obvious from the pkg-config errors. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: error "configure: WARNING: GTK dependencies not met."
On Fri, Oct 21, 2011 at 09:16:54AM -0400, Earnie wrote: > > I'm guessing that since you've used --prefix=$HOME/local on your module > dependent on gtk+ which resides in /usr/local that configure isn't > finding it. Maybe --with-sysroot=/usr/local will help but IDK if it will. If pkg-config can find the libraries when run manually it should also find them when run from configure (if PKG_CONFIG_PATH is exported). I have never had to use --with-sysroot, and the less it should be necessary for something like /usr/local. > The other option is to use --prefix=/usr/local on the configure and make > and then set DESTDIR on install, as in ``make DESTDIR=$HOME/local > install'', which is what I would do. Resulting in a broken installation. The purpose of DESTDIR is to relocate the software temporarily into a different place than where it is supposed to be installed – namely for packaging. The software is *not* expected to work if installed there. It is expected to be moved to the configure-d location eventually. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: error "configure: WARNING: GTK dependencies not met."
On Fri, Oct 21, 2011 at 05:22:39AM +0800, changqi wrote: > Could someone give me some suggestions? See config.log (or configure.ac). GTK there is just a label for the dependence, the actual dependence can be anything. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?
On Mon, Oct 17, 2011 at 06:12:37PM +0200, Oscar Lazzarino wrote:
> On 10/17/2011 11:51 AM, jcup...@gmail.com wrote:
>> On 17 October 2011 10:23, Clemens Eisserer wrote:
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to FOX toolkit.
>>>
>>> Yes, the tree list few is probably one of the worst performing pieces
>>> of code in GTK+.
>>
>> I wonder if this could be down to how they are using the widget?
>>
>
> Last time I checked, GTK used glib containers in a much "sub-optimal" way.
>
> One example of this is the "append_row" method of the tree model which
> was implemented more or less with a
>
> list->insert(new_row, list->size())
>
> (I'm writing by memory and using a pseudo c++ syntax)
>
> list->size() does a linear scan of the list to find out the list size
>
> ...
>
> BTW this was on GTK 2.20 (more or less, I don't remember the exact
> version number and I can't check right now)
That's funny because Gtk{List,Tree}Store has been based on a splay tree
(publicly available as GSequence from GLib now) since Gtk+ 2.5.x.
So either you are off by some six years and seven releases or the code
you checked was not Gtk+ source.
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Using GLists
On Thu, Sep 22, 2011 at 01:31:41PM -0700, sirthunder516 wrote: > I have a gtkiconview that contains both text and images. I know that I can > get a GList from the selected item with gtk_icon_view_get_selected_items(), > but how do I get the that information from the GList? I don't need to get > the icon of the currently selected item, just the text. Or is there a better > way to get the text from the currently selected item? The items of the list returned by gtk_icon_view_get_selected_items() are, according to http://developer.gnome.org/gtk3/stable/GtkIconView.html#gtk-icon-view-get-selected-items GtkTreePaths. So to obtain the items you normally use gtk_tree_model_get_iter() to convert the paths to iterators and then gtk_tree_model_get(), using these iterators, to obtain data from the underlying tree model. What you can obtain from the tree model and how depends how the model looks like. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Interface data/multiple inheritance
Hello, GObject does not support multiple inheritance. GInterface cannot have any data members (g_type_class_add_private() is not possible either). Is there any other way to create a class that has is-a relation to two classes/interfaces/whatever that each carries data? I have control over all the classes/interfaces involved. The thing I want to avoid is replication of identical code handling the data that logically goes with the interface in each class that implements the interface. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK TreeView control in Windows (DND issue)
On Sat, Sep 17, 2011 at 10:25:58AM +0100, John Emmas wrote:
> >
> FWIW I just tried a quick test but the address being printed doesn't
> seem to be the main window's address. At the moment, I'm a bit
> puzzled about what it might be
It might be the DnD icon (or whatever) window. You can add a debug
print to gtk_window_new() to see what is created when... Also if you
have a window a want to know what's inside, call this on it:
static void
print_hierarchy(GtkWidget *widget, guint indent)
{
guint i;
for (i = 0; i < indent; i++)
g_print(" ");
g_print("%s \"%s\" %p\n",
G_OBJECT_TYPE_NAME(widget), gtk_widget_get_name(widget), widget);
if (GTK_IS_CONTAINER(widget)) {
GList *children = gtk_container_get_children(GTK_CONTAINER(widget)),
*child;
for (child = children; child; child = g_list_next(child))
print_hierarchy(GTK_WIDGET(child->data), indent+1);
g_list_free(children);
}
}
Obviously, you cannot do this in GLib but you can insert this to the
Gtk+ code that calls g_object_get_data() to find "gtk-drag-dest".
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK TreeView control in Windows (DND issue)
On Thu, Sep 15, 2011 at 08:16:50PM +0100, John Emmas wrote: > Okay - not sure how far you'll be able to get with only pre-built Wine > binaries. I suppose you could at least let us know whether the > pointer addresses on Linux look sensible though (the first printout to > appear should be the correct address). I added a widget path and object type information to your messages and the output from working testtreecolumns on Linux then looks like this (the various other widgets appeared while dragging over the window towards the treeview): Widget originally set as drag_dest target was 0x0xcb8c80, path GtkWindow.GtkVBox.GtkHBox.GtkScrolledWindow.GtkTreeView Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget originally set as drag_dest target was 0x0xcb8660, path GtkWindow.GtkVBox.GtkHBox.GtkVBox.GtkScrolledWindow.GtkTreeView Widget being tested is 0x0xcb8660 on object GtkTreeView Widget originally set as drag_dest target was 0x0xcb8970, path GtkWindow.GtkVBox.GtkHBox.GtkVBox.GtkScrolledWindow.GtkTreeView Widget being tested is 0x0xca2160 on object GtkHBox Widget being tested is 0x0xca20d0 on object GtkVBox Widget being tested is 0x0xcdb3f0 on object GtkWindow Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget being tested is 0x0xcee020 on object GtkVButtonBox Widget being tested is 0x0xca2310 on object GtkVBox Widget being tested is 0x0xca2160 on object GtkHBox Widget being tested is 0x0xca20d0 on object GtkVBox Widget being tested is 0x0xcdb3f0 on object GtkWindow Widget being tested is 0x0xce33d0 on object GtkButton Widget being tested is 0x0xcee020 on object GtkVButtonBox Widget being tested is 0x0xcb8970 on object GtkTreeView Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget being tested is 0x0xcb8c80 on object GtkTreeView Widget being tested is 0x0xcb8660 on object GtkTreeView Widget being tested is 0x0xcb8660 on object GtkTreeView Widget being tested is 0x0xcb8660 on object GtkTreeView ... The same line also appears after finally dropping the row. Unfortunately the widget path cannot be obtained from within GLib but at least the object name (printed with G_OBJECT_TYPE_NAME()) should tell us something. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK TreeView control in Windows (DND issue)
On Thu, Sep 15, 2011 at 07:51:47PM +0100, John Emmas wrote: > P.S. - what'd be really interesting would be to see what gets printed on > Linux. Unfortunately, I can't do this locally because on Linux, I'm using > pre-built binaries. However, someone else might be able to look at that. I can do this as I am in the opposite situation (having Gtk+ built from source on Linux but only pre-built Win32 binaries – and also no real MS Windows, just Wine). Do you want me to use a specific Gtk+ version? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK TreeView control in Windows (DND issue)
On Thu, Sep 15, 2011 at 06:15:30PM +0100, John Emmas wrote: > > What I found was that the "gtk-drag-dest" data was being correctly set for > the drop target. You can check this by doing the following:- > ... Could you please post the debugging code in the form of a patch so that others can easily and precisely reproduce it? > Now build the toolkit's own treeview sample. If you click and drag a > treeview row, notice that you keep getting the same address getting > printed - but this ISN'T the address that was originally set up as the > drag target. > > So that's what's wrong. I don't yet know which widget the address > actually refers to and don't have any more time to look into this > today but I'll resume again in a few days if no-one's come up with a > possible explanation by then. Regards. Using functions such as gtk_widget_class_path() and gtk_widget_path() it should be relatively easy to figure out which widget it is. Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK TreeView control in Windows (DND issue)
On Thu, Sep 15, 2011 at 01:56:05PM +0100, John Emmas wrote:
> ...
> gtk_drag_find_widget (toplevel, &data);
>
> and it's that function which invokes the callback. Inside that function, the
> relevant code looks like this:-
>
> if (!data->found && g_object_get_data (G_OBJECT (widget), "gtk-drag-dest"))
> {
> data->found = data->callback (widget, data->context,
> data->x - x_offset - allocation_to_window_x,
> data->y - y_offset - allocation_to_window_y, data->time);
> }
>
> Initially of course, 'data->found' is zero - so as long as
> 'g_object_get_data()' returns successfully, the callback function
> should get invoked. Where it all goes wrong is that
> 'g_object_get_data() doesn't return successfully. It returns NULL.
> Here's the function that's failing:-
>
> ...
>
> In gtk-win32, when 'key' == "gtk-drag-dest" (and the drag destination
> is a TreeView) 'g_datalist_id_get_data()' returns NULL. This is where
> my understanding of GTK comes to a halt.
This datalist stuff is just the underlying mechanism of
g_object_set_data()/g_object_get_data() that allows attaching arbitrary
data to an object, while identifying the data by a string (quark). It
is often used to attach ad-hoc auxiliary data to widgets and other
objects in applications, occasionaly also within the libraries
themselves. It might contain some very obscure bug but, generally,
since so many things depend on it I would assume this mechanism works.
Then g_object_get_data() returns NULL simply because nothing has
the data identified as "gtk-drag-dest" is not attached to ‘widget’.
So IMO you need to go one level up and look at what ‘widget’ is and why
it does not have any "gtk-drag-dest" data. AFAIK the data can be
attached by gtk_drag_dest_set() or gtk_drag_dest_set_proxy() and in case
of a treeview this should happen, quite straightforwardly, if you call
gtk_tree_view_enable_model_drag_dest().
So either "gtk-drag-dest" data fails to be set, gets unset somehow
(cannot see how) or the code above looks for it in the wrong widget.
You check see whether the data is attached to an object any time by
inserting g_object_get_data() calls wherever you suspect things may go
wrong. Also try printing the widget pointers and compare as they are
the ultimate unique identifiers (as long as the widgets are not
destroyed and the memory reused).
Hope it helps,
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: make file command not working
On Wed, Jul 27, 2011 at 08:18:23PM +0530, Shashank Gudipati wrote: > make command is not working while trying to install gtk+ . this is after the > ./configure -prefix=/opt/gtk step in the manual > terminal is showing following message: > > make: *** No targets specified and no makefile found . Stop. > > i am unable to iron out the deficiencies. -prefix is wrong, it should be --prefix (even though -prefix works). But primarily, ./configure failed. Otherwise it would have created the Makefiles (read some intro to the GNU build system). So what was the error? Also the location /opt/gtk is an example in the Gtk+ documentation and not a good one IMO as only root can install there. Choose a location in your home directory (e.g. ~/opt/gtk) and do everything as a normal user at least until you are sure you do it right. > Please help as i am new and > enthusiastic on learning gtK. Please read http://www.catb.org/~esr/faqs/smart-questions.html Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Some questions about g_object_new, gtk_type_window and so on
On Mon, Jul 25, 2011 at 08:51:18AM +0200, Jean Brefort wrote: > Each type has an associated GType value which can be retrieved using the > appropriate *_get_type() function. For a GtkButton, the function is: > GType gtk_button_get_type(void); > > and GTK_TYPE_BUTTON is an equivalent macro: > #define GTK_TYPE_BUTTON gtk_button_get_type() > > These are not described in the documentation since they all strictly > follow the same conventions. More precisely, they are described once for all objects here: http://developer.gnome.org/gobject/stable/gtype-conventions.html Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: FGimpMovie project
On Sat, Jun 11, 2011 at 03:17:26PM -0700, Sergei Steshenko wrote: > http://docs.gimp.org/en/gimp-config-use-gegl.html : > > " > Warning > > Please note that GIMP remains 8-bits until GEGL covers the whole application. > ". > > So, to me it doesn't look like 'gimp' supports 16bpp. I have never said GIMP, the program, supports 16bpp. GIMP is huge and rewritting every plug-in, tool and everything takes time – rather lot of time apparently. But this does not prevent a new GEGL-based project from supporting high depths. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: FGimpMovie project
On Sat, Jun 11, 2011 at 02:40:12PM -0700, Sergei Steshenko wrote: > And I do not think one should develop an editor based on 'gimp'. > > 'gimp' after all these years still doesn't have 16bpp images support. Anything developed today ‘based on The GIMP’ is, hopefully, GEGL-based and can handle even 32bit depth if you wish. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Compiling a GTK application on windows
On Mon, May 30, 2011 at 12:22:11AM +0700, Lothar Scholz wrote: > I can't understand why for example this mouse-leave error is not > fixed. This is the most serious show stopper, next are the themes > and third is the unix build system (at least someone is working on > that) The unix build system is actually one of the best things: you can build MS Windows executables completely on the same system where you build Unix executables, i.e. on Unix – which is what most OSS projects seem to do nowadays. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Win32 - invalid cast GdkPixmap to GdkWindow in gdk_event_translate
On Wed, May 18, 2011 at 09:27:15PM +0200, Maarten Bosmans wrote: > For instance, the client-side windows branch is a huge improvement in > graphics quality when rescaling complicated windows, containing e.g. a > lot of spinbuttons. The merging of the client side windows branch in 2.18 is correlated to a number of bugs on Win32 (I cannot prove a causal relation though – that would mean I can also fix the bugs). So, 2.16 may be actually the preferred version there. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How many times can I call gtk_label_set_markup()?
On Fri, Apr 08, 2011 at 11:00:59AM -0700, Igor Korot wrote: > Program received signal SIGABRT, Aborted. > [Switching to Thread 0xb7106b40 (LWP 22539)] > 0xb805c424 in __kernel_vsyscall () > (gdb) bt > #0 0xb805c424 in __kernel_vsyscall () > #1 0xb7169660 in raise () from /lib/libc.so.6 > #2 0xb716ae98 in abort () from /lib/libc.so.6 > #3 0xb73d4a31 in g_logv () from /usr/lib/libglib-2.0.so.0 > #4 0xb73d4ace in g_log () from /usr/lib/libglib-2.0.so.0 > #5 0xb7477896 in g_type_check_instance_cast () from > /usr/lib/libgobject-2.0.so.0 > #6 0xb7a14e9c in gtk_label_set_markup () from /usr/lib/libgtk-x11-2.0.so.0 So the parameter of gtk_label_set_markup() is bogus, aparently NULL. Or, posssibly, something *very* weird happens inside gtk_label_set_markup(), maybe if things are already inconsistent at this point. Did you try valgrind? > Breakpoint 1, CFrame::UpdateData (this=0x94e1450) at > /home/igor/mini2440gtk/mini2440gtk/src/main_window.cc:282 > 282 gtk_label_set_markup( GTK_LABEL( data2 ), m_data2->str ); > (gdb) print data1 > $1 = (GtkWidget *) 0x94e80b0 But the argument is data2, not data1. Anyway, if everything seems right, the last resort is compiling Gtk+ from source, idealy with -O0 to get the line numbers precisely, and running the program with that to see the exact line where the bad typecast occurs. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How many times can I call gtk_label_set_markup()?
On Fri, Apr 08, 2011 at 10:30:32AM -0700, Igor Korot wrote: > $ ./ G_DEBUG=fatal-warnings > > Right? No, G_DEBUG=fatal-warnings ./program It's an environment variable: http://developer.gnome.org/glib/stable/glib-running.html Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How many times can I call gtk_label_set_markup()?
On Fri, Apr 08, 2011 at 01:17:52AM -0700, Igor Korot wrote: > I need to change the markup text in the label conditionally in the loop. > However, I'm getting this on the second call of gtk_label_set_markup(): > > (mini2440gtk:19672): GLib-GObject-WARNING **: invalid cast from > `(null)' to `GObject' > > (mini2440gtk:19672): GLib-GObject-CRITICAL **: g_object_freeze_notify: > assertion `G_IS_OBJECT (object)' failed > > (mini2440gtk:19672): GLib-GObject-WARNING **: invalid cast from > `(null)' to `GObject' > > (mini2440gtk:19672): GLib-GObject-CRITICAL **: g_object_notify: > assertion `G_IS_OBJECT (object)' failed > > (mini2440gtk:19672): GLib-GObject-WARNING **: invalid cast from > `(null)' to `GtkWidget' > > (mini2440gtk:19672): Gtk-CRITICAL **: gtk_widget_queue_resize: > assertion `GTK_IS_WIDGET (widget)' failed > > (mini2440gtk:19672): GLib-GObject-WARNING **: invalid cast from > `(null)' to `GObject' > > (mini2440gtk:19672): GLib-GObject-CRITICAL **: g_object_thaw_notify: > assertion `G_IS_OBJECT (object)' failed > > I checked and the window and the text are both not NULL. > > Is it possible to do it this way? Or I just need to dereference something? gtk_label_set_markup() can be called an arbitrary number of times. You do not need to *dereference* anything. You may need to reference the label – if it's been removed from the container it was in. Otherwise the only conclusion that can be made from this is that you code is buggy. Run it with G_DEBUG=fatal-warnings to obtain a stack trace at the first warning and see what exactly gets the NULL pointer instead of an object. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
DnD on Win32
Hello, is it possible to get *intra*app DnD working on Win32 in newer Gtk+? How? I thought my program did something wrong but it does not work even in gtk-demo (in the edtiable GtkIconView demo) in Tor's 2.22 binaries. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to make a GTK widget get fully focus and how to get its window state ?
On Wed, Feb 09, 2011 at 07:56:24PM +0800, Aaron Lewis wrote:
> Hi,
> I got two questions relating a GTK widget:
>
> 1. How can i get a window state ? i mean , a GTkWidget , i tried
> these code and didn't got a reply:
>
> void message_received_cb () {
> // I got this printed on screen
> g_print ( "Message Received , Starting up GUI" );
>
> switch ( gdk_window_get_state ( GDK_WINDOW(gpAppFrame->window)
> ) ) {
> case GDK_WINDOW_STATE_WITHDRAWN: g_print
> ("GDK_WINDOW_STATE_WITHDRAWN");
> case GDK_WINDOW_STATE_ICONIFIED: g_print
> ("GDK_WINDOW_STATE_ICONIFIED");
> case GDK_WINDOW_STATE_MAXIMIZED: g_print
> ("GDK_WINDOW_STATE_MAXIMIZED");
> case GDK_WINDOW_STATE_STICKY: g_print
> ("GDK_WINDOW_STATE_STICKY");
> case GDK_WINDOW_STATE_FULLSCREEN: g_print
> ("GDK_WINDOW_STATE_FULLSCREEN");
> case GDK_WINDOW_STATE_ABOVE: g_print
> ("GDK_WINDOW_STATE_ABOVE");
> case GDK_WINDOW_STATE_BELOW: g_print
> ("GDK_WINDOW_STATE_BELOW");
> }
This won't work because GdkWindowState is a set of *flags* so multiple
can be set at once (though some combinations are unlikely). You have to
test (state & GDK_WINDOW_STATE_ICONIFIED) for the iconified state, for
instance.
> 2. How can i force a program to be the "current" program , namely ,
> it didn't get the focus of user , and i want it to get the focus ,
> and make all other programs below it.
Probably you mean gtk_window_present().
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_file_chooser_get_filenames multiple folders
On Tue, Feb 08, 2011 at 02:35:02AM +, kevin.s.anth...@gmail.com wrote: > Is there a way, to use gtk_file_chooser_get_filenames to recursively > descend into all the folders selected? > > so you select folders ABC > and click open, > you then go into ABC and select and return all the files in each subfolder, No. You can use GFileEnumerator or GDir to traverse the tree – deciding how to handle hidden files, symlinks to directories, crossing file system boundaries, etc. as the definition of ‘all files’ depends... Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Preventing g-ir-scanner from scanning complex.h
Hello, is it possible to prevent g-ir-scanner from including (and thus scanning) some headers that are #included from my headers? I have some public headers that include C99 which leads to awful errors when they are scanned, reported as https://bugzilla.gnome.org/show_bug.cgi?id=639749 (and apparently g-ir-scanner can have troubles to get in sync again after that so more weird errors can follow). Since the intereset in making complex types work is probably quite low I'd like to at least stop g-ir-scanner from scanning complex.h. Is it possible? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: how to get signal from child widget
On Mon, Jan 17, 2011 at 02:49:33AM -0800, fengzi.gg wrote:
> I've got a question: I have a parent-vbox, and I add some
> child-widgets such as paned-box, label, entry, text-view in it. Now
> when one(it could be anyone) of the child-widgets get focus in, I
> wanna get the signal to handle something.
>
> How should I do? Should I connect "focus-in" signal to every
> child-widget, or some better way? I tried to connect "focus-in" signal
> to the parent-vbox, but seems not work.
Only widgets that can receive keyboard focus themselves can emit
"focus-in". But containers have a "set-focus-child" signal so this
might be what you need:
=
import gtk
win = gtk.Window(gtk.WINDOW_TOPLEVEL)
win.connect('destroy', gtk.main_quit)
hbox = gtk.HBox()
win.add(hbox)
def child_focused(widget, child, i):
print('A child in vbox #%u got focus.' % i)
for i in range(3):
vbox = gtk.VBox()
hbox.add(vbox)
for j in range(5):
entry = gtk.Entry()
vbox.add(entry)
vbox.connect('set-focus-child', child_focused, i+1)
win.show_all()
gtk.main()
=
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK-Doc External Links
On Tue, Jan 11, 2011 at 05:00:28PM -0600, Jeff Johnston wrote: > Does anyone know how I can get my external links to point to the correct > URL, or at least turn them off? It depends on what you mean by correct because... > For instance I have extended the GtkTreeView and I have a nice Hierarchy > (with links) that GTK-Doc created for me. However, all the links in the > generated html code are pointing to the local file system. ...this is definitely correct for some values of correct (the links point to something that does not disappear when you lose network connectivity). To change them to on-line locations use gtkdoc-rebase --online. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Mixing GLib and system file name encoding
On Mon, Nov 29, 2010 at 06:53:20PM +0100, Tadej Borovšak wrote: > You can use g_locale_to_utf8() to convert names in the list to UTF-8, > which can then be fed along with base directory to g_build_filename() > or something similar and opened using g_fopen(). > ... > g_locale_from_utf8() can be used to convert base path to system > encoding. After that you can concatenate it with filename from your > list and open it using fopen(). Thanks, once I knew better what to look for I also found g_win32_locale_filename_from_utf8() which seems to be just what's needed in the second case. > Note that both methods will only work if your input file is indeed > encoded in system locale. If your file originates from other system > that uses different locale, you're basically screwed. Yes, I know, . Regards, Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Mixing GLib and system file name encoding
Hello, I have a file that contains names of other files (in the same directory) and need to load these other files when the user selects the list file. Easy. Except that the file was created by a MS Windows program and the names are in system encoding (whatever it means, usually something like CP1252). Gtk+ functions provide the name in UTF-8 and on Win32 the GLib encoding is also UTF-8. So all I can get from Gtk+ and GLib functions are UTF-8 encoded paths. To load the referenced files it is necessary to either: - convert the names from the list to GLib encoding (UTF-8) and combine it with the directory name of the list file and use g_fopen() to open the files - convert the directory name of the list file from GLib encoding to the system encoding and use fopen() to open the other files But I don't know how to do either reliably. Is there anything in GLib that can help me? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_init breaks fortran data operation
On Mon, Nov 29, 2010 at 03:39:32PM +0300, Alexander Varnin wrote: > I don't need gtk_disable_setlocale() because I want other locale > parameters to be set. Well, in that case the real solution is IMO to use a locale-independent number parsing function (similar to g_ascii_strtod()) which might not be so easy in FORTRAN though... Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_init breaks fortran data operation
On Sun, Nov 28, 2010 at 07:15:54PM +0300, Alexander Varnin wrote: > Yes, you are right. Adding > >setlocale(LC_NUMERIC, "en_US.utf8"); > after gtk_init solved the problem. You can use gtk_disable_setlocale() instead. Anyway, en_US.UTF-8 is not guaranteed to exist; the only one are guaranteed to exist is C (plus POSIX on POSIX systems). Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Masking in GtkEntry
On Thu, Nov 04, 2010 at 02:12:10PM +0530, Vishak V. Kurup wrote: > Has anyone ever tried masking in a GtkEntry. I want to mask my gtkentry > input in format "%3d.%3d.%3d" (IP address). And example is in the FAQ: http://library.gnome.org/devel/gtk-faq/stable/x842.html But if you try to restrict the input in a more complex manner than limiting the set of characters that can be entered the result is usually very frustrating to the user. I suggest to change the text colour to red (or something similar) if the input is not in valid format. Then the user has a feedback but is still free to go through arbitrary intermediate states when editting one valid input into another. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: changing the way checkbutton looks
On Thu, Sep 23, 2010 at 08:14:49AM -0700, Sergei Steshenko wrote: > by default checkbutton has kind of 'v' on it when active and no special > sign when not active. > > Is there a simple way to change what's shown on it inside the application ? > I.e. I do not want to change this in theme. Subclassing GtkCheckButton and overriding draw_indicator() method should work since it works for radio buttons. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GdkPixbuf
On Mon, Sep 20, 2010 at 01:17:21PM +0200, maxim maxim wrote: > How i can to cut one GdkPixbuf from another gdk_pixbuf_new_subpixbuf() And possibly gdk_pixbuf_copy() if you want to modify the subpixbuf independently. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: howto write an interface
On Mon, Sep 06, 2010 at 09:05:37PM +0200, joel krähemann wrote:
> Hi, I want to write an interface with glib-object. The situation is a
> parent object implements the interface, but the subclass should
> overwrite the function pointers in the interface. The parent class
> contains the following code in the function ags_recall_get_type:
>
> ...
>
> static const GInterfaceInfo ags_connectable_interface_info = {
> (GInterfaceInitFunc) ags_recall_connectable_interface_init,
> NULL, /* interface_finalize */
> NULL, /* interface_data */
> };
>
> ...
>
> g_type_add_interface_static(ags_type_recall,
> AGS_TYPE_CONNECTABLE,
> &ags_connectable_interface_info);
>
> ...
>
> AgsRecall has subclasses which should overwrite the functions, but I
> don't know what's the proper way in the subclass to do so. How do I tell
> GInterface to call a function of the subclass to overwrite?
> One more, is it correct to make an object cast on the interface e.g.
> (where AgsConnectable is an interface which is implemented by
> AgsRecall):
>
> void
> ags_recall_connect(AgsConnectable connectable)
> {
> AGS_RECALL(connectable);
>
> ...
> }
This sounds somehow backwards.
1) You define an interface, with a virtual table, i.e. struct
AgsConnectableInterface, containing the method connect():
struct _AgsConnectableInterface {
GTypeInterface parent;
void (*connect)(AgsConnectable *connectable);
};
2) Then standard macros AGS_TYPE_CONNECTABLE, AGS_CONNECTABLE,
AGS_IS_CONNECTABLE, AGS_CONNECTABLE_GET_INTERFACE, see the docs.
3) Methods of this interface, e.g. ags_connectable_connect(), get
AgsConnectable* as the argument and look up the virtual method to call:
void
ags_connectable_connect(AgsConnectable *connectable)
{
void (*connect_method)(AgsConnectable*);
g_return_if_fail(AGS_IS_CONNECTABLE(connectable));
connect_method = AGS_CONNECTABLE_GET_INTERFACE(connectable)->connect;
g_return_if_fail(connect_method);
connect_method(connectable);
}
There is no public ags_recall_connect() as this makes no sense. To
invoke the connect() method of AgsRecall (or any other class
implementing the interface) you call
ags_connectable_connect(AGS_CONNECTABLE(recall));
4) Each class implementing the interface, including subclasses of
something that already implements the interface, does
{
static const GInterfaceInfo ags_connectable_interface_info = {
(GInterfaceInitFunc)ags_recall_connectable_init, NULL, NULL
};
g_type_add_interface_static(g_define_type_id,
AGS_TYPE_CONNECTABLE,
&ags_connectable_interface_info);
}
in the type init function ags_recall_type_init().
5) Function ags_recall_connectable_init() gets the virtual table
AgsConnectableInterface as the argument and fills it:
static void
ags_recall_connectable_init(AgsConnectableInterface *iface)
{
iface->connect = ags_recall_connect;
}
where ags_recall_connect() is a static function implementing the method,
not public.
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_strcmp0
On Tue, Aug 31, 2010 at 10:38:13PM +0200, Milosz Derezynski wrote: > Well, to be honest, the g_ stuff serves as an abstraction layer; I don't > think that currently there is any problem with using the plain C type > instead of the g_ type in this (or other) functions, but for consistency's > sake and for the case that this typedef will become more complex depending > on other platforms supported in the future I would consider this a minor bug > and opt to get it fixed. I am not against changing the function prototype. However, the reasoning that the typedef can change is bogus. The type is equivalent to the C type and has been always specified so: Types which correspond exactly to standard C types, but are included for completeness - gchar, gint, gshort, glong, gfloat, gdouble. A typedef to something else would be a major API breakage. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_strcmp0
On Mon, Aug 30, 2010 at 10:49:26PM -0300, John Williams wrote: > As the documentation > (http://library.gnome.org/devel/glib/2.24/glib-String-Utility-Functions.html#g-strcmp0) > the g_strcmp0 requires const char instead const gchar and returns int > instead gint. Does it matter with typedef char gchar; typedef intgint; ? These types correspond exactly to the standard C types; they are defined only for convenience (you can put g- before everything), see their documentation. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Is GTK signal 'realized' similar to the Windows WM_INITDIALOG event message for dialogs?
On Sun, Jun 06, 2010 at 06:56:52AM -0700, Ken Resander wrote: > The WM_INITDIALOG message is emitted for a dialog when it is safe and > possible to put data into the controls/widgets of the dialog, for > example to put text into entry widgets and fill listviews, combos, > toggle checkboxes etc. Would the following fragments work for GTK? It would because it would work if you put the content there any other time. IOW it is a completely unecessary complication. The "realized" signal is related to the creation of resources on the X-server side, but this does not influence whether the widget objects can hold the data or not. It always can. Sometimes you need the widget to be realized, e.g. if you want to do something that depends on its GdkScreen but that's something quite different. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Compiling GTK with QT based application
On Fri, Jun 04, 2010 at 06:42:43PM +0530, Rajendra Prasad Murakonda wrote: > Due to run flash on webkit I need to call gtk_init from my application once > due to some bug in gtk. I made a sample program in gtk and compiled it > successfully. But when I try to compile it with my application following the > same procedure, I get the following error. > > == > n file included from /usr/include/gtk-2.0/gtk/gtk. > h:44, from src/main.cpp:3: > /usr/include/gtk-2.0/gtk/gtkbindings.h:76: error: expected unqualified-id > before "protected" > /usr/include/gtk-2.0/gtk/gtkbindings.h:76: error: abstract declarator > `GtkBindingSignal*' used as declaration > /usr/include/gtk-2.0/gtk/gtkbindings.h:76: error: expected `;' before > "protected" > == > > Any idea what went wrong. Any help is much appreciated. First, you should have said you compile it as C++. Second, it is not clear what you do: there is no `protected' in gtkbindings.h (at least not in the current version); most likely some identifier that occurs in gtkbindings.h was #defined to something weird in another header. But only you can find out what, why and where in the other headers you include. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Erro with "key-press-event" signal
On Mon, May 31, 2010 at 04:19:26PM +0200, Michael Natterer wrote: > On Mon, 2010-05-31 at 09:52 -0300, frederico schardong wrote: > > Just a attention error, thank you. > > Fixing all compile warnings in your code is usually helpful. Unfortunately, the compiler cannot check callback prototypes. In some cases you can get an incomplete type error if you forget * but this is not one of them. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Erro with "key-press-event" signal
On Mon, May 31, 2010 at 09:47:26AM -0300, frederico schardong wrote:
> I have a window with a callback to resolve the "key-press-event"
> signal. The callback is:
>
> gboolean alterCurrentTab(GtkWidget widget, GdkEventKey *event,
> gpointer user_data)
> {
> g_print("\nkey: %s - %d - %lu", gdk_keyval_name(event->keyval),
> event->state, event->hardware_keycode);
> return FALSE;
> }
>
> The problem is that the return is always:
> key: (null) - -15694833 - 51081
>
> Obs: I'm using the gtk_widget_set_events(window, GDK_KEY_PRESS_MASK);
> on this window.
>
> What I'm doing wrong?
If you really declare the first argument as GtkWidget widget instead of
GtkWidget *widget then you get complete rubbish in the function
arguments.
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK on Linux and UTF-8 text
On Tue, May 04, 2010 at 02:01:45PM +0200, Andreas Falkenhahn wrote: > I previously worked with GTK only on Windows and the Windows builds of GTK > always used UTF-8 for everything. Now I played a bit with GTK on Linux and > noticed that it doesn't seem to handle UTF-8 correctly by default. > Instead, ISO 8859-1 is used (which should be my locale's default charset). > When I pass UTF-8 text to functions like gtk_dialog_add_button(), then the > specified strings seem to be treated as ISO-8859-1, i.e. non ASCII > characters appear as multiple characters instead of being resolved to the > single character they represent according to UTF-8 decoding tables. > > Could someone tell me how I can convince GTK to use UTF-8 as the default > on Linux, too? Gtk+ uses UTF-8 everywhere for everything[*] so I am almost sure that you do not pass UTF-8 even if you think so. Most likely your strings were double-encoded to UTF-8. [*] The only exception are functions working with file names that might to be in on-disk encoding, or something else, see http://library.gnome.org/devel/glib/stable/glib-Character-Set-Conversion.html http://library.gnome.org/devel/gtk/stable/GtkFileChooser.html#gtkfilechooser-encodings etc. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Building gtk+ 2.18.9
On Fri, Apr 23, 2010 at 02:35:17PM -0700, Sterling Smith wrote: > > Could anyone offer any suggestions? Set PKG_CONFIG_PATH, LD_LIBRARY_PATH and PATH to point to subdirs in /usr/local [first]. Do not fiddle with CFLAGS etc. and move files to random directories. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to move focus to another window by program?
On Wed, Mar 31, 2010 at 08:43:14AM -0700, Ken Resander wrote: > The program has a top window with a menu. The menu is used for functions > directly associated with the top window and for functions associated with > dialogs that are brought up via the menu. Each dialog has a single textview > and the top window menu contains functions that generate and insert text > fragments into the textview. > > A dialog gets focus when starting (the title bar has 'active' colour). I then > move the caret to the position in the dialog where text is to be inserted and > select what to insert from the menu. This causes the focus to move to the top > window because the menu is part of it. > > The program writes to the correct place in the dialog by: > > [code] > GtkTextBuffer * buf = gtk_text_view_get_buffer (textviewwidget) ; > gtk_widget_grab_focus ( textviewwidget ); // want to force focus back to > dialog > ... // prepare text, indentation,buf-insert-position etc > gtk_text_buffer_insert (buf,...); > [/code] > > but the focus stays in the top window and I don't understand why. The dialog > title bar never changes to active colour, not even a hint or flicker. Having > or not having gtk_widget_grab_focus does not seem to make any difference. It is probably too early to move the focus, the menu will eat it again. If you connect-after now and it does not help, moving the textview operation to an idle function should help. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: deprecated draw method and cairo context
On Fri, Mar 26, 2010 at 09:00:58AM +0100, Evgeny wrote: > I am looking at this article from the gnome journal > http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28, > and I believe that the draw method in the section "Step 2. Drawing with > Cairo" is deprecated, that should be used instead to draw with a cairo > context? (api mentions gtk_widget_queue_draw_area, but I am not sure if it's > still a "correct"/recommended way of using cairo with gtk...) > is there an updated version of this article somewhere? What exactly you are talking about? There is no draw method mentioned anywehre, the only draw() is a stub for `here we will do the actual drawing' that is later replaced with real code. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.20.0 is now available for download...
On Wed, Mar 24, 2010 at 06:39:11AM -0700, Sergei Steshenko wrote: > > Which part of the non-existent gtk+ release process and non-existent > respect for self-established 'gnome' conventions you did not understand ? None, because I cannot see any. Please enlighten me. It is normal that a stable version works with a stable version of its dependency *and* also some preceeding unstable versions of this dependency. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.20.0 is now available for download...
On Wed, Mar 24, 2010 at 04:57:13AM -0700, Sergei Steshenko wrote: > > > --- On Wed, 3/24/10, Tor Lillqvist wrote: > > > From: Tor Lillqvist > > Subject: Re: GTK+ 2.20.0 is now available for download... > > To: "IMS" > > Cc: gtk-list@gnome.org > > Date: Wednesday, March 24, 2010, 3:04 AM > > > Is it usual to release a stable > > version (here Gtk 2.20.0) based on > > > development librairies like Glib ??? > > > > If you don't like it, feel free to wait then for GLib > > 2.24. > > > Nonsense. > > In the 'gnome' world _stable_are the ones which have even minor version > and as _stable_ they should depend on _stable_ libraries which also have > even minor version. > > A stable release depending on unstable libraries by definition is not > stable. As was explained, you can always ignore the fact that some 2.23 GLib. version is sufficient and pretend that it depends on 2.24 and you get your definitions of stable. In reality, nothing changes. What part of that you did not understand? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTimers - do they need initialization ?
On Wed, Mar 17, 2010 at 11:37:04AM -, John Emmas wrote:
> The following code is giving me strange results when I build it using MSVC++
> and link to the binaries for glib-win32 (I've tried VC++8 and also falling
> back to VC++6)
>
> #include
> int main (int argc, char* argv[])
> {
> gulong microseconds;
> int count;
>
> GTimer* pTimer = g_timer_new ();
>
> do {
> g_timer_elapsed (pTimer, µseconds);
> count = (int) microseconds;
>
> printf ("Time elapsed = %d\n", count);
>
> g_usleep (100);
> } while (microseconds < 1000);
>
> return 0;
> }
The microseconds parameter contains the fractional part hence it can
never reach 1000. Also, it's rather useless, the retrun double
value contains all the information.
Please see the documentation.
> At first, I assumed that running in the debugger
> might be upsetting the timer so I decided to look at the output from just
> running the program normally. But if I run the program normally I just get
> this repeated ad infinitum:-
>
> Time elapsed = 0
> Time elapsed = 0
> Time elapsed = 0
> Time elapsed = 0
> Time elapsed = 0
> Time elapsed = 0
>
> I didn't call 'g_timer_start()' because the manual says that it gets called
> automatically by g_timer_new(). However, even if I call it, I still see the
> same output.
What exactly does g_usleep() on MS Windows? I have no idea. The
documentation says
g_usleep() may have limited precision, depending on hardware and
operating system; don't rely on the exact length of the sleep.
which may mean anything. It works on Unix, of course, but there's
real usleep() available.
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to set focus on a text view when tree selection changed?
On Mon, Mar 08, 2010 at 09:55:02AM -0800, kenny wang wrote:
> Hope for better solutions.
If you can stand (or, better, handle) a slight race condition:
import gtk, gobject, glib, glob
def grab_focus(self, widget):
def grab_this(widget):
widget.grab_focus()
return False
glib.idle_add(grab_this, widget)
window = gtk.Window()
window.set_default_size(0, 400)
hbox = gtk.HBox(False, 2)
window.add(hbox)
scwin = gtk.ScrolledWindow()
scwin.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
hbox.pack_start(scwin)
treemodel = gtk.ListStore(gobject.TYPE_STRING)
for x in glob.glob('*'):
treemodel.append((x, ))
tree = gtk.TreeView(treemodel)
scwin.add(tree)
column = gtk.TreeViewColumn('Name', gtk.CellRendererText(), text=0)
tree.append_column(column)
textmodel = gtk.TextBuffer()
textmodel.set_text('Some text goes here.')
text = gtk.TextView(textmodel)
hbox.pack_start(text)
window.connect('destroy', gtk.main_quit)
selection = tree.get_selection()
selection.connect_after('changed', grab_focus, text)
window.show_all()
gtk.main()
Yeti
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk man pages
On Sun, Mar 07, 2010 at 08:47:01PM +0800, Edward sm...@gtk wrote: > I have found the html doc on GTK on the www.gtk.org, but as an habit, the > manpage is more attractive to me. > So I search the Web for the gtk manpage package. (I use the ubuntu 9.04) > I installed the libglib2.0-doc and libgtk2.0-doc package. but it seems to > have no relationship with the gtk manpage. > I wanna install the gtk manpage, is there anything I missed? There is no *the* gtk man page. While the documentation is written/generated in DocBook which permits generation of man page output format and a bugzila enhancement request exists http://bugzilla.gnome.org/show_bug.cgi?id=467488 for man page generation by gtk-doc, the ready-to-read format is HTML. And I doubt Gtk+ will start distributing man pages in addition to HTML as man pages do not seem suitable for documentation of this extent and structure (you cannot link to a specific part of a man page, for example). So, use devhelp to read the HTML. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Mon, Mar 01, 2010 at 02:13:05PM +0100, Joost wrote: > There are also that folks, who run youtube, there is Zope > (where Mr. van Rossum worked), there are the (unknown for > me) systems, for which the reporting tools of www.reportlabs.com > are made for. Or slqalchemy - also only useful in large projects. > My OKamba is consisting of more than 100 files Python and i have > experienced the power of that language. And the funny part is that none of it backs your claim [cite] nearly every Python programmer is using it in the Tkinter form, when making the first steps in Python [/cite] Not even anecdotally. Actually, I was kidding, the funny part is the `my Python project has more files than your Python project' stuff. Seriously, you claimed that Python is used in a certain manner by almost all its users. After my remark that I don't see it to be used at all in this way no evidence that what I observe is in fact an eccentric behaviour followed. So, please provide it or cease speaking for `almost all Python programmers'. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Mon, Mar 01, 2010 at 11:17:25AM +0200, Tor Lillqvist wrote: > > Gtk+ development is not done on this list. > > Oh no, you let out the secret. Now the s/n ratio will drop on lists > that developers actually read. Well, maybe I should say that Gtk+ development is in fact done on alt.sex.spanking Usenet group. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
