GNOME.org
 

Gtkmm-forge Digest, Vol 9, Issue 5

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-owner lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 399403] borked Gdk::DragContext::get_targets()
      (gtkmm (bugzilla.gnome.org))
   2. [Bug 406960] New: TypeTraits<bool> utterly broken
      (glibmm (bugzilla.gnome.org))
   3. [Bug 406825] i18n chapter update (gtkmm (bugzilla.gnome.org))
   4. [Bug 407711] New: Attempts to register same type	multiple
      times. (glibmm (bugzilla.gnome.org))
   5. [Bug 407711] Attempts to register same type	multiple times.
      (glibmm (bugzilla.gnome.org))
   6. [Bug 407711] Attempts to register same type	multiple times.
      (glibmm (bugzilla.gnome.org))
   7. [Bug 407711] Attempts to register same type	multiple times.
      (glibmm (bugzilla.gnome.org))
   8. [Bug 407711] Attempts to register same type	multiple times.
      (glibmm (bugzilla.gnome.org))


----------------------------------------------------------------------

Message: 1
Date: Mon, 12 Feb 2007 05:19:05 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 399403] borked
	Gdk::DragContext::get_targets()
To: gtkmm-forge lists sourceforge net
Message-ID: <20070212051905 DA6EB6C4180 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=399403

  gtkmm | general | Ver: 2.10.x





------- Comment #6 from Daniel Elstner  2007-02-12 05:17 UTC -------
Aah, nice to see that apparently the traits struct really does exist already.
The patch seemed a bit strange at first, since essentially it relies on the
conversion

  static_cast<GdkAtom>(node->data); // node->data has type void*

to work, and I had trouble imagining how this could compile at all. But then I
figured that GdkAtom is actually a pointer:

  typedef struct _GdkAtom *GdkAtom;

That's okay then. We're stretching the API guarantees of GTK+ a little since it
isn't really public, but I think that's acceptable here. So the patch looks
fine to me. However:

  * gtk/src/selectiondata.ccg: Added a commented-out alternative implementation 
  of get_targets(), using ArrayHandle_AtomString. We can not actually use this
  because it breaks API of a function that apparently does work. 

No way, Gtk::SelectionData::get_targets() can't possibly work. Unless you count
accessing already freed memory as working. The bug will only be apparent if the
caller actually accesses the strings.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 2
Date: Mon, 12 Feb 2007 05:45:03 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 406960] New: TypeTraits<bool> utterly
	broken
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-406960-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=406960

  glibmm | general | Ver: 2.13.x

           Summary: TypeTraits<bool> utterly broken
           Product: glibmm
           Version: 2.13.x
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: daniel kitta gmail com
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I just discovered this little gem:

template <>
struct TypeTraits<bool>
{
  typedef bool          CppType;
  typedef gboolean*     CType;
  typedef gboolean*     CTypeNonConst;

  static CType to_c_type (CppType val) { return (int*)GINT_TO_POINTER(val); }
  static CType to_c_type (CType ptr)   { return ptr;                        }  

  static CppType to_cpp_type(CType ptr)
  { 
    if(ptr)
    {
          //We use this for gboolean too, because it is actually an int.
          return GPOINTER_TO_INT(ptr);
        }
        else
          return CppType();
  }

  static void release_c_type(CType /* ptr */)
  {

  }
};

Bllaaaaarghh! This is completely and utterly broken. Looks like the KeyFile
addition is responsible:

2006-02-20  Rob Page  <page rob gmail com>

        Wraps GKeyFile (Bug #330535)
        * glib/glibmm.h: Added include of keyfile.h
        * glib/glibmm/Makefile.am: Added keyfile.h
        * glib/glibmm/containerhandle_shared.h: Added a TypeTraits
        specialization for converting between bool and gboolean*.
        * glib/src/Makefile_list_of_hg.am_fragment: Added keyfile.hg
        to files_general_hg.
        * glib/src/keyfile.hg: KeyFile header
        * glib/src/keyfile.ccg: KeyFile implementation
        * tools/m4/convert_glib.m4: Added a conversion for KeyFileFlags

It's used here:

Glib::ArrayHandle<bool> KeyFile::get_boolean_list(const Glib::ustring&
group_name, const Glib::ustring& key) const
{
  gboolean* bool_list  = 0;
  gsize length_of_list = 0; 
  GError* error        = 0;
  bool_list = g_key_file_get_boolean_list(const_cast<GKeyFile*>(gobj()),
group_name.c_str(), key.c_str(), &length_of_list, &error);
  if(error)
    Glib::Error::throw_exception(error);
  return Glib::ArrayHandle<bool>(&bool_list, length_of_list,
Glib::OWNERSHIP_DEEP);
}

I bet my ass this code will cause hell to break loose at runtime. The actual
mistake which probably prompted the author to add the TypeTraits<bool>
specialization (*aaarrghg!*) is rather subtle:

  return Glib::ArrayHandle<bool>(&bool_list, length_of_list, ...)
                                ^^^
That & is one & too many. The ownership should be SHALLOW, too, but that's
comparatively minor in this case as DEEP ownership is meaningless for arrays of
plain old values.

Strangely enough, KeyFile::get_integer_list() does it right (except for the
ownership), even though the code is almost identical.

I dearly hope that we're not using *_Handle<bool> anywhere else throughout the
library stack, or they might be ABI fun to deal with.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 3
Date: Tue, 13 Feb 2007 14:13:06 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 406825] i18n chapter update
To: gtkmm-forge lists sourceforge net
Message-ID: <20070213141306 9D4796C41FD box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=406825

  gtkmm | documentation | Ver: 2.10.x





------- Comment #3 from Marko Anastasov  2007-02-13 14:11 UTC -------
Yes, that line is not necessary.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 4
Date: Wed, 14 Feb 2007 02:24:13 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 407711] New: Attempts to register same
	type	multiple times.
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-407711-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=407711

  glibmm | general | Ver: 2.8.x

           Summary: Attempts to register same type multiple times.
           Product: glibmm
           Version: 2.8.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: pjdavis engineering uiowa edu
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I've got a class derived from Gtk::TreeModel::ColumnRecord defined in a plugin.

If I load the plugin multiple times, Glibmm gives this error:

glibmm-WARNING **: file value_custom.cc: (Glib::custom_boxed_type_register):
The type name `glibmm__CustomBoxed_N3cas13_MachineCoordE' has been registered
already.
This is not supposed to happen -- please send a mail with detailed information
about your platform to gtkmm-list gnome org   Thanks.

I don't have a test case worked up, but I might be able to work one up later if
I have time.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 5
Date: Wed, 14 Feb 2007 04:16:19 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 407711] Attempts to register same type
	multiple times.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070214041619 61CD36C4164 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=407711

  glibmm | general | Ver: 2.8.x


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel kitta gmail com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
         OS/Version|Linux                       |All




------- Comment #1 from Daniel Elstner  2007-02-14 04:14 UTC -------
This warning is triggered when the static member variable in
Glib::Value_Boxed<> that holds the GType has a zero value, but upon
registration the GType appears to have been already registered.  When I added
this warning, the only situation I had in mind where this could happen was if
the linker doesn't correctly merge static member data of template classes
across multiple translation units.

I didn't consider the possibility of dynamically loaded plugins, though.  Now
as I think about it, it's obvious why it breaks:  The static member data goes
away with the module, and reappears zero-initialized.

Urgh, that's a tough one to solve.  Just skipping the second registration
doesn't cut it, as the function pointers back to the template methods are now
different, too.  We can't just unregister a statically registered type, either.
 It'll be necessary to use a GTypePlugin, specifically GTypeModule, in order to
support dynamic loading and unloading.

http://developer.gnome.org/doc/API/2.0/gobject/GTypeModule.html

If we can actually pull this off -- without breaking ABI --, it would be wise
to perform some measurements to gauge the impact on TreeModel performance.  I
vaguely remember having read somewhere that dynamic types involve additional
mutex locks.

Uh-oh.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 6
Date: Wed, 14 Feb 2007 04:38:38 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 407711] Attempts to register same type
	multiple times.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070214043838 B50A36C416B box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=407711

  glibmm | general | Ver: 2.8.x





------- Comment #2 from Daniel Elstner  2007-02-14 04:36 UTC -------
One possible way to handle this could be to provide a different implementation
of Glib::Value_Boxed<> when compiling a plugin.  This would require the plugin
to be compiled with a global -D preprocessor macro defined to the unique name
of the plugin.  Also, it would be necessary to make absolutely sure that none
of the Gtk::TreeModel::Column<> stuff turns up in any public header file.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 7
Date: Wed, 14 Feb 2007 09:50:57 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 407711] Attempts to register same type
	multiple times.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070214095057 1B8516C4159 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=407711

  glibmm | general | Ver: 2.8.x


Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |murrayc murrayc com




------- Comment #3 from Murray Cumming  2007-02-14 09:49 UTC -------
I wonder if this is fixed by bug #383340. That's in the latest gtkmm 2.10
tarball, and in svn for all branches.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 8
Date: Wed, 14 Feb 2007 10:22:52 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 407711] Attempts to register same type
	multiple times.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070214102252 82E656C414E box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=407711

  glibmm | general | Ver: 2.8.x





------- Comment #4 from Paul Davis  2007-02-14 10:20 UTC -------
As a disclaimer I know absolutely nothing about this part of the API, but after
reading through the comments in bug #383340 it doesn't sound like the same
problem.

I'm not calling Gtk::Main( int argc, char* argv[] ) in the plugin. The Gtk
'context' exists before and after the plugin is loaded/unloaded.

In other words, imagine a window with a button. I click the button. The plugin
loads, opens a window that has a treeview (with the offending ColumnRecord
class). I close the window, the plugin is unloaded. If the main window 'load
plugin' button is clicked again I get the message.

I hope thats not overly confusing...

Earlier I glanced at value_custom.cc and found where the description is printed
in custom_boxed_type_register(), but grepping glibmm and gtkmm I didn't find
any actual calls to that function so I couldn't trace beyond where the warning
gets displayed.

Just skipping the second registration
doesn't cut it, as the function pointers back to the template methods are now
different, too.

I'm not entirely sure what this sentence means. But like I said I don't know
the api. The way I understand the custom_boxed_type_register is that it
registers an allocate/deallocate/copy function with glib. If these are provided
by a plugin, then the addresses *probably* change after an unload/load cycle. 
Granted I haven't the slightest how its called, but why can't we just register
the new allocate/deallocate functions and change the message to "this
registration invalidates the previous." ? It seems like the current warning is
just a sanity check. So instead of returning the currently registered type, we
re-register the type, and make the sanity check "You've re-registered a type,
if you haven't unloaded a static type and reloaded it, you need to talk to the
gtkmm mailing list"

Keep in mind I have absolutely no idea about the specifics. I could see the C
api not allowing this and a host of other reasons that this might not work. But
its just a thought.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

------------------------------

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 9, Issue 5
*****************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]