Send Gtkmm-forge mailing list submissions to
        [EMAIL PROTECTED]

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
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

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 Gtk::DragContext::get_targets()
      (gtkmm (bugzilla.gnome.org))
   2. [Bug 397167] build failure: error: expected       initializer
      before '&' token (glibmm (bugzilla.gnome.org))
   3. [Bug 399403] borked Gtk::DragContext::get_targets()
      (gtkmm (bugzilla.gnome.org))
   4. [Bug 399403] borked Gdk::DragContext::get_targets()
      (gtkmm (bugzilla.gnome.org))
   5. [Bug 399403] borked Gdk::DragContext::get_targets()
      (gtkmm (bugzilla.gnome.org))
   6. [Bug 397167] build failure: error: expected       initializer
      before '&' token (glibmm (bugzilla.gnome.org))
   7. [Bug 399216] New feature: Glib::ustring::compose()
      (glibmm (bugzilla.gnome.org))
   8. [Bug 399216] New feature: Glib::ustring::compose()
      (glibmm (bugzilla.gnome.org))


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

Message: 1
Date: Mon, 22 Jan 2007 15:18:19 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399403] borked
        Gtk::DragContext::get_targets()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]
          Component|general                     |general
            Product|glibmm                      |gtkmm
            Summary|Issue with functions        |borked
                   |returning                   |Gtk::DragContext::get_target
                   |ArrayHandle<ustring>        |s()
            Version|2.12.x                      |2.10.x




------- Comment #1 from Daniel Elstner  2007-01-22 15:16 UTC -------
Your test case is broken; it is not valid to return a Glib::ArrayHandle<> that
was constructed from data with local scope.  It's a wonder that it doesn't
simply crash.  If as you say Gtk::DragContext::get_targets() does that, it is
broken.  Therefore I'll reassign the bug to gtkmm.  Thanks for your report.

Doh.  It's called "Handle" for a reason, really.


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



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

Message: 2
Date: Mon, 22 Jan 2007 15:22:43 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 397167] build failure: error: expected
        initializer before '&' token
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=397167

  glibmm | build | Ver: unspecified





------- Comment #4 from Murray Cumming  2007-01-22 15:21 UTC -------
Craig, I'm not sure what you are trying to tell us with that first chunk of
(strange) code.

gtkmmproc is now called gmmproc, but you should never need to execute it
directly. Just changing the .hg and .ccg files and running make again should
regenerate the files. You might need to run autogen.sh.

Daniel wrote:
> It should be safe to simply #undef mkstemp if necessary

I'd rather not do that in a public header. I think we'll need to check for it
in configure to #ifdef it out when necessary. And we'll have to add an
alternative method.


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



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

Message: 3
Date: Mon, 22 Jan 2007 15:25:17 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399403] borked
        Gtk::DragContext::get_targets()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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


Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]




------- Comment #2 from Murray Cumming  2007-01-22 15:23 UTC -------
So I guess we need to allocate copies of the items? A patch would be welcome.


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



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

Message: 4
Date: Mon, 22 Jan 2007 15:42:26 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399403] borked
        Gdk::DragContext::get_targets()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|borked                      |borked
                   |Gtk::DragContext::get_target|Gdk::DragContext::get_target
                   |s()                         |s()




------- Comment #3 from Daniel Elstner  2007-01-22 15:40 UTC -------
I just had a look at the code, and it is indeed broken.  The proper solution
would be to define new traits for conversion from GdkAtom to strings, but that
would break API/ABI.  By the way, GDK_POINTER_TO_ATOM() should rather be used
instead of a direct cast.  I think we should do either

a) Convert each GList element to a string, as in:
   node->data = g_atom_name(G_POINTER_TO_ATOM(node->data))
   and then return a Glib::ListHandle<Glib::ustring> with OWNERSHIP_DEEP
or
b) Define the appropriate traits struct.  Come to think of it, maybe
   it even exists already.  Dunno.

Hmm, I just realized that a) break API/ABI too, since it is a list, not an
array.   That could be hacked around by creating a temporary array instead. 
However, in fact it doesn't matter if we break this API/ABI since it is broken
to begin with.  Nobody can possibly be using it at the moment.  So I'd vote for
b).


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



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

Message: 5
Date: Mon, 22 Jan 2007 15:44:47 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399403] borked
        Gdk::DragContext::get_targets()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




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



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

Message: 6
Date: Tue, 23 Jan 2007 09:55:18 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 397167] build failure: error: expected
        initializer before '&' token
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=397167

  glibmm | build | Ver: unspecified





------- Comment #5 from Craig Keogh  2007-01-23 09:53 UTC -------
Sorry. The code is what gmmproc generated on my computer. The code is obviously
wrong. gmmproc must have a bug that causes it to generate this bad code.


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



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

Message: 7
Date: Tue, 23 Jan 2007 11:46:45 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399216] New feature:
        Glib::ustring::compose()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=399216

  glibmm | strings | Ver: 2.13.x


Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]




------- Comment #2 from Murray Cumming  2007-01-23 11:45 UTC -------
> using Glib::ustring;
> const int percentage = 50;
> const ustring text = ustring::compose("%1%% done",
> ustring::format(percentage));

Could you explain why we can't just do:
  const ustring text = ustring::compose("%1%% done", 50);
?

Is %1% something standard with printf, or something new? Would %d be as valid?

Also, I don't understand the need for wchar. I thought that was something we
never needed to use with UTF-8.


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



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

Message: 8
Date: Tue, 23 Jan 2007 14:33:53 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399216] New feature:
        Glib::ustring::compose()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=399216

  glibmm | strings | Ver: 2.13.x





------- Comment #3 from Daniel Elstner  2007-01-23 14:32 UTC -------
> Could you explain why we can't just do:
>  const ustring text = ustring::compose("%1%% done", 50);
> ?

This would work with Ole Laursen's compose mini-library.  But as I said above,
I'm somewhat in favor of separating the compose and format functionality.  I'll
hopefully have the time today to outline my reasons for this on the mailing
list, as promised.

> Is %1% something standard with printf, or something new? Would %d be as valid?

No, %d would not be valid because compose() is not printf().  However, the
format is already used by Qt (and therefore known as qt-format).  It is
supported by gettext, too, and I have been using it in regexxer for years now. 
Note that the whole idea of compose() is to offer a typesafe means of message
formatting.  The %d or %f or whatever would make no sense, as these are used to
specify the type of the argument.  %1 just means that the first argument is to
be substituted.

> Also, I don't understand the need for wchar. I thought that was something we
> never needed to use with UTF-8.

We don't.  It's an implementation detail hidden behind the compose/format API. 
The problem is that e.g. thousands separators are defined by single characters,
not strings.  In a locale where the thousand separator doesn't fit into a
single byte, plain std::ostream will truncate it.  In fact, such subtleties are
one more reason to have the compose functionality in glibmm, so our users don't
have to put up with that.  Also note that using wchar_t has the advantage of
avoiding locale->UTF-8 conversion through iconv, since it always holds UCS-4
code points on modern Linux systems, independently of the locale.  This can be
detected at compile time; just have a look at the patch.


-- 
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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 8, Issue 16
******************************************
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to