Re: GObject Destruction
Use g_object_get(CAST_TO_PARENT_TYPE(obj), "x", &x, NULL); On Tue, Dec 18, 2012 at 4:57 AM, Günther Wutz wrote: > Hi, > > i have read the development stuff about GObject initialization and > destruction of an Object. But i have currently a problem, which drives > me crazy. > > I have an Class A, which stores two Integer as properties (say x and y) > and an Class B which inherits from A and makes a multidimensional array > on the heap with size x*y. In my finalize method i want to free the > dynamically allocated multidimensional array, therefore i ned the > borders from Class A. If i write g_object_get(obj, "x", &x, NULL); i get > an > > GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > > 0' failed > > GLib-GObject-CRITICAL **: g_object_unref: assertion `object->ref_count > > 0' failed > > Especially the cast to Class A fails. How would i do this correctly? > > I hope somebody out there can help me to understand this issue. > > Günther > > ___ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list > -- Everything is Original. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: A thumbnails widget
Hello Phil, A few words on your response, if I am allowed: My initial thought was to reduce all input images by a fixed factor supplied > by the caller (I would use 3% for my own application), along with a fixed > spacing between images again supplied by the caller (again, 10px for my own > application). If I can figure out how to use a user-supplied renderer, I > will of course incorporate it. > > It should be part of the design from the start, not an optional afterthought. That said, the default renderer needs to be thought out well as well, since the ideal goal is that people do *not* need to write an own renderer, since that will cause that widget to look mostly uniform in most of the applications. Ideally, the API for a custom renderer should be thought out in such a way that even if the designer of a custom renderer goes much out of his way to make it look a specific way, the combined logic and semantics, and final rendition, of the widget would enforce some kind of standard towards the look of the thumbnails. The API itself could be initially borrowed from the CellRenderer architecture. But if all of the above would be factored into the initial design there would be some degree of departure from the TreeView-CellRenderer architecture (not neccessarily bad, but it's always good to keep things as familiar as possible for future API users). I know this sounds very abstract, but if 2 people who are good up the usability ladder would focus on this for a week or two, it could be done. I would offer myself to do the usability work, if you wish (but most likely not over the course of the next month, and starting again in November; maybe you could find some other usability person to do it?). > My own style is to develop from the base code, and my current thinking > revolves around GtkImage, GtkScrollbar and GtkTable, but I need to think > through the issues, and try a few experiments, before I can come to a > well-informed decision. > > To be completely blunt, this sounds like a bad idea. Ideally, this widget would be written from scratch or perhaps based on GtkIconView, but I can't imagine anything good from how you describe it. If you're interested in why particularily, please say so and I'll explain why I think it's a bad idea! Don't hesitate! > For what it is worth, I am using Code::Blocks 10.05 in a Windows 7 64-bit > environment (gah!) while fighting issues on multiple fronts. Once I have > "defeated the enemy(ies)", I will be looking to port to Ubuntu. Then, and > only then, might I have something that might be considered useful. My ideal, > which is probably unrealisable, is to have something that could be > incorporated into Gtk itself. (Me, ambitious? Yes, but I have got to have > *something* to aim at!) > > Ambition is always good but as with all open source, you eventually need to let this go the open-source-soul-searching process. > Best Regards, > Phil Hart > > Regards, Milosz > > On 28/09/2011 16:27, Milosz Derezynski wrote: > > Just want to throw in my "vote": I also would be very much for having such > a widget, but still leaving the thumbnail rendering routine open to > implementation (with a standard default renderer present). > > To be a little preemptive: In case someone says nuh-uh too fast: I've > never coded with Cocoa, but I imagine that the/a CoverFlow widget exists in > the library and doesn't need to be reimplemented each time. > > These days, thumbnails could be used for quite a lot of stuff. > > Also, as a last, completely intuitive and at the moment not > rationalizeable thought (I'll try it to flesh out in an upcoming message): > Please, please don't base the code for the ThumbView widget on anything > Nautilus. Please. > > > Regards > Milosz > > On Wed, Sep 28, 2011 at 9:40 AM, Phil Hart wrote: > >> Hello Everybody, >> >> I want (need?) a scrollable (both vertical and horizontal) widget for >> displaying thumbnails which also re-arranges them depending on how many >> thumbnails wide is chosen in an up-down counter. (Gigapan stitcher users >> will know what I am talking about.) >> >> Is there anything similar already around - if not, I will write one (and >> if I regard it as good enough, I will also publish the source code). >> >> Many Thanks In Advance, >> Phil >> >> ___ >> gtk-list mailing list >> gtk-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/gtk-list >> > > > > -- > Everything is Original. > > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Everything is Original. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkFrame in Gtk+-3.0
Hey,
Which theme and engine are you using? Did you try this with different
themes?
Regards
Milosz
On Wed, Sep 21, 2011 at 11:54 PM, Glus Xof wrote:
> Hi guys,
>
> > It seems that the effects for all Gtk+3.0 frames shadow type are the
> > same for almost the GtkShadowType values: GTK_SHADOW_IN,
> > GTK_SHADOW_OUT, GTK_SHADOW_ETCHED_IN and GTK_SHADOW_ETCHED_OUT.
>
> Doing
>
> frame1 = gtk_frame_new("My Frame");
> gtk_frame_set_shadow_type(GTK_FRAME(frame1), GTK_SHADOW_IN);
>
> or
>
> frame1 = gtk_frame_new("My Frame");
> gtk_frame_set_shadow_type(GTK_FRAME(frame1), GTK_SHADOW_OUT);
>
> throws the same frame shadow type to me...
>
> I'd like just ask you if it's normal at this point of current Gtk+-3.0
> developpment status
>
> > Is there any mistake on my side ? It's a bug ? or a feature not yet fixed
> ?
>
> Glus
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
--
Everything is Original.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Status for long-running operation
p_text(entry, "Name of the Database");
> g_ptr_array_add(dispState[DBNOCONN][DISPEDITABLE][OFF], entry);
> g_ptr_array_add(dispState[DBDISPLAY][DISPEDITABLE][OFF], entry);
> g_ptr_array_add(dispState[DBEDIT][DISPEDITABLE][OFF], entry);
> g_ptr_array_add(dispState[DBCREATE][DISPEDITABLE][ON], entry);
>
> // A button that is sensitive only when editing a database, otherwise not
> selectable
> button = gtk_button_new_with_label("ADD");
> g_ptr_array_add(dispState[DBNOCONN][DISPSENS][OFF], button);
> g_ptr_array_add(dispState[DBDISPLAY][DISPSENS][OFF], button);
> g_ptr_array_add(dispState[DBEDIT][DISPSENS][ON], button);
> g_ptr_array_add(dispState[DBCREATE][DISPSENS][ON], button);
>
> // add all other widgets appropriately as they are created
> //...
>
> // Initialize Display State to NO DB Connection
> setDispState(DBNOCONN);
> }
>
> END CODE SNIPPET ==
>
> On Sat, Sep 18, 2010 at 4:39 AM, Milosz Derezynski <
> internaler...@gmail.com> wrote:
>
>> One option as already said is a modal dialog with progress bar, another
>> option is to have a progress bar in the main GUI and set the rest of the GUI
>> insensitive (you _really_ should familiarize yourself with
>> gtk_widget_set_sensitive() ).
>>
>>
>> http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#gtk-widget-set-sensitive
>>
>> M.
>>
>>
>> On Sat, Sep 18, 2010 at 3:01 AM, Jeffrey Barish <
>> jeff_bar...@earthlink.net> wrote:
>>
>>> Lex Trotman wrote:
>>>
>>> > On 18 September 2010 08:22, Jeffrey Barish
>>> > wrote:
>>> >> Jeffrey Barish wrote:
>>> >>
>>> >>> My application has one operation that runs for a long time (~1
>>> minute).
>>> >>> During this time, the user is not allowed to do anything.
>>> Nevertheless,
>>> >>> I felt that it was important to give the user some feedback that the
>>> >>> application is still alive and that the operation is running. My
>>> >>> solution was to print a message in a TextBuffer and follow the
>>> message
>>> >>> with a string
>>> >>> of dots that grows in length by one every second. To get the
>>> TextView
>>> >>> to update, I used events_pending/main_iteration. This all works
>>> nicely.
>>> >>> However, because of the events_pending/main_iteration statements, the
>>> >>> entire
>>> >>> GUI is now alive. Thus, the user is able to do things that disrupt
>>> the
>>> >>> long-running operation. Basically, what I want is a way to get the
>>> >>> TextView to update so that I can update the progress indicator but
>>> for
>>> >>> everything
>>> >>> else still to be locked out. Is there a way to do this?
>>> >>
>>> >> Here's a possibility that seems to work:
>>> >>
>>> >> I used event_handler_set to define an event handler that filters out
>>> all
>>> >> events (by not calling main_do_event) except EXPOSE while the
>>> >> long-running operation is underway. I wish that there were a way to
>>> >> restore the default event handler, but there is only a set method.
>>> >> Anything bad about this solution?
>>> >> --
>>> >> Jeffrey Barish
>>> >
>>> > You should show progress and block the application by showing a modal
>>> > dialog containing a progress bar.
>>> >
>>> > Cheers
>>> > Lex
>>>
>>> Good point. The TextView is where I put all messages, so I didn't want
>>> to
>>> put the progress indicator in a different place, if I could avoid it.
>>>
>>> My solution still seems to be working, but I worry about having all
>>> events
>>> go through my filter all the time because it seems a bit inefficient.
>>> --
>>> Jeffrey Barish
>>>
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>
>>
>>
>> --
>> Please note that according to the German law on data retention,
>> information on every electronic information exchange with me is
>> retained for a period of six months.
>> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
>> jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Status for long-running operation
One option as already said is a modal dialog with progress bar, another option is to have a progress bar in the main GUI and set the rest of the GUI insensitive (you _really_ should familiarize yourself with gtk_widget_set_sensitive() ). http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#gtk-widget-set-sensitive M. On Sat, Sep 18, 2010 at 3:01 AM, Jeffrey Barish wrote: > Lex Trotman wrote: > > > On 18 September 2010 08:22, Jeffrey Barish > > wrote: > >> Jeffrey Barish wrote: > >> > >>> My application has one operation that runs for a long time (~1 minute). > >>> During this time, the user is not allowed to do anything. > Nevertheless, > >>> I felt that it was important to give the user some feedback that the > >>> application is still alive and that the operation is running. My > >>> solution was to print a message in a TextBuffer and follow the message > >>> with a string > >>> of dots that grows in length by one every second. To get the TextView > >>> to update, I used events_pending/main_iteration. This all works > nicely. > >>> However, because of the events_pending/main_iteration statements, the > >>> entire > >>> GUI is now alive. Thus, the user is able to do things that disrupt the > >>> long-running operation. Basically, what I want is a way to get the > >>> TextView to update so that I can update the progress indicator but for > >>> everything > >>> else still to be locked out. Is there a way to do this? > >> > >> Here's a possibility that seems to work: > >> > >> I used event_handler_set to define an event handler that filters out all > >> events (by not calling main_do_event) except EXPOSE while the > >> long-running operation is underway. I wish that there were a way to > >> restore the default event handler, but there is only a set method. > >> Anything bad about this solution? > >> -- > >> Jeffrey Barish > > > > You should show progress and block the application by showing a modal > > dialog containing a progress bar. > > > > Cheers > > Lex > > Good point. The TextView is where I put all messages, so I didn't want to > put the progress indicator in a different place, if I could avoid it. > > My solution still seems to be working, but I worry about having all events > go through my filter all the time because it seems a bit inefficient. > -- > Jeffrey Barish > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_strcmp0
Thanks, that was the point I was trying to make! 2010/9/1 richard boaz > 2010/9/1 David Nečas > > 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 >> > > desiring consistency is never a bogus reason. making it right now, since, > as you say, it is currently equivalent, would cause no API breakage (what > breaks exactly?). > > when, and if, the typedef wrapper ever does need to change, this would > indeed result in API breakage. > > better to fix now when no harm possible, rather than waiting till a > necessary change necessarily breaks the API. the longer into the future > that the typedef remains unchanged, the less likely it will cause harm in > old code. > > or, why should it remain wrong just because it wasn't right in the first > place? i.e., this "wrongness" works now, but is not guaranteed to work > forever. > > richard > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_strcmp0
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. 2010/8/31 David Nečas > 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 > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remove only side border from a Gtk::Window
No, sorry there's really no way to do this. The decoration is (as of yet; there have been proposals in the past) not handled by Gtk+ but by the WM or a decorator, and can thus only be enabled or disabled wholesale. On Mon, Mar 22, 2010 at 8:14 PM, Pioz wrote: > Hi all, > is there a way to remove only the left and right border of a Gtk::Window? > > Similar to gtk_window_set_decorated(w,false) but that do not remove the > title bar and resize controls? > > Thx. > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ 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?
Hmm I haven't written Gtk+ code for a while and I seem to be forgetting
things. I had the impression that "changed" was a signal with a bool return
value, but it turns out that's not the case.
OK anyway, here's what you've got to do: Connect to the _TreeView's_
"button-press-event" (
http://library.gnome.org/devel/pygtk/stable/class-gtkwidget.html#signal-gtkwidget--button-press-event)
and check for the button being the right mouse button in the event passed
into (see here
http://library.gnome.org/devel/pygtk/stable/class-gdkevent.html under
"gtk.gdk.BUTTON_PRESS", I can not link directly). The numerical value for
the right mouse button is 3.
And this time:
* Make sure this time you do NOT connect_after, but just connect
and:
* Return "True" from your handler, so that the TreeView itself doesn't
process the button press and changes the selection
HTH :)
Milosz
On Mon, Mar 8, 2010 at 2:57 AM, smartkenny wrote:
> Hello, Milosz
>
> Thank you for answer my question. But it doesn't work. Here's my program:
>
>
> #!/usr/bin/env python
>
> import pygtk
> pygtk.require('2.0')
> import gtk
>
>
> def wrap(widget):
> sw = gtk.ScrolledWindow()
> sw.add(widget)
> sw.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
> sw.set_shadow_type(gtk.SHADOW_ETCHED_IN)
> sw.set_border_width(1)
> return sw
>
>
>
> def on_selection_changed(selection):
> selection.get_tree_view().grab_focus()
>
>
> if __name__ == "__main__":
> paned = gtk.HPaned()
> treestore = gtk.TreeStore(str)
> new_iter = treestore.append(None)
> treestore.set(new_iter, 0, '0')
> new_iter = treestore.append(None)
> treestore.set(new_iter, 0, '1')
> new_iter = treestore.append(None)
> treestore.set(new_iter, 0, '2')
> new_iter = treestore.append(None)
> treestore.set(new_iter, 0, '3')
> new_iter = treestore.append(None)
> treestore.set(new_iter, 0, '4')
> treeview = gtk.TreeView(treestore)
> treeview.set_enable_search(False)
> treeview.get_selection().connect_after('changed', on_selection_changed)
> column = gtk.TreeViewColumn();
> renderer = gtk.CellRendererText()
> column.pack_start(renderer, False)
> column.add_attribute(renderer, 'text', 0)
> treeview.append_column(column)
> paned.add1(wrap(treeview))
> textview = gtk.TextView()
> paned.add2(wrap(textview))
> paned.set_position(250)
> window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> window.set_default_size(800, 600)
> window.add(paned)
> window.show_all()
> gtk.main()
>
>
> Thank you!
>
> Kenny
>
>
>
> Milosz Derezynski wrote:
>
>> You need to get the TreeSelection from the TreeView and connect to that's
>> "changed" signal, and make sure you connect_after.
>>
>> Sent from my iPod
>>
>> On 07.03.2010, at 19:25, smartkenny wrote:
>>
>> Hi, all
>>>
>>> Searched for a long time but didn't find any hints on this. Here's my
>>> layout:
>>>
>>> -
>>> | | |
>>> | tree view | text view |
>>> | | |
>>> -
>>>
>>> When clicked on a tree view row, I am going to change text in text view
>>> accordingly AND let text view grab focus, so that whenever I press keys it
>>> put characters into the text view.
>>>
>>> I tried to connect "changed" on tree view and grab focus on text view,
>>> but it didn't work, the focus is still on tree view. So when I press keys it
>>> doesn't put into the text view.
>>>
>>> Can any body please give me a clue how to do this? Thank you very much.
>>>
>>> Kenny
>>>
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>
>>
>
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
___
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?
You need to get the TreeSelection from the TreeView and connect to that's "changed" signal, and make sure you connect_after. Sent from my iPod On 07.03.2010, at 19:25, smartkenny wrote: Hi, all Searched for a long time but didn't find any hints on this. Here's my layout: - | | | | tree view | text view | | | | - When clicked on a tree view row, I am going to change text in text view accordingly AND let text view grab focus, so that whenever I press keys it put characters into the text view. I tried to connect "changed" on tree view and grab focus on text view, but it didn't work, the focus is still on tree view. So when I press keys it doesn't put into the text view. Can any body please give me a clue how to do this? Thank you very much. Kenny ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkImageViewer
CAIRO_ARGB32 is the right colorspace On Sun, Apr 12, 2009 at 10:12 AM, Dov Grobgeld wrote: > Regarding the gtk-list subscription, see: > > http://mail.gnome.org/mailman/listinfo/gtk-list > > for details. > > About the strange colors, it is most likely that your pixbuf has an alpha > channel, which is different from my tutorial example where I hardcoded the > assumption that GtkImageViewer always passes a 24-bit pixbuf in the annotate > signal. If you use alpha channel, then you should use > cairo_image_surface_create_for_data with CAIRO_FORMAT_ARGB32 instead. I'm > not sure whether it is enough for to switch R and B in such a case though. > Check the documentation or just check if it works. > > Regards, > Dov > > 2009/4/12 Eduardo J. Andres > >> Hello Dov, >> >> Thanks fo the answer. >> I am trying to know how to reply you by the gtk-list, but even I have done >> my suscription to it, I do not know yet how to do it, therefore, I write you >> again to same "gmail". Would you be able to explain me how to reply you >> there. >> >> I shall look to the giv code, but in the meantime, I have seen that it is >> not an issue with your software/widget, it is the same with GtkImageView, >> for example. I would like to note you at that point that I am doing all my >> testing under XP. >> >> So, if you have a pixbuf on a widget (whatever the widget may be), and you >> make a cairo_surfacet_t from that pixbuf, when you draw with cairo to the >> surface, you alway lose the color and get a line or arc with strange >> effects. >> >> That´s what I would like to know, why?? >> >> Best regards >> Eduardo >> >> 2009/4/12 Dov Grobgeld >> >> Hello Eduardo, >>> >>> Thanks for the feedback. >>> >>> Regarding the drawing of polygons, I have had the same problem and the >>> solution I made is outside the GtkImageViewer. Please download my program >>> giv at giv.sf.net and have a look at the the pair of files >>> giv_backstore.[ch] that provide a way of quickly storing all the information >>> under a line and then restoring it. By tieing it to the button press and >>> motion events it is possible to get a rubberband effect with only minimal >>> flicker. (I'm considering a rewrite that eliminates flicker all together). >>> See giv's use of it for details. (I agree it is also worthy of a tutorial. >>> We'll see if I'll get around to it.) >>> >>> Once you have a fixed line of the polygon, I add it to the lines drawn by >>> the annotate callback, since update time is no longer an issue. >>> >>> Regarding why your example doesn't work, I don't know, but it might have >>> to do with the fact that you fix the pixbuf format to RGB24 without checking >>> whether your pixbuf has an alpha channel. >>> >>> Good luck! >>> >>> Also, next time, please send the questions to the gtk-list. I take the >>> freedom of CC:ing it. >>> >>> Regards, >>> Dov >>> >>> 2009/4/10 Eduardo J. Andres >>> >>> Dear Dov I have been working with the widget during last days and have had not success to get my requirement. It is to draw with cairo and the mouse poligons and lines as overlay of the image pixbuf. Poligons will have a lot of points so the best aproach I have seen is to draw them on the pixbuf an draw the new pixbuf to the image. But it is so slow doing it on the "image_annotate" handler. I have seen a number of issues at that point, for example the idea to get the cairo surface from your tutorial int img_width = gdk_pixbuf_get_width(pixbuf); int img_height = gdk_pixbuf_get_height(pixbuf); cairo_surface_t *surface = cairo_image_surface_create_for_data(gdk_pixbuf_get_pixels(pixbuf), CAIRO_FORMAT_RGB24, img_width, img_height, gdk_pixbuf_get_rowstride(pixbuf)); cairo_t *cr = cairo_create (surface); cairo_translate(cr, -shift_x, -shift_y); cairo_scale(cr, scale_x, scale_y); // Now do any cairo commands you want, but you have to swap // R and B in set_source_rgba() commands because of cairo and // pixbuf incompabilitities. cairo_set_source_rgba (cr, 0,0,1.0,0.5); cairo_arc(cr, -1, 0, 3, 0.0, 2*G_PI); cairo_fill(cr); cairo_set_source_rgba (cr, 1.0,0,0,0.5); only works when you do inside the image annotate. In any other situation, the cairo drawing does not get the color. I have got, for example, the cairo surface from the pixbuf inside the gtk_image_viewer_new() function and draw directly there , but it
Re: Font style in widget->size_request
The problem seems to be that you're using Cairo to render the text but use
Pango to calculate the text extents. This doesn't make a lot of sense to me.
Just use Pango for everything, or just use Cairo for everything (it has
functionality to determine extents of text layouts as well), that should fix
the problem.
Sounds a little bit "bump on the head"-ish to just say it like this but it's
really the only viable solution, because at the level you're doing this
Pango and Cairo have nothing in common.
Regards,
M.
On Tue, Mar 24, 2009 at 7:18 PM, David Brigada wrote:
> Hello,
>
> I am writing a graph widget for use in GTK+ applications. I'm trying to
> calculate the minimum size for the widget from the text along the axes of
> the graph. I use Cairo to draw the text, so I'm using the
> cairo_text_extents functions to calculate their sizes.
>
> However, I'm running into a problem where widget->style->font_desc does not
> seem to be returning a valid Pango font description. When I call
> pango_font_description_get_size on the font_desc, it returns 10 *
> PANGO_SCALE, which seems to be a default value when the style isn't
> initialized. This causes my function to assume the incorrect font size when
> calculating its size request. I tried calling gtk_widget_ensure_style on my
> widget before accessing the font_desc element, but that does not help.
>
> Here's a code snippet:
>
> static void gtk_graph_size_request(GtkWidget *widget,
>GtkRequisition *requisition)
> {
>gdouble bfont_sz;
>/* ... */
>gtk_widget_ensure_style(widget);
>bfont_sz = pango_font_description_get_size(
>widget->style->font_desc) /
>(gdouble)PANGO_SCALE;
>
>/* bfont_sz here is 10, for my theme, it should be 13.3 */
>
>/* ... */
> }
>
> I'm running GTK+ 2.14.7, (2.14.7-4+b1 as shipped by Debian sid), GLib
> 2.20.0 (2.20.0-2), ATK 1.24.0 (1.24.0-2), Pango 1.22.4 (1.22.4-3), and Cairo
> 1.8.6 (1.8.6-2+b1).
>
> Let me know if you need any more information. Thanks in advance for your
> help!
>
> Thanks,
> David Brigada
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: I would like GtkVPaned whose can manage more than 2 panes
You can put multiple VPaneds one into another. On Sun, Dec 28, 2008 at 7:22 PM, KLEIN Stéphane wrote: > Hi, > > I would like a widget container with two or more panes. The divisions > between the panes are adjustable by the user by dragging a handle. > > To summarize I would like GtkVPaned whose can manage more than two pane. > > Is there one widget like it in one other project ? If not, how can I do > that ? > > About the widget behavior, I would like something like in splited buffer > in gvim. > > Thanks for your help, > Stephane > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem in connecting signal handler with gtk_builder in C++ code
The symbols must be non-mangled (look up C++ symbol mangling on Google), or, but this is really only theoretical, you would need to provide the already mangled symbol names to Builder. However, while theoretically not impossible, this is highly unpractical (and by highly i mean you really, really don't want to go there). Your solution is to have the functions in question having C linkage: prefix them with: extern "C" in the source code, e.g. extern "C" void some_callback (.) M. 2008/12/1 PT SWing <[EMAIL PROTECTED]> > Hi, all: > > I knew gtk+ was a C builded technic, but now i have to use it in C++ codes, > and the problem i encountered is that, i use *gtk_builder_connect_signals*to > connect all the widgets from the xml to the handler function, just as > what micahcarrick's tutorial do in C, and complied and link it with > -export-dynamic, > > *$ g++ entry.cpp `pkg-config --libs --cflags gtk+-2.0` -export-dynamic* > > no problem happens. > > But when i run it, the program just couldn't find the handler function, > reporting : > > [EMAIL PROTECTED]:~/Programming/linux/entry$ ./a.out > > (a.out:12605): Gtk-WARNING **: Could not find signal handler > 'on_window_destroy' > > (a.out:12605): Gtk-WARNING **: Could not find signal handler > 'on_exit_clicked' > > (a.out:12605): Gtk-WARNING **: Could not find signal handler > 'on_add_clicked' > ^C > > I knew there must be something different with the g++ linker and the > -export-dynamic, but i have no clue how to solve this. > > Thanks so much if anyone could give me a hand on this. thanks > > ps: a simple test code was in the attach file. you will find that the > c_style code works very well, but not the cpp one. > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: List Scrolling
Something like you take the coordinates at press, and on subsequent motion events you take the coordinates again, with the velocity depending on the position/distance from the original coordinates. On "unpress" (release) you stop the scroll. No? On Wed, Nov 26, 2008 at 2:22 PM, Demetris Zavorotnichenko < [EMAIL PROTECTED]> wrote: > Hi to all. > > I have a Tree View on a scrolling window. I need to be able to scroll it by > pressing on the tree and dragging it. > > I need this since the application runs on a Touchscreen device so I don't > want to Drag the window Up and Down from the scroll bars but by pressing on > it and dragging. > > How would I do this? I mean, if I take an event->y then I don't know the > direction. So how would this be done ? > > Please help out guys. > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Text layout in a GtkLabel
I meant "in this context", sorry. On Thu, Oct 30, 2008 at 5:25 AM, Milosz Derezynski <[EMAIL PROTECTED]> wrote: > What is the difference between "character formatting" and "layout > formatting" here? > > On Thu, Oct 30, 2008 at 5:02 AM, Ian Puleston > <[EMAIL PROTECTED]> wrote: >>> -Original Message- >>> From: Milosz Derezynski [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, October 29, 2008 5:24 PM >>> >>> You can use gtk_label_set_markup() and set the internal Layout of the >>> Label using Pango markup, or use gtk_label_get_layout() (it's safe to >>> call this function without realizing the widget first); that way >>> actually have the Label's/a PangoLayout and can modify it as you were >>> used to. There's also gtk_label_get/set_attributes() by which you >>> don't need to get the actual Layout but that runs down to the same >>> thing. >> >> Thanks, I'll look into using gtk_label_get_layout(). >> >> But on the suggestion to use gtk_label_set_markup, that's actually what I >> meant below when I said "with Pango meta formatting" (sorry, was working on >> something else and got the terminology confused, I meant markup formatting). >> From what I see of the Pango Markup language it doesn't seem to provide for >> formatting the layout, just for character formatting, or am I missing >> something? >> >> Ian >> >>> 2008/10/30 Ian Puleston <[EMAIL PROTECTED]>: >> >>> > The GtkLabel supports setting a Pango attributes list or text with >>> Pango >>> > meta formatting, but that is all character formatting. I think I >>> could >>> > achieve what I want using a Pango layout, but I can't see any way to >>> use >>> > that with a GtkLabel. >> >> >> > > > > -- > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. > [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge > jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Text layout in a GtkLabel
What is the difference between "character formatting" and "layout formatting" here? On Thu, Oct 30, 2008 at 5:02 AM, Ian Puleston <[EMAIL PROTECTED]> wrote: >> -Original Message- >> From: Milosz Derezynski [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 29, 2008 5:24 PM >> >> You can use gtk_label_set_markup() and set the internal Layout of the >> Label using Pango markup, or use gtk_label_get_layout() (it's safe to >> call this function without realizing the widget first); that way >> actually have the Label's/a PangoLayout and can modify it as you were >> used to. There's also gtk_label_get/set_attributes() by which you >> don't need to get the actual Layout but that runs down to the same >> thing. > > Thanks, I'll look into using gtk_label_get_layout(). > > But on the suggestion to use gtk_label_set_markup, that's actually what I > meant below when I said "with Pango meta formatting" (sorry, was working on > something else and got the terminology confused, I meant markup formatting). > From what I see of the Pango Markup language it doesn't seem to provide for > formatting the layout, just for character formatting, or am I missing > something? > > Ian > >> 2008/10/30 Ian Puleston <[EMAIL PROTECTED]>: > >> > The GtkLabel supports setting a Pango attributes list or text with >> Pango >> > meta formatting, but that is all character formatting. I think I >> could >> > achieve what I want using a Pango layout, but I can't see any way to >> use >> > that with a GtkLabel. > > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Text layout in a GtkLabel
You can use gtk_label_set_markup() and set the internal Layout of the Label using Pango markup, or use gtk_label_get_layout() (it's safe to call this function without realizing the widget first); that way actually have the Label's/a PangoLayout and can modify it as you were used to. There's also gtk_label_get/set_attributes() by which you don't need to get the actual Layout but that runs down to the same thing. M. 2008/10/30 Ian Puleston <[EMAIL PROTECTED]>: > > Hi, > > > > I've implemented a help mechanism where clicking on a help icon pops up a > help message, and am using a GtkMessageDialog to do it. It's pretty simple > and is working fine, except that in one case I want to display a numbered > list and to make it look neat I want to have all the text apart from the > numbers indented. But I can't find an easy way to do that with a GtkLabel > which is what the GtkMessageDialog uses to display the text. > > > > The GtkLabel supports setting a Pango attributes list or text with Pango > meta formatting, but that is all character formatting. I think I could > achieve what I want using a Pango layout, but I can't see any way to use > that with a GtkLabel. > > > > Anyone know if there's any way to format the layout of text in a GtkLabel? > > Otherwise, what would be the best widget to use to display text with a > layout like this? > > Ian > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Combo Box Problem
Sounds really odd if it's a ComboBoxText. Could you make all of the code available somewhere? Cheers, M. 2008/9/25, William Ramsay <[EMAIL PROTECTED]>: > Hi all, > > I'm doing a list box with 24 text entries - the list represents the hours > of the day. Oddly enough, I end up with about ten blank lines when I drop > down the list. All my entries are there and it indexes correctly if I set > a default value, but no matter what I do I get the blank lines. Is this a > bug, or am I doing something wrong? Short lists work perfectly, but the > long list adds the blanks. > > I use the following procedures to create the list... > > GtkWidget *combo = gtk_combo_box_new_text (); > > gtk_combo_box_append_text (GTK_COMBO_BOX (combo), time); > > thanks > > Bill > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: lasso tool
You could use expose regions and in case the lasso size changes, only redraw the previous area covered by the lasso (i don't mean the full area btw but simply the areas covered by the lasso lines, so maybe "lines" would be more appropriate than "area"). For reference see: http://library.gnome.org/devel/gdk/stable/gdk-Event-Structures.html#GdkEventExposeand http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-queue-draw-area BTW this list is intended for development _of_ Gtk+ and not for applications using Gtk+, it would be better suited to ask on gtk-app-devel-list if this concerns an application. Am 11. August 2008 20:57 schrieb Matt Kowalczyk <[EMAIL PROTECTED]>: > Hello, > > I am trying to implement a lasso-type tool. I need to be able to load and > display a user-selected image and provide the "lasso" tool ability wherein > the user will be able to select a rectangular box within the image. > > I've been working on this all day; and though I've come _very_ close to > solving my problem; my solution is very slow. If I load an image that is say > 1.5k x 1.5k pixels and make a large selection; the performance clearly > degrades as the selection gets bigger. > > My approach was to continually clear an rectangle the size of the previous > selection (L * W) and redraw the new selection--a rectangle the size of the > selection. This works well on small selections say < 500x500px but once > outside that range the performance is terrible because it's equivalent to > repainting the entire image. > > I had to implement a double buffer scheme because I would get flickering. I > used a Pixmap to do this. > > Are there approach where in I can reduce the run-time complexity to solve > this problem? Are there ways that I can overlay the selection box over the > original image so that I don't have to redraw the original image just clear > the selection that was made? I've been working on a solution wherein instead > of redrawing the entire rectangle composing the selection, I would only > redraw the border of the selection. That means, I only have to redraw O(2W + > 2L) pixels, instead of O(W * L). Not sure if I'm headed down a dead-end road > with this one. Is GnomeCanvas something I should look at? > > The solution to only clear the pixels representing the selection clearly > improves performance. > > I'm just a newbie UI developer and wanted to solicit some suggestions as > this is my first day working with GTK and I would hate to overlook a > possibly simple solution to this problem. > > Thanks! > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Where's ZLib?
It works here. 2008/8/6 Felipe Castro <[EMAIL PROTECTED]> > Hello, > > Trying to compile XPad on a Windows 2000 machine I tried to download > this file with no success: > > http://www.zlib.net/zlib123-dll.zip > > It seems someone "stole" ZLib's site, so it doesn't work anymore. Does > anybody here knows who are the maintainers of this package? > > Thanks, > > Felipe Castro. > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
Oh yeah, 1:0 for Occam ;) 2008/7/27 Milosz Derezynski <[EMAIL PROTECTED]> > That does indeed mean it; it's what Emmanuele supposed and it turns out to > be right. > It's rather strange for a gtk+ app to do this, is there some kind of other > non-glib-based main loop running? > > 2008/7/26 Guido Berhoerster <[EMAIL PROTECTED]> > > * Emmanuele Bassi <[EMAIL PROTECTED]> [2008-07-26 17:56]: >> > I have no idea. the FileChooser only job is to read the file to get the >> > contents; I would expect to see a lot of read() operations. >> >> Yes, it gets only written, after the dialog is closed. >> >> > the only time when a gtk+ application writes to the recently used files >> > storage and it's not calling the GtkRecentManager API directly is when >> > the gtk+ main loop level reaches 0 - which is to say after the first >> > gtk_main() call in the whole application returns (this is needed to >> > ensure that the file is not left in an inconsistent state); all other >> > writes are definitely explicit. I seriously doubt that vim spins the >> > main loop and the stops it at every key press - it would be quite >> > insane. >> >> Thanks for the explanation, I'm not sure if I got it right, in >> the eventhandlers there is often code like: >> [...] >>if (gtk_main_level() > 0) >>gtk_main_quit(); >> [...] >> If gtk_main_level() returns 1 and gtk_main_quit() is called, does >> that mean that the recently used files list gets written? >> >> -- >> Guido Berhoerster >> ___ >> gtk-list mailing list >> gtk-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/gtk-list >> > > > > -- > > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. > [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge > jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
That does indeed mean it; it's what Emmanuele supposed and it turns out to be right. It's rather strange for a gtk+ app to do this, is there some kind of other non-glib-based main loop running? 2008/7/26 Guido Berhoerster <[EMAIL PROTECTED]> > * Emmanuele Bassi <[EMAIL PROTECTED]> [2008-07-26 17:56]: > > I have no idea. the FileChooser only job is to read the file to get the > > contents; I would expect to see a lot of read() operations. > > Yes, it gets only written, after the dialog is closed. > > > the only time when a gtk+ application writes to the recently used files > > storage and it's not calling the GtkRecentManager API directly is when > > the gtk+ main loop level reaches 0 - which is to say after the first > > gtk_main() call in the whole application returns (this is needed to > > ensure that the file is not left in an inconsistent state); all other > > writes are definitely explicit. I seriously doubt that vim spins the > > main loop and the stops it at every key press - it would be quite > > insane. > > Thanks for the explanation, I'm not sure if I got it right, in > the eventhandlers there is often code like: > [...] >if (gtk_main_level() > 0) >gtk_main_quit(); > [...] > If gtk_main_level() returns 1 and gtk_main_quit() is called, does > that mean that the recently used files list gets written? > > -- > Guido Berhoerster > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Using g_signal_connect in class
I think he meant that in order to use the function with g_signal_connect(), a C linkage is not needed (and i think this is actually right, too). 2008/7/19 Chris Vine <[EMAIL PROTECTED]>: > On Sat, 19 Jul 2008 13:42:58 +0200 > Jean Bréfort <[EMAIL PROTECTED]> wrote: > > Le samedi 19 juillet 2008 à 12:29 +0100, Chris Vine a écrit : > > > This will work with gcc/g++ but it is not standard conforming, as > > > static class functions do not have C linkage, and the C++ standard > > > states that functions otherwise identical with C++ and C linkage are > > > different types. > > > > > > To be standard conforming you should use a friend function (if it > > > needs access to private data) declared extern "C". > > > > The extern "C" declaration is not needed. > > Are you saying there is a misprint in the C++ standard, or that > with the particular compiler you use it is not necessary? If the > latter, what part of my post do you disagree with? > > Chris > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop
A function is just a piece of code, so if you call a function in T1 from T2, you still call it in the context of T2; the only thing really helping here is having a maincontext in T1 and T2, and using a g_idle_add() *on* the maincontext of T1 (but the code that adds it can be called from T2) so the idle handler can call some code with the context of T1. Am 15. Juli 2008 16:38 schrieb Ed James <[EMAIL PROTECTED]>: > Just a guess, but I'd try putting a function in Thread 1 that emits the > signal, but call > that function from Thread 2. This way, Thread 2 controls when the signal > is emitted, > but the signal is still handled by Thread 1. Never actually tried this > myself, though, > so I don't know for sure if one thread can call a function in another > thread. > > Ed James > > 2008/7/15 HASWANI HARISH-VCKR47 <[EMAIL PROTECTED]>: > >> Hi All, >> >> I am a beginner to gtk APIs. >> My query is : >> - In Thread T1 I am calling g_main_loop() >> - In Thread T2 I am emitting a signal through >> g_signal_emit_by_name(G_OBJECT, signal-name); >> >> I saw that signal handler is running in Thread2 context. I want that it >> should run in Thread 1 context. How I can achieve this? >> >> >> >> > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Proper handling of unicode strings
It's "safe" in the aforementioned sense, but if you want to properly count characters in the UTF-8 string, you should use g_utf8_strlen() instead. 2008/7/7 LCID Fire <[EMAIL PROTECTED]>: > That's great - simplifies a lot of things. But since one character might > need more space than a gchar is it save to call strlen on that string? > > Thanks > > Milosz Derezynski wrote: > > Yes an UTF-8 string a NULL-terminated ASCII-compatible string. For all > > purposes except where you need to read it character-by-character (e.g. > > Gtk+/Pango "reading" the string to display it), you can just treat it > > like a normal ASCII string. > > > > 2008/7/6 LCID Fire <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > > > I'm currently in the process of writing an application which needs to > > support unicode - but I'm still a little confused of how to properly > > handle it. Maybe someone can help me out here. > > > > First of is it valid for e.g. utf8 strings to assume they are NULL > > terminated? Would it be valid to call g_strdup on a utf8 string? > > > > If not (and this is done quite often in the unicode glib part) I > assume > > I have to add the byte length of a string, right (which will bloat > > function declarations)? > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Proper handling of unicode strings
Yes an UTF-8 string a NULL-terminated ASCII-compatible string. For all purposes except where you need to read it character-by-character (e.g. Gtk+/Pango "reading" the string to display it), you can just treat it like a normal ASCII string. 2008/7/6 LCID Fire <[EMAIL PROTECTED]>: > I'm currently in the process of writing an application which needs to > support unicode - but I'm still a little confused of how to properly > handle it. Maybe someone can help me out here. > > First of is it valid for e.g. utf8 strings to assume they are NULL > terminated? Would it be valid to call g_strdup on a utf8 string? > > If not (and this is done quite often in the unicode glib part) I assume > I have to add the byte length of a string, right (which will bloat > function declarations)? > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_window_move
Ooops, obviously i meant
while (g_timer_elapsed(timer) < 0.5)
not "> 0.5"
2008/6/18 Milosz Derezynski <[EMAIL PROTECTED]>:
> What is probably better is to use gdk_flush() after the execution of
> gtk_window_move() or _resize(), and after that make sure that you run the
> main event loop with gtk_main_iteration(); you can use a GTimer to determine
> the time elapsed. Obviously, and also since this involves the windowing
> system whose timing can not really be predicted, this is nothing for time
> critical applications and can't be very precise, but tweaks of the mentioned
> mechanism are surely possible.
>
> An example would look like this (off the top of my head, might contain some
> errors):
>
> GTimer *timer = g_timer_new();
> gtk_window_move(GTK_WINDOW(window), x, y);
> g_timer_reset(timer);
> while(g_timer_elapsed(timer) > 0.5)
> while(gtk_events_pending())
> gtk_main_iteration();
> g_timer_destroy(timer);
>
> Hopefully someone has a more elegant solution :)
>
> -- Milosz
>
> 2008/6/18 Craig Harding <[EMAIL PROTECTED]>:
>
> I'm trying to move a gtk window multiple times within a period of time
>> but it seems that it doesn't update the window position for each
>> window move until gtk_main() is called and then all window moves are
>> done at once it seems. I want to move a window with a usleep call
>> inbetween window moves.
>>
>> Can any provide me with some guidance? Is there a flush or update call
>> I'm missing?
>>
>> Below is my code..
>>
>> #include
>> #include
>>
>> int main (int argc, char **argv) {
>>
>> GtkWidget *window;
>> int w=200, h=200;
>> int x, y;
>>
>> x=100;
>> y=50;
>>
>> gtk_init(&argc, &argv);
>> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>> gtk_widget_show_all(window);
>> g_signal_connect (G_OBJECT (window), "delete-event", gtk_main_quit,
>> NULL);
>> usleep(50);
>> printf("sleep fnished\n");
>> gtk_widget_show(window);
>> gtk_window_resize (GTK_WINDOW (window), w, h);
>> usleep(50);
>> printf("sleep fnished\n");
>> gtk_window_move (GTK_WINDOW (window), x, y);
>>
>> usleep(50);
>> gtk_widget_show(window);
>> gtk_window_resize (GTK_WINDOW (window), w+300, h);
>>
>> printf("gtk_main()\n");
>> gtk_main();
>>
>> return 0;
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_window_move
What is probably better is to use gdk_flush() after the execution of
gtk_window_move() or _resize(), and after that make sure that you run the
main event loop with gtk_main_iteration(); you can use a GTimer to determine
the time elapsed. Obviously, and also since this involves the windowing
system whose timing can not really be predicted, this is nothing for time
critical applications and can't be very precise, but tweaks of the mentioned
mechanism are surely possible.
An example would look like this (off the top of my head, might contain some
errors):
GTimer *timer = g_timer_new();
gtk_window_move(GTK_WINDOW(window), x, y);
g_timer_reset(timer);
while(g_timer_elapsed(timer) > 0.5)
while(gtk_events_pending())
gtk_main_iteration();
g_timer_destroy(timer);
Hopefully someone has a more elegant solution :)
-- Milosz
2008/6/18 Craig Harding <[EMAIL PROTECTED]>:
> I'm trying to move a gtk window multiple times within a period of time
> but it seems that it doesn't update the window position for each
> window move until gtk_main() is called and then all window moves are
> done at once it seems. I want to move a window with a usleep call
> inbetween window moves.
>
> Can any provide me with some guidance? Is there a flush or update call
> I'm missing?
>
> Below is my code..
>
> #include
> #include
>
> int main (int argc, char **argv) {
>
> GtkWidget *window;
> int w=200, h=200;
> int x, y;
>
> x=100;
> y=50;
>
> gtk_init(&argc, &argv);
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_widget_show_all(window);
> g_signal_connect (G_OBJECT (window), "delete-event", gtk_main_quit,
> NULL);
> usleep(50);
> printf("sleep fnished\n");
> gtk_widget_show(window);
> gtk_window_resize (GTK_WINDOW (window), w, h);
> usleep(50);
> printf("sleep fnished\n");
> gtk_window_move (GTK_WINDOW (window), x, y);
>
> usleep(50);
> gtk_widget_show(window);
> gtk_window_resize (GTK_WINDOW (window), w+300, h);
>
> printf("gtk_main()\n");
> gtk_main();
>
> return 0;
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Memory leak tools for Gtk
You could try RefDbg: http://refdbg.sourceforge.net/ It's a debugger specifically written for the task of debugging GObject reference counting. Am 12. Juni 2008 13:53 schrieb Ratna Kishore <[EMAIL PROTECTED]>: > Hi, > Is there any tool avialable to identify the memory leaks in the gtk > programs specifically? > I know there is Valgrind, but I think it is for the linux based programs > which is not specific to the Gtk. I suspect that Valgring may not be able to > idetify the ref and unref counts which will be gtk programs. > > So I want to know if there is any tool avialable for specific to the gtk > programs which can identify the memory leaks? Which can list down the > current statistics of a gtk program? i.e. current memory blocks allocated to > the widgets and reference counts of each widgets, like on. > > Please provide me this information if any one know about this. > > thanks > kishore > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Progressbar
try self.step = 1./len(list) 2008/5/19 Gorshkov <[EMAIL PROTECTED]>: > Sandra Derbring wrote: > > Hello, > > > > I have a problem with a progressbar. I want, for every file I look into, > > for the bar to show some progress, so that while you wait for the > > program to finish, the whole time can see the bar moving. When I > > implement it, all that happens is that the bar gets filled first after > > the program's finished. How do I make it show during the process? > > > > self.progressbar = gtk.ProgressBar() > > self.progressbar.show() > > > > self.step = 1/len(list) > > > > for file in list: > > self.x += self.step > > #do smth with file > > self.progressbar.set_fraction(self.x) > > > > > > gtk_progress_bar_set_fraction(pb, dpercent); >gtk_progress_bar_set_text(pb, "Your text here"); >while (gtk_events_pending()) >gtk_main_iteration(); > > > > what you're missing is to force the updates to occur AT THE TIME, and > not have them sit in the queue untill you're finished. > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to put widget in CUSTOM GtkContainer
I don't believe that using set_parent() will actually place the widget
inside the container; try gtk_container_add(GTK_CONTAINER(grid), widget);
instead
2008/4/29 Tomas Carnecky <[EMAIL PROTECTED]>:
> AlannY wrote:
> > Hi there, my name is Alan and I have some troubles with GtkContainer.
> >
> > It's about 2 days, I already have spent trying to solve it, but I (i
> > guess) can't.
> >
> > I'm writing a program, which looks like:
> > +-+
> > | Main Window (GtkWindow) |
> > | +-+ |
> > | | My custom widget| |
> > | | +-+ | |
> > | | | GtkButton | | |
> > | | +-+ | |
> > | +-+ |
> > +-+
> >
> > I need some approach to place a GtkButton in my custom widget. I found
> > (from GTK+ sources) that GtkTreeView, GtkNotebook (and others) inherits
> > from GtkContainer . So, I decide to inherit my widget not from
> > GtkWidget, but from GtkContainer.
> >
> > typedef struct _GridGrid;
> > typedef struct _GridClass GridClass;
> >
> > struct _Grid
> > {
> >GtkContainer parent;
> > };
> >
> > struct _GridClass
> > {
> >GtkContainerClass parent_class;
> > };
> >
> > And my _get_type function looks like:
> >
> > GtkType
> > grid_get_type ()
> > {
> >static GtkType grid_type = 0;
> >
> >if (!grid_type)
> > {
> >const GTypeInfo object_info =
> >{
> > sizeof (GtkContainerClass),
> > NULL,
> > NULL,
> > (GClassInitFunc) grid_class_init,
>
> That still isn't the whole code! What does grid_class_init() do? Attach
> both the whole grid header and source file to the email.
>
> > NULL,
> > NULL,
> > sizeof (Grid),
> > 0,
> > (GInstanceInitFunc) grid_init,
> > NULL,
> >};
> >
> >grid_type = g_type_register_static (GTK_TYPE_CONTAINER,
> > g_intern_static_string ("Grid"), &object_info, 0);
> > }
> >
> >return grid_type;
> > }
> >
> > The main feature of this function is GTK_TYPE_CONTAINER ;-) You see ;-)
> >
> > Next in my program, I'm creating my widget (grid) with that:
> >
> > [...]
> > grid = grid_new ();
> > gtk_container_add (GTK_CONTAINER (window), grid);
> > [...]
> >
> > So, my problem starts here: at _new() function. I want to create
> > GtkButton and place it in my widget.
> >
> > GtkWidget*
> > grid_new ()
> > {
> >Grid *grid;
> >
> >grid = g_object_new (grid_get_type (), NULL);
> >
> >button = gtk_button_new_with_label ("Test");
> >gtk_widget_set_parent (button, GTK_WIDGET (grid));
> >gtk_widget_show (button);
> >
> >return GTK_WIDGET (grid);
> > }
> >
> > Everything right and works without errors ;-) But nothing happens. I
> > can't see a GtkButton ;-)
> >
> > How to solve it? I need some way for "draw" (expose) GtkButton in my
> > custom widget ;-) How to do it?
> >
> > P.S. I extremely think, that I just forgot something. But there are no
> > tutorials about it ;-) "Information vacuum", so I decide to ask in
> > mailing-lists.
> > P.P.S. Only information about custom widget creation is a GTK sources,
> > but (even with it) I can't solve my problem. ;-)
> > P.P.P.S. Also, I really want to understand how GtkBox works ;-)
>
> And stop creating new threads... This is your third thread in
> gtk-app-devel where you ask the same question.
>
> tom
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkCombobox
gtk_tree_model_iter_n_children(GTK_TREE_MODEL(gtk_combo_box_get_model(combo)),
NULL);
is better, since it uses public API
2008/4/10, Alexander Semenov <[EMAIL PROTECTED]>:
>
> Hi. You can do something like this.
>
> #include
>
> int
> main (int argc, char *argv[])
> {
> GtkWidget *window, *combo;
> GtkTreeModel *model;
>
> gtk_init (&argc, &argv);
>
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> combo = gtk_combo_box_new_text ();
> gtk_combo_box_append_text (GTK_COMBO_BOX (combo), "1");
> gtk_combo_box_append_text (GTK_COMBO_BOX (combo), "2");
> gtk_combo_box_append_text (GTK_COMBO_BOX (combo), "3");
> gtk_container_add (GTK_CONTAINER (window), combo);
>
> model = gtk_combo_box_get_model (GTK_COMBO_BOX (combo));
> g_assert (model);
> g_print ("%d\n", GTK_LIST_STORE (model)->length);
>
> gtk_widget_show_all (window);
> gtk_main ();
> return 0;
>
> }
>
> On Thu, 2008-04-10 at 18:13 +0530, Harinandan S wrote:
> >
> > Hi All,
> >
> > How can I find the number of entries I have in GtkCombobox during
> > runtime? I use gtk_combo_box_append_text for appending strings into
> > the combo box list.
> >
> > I'm using GTK+ 2.12.2
> > --
> > Regards,
> > Harinandan S
>
> > ___
> > gtk-list mailing list
> > gtk-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-list
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: problems with pixbuf
IIRC Pixbufs used not to be GObjects some way back. 2008/3/30, Moises <[EMAIL PROTECTED]>: > > Sorry for last email > > I put g_type_init(); before I call > "gdk_pixbuf_new_from_file" and I can read the file, > but I have a question: > > Why I need to call g_type_init() before of call > gdk_pixbuf_new_from_file? > If it used gdk_pixbuf_new_from_file before , but never > I need to use g_type_init(). > > > > > > > > > ¡Capacidad ilimitada de almacenamiento en tu correo! > No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: > http://correo.yahoo.com.mx/ > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Font class/struct documentation
As far as i am aware, the gtk_paint_ functions will just use pango-cairo code internally to render the text anyway; doing it yourself is simply more direct API-wise but that's it. As for how to obtain that information from Pango (TT font or not), maybe someone else can answer it, i don't know the insides that much. -- Milosz 2008/3/29, Igor Korot <[EMAIL PROTECTED]>: > > Hi, Milosz, > > 2 questions: > > 1. What is the difference between those 2? > > 2. Is there a way to discover if the font is a "TrueType"? > > > > Thank you. > > > -Original Message- > From: Milosz Derezynski > Sent: Mar 28, 2008 4:36 PM > To: Igor Korot > Cc: gtk-list@gnome.org > Subject: Re: Font class/struct documentation > > Fonts are now being handled by Pango and drawing can happen either > directly through Cairo: > http://library.gnome.org/devel/pango/1.20/pango-Cairo-Rendering.html > > or the Style API (note to use the *_paint_* variants, e.g. > gtk_paint_layout, not _draw_layout): > http://library.gnome.org/devel/gtk/stable/GtkStyle.html > > HTH > > 2008/3/28, Igor Korot <[EMAIL PROTECTED]>: > > > > Hi, ALL, > > Browsing through the GTK/GDK documentation, I found this: > > > > http://library.gnome.org/devel/gdk/stable/gdk-Fonts.html > > > > The problem with it is that 98% of functions there said to > > be deprecated. > > > > So, here is the question: Is there a doc of functions I > > can use to get the font info that are _not_ deprecated? > > And where is the doc on them? > > > > Thank you. > > ___ > > gtk-list mailing list > > gtk-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-list > > > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Font class/struct documentation
Fonts are now being handled by Pango and drawing can happen either directly through Cairo: http://library.gnome.org/devel/pango/1.20/pango-Cairo-Rendering.html or the Style API (note to use the *_paint_* variants, e.g. gtk_paint_layout, not _draw_layout): http://library.gnome.org/devel/gtk/stable/GtkStyle.html HTH 2008/3/28, Igor Korot <[EMAIL PROTECTED]>: > > Hi, ALL, > Browsing through the GTK/GDK documentation, I found this: > > http://library.gnome.org/devel/gdk/stable/gdk-Fonts.html > > The problem with it is that 98% of functions there said to > be deprecated. > > So, here is the question: Is there a doc of functions I > can use to get the font info that are _not_ deprecated? > And where is the doc on them? > > Thank you. > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_idle_add() deprecation? (was Re: Help with call to function)
In favor of g_idle_add and g_timeout_add; Christian mentioned the variants with the gtk_ prefix not the g_ Glib based ones. 2008/2/17, Chris MacGregor <[EMAIL PROTECTED]>: > > On 02/17/2008 08:31 AM, Christian Bünnig wrote: > > Btw.. gtk_timeout_add() and gtk_idle_add() has been deprecated. > > > Deprecated in favor of what alternative? The apparently-latest docs > (unstable or 2.15) don't give any clue about the deprecation or the > recommended alternative. > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: general build question
Add -lstdc++ as flag to the compilation (you missed linking to libstdc++). -- Milosz 2007/11/19, Andres Gonzalez <[EMAIL PROTECTED]>: > > folks, > > I am sorry to ask such elementary questions about building Gtk > applications but I am a bit confused and cannot find the answers > elsewhere. I get the following error when linking a simple test > application I have written: > > ld: warning: cannot find entry symbol _start; defaulting to 08048764 > main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' > > I get the same __gxx_personality_v0 error for every file that compiled > in my build. > > I am using `pkg-config --cflags gtk+-2.0` on the g++ command line for > every compilation. And I am using `pkg-config --libs gtk+-2.0` on the > ld command line for the linking. > > I am confused about what the pkg-config actually does and what this > back-quoted string actually is telling the compiler to do. I have > never seen this construction before. So... > > Q: what actually does pkg-config do? > Q: do I use `pkg-config --cflags gtk+-2.0` if I am using g++ and not > gcc? > Q: what is the reference to: __gxx_personality_v0 ?? > Q: how do I resolve that undefined reference error? > > > Thanks for any guidance you can give this newbee... > > -Andres > > > > > > > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to redraw the blanked section of a widget after a expose-event?
This forces the XOverlay element (in this case xvimagesink?) to redraw: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstxoverlay.html#gst-x-overlay-expose , although your actual code would be of much interest in order to help. -- Milosz On 9/27/07, krist misra <[EMAIL PROTECTED]> wrote: > Hi Paul, > Thanks for your reply, generally for the static stuff, such as text or a > picture, it can be saved and then redrawed after expose-event occurs, but > how can i save and redraw it for video that keeps moving on? I try to set > the xviamge output to the exposed widget one more time in the expose-event > handler, I thought it should rerender the covered part, but in fact it does > not act as what i was thinking. > I am not sure where I should post this question, maillist of gstreamer or > that of gtk... > Thanks > > K.M > > > > On 9/27/07, Paul Davis <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-09-27 at 10:42 +0800, krist misra wrote: > > > Hi experts, > > > > > > I am using GTK+ and gstreamer to capture and show the video frames, I > > > created a drawable widget using gtk_drawing_area_new() and using > > > xvimage element of gstreamer to render the video, I also connected > > > them by a gstreamer function gst_x_overlay_set_xwindow_id(), so the > > > video frames rendered by xvimage can show in the widget, now it works > > > well. > > > > > But I encounter a problem that if part of the drawable widget being > > > covered by a menu or something, when the menu disappears, the covered > > > section keeps blank, even other part of the widget still show the > > > video. > > > > an expose event handler is required to *redraw* the area specified in > > the expose event. receipt of this event means (generally speaking) that > > whatever the contents of the window in that area used to be, they are > > lost and needed to be recomputed/redrawn. > > > > > > > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Drag-n-drop between tabs
The mechanism i'd implement would be: - Create something that can serve as a container for other widgets, and add an interface to it for being a DND-proxy (that's easiest done in gtkmm really, with C Gtk+, it's of course also doable) - Use that in the notebook tabs - Configure it to proxy DND for something that's inside the tabs (could be basically anything but of it's probably going to be something in the tab) - In that thing, install an Gtk::Widget::drag_motion handler, to determine if the give type can be accepted, and a handler for Gtk::Widget::drag_leave So basically the proxy system would determine whether something can be accepted at all, and change the mouse cursor to a 'drop' cursor (i don't know off head which X cursor this is), if, and only if the type can be accepted, then a timer is started and some code flips the notebook page after, let's say 1.5 seconds (sound reasonably short and with good margin for error, so one doesn't go about devastating his UI by dragging things around accidentally). The drag-leave handler would be responsible for resetting the cursor shape for the relevant GdkWindow, and to stop the timer, and abort other pending stuff that would be started when a drop candidate has entered the tab region. On 9/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I am interested in enhancing the drag-n-drop functionality of the GIMP > and am unable to find whether GTK+ supports the feature I desire. > > The GIMP uses a notebook widget for docking various windows and it is > often convenient to have the Layers window and Channels present in the > same notebook (as shown in the first figure in > http://docs.gimp.org/en/gimp-concepts-docks.html). The problem I wish > to solve is being able to drag a layer from the Layers tab over to > the Channels tab. This is currently only possible (to my knowledge) if > I detach one of the tabs and thus far I have been unable to find how > this would be implemented. > > If there is a way to do this, I would appreciate if someone could > point me in the right direction. If not, would it be feasible to > enhance the notebook widget so that hovering the pointer over a tab > while a mouse button is depressed for a certain duration (one or two > seconds) would raise that tab? > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: where are may i found more gtk widgets?
Like this: http://library.gnome.org/devel/gtk/2.10/GtkCalendar.html ? On 9/13/07, 吴小虎 <[EMAIL PROTECTED]> wrote: > the gtk+ release seem has not a widget to let user select date or time from > popup window, just like combo box. i see evolution has such widget, is > someone already develop such widget? > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying "all nodes below
this one have changed") would be _very_ welcome for gtkmm, because right
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const& track,
Gtk::TreeModel::iterator & iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? "GtkTreeModelTransactional"?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say "yeah", and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> >
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> >
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
>
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model. After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed. This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.
>
> I think a much better solution would be to be able to group a bunch of
> changes together in a kind of "atomic changeset" which is then emitted
> with a single signal. All connected views/models could then process the
> full changeset in one pass. (Possibly this could also add/remove ranges
> of nodes, etc).
>
>
> regards,
>
> -kris.
> ___
> gtk-devel-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
Just FWIW, can we agree on one meaning of "transactional"?
For me, the fact that the model shouldn't have to know about the number of
views showing it has nothing to do with transactionality:
> there may be multiple views on the model, and when changing the model, one
> should not be required to know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
I think the most sensible meaning is the one we e.g. know from SQL and which
Kris mentioned: One atomic changeset which can be "committed" to the model
in one run. (It can probably not be rolled back, or if it would be possible,
then it'd be quite expensive, but that's not really the point anyway).
As for the model-should-be-view-ignorant issues, they have nothing to do
with transactions, but are just as valid concerns of course.
--Milosz
On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > The model itself is the source. The view is just a viewer for it.
> The
> > > > source itself doesn't change. The content of the source changes. The
> > > > view, being an observer of the model in the MVC paradigm, should
> adapt
> > > > to the changes. It should not require a sudden set and unset of its
> > > > model.
> > >
> > > I'm a big user of MVC. Although on some level I agree with you, I
> would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i use MVC a
> *lot* myself. the key point you raise is one that i had forgotten: there
> may be multiple views on the model, and when changing the model, one
> should not be required to know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying "all nodes below
this one have changed") would be _very_ welcome for gtkmm, because right
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const& track,
Gtk::TreeModel::iterator & iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id ;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? "GtkTreeModelTransactional"?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say "yeah", and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> >
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> >
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
>
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model. After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed. This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.
>
> I think a much better solution would be to be able to group a bunch of
> changes together in a kind of "atomic changeset" which is then emitted
> with a single signal. All connected views/models could then process the
> full changeset in one pass. (Possibly this could also add/remove ranges
> of nodes, etc).
>
>
> regards,
>
> -kris.
> ___
> gtk-devel-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
