client side windows - request for testing and reviewing
The client side window branch is now feature complete on X11, and includes API to do offscreen window embedding (with patches for clutter-gtk availible to test this). Today I merged the latest master into the branch to make it easy for people to test it (its got the new so version). I fixed the last known (to me) bug yesterday (an obscure WM interaction issue on loading the saved session), and am running this as my default Gtk+ without issues. The win32 branch is getting some work done by Cody Russell, and the Quartz backend used to work fine but requires some minor API change updates (hopefully Richard can do this soon, CC:ed). It would be very nice if we could merge this soon. However, to do that we need more testing and people to look at the code. As things stand right now I've gotten essentially zero feedback. I don't know of anyone except the two backend porters who have built or looked at the code really. So, please, please, please, test this code. We need people who run "uncommon" apps to test it, and we need people to run it on apps they know really well so we can find minor changes in behaviour. Also, anyone who knows gdk or have an interest in this, please take a look at the code and give feedback. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTKMM Clipboard::wait_for_targets() bug?
Hi, I'm playing with getting inkscape to paste successfully from our application (gschem), and have encountered some weird corruption-like problems with inkscape not successfully getting the correct list of targets on the clipboard. Running with valgrind, I see the following: ==28334== Invalid read of size 1 ==28334==at 0x40276E8: strlen (mc_replace_strmem.c:242) ==28334==by 0x58F888A: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.10) ==28334==by 0x451B74A: Glib::ustring::ustring(char const*) (in /usr/lib/libglibmm-2.4.so.1.2.0) ==28334==by 0x8389DF3: Inkscape::UI::ClipboardManagerImpl::_getBestTarget() (containerhandle_shared.h:291) ==28334==by 0x838AE7D: Inkscape::UI::ClipboardManagerImpl::paste(bool) (clipboard.cpp:305) ==28334==by 0x80C38C3: sp_selection_paste(SPDesktop*, bool) (selection-chemistry.cpp:954) ==28334==by 0x824642C: sp_action_perform(SPAction*, void*) (action.cpp:181) ==28334==by 0x80D41E7: sp_shortcut_invoke(unsigned int, Inkscape::UI::View::View*) (shortcuts.cpp:55) ==28334==by 0x824CB36: on_window_key_press(_GdkEventKey*) (window.cpp:34) ==28334==by 0x42AFEF1: (anonymous namespace)::Widget_signal_key_press_event_callback(_GtkWidget*, _GdkEventKey*, void*) (slot.h:515) ==28334==by 0x47EE525: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) ==28334==by 0x4D3BC7A: g_closure_invoke (gclosure.c:767) The string which causes the invalid read is the target returned from inkscape's Inkscape::UI::ClipboardManagerImpl::_get_best_target() function. The string originates from a call to Gtk::Clipboard::wait_for_targets() within the _get_best_target() function. ==28334== Address 0x7e6164c is 12 bytes inside a block of size 22 free'd ==28334==at 0x402599A: operator delete(void*) (vg_replace_malloc.c:342) ==28334==by 0x58F79FC: std::string::_Rep::_M_destroy(std::allocator const&) (in /usr/lib/libstdc++.so.6.0.10) ==28334==by 0x451E5C0: Glib::ustring::~ustring() (in /usr/lib/libglibmm-2.4.so.1.2.0) ==28334==by 0x41F6206: Gtk::Clipboard::wait_for_targets() const (new_allocator.h:118) ==28334==by 0x8389DBD: Inkscape::UI::ClipboardManagerImpl::_getBestTarget() (clipboard.cpp:1242) ==28334==by 0x838AE7D: Inkscape::UI::ClipboardManagerImpl::paste(bool) (clipboard.cpp:305) ==28334==by 0x80C38C3: sp_selection_paste(SPDesktop*, bool) (selection-chemistry.cpp:954) ==28334==by 0x824642C: sp_action_perform(SPAction*, void*) (action.cpp:181) ==28334==by 0x80D41E7: sp_shortcut_invoke(unsigned int, Inkscape::UI::View::View*) (shortcuts.cpp:55) ==28334==by 0x824CB36: on_window_key_press(_GdkEventKey*) (window.cpp:34) ==28334==by 0x42AFEF1: (anonymous namespace)::Widget_signal_key_press_event_callback(_GtkWidget*, _GdkEventKey*, void*) (slot.h:515) ==28334==by 0x47EE525: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) What I can't understand, is why the destructor for the ustring is being called in Gtk::Clipboard::wait_for_targets(), since that ustring should be "owned" by the std::list of ustrings which is being returned. I'm not a C++ programmer by any means, so any help in finding the right path to pursue in debugging this would be much appreciated. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client side windows - request for testing and reviewing
2009/6/17 Alexander Larsson : > The client side window branch is now feature complete on X11, and > includes API to do offscreen window embedding (with patches for > clutter-gtk availible to test this). Today I merged the latest master > into the branch to make it easy for people to test it (its got the new > so version). > > I fixed the last known (to me) bug yesterday (an obscure WM interaction > issue on loading the saved session), and am running this as my default > Gtk+ without issues. > > The win32 branch is getting some work done by Cody Russell, and the > Quartz backend used to work fine but requires some minor API change > updates (hopefully Richard can do this soon, CC:ed). > > It would be very nice if we could merge this soon. However, to do that > we need more testing and people to look at the code. As things stand > right now I've gotten essentially zero feedback. I don't know of anyone > except the two backend porters who have built or looked at the code > really. > > So, please, please, please, test this code. We need people who run > "uncommon" apps to test it, and we need people to run it on apps they > know really well so we can find minor changes in behaviour. Alex, count on me to test it during next week :-) > Also, anyone who knows gdk or have an interest in this, please take a > look at the code and give feedback. > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject Introspection support for GSList or other types without a GLib type
On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote: > How to handle data types without a GLib GType defined. > > On libgda, it define a GType for GError and a GSList becouse these > doesn't exist on GLib and it uses them as parameters when creating > properties and events. > > For now may be the library (as Anjuta does) must create its own GType > definition but with the following rule: the name of the type must be > defined as "GError" and "GSList", in order to allow g-ri-scanner to > detects the currect types GError and GSList as the example. > > In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with "GdaError" and > "GdaSList", then the scanner tries to find a definition to GdaError > and GdaSList but they don't exist, when changed this types' names as > avobe the correct type is detected. To point out what may be obvious - there is zero advantage of a _TYPE_SLIST over G_TYPE_POINTER. This is true in general, and true for gobject-introspection - if gobject-introspection finds a property by introspection and deduces a type of GSList for it, it still doesn't have the element-type. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client side windows - request for testing and reviewing
2009/6/17 Alexander Larsson : > The client side window branch is now feature complete on X11, and > includes API to do offscreen window embedding (with patches for > clutter-gtk availible to test this). Today I merged the latest master > into the branch to make it easy for people to test it (its got the new > so version). > > I fixed the last known (to me) bug yesterday (an obscure WM interaction > issue on loading the saved session), and am running this as my default > Gtk+ without issues. > > The win32 branch is getting some work done by Cody Russell, and the > Quartz backend used to work fine but requires some minor API change > updates (hopefully Richard can do this soon, CC:ed). > > It would be very nice if we could merge this soon. However, to do that > we need more testing and people to look at the code. As things stand > right now I've gotten essentially zero feedback. I don't know of anyone > except the two backend porters who have built or looked at the code > really. > > So, please, please, please, test this code. We need people who run > "uncommon" apps to test it, and we need people to run it on apps they > know really well so we can find minor changes in behaviour. > > Also, anyone who knows gdk or have an interest in this, please take a > look at the code and give feedback. I think I need some pointers to give some constructive feedback on this. I've now compiled the client-side-windows branch, but I am unsure where to start looking and what to try out. I looked about the wiki page[1], but didn't find any hints. I found some undocumented signals on GdkWindow in the gtk-doc html that I couldn't figure out what was for; "get-parent", "get-off-screen-parent" et. al. And also - is there an easy way to run my existing apps on top of the new libs I've installed in /opt? Like some LD_LIBRARY*-magic... -- Cheers, Mikkel [1]: http://live.gnome.org/GTK%2B/ClientSideWindows ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client side windows - request for testing and reviewing
On Wed, 2009-06-17 at 18:21 +0200, Mikkel Kamstrup Erlandsen wrote: > 2009/6/17 Alexander Larsson : > > The client side window branch is now feature complete on X11, and > > includes API to do offscreen window embedding (with patches for > > clutter-gtk availible to test this). Today I merged the latest master > > into the branch to make it easy for people to test it (its got the new > > so version). > > > > I fixed the last known (to me) bug yesterday (an obscure WM interaction > > issue on loading the saved session), and am running this as my default > > Gtk+ without issues. > > > > The win32 branch is getting some work done by Cody Russell, and the > > Quartz backend used to work fine but requires some minor API change > > updates (hopefully Richard can do this soon, CC:ed). > > > > It would be very nice if we could merge this soon. However, to do that > > we need more testing and people to look at the code. As things stand > > right now I've gotten essentially zero feedback. I don't know of anyone > > except the two backend porters who have built or looked at the code > > really. > > > > So, please, please, please, test this code. We need people who run > > "uncommon" apps to test it, and we need people to run it on apps they > > know really well so we can find minor changes in behaviour. > > > > Also, anyone who knows gdk or have an interest in this, please take a > > look at the code and give feedback. > > I think I need some pointers to give some constructive feedback on > this. I've now compiled the client-side-windows branch, but I am > unsure where to start looking and what to try out. That depends on what you want to do. Generally there is not a lot of new API in the csw branch, most of it is a total redesign of how gdk works internally. If you want to test, then just run normal apps like you normally do but with the client side window libraries, then try to find places where it differs in behaviour from the normal one. If you want to review the code, i'd recommend starting in gdkwindow.c, it has a long comment at the top describing how windows work in the new world, then go from there. The new API is mainly about doing offscreen windows: * New window type GDK_WINDOW_OFFSCREEN * gdk_window_get_offscreen_pixmap: Get the current GdkPixmap for an offscreen window * gdk_window_set/get_has_offscreen_children: enable embedding of offscreen children * gdk_window_offscreen_children_changed: Used when the geometry of the embedded offscreen windows change * a few new signals on GdkWindow to handle offscreen window embedding Although there is also a new generic function gdk_window_get_root_coords() that gets the root coordinates of any point in a window (as opposed to the old gdk_window_get_origin() which is not useful when windows may be transformed. > And also - is there an easy way to run my existing apps on top of the > new libs I've installed in /opt? Like some LD_LIBRARY*-magic... Yes, just install in another prefix and run with that in LD_LIBRARY_PATH there. Although this will change where gtk modules are loaded from so e.g. themes may not work with this. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
PATCH: Re: GTKMM Clipboard::wait_for_targets() bug?
On Wed, 2009-06-17 at 14:23 +0100, Peter Clifton wrote: > Hi, > > I'm playing with getting inkscape to paste successfully from our > application (gschem), and have encountered some weird corruption-like > problems with inkscape not successfully getting the correct list of > targets on the clipboard. > > Running with valgrind, I see the following: > > ==28334== Invalid read of size 1 > ==28334==at 0x40276E8: strlen (mc_replace_strmem.c:242) > ==28334==by 0x58F888A: std::basic_string, > std::allocator >::basic_string(char const*, std::allocator > const&) (in /usr/lib/libstdc++.so.6.0.10) > ==28334==by 0x451B74A: Glib::ustring::ustring(char const*) (in > /usr/lib/libglibmm-2.4.so.1.2.0) > ==28334==by 0x8389DF3: > Inkscape::UI::ClipboardManagerImpl::_getBestTarget() > (containerhandle_shared.h:291) > ==28334==by 0x838AE7D: Inkscape::UI::ClipboardManagerImpl::paste(bool) > (clipboard.cpp:305) > ==28334==by 0x80C38C3: sp_selection_paste(SPDesktop*, bool) > (selection-chemistry.cpp:954) > ==28334==by 0x824642C: sp_action_perform(SPAction*, void*) > (action.cpp:181) > ==28334==by 0x80D41E7: sp_shortcut_invoke(unsigned int, > Inkscape::UI::View::View*) (shortcuts.cpp:55) > ==28334==by 0x824CB36: on_window_key_press(_GdkEventKey*) (window.cpp:34) > ==28334==by 0x42AFEF1: (anonymous > namespace)::Widget_signal_key_press_event_callback(_GtkWidget*, > _GdkEventKey*, void*) (slot.h:515) > ==28334==by 0x47EE525: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) > ==28334==by 0x4D3BC7A: g_closure_invoke (gclosure.c:767) > > The string which causes the invalid read is the target returned from > inkscape's Inkscape::UI::ClipboardManagerImpl::_get_best_target() > function. The string originates from a call to > Gtk::Clipboard::wait_for_targets() within the _get_best_target() > function. > > ==28334== Address 0x7e6164c is 12 bytes inside a block of size 22 free'd > ==28334==at 0x402599A: operator delete(void*) (vg_replace_malloc.c:342) > ==28334==by 0x58F79FC: std::string::_Rep::_M_destroy(std::allocator > const&) (in /usr/lib/libstdc++.so.6.0.10) > ==28334==by 0x451E5C0: Glib::ustring::~ustring() (in > /usr/lib/libglibmm-2.4.so.1.2.0) > ==28334==by 0x41F6206: Gtk::Clipboard::wait_for_targets() const > (new_allocator.h:118) > ==28334==by 0x8389DBD: > Inkscape::UI::ClipboardManagerImpl::_getBestTarget() (clipboard.cpp:1242) > ==28334==by 0x838AE7D: Inkscape::UI::ClipboardManagerImpl::paste(bool) > (clipboard.cpp:305) > ==28334==by 0x80C38C3: sp_selection_paste(SPDesktop*, bool) > (selection-chemistry.cpp:954) > ==28334==by 0x824642C: sp_action_perform(SPAction*, void*) > (action.cpp:181) > ==28334==by 0x80D41E7: sp_shortcut_invoke(unsigned int, > Inkscape::UI::View::View*) (shortcuts.cpp:55) > ==28334==by 0x824CB36: on_window_key_press(_GdkEventKey*) (window.cpp:34) > ==28334==by 0x42AFEF1: (anonymous > namespace)::Widget_signal_key_press_event_callback(_GtkWidget*, > _GdkEventKey*, void*) (slot.h:515) > ==28334==by 0x47EE525: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) > > > What I can't understand, is why the destructor for the ustring is being > called in Gtk::Clipboard::wait_for_targets(), since that ustring should > be "owned" by the std::list of ustrings which is being returned. > > I'm not a C++ programmer by any means, so any help in finding the right > path to pursue in debugging this would be much appreciated. It seems that the implicit creation of a Glib::StringArrayHandle upon return was causing the problem. The constructor which takes a container (our std::list of ustring targets), does not associate ownership of the array elements with the newly created Glib::StringArrayHandle, it just stores pointers. When our "listTargets" std::list goes out of scope, its elemensts are free'd, thus causing the corruption / problems when our caller tries to use its result. I'm no C++ programmer, so the best I could come up with was using the alternative array based constructor for Glib::StringArrayHandle, passing an array of char *, and associating their ownership with the returned list. I _think_ this works in terms of non-leakiness, but I'm not sure. Anyway - the fact it fixes the bug ought to help identify a better fix if necessary. Could someone point me to the appropriate place / person to file a bug / bug regarding this fix? Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: PATCH: Re: GTKMM Clipboard::wait_for_targets() bug?
Patch attached this time!
[snip]
> It seems that the implicit creation of a Glib::StringArrayHandle upon
> return was causing the problem. The constructor which takes a container
> (our std::list of ustring targets), does not associate ownership of the
> array elements with the newly created Glib::StringArrayHandle, it just
> stores pointers.
>
> When our "listTargets" std::list goes out of scope, its elemensts are
> free'd, thus causing the corruption / problems when our caller tries to
> use its result.
>
> I'm no C++ programmer, so the best I could come up with was using the
> alternative array based constructor for Glib::StringArrayHandle, passing
> an array of char *, and associating their ownership with the returned
> list.
>
> I _think_ this works in terms of non-leakiness, but I'm not sure. Anyway
> - the fact it fixes the bug ought to help identify a better fix if
> necessary.
>
> Could someone point me to the appropriate place / person to file a bug /
> bug regarding this fix?
>
> Best regards,
>
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
--- clipboard.ccg.orig 2009-06-18 00:16:05.429600954 +0100
+++ clipboard.ccg 2009-06-18 00:16:59.237571924 +0100
@@ -329,8 +329,7 @@
Glib::StringArrayHandle Clipboard::wait_for_targets() const
{
- std::list listTargets;
-
+ char **array;
//Get a newly-allocated array of atoms:
GdkAtom* targets = 0;
gint n_targets = 0;
@@ -338,20 +337,18 @@
if(!test)
n_targets = 0; //otherwise it will be -1.
+ if (n_targets == 0)
+return Glib::StringArrayHandle (NULL, 0, Glib::OWNERSHIP_DEEP);
+
+ array = static_cast(g_malloc (n_targets * sizeof (char *)));
+
//Add the targets to the C++ container:
for(int i = 0; i < n_targets; i++)
{
//Convert the atom to a string:
-gchar* const atom_name = gdk_atom_name(targets[i]);
-
-Glib::ustring target;
-if(atom_name)
- target = Glib::ScopedPtr(atom_name).get(); //This frees the gchar*.
-
-listTargets.push_back(target);
+array[i] = gdk_atom_name(targets[i]);
}
-
- return listTargets;
+ return Glib::StringArrayHandle (array, n_targets, Glib::OWNERSHIP_DEEP);
}
void Clipboard::set_can_store(const ArrayHandle_TargetEntry& targets)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
