tag:old.nabble.com,2006:forum-1329Nabble - Gtk+2009-11-25T07:49:00ZGTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off projects to complete application suites. Gtk+ home is <a href="http://www.gtk.org/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26515082Re: Minutes of the GTK+ Team Meeting - 2009-11-272009-11-25T07:49:00Z2009-11-25T07:49:00ZAlejandro Garcia Castro-2On Tue, Nov 24, 2009 at 10:13:20PM +0000, Emmanuele Bassi wrote:
<div class='shrinkable-quote'><br>>
<br>> [...]
<br>>
<br>> 4. Implement finger and kinetic scrolling [jjardon]
<br>> - Midori has a finger/kinetic scrolled window implementation
<br>> - Hildon has one as well
<br>> - OpenMoko had one
<br>> - would it make sense to port the feature to GtkScrolledWindow when
<br>> :gtk-touchscreen-mode is set to TRUE?
<br>> - issue: event delivery to children requires subclassing to override
<br>> current default behaviour of gtk+ widgets
<br>>
</div><br>Hi,
<br><br>some comments about the hildon kinetic scrolling widget
<br>(HildonPannableArea [1]), it was implemented using moko finger
<br>scroll, the solution was improved so basically we could consider
<br>both options the same one, some of the changes:
<br> - added API (jump-to, scroll-to)
<br> - changed children detection
<br> - added gesture signals
<br> - changed the structure of the composition
<br> - overshooting
<br> - added more events handlers
<br> - added the auto-mode
<br> - reviewed kinetics (very adapted to the N900)
<br> - etc.
<br><br>Basically it has a GdkWindow and it captures and later uses or
<br>reinjects the events to the proper children. Before that we did the
<br>test of implementing it as a modification of gtkscrolledwindow with
<br>signals, it was restricted to direct children, not an option for
<br>hildon. We decided to use the gdkwindow+reinjection solution but it
<br>created a very different code so we decided to create a new widget
<br>instead of adding the code. I agree with Kris about adding a new
<br>widget if we do not implement a new support to the event handling that
<br>removes all the gdkwindow/event hadler/signals.
<br><br>The main issues now:
<br> - Selection/dragging vs scrolling (touchscreen mode?, more complex
<br> widgets or subclassing)
<br> - Animations with timeouts in gtk are not that good (check Owen posts about
<br> that), this is something to discuss about the library
<br> - Embedding finger scroll widgets inside each other?
<br> - Double events in the callbacks, original and reinjection if
<br> widgets do not deal with them.
<br><br>I do not think this solution is a clean option, we should add clean
<br>support for this event handling, maybe using top-down widget detection
<br>in csw or adding new specific gdk event or something like that. We
<br>could check how to do that.
<br><br>Anyway, not sure if we should think about a touchscreen mode in
<br>the library, not just in the widget if we want to add this kind of
<br>features. Or if this should stay in a mobile/touchscreen specific fork
<br>(hildon/gtk) at least if we do not find any good option to include the
<br>code, was there any debate about this?
<br><br>I hope it helps.
<br><br>[1] <a href="http://maemo.gitorious.org/hildon/hildon/blobs/master/hildon/hildon-pannable-area.c" target="_top" rel="nofollow">http://maemo.gitorious.org/hildon/hildon/blobs/master/hildon/hildon-pannable-area.c</a><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26515082&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26514444AUTO: Wen Long WL Feng is out of the office (returning 2009-11-30)2009-11-25T07:13:40Z2009-11-25T07:13:40ZWen Long WL Feng<html><body>
<p><font size="2">I am out of the office until 2009-11-30.<br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2" color="#808080">Note: This is an automated response to your message </font><b><font size="2">"gtk-devel-list Digest, Vol 67, Issue 40"</font></b><font size="2" color="#808080"> sent on </font><b><font size="2">11/25/09 20:00:17</font></b><font size="2" color="#808080">. <br>
</font><font size="2" color="#808080"><br>
</font><font size="2" color="#808080">This is the only notification you will receive while this person is away.</font></body></html><br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26514444&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26514447AUTO: Wen Long WL Feng is out of the office (returning 2009-11-30)2009-11-25T07:13:40Z2009-11-25T07:13:40ZWen Long WL Feng<html><body>
<p><font size="2">I am out of the office until 2009-11-30.<br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2"><br>
</font><font size="2" color="#808080">Note: This is an automated response to your message </font><b><font size="2">"gtk-list Digest, Vol 67, Issue 25"</font></b><font size="2" color="#808080"> sent on </font><b><font size="2">11/25/09 17:44:55</font></b><font size="2" color="#808080">. <br>
</font><font size="2" color="#808080"><br>
</font><font size="2" color="#808080">This is the only notification you will receive while this person is away.</font></body></html><br />_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26514447&i=0" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26513964How to get mute and record state of a mixer?2009-11-25T06:48:53Z2009-11-25T06:48:53ZCarlo WoodGst::Mixer has
<br><br>set_volume, set_mute and set_record.
<br><br>But there is only get_volume.
<br><br>Why isn't there a get_mute and get_record?
<br>Is that impossible, or is there another way I can get the current values?
<br><br>--
<br>Carlo Wood <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26513964&i=0" target="_top" rel="nofollow">carlo@...</a>>
<br>_______________________________________________
<br>gtkmm-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26513964&i=1" target="_top" rel="nofollow">gtkmm-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtkmm-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtkmm-f1344.html" embed="fixTarget[1344]" target="_top" >Gtkmm</a></p>tag:old.nabble.com,2006:post-26513182Next Stable Version of glibmm2009-11-25T06:04:25Z2009-11-25T06:04:25Zmichi7x7Hi all,
<br><br>when is the next stable Version of glibmm, containing Gio::Socket and
<br>others, supposed to be released?
<br><br>With regards
<br><br>Michi
<br>_______________________________________________
<br>gtkmm-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26513182&i=0" target="_top" rel="nofollow">gtkmm-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtkmm-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtkmm-f1344.html" embed="fixTarget[1344]" target="_top" >Gtkmm</a></p>tag:old.nabble.com,2006:post-26512929focus-chain; Python-API depikt2009-11-25T05:48:30Z2009-11-25T05:48:30ZJoost BehrendsHello,
<br><br>i have problems with gtk_container_set_focus_chain,
<br>as i had earlier with pygtk.
<br><br>Here my question: Can i exclude children of a container
<br>by this method from the focus_chain (as long as the
<br>focus isn't set by the mouse to the excluded widgets)
<br>or only "reorder" them ? This here from the reference
<br><br>""
<br>Sets a focus chain, overriding the one computed automatically by GTK+.
<br><br>In principle each widget in the chain should be a descendant of the container,
<br>but this is not enforced by this method, since it's allowed to set the
<br>focus chain before you pack the widgets, or have a widget in the chain
<br>that isn't always packed. The necessary checks are done when the focus chain
<br>is actually traversed.
<br>"""
<br><br>is not clear in this point. Or was
<br>gtk_container_set_focus_chain defunct for Windows anyway
<br>in 2.16.6 ?
<br><br>Currently this is the last known bug in depikt, my new
<br>Python-API in one file. depikt now supports threads, its
<br>classes are subclassable without problems. With show_all()
<br>and gdk_Pixbuf_serialize() for inlining pixbufs to Python code
<br>(analogous to gdk_pixbuf_csource, which gives nothing usable with
<br>Python) in all its minimality it already has features
<br>pygtk has not. The status will be set to "Alpha" soon.
<br><br>Thanks for reading, Joost Behrends
<br><br>_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26512929&i=0" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26512218"invisible" property of GtkTextTag2009-11-25T04:59:40Z2009-11-25T04:59:40ZSuren GrigoryanHi, in the documentation of GtkTextTag there is a sentence "The
<br>"invisible" property was not implemented for GTK+ 2.0; it's planned to
<br>be implemented in future releases." but it seems implemented and
<br>functions like gtk_text_iter_get_visible_* work correctly with that
<br>property. Maybe it's documentation bug or maybe I shouldn't use those
<br>functions and "invisible" property?
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26512218&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26510787Re: Minutes of the GTK+ Team Meeting - 2009-11-272009-11-25T02:55:31Z2009-11-25T02:55:31ZCarlos GarnachoHi Kris!,
<br><br>On mié, 2009-11-25 at 08:50 +0100, Kristian Rietveld wrote:
<div class='shrinkable-quote'><br>> On Tue, Nov 24, 2009 at 11:13 PM, Emmanuele Bassi <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26510787&i=0" target="_top" rel="nofollow">ebassi@...</a>> wrote:
<br>> > 4. Implement finger and kinetic scrolling [jjardon]
<br>> > - Midori has a finger/kinetic scrolled window implementation
<br>> > - Hildon has one as well
<br>> > - OpenMoko had one
<br>> > - would it make sense to port the feature to GtkScrolledWindow when
<br>> > :gtk-touchscreen-mode is set to TRUE?
<br>>
<br>> I don't think so. IMHO it would be better to put this in as a
<br>> GtkScrolledWindow subclass or a new class with a shared interface.
<br>> For stylus-based devices (if these are still going to be made), the
<br>> normal scrolled window would be preferred. But still touch screen
<br>> mode will be enabled in that case. Then there is also a case to be
<br>> made for embedded devices with touch screens that do not have enough
</div><br>In the future, touchscreen mode should perhaps be a per-device setting,
<br>so I think it makes some sense to have this in GtkScrolledWindow, so the
<br>behavior can be chosen based on the device that's currently interacting
<br>with it.
<br><br>> CPU/GPU power for kinetic scrolling, in which case you also want to
<br>> use a normal scrolled window with touch screen mode. (Think a touch
<br>> screen configuration panel for a copier machine, our University has
<br>> one. Apart from CPU power, the thick coating on that screen is also
<br>> not suitable for kinetic scrolling).
<br><br>That's a reasonable usecase, perhaps kinetic scrolling should also obey
<br>the gtk-enable-animations setting.
<br><br>>
<br>>
<br>> regards,
<br>>
<br>> -kris.
<br>> _______________________________________________
<br>> gtk-devel-list mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26510787&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br>> <a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26510787&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26510437Re: Controlling the hardware volume2009-11-25T02:24:59Z2009-11-25T02:24:59ZChris VineOn Wed, 25 Nov 2009 01:04:06 -0500
<br>José Alburquerque <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26510437&i=0" target="_top" rel="nofollow">jaalburquerque@...</a>> wrote:
<div class='shrinkable-quote'><br>> On Tue, 2009-11-24 at 17:05 -0500, José Alburquerque wrote:
<br>> > The problem is that your trying to initialize a Glib::RefPtr<>&
<br>> > from a Glib::RefPtr<> (which the std::list<> contains). A
<br>> > std::list<> is not designed to store references.
<br>>
<br>> It doesn't seem clear what I was trying to say about lists not
<br>> "storing" references. I guess what I was trying to say is that I
<br>> think trying to extract a reference by dereferencing a
<br>> list<>::iterator is not doable. I was also trying to suggest another
<br>> way get at the contents of the list.
</div><br>You would expect std::list<T>::iterator::operator*() to return a
<br>reference rather than a value type (it does on my version of libstdc++),
<br>so it shouldn't fall foul of the preclusion of binding a temporary to a
<br>non-const reference.
<br><br>Isn't the explanation simply that Glib::RefPtr<Gst::MixerTrack> and
<br>Glib::RefPtr<Gst::MixerTrack const> are different types (as they are)?
<br><br>Glib::RefPtr<Gst::MixerTrack const> track = *iter (ie instantiating a
<br>new RefPtr object rather than a reference) should work because it will
<br>cause the templated version of the RefPtr's copy constructor to be
<br>invoked, which will allow implicit conversion of the RefPtr's value
<br>type.
<br><br>Chris
<br><br><br>_______________________________________________
<br>gtkmm-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26510437&i=1" target="_top" rel="nofollow">gtkmm-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtkmm-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtkmm-f1344.html" embed="fixTarget[1344]" target="_top" >Gtkmm</a></p>tag:old.nabble.com,2006:post-26509912Re: Self destructing dialog question2009-11-25T01:44:32Z2009-11-25T01:44:32ZDov Grobgeld-2<div dir="ltr">Thanks David,<br><br>It was the "destroy" signal that I was looking for. Indeed I mixed it up with the "destroy-event" signal, as I only looked at the GtkWidget signals and not at its parent signals.<br>
<br>I knew the solution was simple...<br><br>Regards,<br>Dov<br><br><div class="gmail_quote">2009/11/25 David Nečas <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509912&i=0" target="_top" rel="nofollow">yeti@...</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Nov 25, 2009 at 08:41:58AM +0200, Dov Grobgeld wrote:<br>
> Assume I have a program with a widget MyApp that has a member called<br>
> my_dialog that is created to catch its destruction as follows:<br>
><br>
> if (!priv->my_dialog) {<br>
> priv->my_dialog = my_dialog_new();<br>
><br>
> g_signal_connect(priv->my_dialog, "delete-event",<br>
> G_CALLBACK(cb_my_dialog_destroy), priv);<br>
> }<br>
> :<br>
><br>
> static gboolean cb_my_dialog_destroy(GtkWidget *widget,<br>
> GdkEvent *event,<br>
> gpointer data)<br>
> {<br>
> MyAppPriv *priv = MY_APP_PRIV(data);<br>
> priv->my_dialog = NULL;<br>
> return FALSE;<br>
> }<br>
><br>
</div>> ...<br>
<div class="im">><br>
> Trying to connect to the "destroy-event" in MyApp didn't work. I never got<br>
> any callback.<br>
><br>
> So how should this be done?<br>
<br>
</div>By inspecting the list of signals more closely.<br>
<br>
"delete-event" is sent when the delete event is received, i.e.<br>
(typically) when the user closes the window by window manager means.<br>
Receiving "delete-event" may and may not lead to actual destruction of<br>
the widget (destruction is just the default response). If you destroy<br>
the widget directly with gtk_widget_destroy(), no delete events are<br>
involved.<br>
<br>
"destroy" is emitted when the widget is destroyed. It is not an<br>
event-signal and has no "-event" in its name.<br>
<br>
g_object_add_weak_pointer() ensures clearing a pointer when an object is<br>
finalized. Note if the holder of the weak pointer can be finalized<br>
first, it needs to remove the weak pointer to avoid disaster.<br>
<br>
Yeti<br>
<br>
</blockquote></div><br></div>
<br />_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509912&i=1" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26509721Re: Self destructing dialog question2009-11-25T01:29:28Z2009-11-25T01:29:28ZDavid Nečas (Yeti)-2On Wed, Nov 25, 2009 at 08:41:58AM +0200, Dov Grobgeld wrote:
<div class='shrinkable-quote'><br>> Assume I have a program with a widget MyApp that has a member called
<br>> my_dialog that is created to catch its destruction as follows:
<br>>
<br>> if (!priv->my_dialog) {
<br>> priv->my_dialog = my_dialog_new();
<br>>
<br>> g_signal_connect(priv->my_dialog, "delete-event",
<br>> G_CALLBACK(cb_my_dialog_destroy), priv);
<br>> }
<br>> :
<br>>
<br>> static gboolean cb_my_dialog_destroy(GtkWidget *widget,
<br>> GdkEvent *event,
<br>> gpointer data)
<br>> {
<br>> MyAppPriv *priv = MY_APP_PRIV(data);
<br>> priv->my_dialog = NULL;
<br>> return FALSE;
<br>> }
<br>>
<br>> ...
<br>>
<br>> Trying to connect to the "destroy-event" in MyApp didn't work. I never got
<br>> any callback.
<br>>
<br>> So how should this be done?
</div><br>By inspecting the list of signals more closely.
<br><br>"delete-event" is sent when the delete event is received, i.e.
<br>(typically) when the user closes the window by window manager means.
<br>Receiving "delete-event" may and may not lead to actual destruction of
<br>the widget (destruction is just the default response). If you destroy
<br>the widget directly with gtk_widget_destroy(), no delete events are
<br>involved.
<br><br>"destroy" is emitted when the widget is destroyed. It is not an
<br>event-signal and has no "-event" in its name.
<br><br>g_object_add_weak_pointer() ensures clearing a pointer when an object is
<br>finalized. Note if the holder of the weak pointer can be finalized
<br>first, it needs to remove the weak pointer to avoid disaster.
<br><br>Yeti
<br><br>_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509721&i=0" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26509583Re: Hiding modal dialogs2009-11-25T01:18:18Z2009-11-25T01:18:18ZDavid Nečas (Yeti)-2On Wed, Nov 25, 2009 at 12:46:48AM +0000, John J Lee wrote:
<br>> Yes. So I was asking about hiding the dialog without closing it. It's
<br>> not obvious to me why setting the dialog's "visible" property causes its
<br>> main loop to quit.
<br><br>What are you trying to achieve?
<br><br>gtk_dialog_run() runs the dialog as modal, i.e. all other controls in
<br>the application become non-responsive.
<br><br>With a hidden modal dialog you can neither use the rest of the UI nor
<br>bring the dialog back (because you must do *something* to bring it back
<br>but the UI is non-responsive).
<br><br>So, hiding modal dialogs makes no sense at all (hence Gtk+ terminates
<br>the nested loop when the dialog is unmapped).
<br><br>Maybe you have invented some novel interaction mode where this does not
<br>apply. Maybe you approach the problem from the wrong side. How can we
<br>tell?
<br><br>Yeti
<br><br>_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509583&i=0" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26509515Re: Minutes of the GTK+ Team Meeting - 2009-11-272009-11-25T01:13:12Z2009-11-25T01:13:12ZXavier Bestel<br>On Wed, 2009-11-25 at 08:50 +0100, Kristian Rietveld wrote:
<div class='shrinkable-quote'><br>> On Tue, Nov 24, 2009 at 11:13 PM, Emmanuele Bassi <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509515&i=0" target="_top" rel="nofollow">ebassi@...</a>> wrote:
<br>> > 4. Implement finger and kinetic scrolling [jjardon]
<br>> > - Midori has a finger/kinetic scrolled window implementation
<br>> > - Hildon has one as well
<br>> > - OpenMoko had one
<br>> > - would it make sense to port the feature to GtkScrolledWindow when
<br>> > :gtk-touchscreen-mode is set to TRUE?
<br>>
<br>> I don't think so. IMHO it would be better to put this in as a
<br>> GtkScrolledWindow subclass or a new class with a shared interface.
<br>> For stylus-based devices (if these are still going to be made), the
<br>> normal scrolled window would be preferred. But still touch screen
<br>> mode will be enabled in that case. Then there is also a case to be
<br>> made for embedded devices with touch screens that do not have enough
<br>> CPU/GPU power for kinetic scrolling, in which case you also want to
<br>> use a normal scrolled window with touch screen mode. (Think a touch
<br>> screen configuration panel for a copier machine, our University has
<br>> one. Apart from CPU power, the thick coating on that screen is also
<br>> not suitable for kinetic scrolling).
</div><br>And kinetic scrolling would be nice to have for normal (mouse-based)
<br>desktops. It provides way more visual clues as to the "quantity of
<br>widget space" scrolled, and where you are after scrolling.
<br><br> Xav
<br><br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26509515&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26508702Re: Minutes of the GTK+ Team Meeting - 2009-11-272009-11-24T23:50:38Z2009-11-24T23:50:38ZKristian Rietveld-2On Tue, Nov 24, 2009 at 11:13 PM, Emmanuele Bassi <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508702&i=0" target="_top" rel="nofollow">ebassi@...</a>> wrote:
<br>> 4. Implement finger and kinetic scrolling [jjardon]
<br>> - Midori has a finger/kinetic scrolled window implementation
<br>> - Hildon has one as well
<br>> - OpenMoko had one
<br>> - would it make sense to port the feature to GtkScrolledWindow when
<br>> :gtk-touchscreen-mode is set to TRUE?
<br><br>I don't think so. IMHO it would be better to put this in as a
<br>GtkScrolledWindow subclass or a new class with a shared interface.
<br>For stylus-based devices (if these are still going to be made), the
<br>normal scrolled window would be preferred. But still touch screen
<br>mode will be enabled in that case. Then there is also a case to be
<br>made for embedded devices with touch screens that do not have enough
<br>CPU/GPU power for kinetic scrolling, in which case you also want to
<br>use a normal scrolled window with touch screen mode. (Think a touch
<br>screen configuration panel for a copier machine, our University has
<br>one. Apart from CPU power, the thick coating on that screen is also
<br>not suitable for kinetic scrolling).
<br><br><br>regards,
<br><br>-kris.
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508702&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26508445Re: GConverter commited2009-11-24T23:16:01Z2009-11-24T23:16:01ZAlexander LarssonOn Tue, 2009-11-24 at 10:09 -0600, Shaun McCance wrote:
<br>> On Tue, 2009-11-24 at 09:36 +0100, Alexander Larsson wrote:
<br>> > I'm not sure why you'd need this, you just don't add a
<br>> > GConverterInputStream in that case.
<br>>
<br>> Well, the way I did the magic was with a GConverter that
<br>> inspects its data the first time convert is called, and
<br>> then constructs another GConverter to pass everything
<br>> off to. (This assumes the first call to convert has at
<br>> least some number of bytes, by the way.)
<br><br>If there is not enough bytes for what you want just return
<br>G_IO_ERROR_PARTIAL_INPUT and you'll be called with more data.
<br><br>> So with my implementation, by the time you get to the
<br>> magic, you've already set up a GConverterInputStream
<br>> with the magic decompressor. If the stream turns out
<br>> to be uncompressed, you'd have to do a null conversion.
<br>> I suppose the magic decompressor could just have the
<br>> null conversion built in.
<br><br>Yeah, seems easiest to do this in the magic converter then.
<br><br>> > Its not a lot of code either, nor is it very complicated, so maybe cut
<br>> > and paste is not such a horrible idea.
<br>>
<br>> I don't disagree. Is there a place to plop this code
<br>> for people to pick it up? I'll be putting at least the
<br>> bz2 and lzma converters into Yelp soon (or possibly an
<br>> xv converter instead of the lzmadec-based one). I'm
<br>> still undecided on the magic converter.
<br><br>Well, there is libegg. But its meant for things that have a final
<br>destination in some other library, so its not an ideal match.
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508445&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26508202Self destructing dialog question2009-11-24T22:41:58Z2009-11-24T22:41:58ZDov Grobgeld-2<div dir="ltr">I have a small problem that's been bothering me for a while and I have yet to find an elegant solution to it. The problem is related to the notification of the destruction of a dialog window.<br><br>Assume I have a program with a widget MyApp that has a member called my_dialog that is created to catch its destruction as follows:<br>
<br><span style="font-family: courier new,monospace;">if (!priv->my_dialog) {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> priv->my_dialog = my_dialog_new();</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> g_signal_connect(priv->my_dialog, "delete-event",</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> G_CALLBACK(cb_my_dialog_destroy), priv);</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">}</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">:</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">static gboolean cb_my_dialog_destroy(GtkWidget *widget,</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> GdkEvent *event,</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> gpointer data)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">{</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> MyAppPriv *priv = MY_APP_PRIV(data);</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> priv->my_dialog = NULL;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> return FALSE;</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">}</span><br style="font-family: courier new,monospace;">
<br>I.e. when the dialog is deleted we would like to clear the priv->my_dialog variable. (Of course I could hide the dialog on delete, but I would like to destroy it.)<br><br>The MyDialog class inherits from GtkDialog and it creates a dialog button "Close" that is handled in the response callback. So in MyDialog I override the "response" signal handler and when we get the response==GTK_RESPONSE_CLOSE we self destruct by calling gtk_widget_destroy(widget).<br>
<br>But here's the problem, because destroying a widget does not generate a "delete-event" and thus cb_my_dialog_destroy is never called and thus priv->my_dialog is never set to NULL.<br><br>Meanwhile I have solved it by overriding the the response signal in MyApp, but I feel that is ugly as I would like to keep the functionality of MyDialog self contained. <br>
<br>Other possible solutions would be to emit a "delete-event" in MyDialog. But my attempts to call g_signal_emit_by_name(widget, "delete-event", NULL, &retval) have caused the program to crash.<br>
<br>Another solution would be to create yet another signal.<br><br>Trying to connect to the "destroy-event" in MyApp didn't work. I never got any callback.<br><br>So how should this be done?<br><br>Thanks!<br>
Dov<br><br></div>
<br />_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508202&i=0" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26507981Controlling the hardware volume2009-11-24T22:04:06Z2009-11-24T22:04:06ZJosé Alburquerque-3On Tue, 2009-11-24 at 17:05 -0500, José Alburquerque wrote:
<br>> The problem is that your trying to initialize a Glib::RefPtr<>& from a
<br>> Glib::RefPtr<> (which the std::list<> contains). A std::list<> is not
<br>> designed to store references.
<br><br>It doesn't seem clear what I was trying to say about lists not "storing"
<br>references. I guess what I was trying to say is that I think trying to
<br>extract a reference by dereferencing a list<>::iterator is not doable.
<br>I was also trying to suggest another way get at the contents of the
<br>list.
<br><br>There are other ways to access the list, of course.
<br>std::list<>::pop_front(), for example, removes the first element of the
<br>list and std::list<>::front() does in fact return a reference so it
<br>would be fine to initialize a Glib::RefPtr<>& with the result from that.
<br>I'm sure you probably know all this, but in case you don't I might as
<br>well add this comment in case it helps further.
<br><br>Also, from the docs, a std::vector can be used instead of std::list.
<br><br>Finally, another element you might consider when working with volume
<br>control is the Gst::Volume plug-in. According to the docs here:
<br><br><a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-volume.html" target="_top" rel="nofollow">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-volume.html</a><br><br>It allows the control of the volume of audio through a pipeline. I hope
<br>this all might be useful.
<br><br>--
<br>José
<br><br><br>_______________________________________________
<br>gtkmm-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26507981&i=0" target="_top" rel="nofollow">gtkmm-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtkmm-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtkmm-f1344.html" embed="fixTarget[1344]" target="_top" >Gtkmm</a></p>tag:old.nabble.com,2006:post-26506326Re: Minutes of the GTK+ Team Meeting - 2009-11-272009-11-24T17:43:44Z2009-11-24T17:43:44ZCarlos GarnachoHi,
<br><br>On mar, 2009-11-24 at 22:13 +0000, Emmanuele Bassi wrote:
<br>> = minutes for the 2009-11-27 meeting =
<br>>
<br><br>> 2. MPX awesomeness [garnacho]
<br>> - No garnacho present, we'll be dealt with through bounty hunters
<br><br>Damn, sorry :(
<br><br>I mostly wanted to raise awareness on some things that could help
<br>getting the wheel moving.
<br><br> * Testing on X11 in general is most welcome, since there has been
<br> a refactor of event handling, not only XI2 has to be tested, but
<br> core events and XI1 impls as well, although most of the changes
<br> are due to code shuffling, there aren't practically any
<br> fundamental changes here.
<br><br> * There have been changes in _gdk_windowing_* API, and some
<br> additional things left for Gdk backends to implement, win32 and
<br> quartz backends should implement a GdkDeviceManager and the
<br> additional methods in GdkDevice. The class struct had to be
<br> extended here, but I don't think that's a problem, since this is
<br> sort of a final object.
<br><br> * There are compatibility issues with applications that mix Xlib
<br> and GTK+ API usages in creative ways, these don't apply of
<br> course if the core events GdkDeviceManager impl is in use. The
<br> two examples I've been able by to find across my desktop are:
<br> * Emacs-gtk: seems to create GtkWidgets, but actually
<br> ignores GdkEvents in favor of interpreting XEvents
<br> itself. When the XI2 backend is in use core device
<br> events aren't even selected, leaving a pretty useless
<br> operative system :)
<br> * Metacity: Uses all the Gdk machinery, but for grabs.
<br> XGrabPointer() coerces core pointer events into the grab
<br> window, even if XI2-enabled Gdk didn't select for these
<br> events, nor actually translates them into GdkEvents.
<br> There is no easy solution for this, and it looks like
<br> mixing XI2 and X pointer/keyb APIs in the same client is
<br> considered a bad idea.
<br><br> I added the GDK_CORE_DEVICE_EVENTS envvar to force the core
<br> GdkDeviceManager to be used, device managers are attached to a
<br> GdkDisplay and created together with it in gdk_display_open()
<br> (and hence gtk_init()). I'm not sure of the best solution to let
<br> apps choose whether to be XI2 aware or stick to core events.
<br><br> * I also introduced GtkDeviceGroup and GdkMultiDeviceEvents in
<br> order to ease multiple pointers interaction, but I'm still a bit
<br> unsure on how well will this fit with the future Xorg multitouch
<br> plans. There are a few tests in tests/multidevice/ exercising
<br> this and looks easy and powerful enough to me.
<br><br> * There is an overview of the changes in <a href="http://live.gnome.org/GTK" target="_top" rel="nofollow">http://live.gnome.org/GTK</a><br> +/MPX/ , there are some additional concepts such as grab
<br> ownership and the new objects/interfaces that I've tried to
<br> explain there.
<br><br>I've sucked wrt GTK+ meetings lately, will try to improve that from now
<br>on.
<br><br> Carlos
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26506326&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26505831Re: Hiding modal dialogs2009-11-24T16:46:48Z2009-11-24T16:46:48ZJohn J LeeYes. So I was asking about hiding the dialog without closing it. It's
<br>not obvious to me why setting the dialog's "visible" property causes its
<br>main loop to quit.
<br><br><br>John
<br><br>On Tue, 24 Nov 2009, Donny Viszneki wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> The modal dialogs I've used offer a "run" method (working from Python)
<br>> which not only introduces the modal dialog, but pushes/nests a further
<br>> GMainLoop onto the main loop stack. By default, when the user hits a
<br>> button to end the dialog, this causes that GMainLoop to return, and my
<br>> "run" method to return me the code for the way the user closed the
<br>> dialog. At this point I call a "hide" method to hide the dialog, and
<br>> everything turns back to normal. Calling "run" again reappears the
<br>> dialog and re-pushes its main loop.
<br>>
<br>> On Mon, Nov 23, 2009 at 6:22 PM, John J Lee <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505831&i=0" target="_top" rel="nofollow">jjl@...</a>> wrote:
<br>>> Is it possible to hide and re-show modal dialogs?
<br>>>
<br>>> Trying this in a tiny app, calling gtk_widget_hide_all() or setting the
<br>>> visible property true on a running modal dialog caused its main loop to
<br>>> quit.
<br>>>
<br>>> I no longer intend to try to do this in real code -- I'm just curious re
<br>>> whether its possible, and why. The original use case involved hiding all
<br>>> dialogs using a generic function that doesn't know about specific dialogs.
<br>>>
<br>>> Is there a way to hide a modal dialog without quitting its event loop?
<br>>>
<br>>> Thanks
<br>>>
<br>>>
<br>>> John
<br>>>
<br>>> _______________________________________________
<br>>> gtk-list mailing list
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505831&i=1" target="_top" rel="nofollow">gtk-list@...</a>
<br>>> <a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br>>>
<br>>
<br>>
<br>>
<br>> --
<br>> <a href="http://codebad.com/" target="_top" rel="nofollow">http://codebad.com/</a><br>></div></div>_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505831&i=2" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26505571GtkTreeView, database and load data on demand2009-11-24T16:04:45Z2009-11-24T16:04:45ZAlexander BöglHi!
<br><br>I try to program a class to view big database tables with GtkTreeView
<br>simular to the data-aware components in Delphi, Basic, etc,
<br>which loads only the data from the DB what it has to view, but it
<br>seems difficult get scrollbar positions, or the number of the selected
<br>row.
<br><br>Has someone a hint for me how to get rid of this?
<br><br><br>Greetz,
<br>Alex
<br><br><br>--
<br>PHP-GTK General Mailing List (<a href="http://gtk.php.net/" target="_top" rel="nofollow">http://gtk.php.net/</a>)
<br>To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_top" rel="nofollow">http://www.php.net/unsub.php</a><br><br><p>From forum: <a href="http://old.nabble.com/Php---GTK---General-f171.html" embed="fixTarget[171]" target="_top" >Php - GTK - General</a></p>tag:old.nabble.com,2006:post-26505429Re: GConverter commited2009-11-24T15:58:08Z2009-11-24T15:58:08ZShaun McCance-2On Tue, 2009-11-24 at 17:20 -0500, Behdad Esfahbod wrote:
<div class='shrinkable-quote'><br>> On 11/24/2009 11:09 AM, Shaun McCance wrote:
<br>>
<br>> > So with my implementation, by the time you get to the
<br>> > magic, you've already set up a GConverterInputStream
<br>> > with the magic decompressor. If the stream turns out
<br>> > to be uncompressed, you'd have to do a null conversion.
<br>> > I suppose the magic decompressor could just have the
<br>> > null conversion built in.
<br>>
<br>> Isn't it like a matter of memcpy() in convert(), and nothing in reset()? Not
<br>> that I oppose a cat-converter.
</div><br>Oh duh. I was thinking it was slightly less trivial, that
<br>you'd have to maintain a buffer in case outbuf is smaller
<br>than inbuf. But I just realized that convert doesn't have
<br>to consume all of inbuf. That's what bytes_read is for.
<br><br>So I updated my magic decompressor in my git repository so
<br>that, if it doesn't detect any compression, it just passes
<br>the data through. It's like six lines of code.
<br><br>--
<br>Shaun
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505429&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26505158Re: Gtk2::MessageDialog title2009-11-24T15:27:17Z2009-11-24T15:27:17ZKevin Rydemuppet <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505158&i=0" target="_top" rel="nofollow">scott@...</a>> writes:
<br>>
<br>> With a "compliant" window manager, at least.
<br><br>Compliant in the sense of rigid, instead of flexible :-).
<br><br>--
<br>People laugh when they hear I've still got an 8-track in my car.
<br>I say you can make a perfectly good mix on an 8-track if you're
<br>organised, but I think a 24-track desk will fit some time.
<br>_______________________________________________
<br>gtk-perl-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505158&i=1" target="_top" rel="nofollow">gtk-perl-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-perl-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-perl-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Perl-f1340.html" embed="fixTarget[1340]" target="_top" >Gtk+ - Perl</a></p>tag:old.nabble.com,2006:post-26504996Re: Hiding modal dialogs2009-11-24T15:13:19Z2009-11-24T15:13:19ZDonny VisznekiThe modal dialogs I've used offer a "run" method (working from Python)
<br>which not only introduces the modal dialog, but pushes/nests a further
<br>GMainLoop onto the main loop stack. By default, when the user hits a
<br>button to end the dialog, this causes that GMainLoop to return, and my
<br>"run" method to return me the code for the way the user closed the
<br>dialog. At this point I call a "hide" method to hide the dialog, and
<br>everything turns back to normal. Calling "run" again reappears the
<br>dialog and re-pushes its main loop.
<br><br>On Mon, Nov 23, 2009 at 6:22 PM, John J Lee <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26504996&i=0" target="_top" rel="nofollow">jjl@...</a>> wrote:
<div class='shrinkable-quote'><br>> Is it possible to hide and re-show modal dialogs?
<br>>
<br>> Trying this in a tiny app, calling gtk_widget_hide_all() or setting the
<br>> visible property true on a running modal dialog caused its main loop to
<br>> quit.
<br>>
<br>> I no longer intend to try to do this in real code -- I'm just curious re
<br>> whether its possible, and why. The original use case involved hiding all
<br>> dialogs using a generic function that doesn't know about specific dialogs.
<br>>
<br>> Is there a way to hide a modal dialog without quitting its event loop?
<br>>
<br>> Thanks
<br>>
<br>>
<br>> John
<br>>
<br>> _______________________________________________
<br>> gtk-list mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26504996&i=1" target="_top" rel="nofollow">gtk-list@...</a>
<br>> <a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br>>
</div><br><br><br>--
<br><a href="http://codebad.com/" target="_top" rel="nofollow">http://codebad.com/</a><br>_______________________________________________
<br>gtk-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26504996&i=2" target="_top" rel="nofollow">gtk-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---General-f1334.html" embed="fixTarget[1334]" target="_top" >Gtk+ - General</a></p>tag:old.nabble.com,2006:post-26505001Gtk2::Assistant and Button Access2009-11-24T15:13:00Z2009-11-24T15:13:00ZJeff Hallock<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:Z="urn:schemas-microsoft-com:" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>How to remove a button from the assistant:<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>It took me a while – but I figured it out. <o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I wanted to remove the ‘Last’ button from a
Gtk2::Assistant – and couldn’t figure out how to get access to the
buttons. I found this<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><a href="http://old.nabble.com/Gtk2%3A%3AAssistant%3A-Access-to-Buttons-td11415772.html#a11415772" target="_top" rel="nofollow">http://old.nabble.com/Gtk2%3A%3AAssistant%3A-Access-to-Buttons-td11415772.html#a11415772</a><o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>The accessors were added - <a href="http://cpansearch.perl.org/src/TSCH/Gtk2-1.180/NEWS" target="_top" rel="nofollow">http://cpansearch.perl.org/src/TSCH/Gtk2-1.180/NEWS</a><o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>But never documented - <a href="http://gtk2-perl.sourceforge.net/doc/pod/Gtk2/Assistant.html" target="_top" rel="nofollow">http://gtk2-perl.sourceforge.net/doc/pod/Gtk2/Assistant.html</a><o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Is there someplace else I should be looking?<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>The accessors are get_*button-name*_button<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>So:<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>$assistant->get_next_button<o:p></o:p></p>
<p class=MsoNormal>$assistant->get_last_button<o:p></o:p></p>
<p class=MsoNormal>$assistant->get_previous_button<o:p></o:p></p>
<p class=MsoNormal>$assistant->get_close_button<o:p></o:p></p>
<p class=MsoNormal>…<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Hope this helps.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>-Jeff<o:p></o:p></p>
</div>
</body>
</html>
<br />_______________________________________________
<br>gtk-perl-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26505001&i=0" target="_top" rel="nofollow">gtk-perl-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-perl-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-perl-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Perl-f1340.html" embed="fixTarget[1340]" target="_top" >Gtk+ - Perl</a></p>tag:old.nabble.com,2006:post-26516467Re: GConverter commited2009-11-24T14:20:18Z2009-11-24T14:20:18ZBehdad Esfahbod-7On 11/24/2009 11:09 AM, Shaun McCance wrote:
<br><br>> So with my implementation, by the time you get to the
<br>> magic, you've already set up a GConverterInputStream
<br>> with the magic decompressor. If the stream turns out
<br>> to be uncompressed, you'd have to do a null conversion.
<br>> I suppose the magic decompressor could just have the
<br>> null conversion built in.
<br><br>Isn't it like a matter of memcpy() in convert(), and nothing in reset()? Not
<br>that I oppose a cat-converter.
<br><br>behdad
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516467&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26504208Minutes of the GTK+ Team Meeting - 2009-11-272009-11-24T14:13:20Z2009-11-24T14:13:20ZEmmanuele Bassi= minutes for the 2009-11-27 meeting =
<br><br>1. client-side decorations, RGBA windows [bratsche]
<br>- bratsche has time to finish the work on csd
<br>- currently targeting gtk+ 2.20
<br>- some fallout in nautilus/gnome-bg
<br>- Google is interested in csd for Chromium (browser)
<br>- there's the potential for some abuse, but the API should not be
<br> designed to allow that
<br>- issue on the table: how to signal to the WM the transparent regions
<br> for shadows and border effects?
<br>- potential solution: XFixes region exposed on the top-level window
<br> and a property
<br>- submission of window geometry:
<br> - blocks on: EWMH amendment
<br> - blocks: client-side window resizing and WM interaction
<br> - blocks: client-side shadows
<br><br>2. MPX awesomeness [garnacho]
<br>- No garnacho present, we'll be dealt with through bounty hunters
<br><br>3. Drop tear-off menus [jjardon]
<br>- <a href="https://bugzilla.gnome.org/show_bug.cgi?id=597904" target="_top" rel="nofollow">https://bugzilla.gnome.org/show_bug.cgi?id=597904</a><br>- ebassi, mclasen already in favour
<br>- bratsche joins in
<br>- no objections raised
<br><br>4. Implement finger and kinetic scrolling [jjardon]
<br>- Midori has a finger/kinetic scrolled window implementation
<br>- Hildon has one as well
<br>- OpenMoko had one
<br>- would it make sense to port the feature to GtkScrolledWindow when
<br> :gtk-touchscreen-mode is set to TRUE?
<br>- issue: event delivery to children requires subclassing to override
<br> current default behaviour of gtk+ widgets
<br><br>5. Deprecate non-multihead API in GDK and GTK+ [jjardon]
<br>- Blocks on mitch and mclasen getting in the Thunderdome
<br><br>6. Rename configure.in to configure.ac [Enselic]
<br>- trivial issue
<br>- mclasen will have to decide
<br>- ebassi points out that GLib should switch as well
<br>- kalikiana wants to know if there are compatibility issues for the rename
<br>- none direct; there might be external scripts relying on configure.in
<br><br>7. menu export over D-Bus [bratsche]
<br>- useful for ubuntu's "application indicators"
<br>- Quartz backend
<br>- menu reflowing
<br>- bratsche is working on a general purpose menu proxy
<br>- 3.0 material
<br><br>8. frequent build issues with jhbuild [timj]
<br>- issues with jhbuild make it difficult to build the platform
<br>- keeping the build from breaking should be a goal
<br>- build dependencies should be targeted at stock systems, e.g. latest
<br> stable ubuntu, fedora
<br>- build server, to check for breakages: <a href="http://build.gnome.org" target="_top" rel="nofollow">http://build.gnome.org</a><br><br>9. status of gdbus
<br>- waiting for more reviews
<br>- still on track for glib 2.24
<br>- depends on gvariant
<br>- gvariant waiting for more reviews as well
<br>- reviews welcome on gtk-devel-list
<br><br>next meeting: 2009-12-01
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26504208&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26504106Re: ANNOUNCE: gstreamermm-0.10.52009-11-24T14:05:57Z2009-11-24T14:05:57ZJosé Alburquerque-3On Tue, 2009-11-24 at 13:55 +0100, Carlo Wood wrote:
<div class='shrinkable-quote'><br>> Hi, I have another question about gstreamermm. Trying to print the volume
<br>> of the given tracks:
<br>>
<br>> // List the tracks of the mixer.
<br>> typedef std::list<Glib::RefPtr<Gst::MixerTrack> > tracks_type;
<br>> tracks_type tracks = mixer->list_tracks();
<br>>
<br>> for (tracks_type::iterator iter = tracks.begin(); iter != tracks.end(); ++iter)
<br>> {
<br>> Glib::RefPtr<Gst::MixerTrack const>& track = *iter;
<br>> std::cout << track->get_label() << ' ' << mixer->get_volume(track) << std::endl;
<br>> }
<br>>
<br>>
<br>> This doesn't work... First I tried get_volume(*iter) but that can't find
<br>> a 'get_volume', because the only get_volume that is there demands a
<br>> Glib::RefPtr<Gst::MixerTrack const> (note the 'const').
<br>>
<br>> So, I tried to convert *iter (which is a Glib::RefPtr<Gst::MixerTrack>)
<br>> to a Glib::RefPtr<Gst::MixerTrack const> in the line before, and indeed,
<br>> that fails.
<br>>
<br>> How am I supposed to get the volume of the tracks now?
</div><br>The problem is that your trying to initialize a Glib::RefPtr<>& from a
<br>Glib::RefPtr<> (which the std::list<> contains). A std::list<> is not
<br>designed to store references. You should just do something like:
<br><br>Glib::RefPtr<..> ref = *iter;
<br><br>Also, the std::cout line cannot work because the
<br>"mixer->get_volume(track)" returns an array of integers.
<br><br>I would suggest that you make sure you follow the docs so that you know
<br>what is supported. One good chapter as far as ArrayHandle and
<br>ListHandle is in the "Intermediate types" section[1] of the online
<br>book[2].
<br><br>[1]
<br><a href="http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-intermediate-types.html.en" target="_top" rel="nofollow">http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-intermediate-types.html.en</a><br>[2] <a href="http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html" target="_top" rel="nofollow">http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html</a><br><br><br>--
<br>José
<br><br>_______________________________________________
<br>gtkmm-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26504106&i=0" target="_top" rel="nofollow">gtkmm-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtkmm-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtkmm-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtkmm-f1344.html" embed="fixTarget[1344]" target="_top" >Gtkmm</a></p>tag:old.nabble.com,2006:post-26502684Re: GConverter commited2009-11-24T12:25:09Z2009-11-24T12:25:09ZShaun McCance-2On Tue, 2009-11-24 at 16:22 +0000, Bastien Nocera wrote:
<div class='shrinkable-quote'><br>> On Tue, 2009-11-24 at 10:09 -0600, Shaun McCance wrote:
<br>> <snip>
<br>> > I don't disagree. Is there a place to plop this code
<br>> > for people to pick it up? I'll be putting at least the
<br>> > bz2 and lzma converters into Yelp soon (or possibly an
<br>> > xv converter instead of the lzmadec-based one). I'm
<br>> > still undecided on the magic converter.
<br>>
<br>> I've written some code for gdk-pixbuf's XCF loader to use GConverter to
<br>> uncompress gz files, and would be happy to clean up the code to use the
<br>> same codepath for bz2.
<br>>
<br>> So I'd be happy to see your code.
</div><br>Code is here:
<br><br><a href="http://www.gnome.org/~shaunm/git/convert.git" target="_top" rel="nofollow">http://www.gnome.org/~shaunm/git/convert.git</a><br><br>The bz2 converter was pretty trivial to write. The one
<br>possible hiccup is the implementation of reset. Since
<br>libbz2 doesn't provide a reset function, I just ended
<br>and reinitialized the stream. But I didn't actually
<br>test it. GConverterInputStream doesn't actually call
<br>reset.
<br><br>--
<br>Shaun
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26502684&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26502468Re: GTKTreeView navigation improvement2009-11-24T12:10:00Z2009-11-24T12:10:00ZAndrey M> If someone makes changes that breaks your new feature, there should be
<br>> regression tests that detects this. To run tests you do 'make check'.
<br>I don't know how to do that (or if it even applies to this).
<br><br>Additionally, as long as the functionality of the following remains
<br>the same (as of GTK+2.18), the patch should always work.
<br>{GtkRBNode::children == NULL} when GtkRBNode is either collapsed or
<br>has no children.
<br>{gtk_tree_path_up(GtkTreePath *path)} moves the innerworkings of path
<br>to the parent.
<br>{gtk_tree_view_set_cursor(GtkRBTree *tree, GtkTreePath *cursor_path, NULL,NULL)}
<br><br>-Andrey
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26502468&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26502141Re: GTKTreeView navigation improvement2009-11-24T11:45:36Z2009-11-24T11:45:36ZMartin Nordholts-2Andrey M wrote:
<br>>> Just two spontaneous comments:
<br>>> 1. You should provide regression tests for this feature (tests/testtree*)
<br>> What are those?
<br>> I'm not changing any structures or declaring any new variables. I
<br>> don't understand.
<br><br>If someone makes changes that breaks your new feature, there should be
<br>regression tests that detects this. To run tests you do 'make check'.
<br><br> / Martin
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26502141&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26516465Re: GTKTreeView navigation improvement2009-11-24T11:39:07Z2009-11-24T11:39:07ZAndrey M> Just two spontaneous comments:
<br>> 1. You should provide regression tests for this feature (tests/testtree*)
<br>What are those?
<br>I'm not changing any structures or declaring any new variables. I
<br>don't understand.
<br>> 2. You are introducing C++ comments (//) but the core code should use
<br>> C-style comments (/* */)
<br>Didn't know about that,
<br>Fixed patch is attached
<br><br>-Andrey
<br><br /><tt>[treeviewpatch.diff]</tt><br /><hr align="left" width="300" /><tt>--- gtk+2.0-2.18.3/gtk/gtktreeview.c 2009-10-08 22:00:44.000000000 -0700
<br>+++ gtktreeview.c 2009-11-22 19:43:44.792600790 -0800
<br>@@ -10102,14 +10102,30 @@ gtk_tree_view_real_expand_collapse_curso
<br> if (_gtk_tree_view_find_node (tree_view, cursor_path, &tree, &node))
<br> return FALSE;
<br>
<br>- /* Don't handle the event if we aren't an expander */
<br>- if (!((node->flags & GTK_RBNODE_IS_PARENT) == GTK_RBNODE_IS_PARENT))
<br>- return FALSE;
<br>-
<br> if (!logical
<br> && gtk_widget_get_direction (GTK_WIDGET (tree_view)) == GTK_TEXT_DIR_RTL)
<br> expand = !expand;
<br>
<br>+ /* On a keyboard accelerator for collapse, this code should move the cursor */
<br>+ /* to the parent, if the node has no children or is collapsed */
<br>+ /* notes: */
<br>+ /* a node is expanded if node->children != null */
<br>+
<br>+ if(!expand && (node->children == NULL))
<br>+ {
<br>+ /* get parent path or return false */
<br>+ if(!gtk_tree_path_up(cursor_path))
<br>+ return FALSE;
<br>+
<br>+ /*do the parent select */
<br>+ gtk_tree_view_set_cursor(tree_view,cursor_path,NULL,FALSE);
<br>+ return TRUE;
<br>+ }
<br>+
<br>+ /* Don't handle the event if we aren't an expander */
<br>+ if (!((node->flags & GTK_RBNODE_IS_PARENT) == GTK_RBNODE_IS_PARENT))
<br>+ return FALSE;
<br>+
<br> if (expand)
<br> gtk_tree_view_real_expand_row (tree_view, cursor_path, tree, node, open_all, TRUE);
<br> else
<br></tt><hr align="left" width="300" /><br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516465&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26501842Re: GTKTreeView navigation improvement2009-11-24T11:24:06Z2009-11-24T11:24:06ZMartin Nordholts-2Andrey M wrote:
<br>> I've included a patch that should greatly enhance the usability of GTKTreeView.
<br><br>Hi,
<br><br>Just two spontaneous comments:
<br>1. You should provide regression tests for this feature (tests/testtree*)
<br>2. You are introducing C++ comments (//) but the core code should use
<br>C-style comments (/* */)
<br><br>Regards,
<br>Martin
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26501842&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26501664Re: GTKTreeView navigation improvement2009-11-24T11:12:57Z2009-11-24T11:12:57ZAndrey MHi Kris,
<br><br>Thanks for your quick reply.
<br><br>> Are you aware that there is a key binding bound to "backspace" that is
<br>> in charge of selecting the parent node?
<br>I was unaware about "backspace" and none of the following searches
<br>yielded any usable results:
<br>(0 hits) <a href="http://www.google.com/#hl=en&q=gtk+keyboard+shortcuts" target="_top" rel="nofollow">http://www.google.com/#hl=en&q=gtk+keyboard+shortcuts</a><br>(1 hit) <a href="http://www.google.com/#hl=en&q=gtk+treeview+shortcut" target="_top" rel="nofollow">http://www.google.com/#hl=en&q=gtk+treeview+shortcut</a><br>(0 hits) <a href="http://www.google.com/#hl=en&q=gtk+treeview+backspace" target="_top" rel="nofollow">http://www.google.com/#hl=en&q=gtk+treeview+backspace</a><br><br>To me, the intuitive function of backspace is to delete and erase, as
<br>in if the treeview is used like a property editor.
<br><br>> I don't fully see how your proposed behavior greatly enhances the
<br>> usability. Other than that you can easily collapse the entire tree by
<br>> keeping shift+left pressed. (But, we have another key binding just
<br>> for that). In general I think that overloading key bindings with
<br>> multiple actions is bad; when the key bindings were being "designed"
<br>> by the usability team, I recall that avoiding overloading was
<br>> important.
<br><br>Ideally, I would like unmodified left/right keys (like in windows) for
<br>the navigation of a treeview.
<br>I believe that would be the most intuitive for all users, especially
<br>ones attempting the switch from windows to linux.
<br>However, I do understand that the gtk treeview control is much more
<br>complex than its windows counterpart and that left and right are used
<br>for cell navigation.
<br>I tried searching for any documentation on keyboard accelerators in
<br>gtk, but I could not find anything on expand/collapse nodes in a
<br>treeview.
<br>Ultimately, I discovered <shift>+<left/right> only from trial and error.
<br>Extending the functionality of <shift>+<left> will only improve the
<br>control and the convenience with which a user can navigate through it.
<br><br>I would really appreciate any and all input from the gtk community.
<br><br>Best Regards,
<br>-Andrey
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26501664&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26500995[REMINDER] GTK+ IRC Team meeting - 2009-11-242009-11-24T10:23:47Z2009-11-24T10:23:47ZEmmanuele Bassihi everyone;
<br><br>this is a reminder for the GTK+ team IRC meeting:
<br><br>◦ date: 2009-11-24
<br>◦ time: 20:00 UTC [0]
<br>◦ channel: #gtk-devel on irc.gnome.org
<br>◦ agenda:
<br> • CodyRussell: Client-side decorations, RGBA windows GTK+/ClientSideDecorations
<br> • CarlosGarnacho: MPX awesomeness GTK+/MPX
<br> • Drop tear-off menu items: <a href="https://bugzilla.gnome.org/show_bug.cgi?id=597904" target="_top" rel="nofollow">https://bugzilla.gnome.org/show_bug.cgi?id=597904</a>
<br> • JavierJardon: Implement drag (finger) and kinetic scrolling: bug #601923
<br> • JavierJardon: Deprecate non-multihead API in Gdk and Gtk: bug #547920
<br> • miscellaneous
<br><br>as always, everyone is invited to attend.
<br><br>ciao,
<br> Emmanuele.
<br><br>[0] <a href="http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=24&year=2009&hour=20&min=0&sec=0&p1=0" target="_top" rel="nofollow">http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=24&year=2009&hour=20&min=0&sec=0&p1=0</a><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26500995&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>tag:old.nabble.com,2006:post-26498953Re: GConverter commited2009-11-24T08:22:54Z2009-11-24T08:22:54ZBastien NoceraOn Tue, 2009-11-24 at 10:09 -0600, Shaun McCance wrote:
<br><snip>
<br>> I don't disagree. Is there a place to plop this code
<br>> for people to pick it up? I'll be putting at least the
<br>> bz2 and lzma converters into Yelp soon (or possibly an
<br>> xv converter instead of the lzmadec-based one). I'm
<br>> still undecided on the magic converter.
<br><br>I've written some code for gdk-pixbuf's XCF loader to use GConverter to
<br>uncompress gz files, and would be happy to clean up the code to use the
<br>same codepath for bz2.
<br><br>So I'd be happy to see your code.
<br><br>Cheers
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26498953&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><p>From forum: <a href="http://old.nabble.com/Gtk%2B---Dev---General-f1332.html" embed="fixTarget[1332]" target="_top" >Gtk+ - Dev - General</a></p>