GNOME.org
 

Gtkmm-forge Digest, Vol 36, Issue 15

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 583992] Provide conversion between wide and	narrow
      unicode strings in glibmm (glibmm (bugzilla.gnome.org))
   2. [Bug 583992] Provide conversion between wide and	narrow
      unicode strings in glibmm (glibmm (bugzilla.gnome.org))
   3. [Bug 583992] Provide conversion between wide and	narrow
      unicode strings in glibmm (glibmm (bugzilla.gnome.org))
   4. [Bug 583992] Provide conversion between wide and	narrow
      unicode strings in glibmm (glibmm (bugzilla.gnome.org))
   5. [Bug 583657] A patch to build static libraries	correctly
      under MinGW (glibmm (bugzilla.gnome.org))
   6. [Bug 583992] Provide conversion between wide and	narrow
      unicode strings in glibmm (glibmm (bugzilla.gnome.org))
   7. [Bug 583657] A patch to build static libraries	correctly
      under MinGW (glibmm (bugzilla.gnome.org))


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

Message: 1
Date: Wed, 27 May 2009 12:50:34 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583992] Provide conversion between wide
	and	narrow unicode strings in glibmm
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527125034 773EB23F59B label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583992

  glibmm | strings | Ver: 2.20.x




------- Comment #1 from Chris Vine  2009-05-27 12:50 UTC -------
Created an attachment (id=135434)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=135434&action=view)
Patch for unicode.hg and unicode.ccg


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583992.



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

Message: 2
Date: Wed, 27 May 2009 14:00:50 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583992] Provide conversion between wide
	and	narrow unicode strings in glibmm
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527140050 C4F2623F59E label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583992

  glibmm | strings | Ver: 2.20.x




------- Comment #3 from Daniel Elstner  2009-05-27 14:00 UTC -------
Sorry, I missed this comment in your code:

  // SIZEOF_WCHAR_T is not defined in config.h for all builds

That's something that should be fixed rather than worked around.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583992.



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

Message: 3
Date: Wed, 27 May 2009 13:52:44 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583992] Provide conversion between wide
	and	narrow unicode strings in glibmm
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527135244 7266523F59D label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583992

  glibmm | strings | Ver: 2.20.x

Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel kitta gmail com
 Attachment #135434|none                        |needs-work
               Flag|                            |
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|usability                   |API




------- Comment #2 from Daniel Elstner  2009-05-27 13:52 UTC -------
I don't like depending on the if () expression to be resolved at compile time,
since it might trigger warnings about unreachable code.  Also, it isn't
necessary since the preprocessor is sufficient.  For inspiration, look at how
the wide stream conversion is done for ustring::format() in ustring.cc.  The
necessary configure magic is already in place, you can just make use of the
same macros.  Also, note that there may be platforms where wchar_t is neither
UCS-4 nor UTF-16.  The implementation in ustring.cc falls back to iconv() in
that case.

Also note that conversion from wide strings to ustrings already works just
fine, by using ustring::format():

    const Glib::ustring s = Glib::ustring::format(L"foo");


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583992.



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

Message: 4
Date: Wed, 27 May 2009 17:35:21 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583992] Provide conversion between wide
	and	narrow unicode strings in glibmm
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527173521 26C4023F59E label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583992

  glibmm | strings | Ver: 2.20.x




------- Comment #4 from Chris Vine  2009-05-27 17:35 UTC -------
The trouble with using Glib::ustring::format() is that it only goes one way. 
Someone interesting in interfacing with modules passing unicode in wide strings
is likely to be interested in going both ways.

On SIZEOF_WCHAR_T, ustring.cc itself has a conditional inclusion of config.h
and my recollection is that this is something to do with MSVC builds.  I do not
know enough about the windows build system to deal with that case, and this
form of conditional compilation on compile time constants is quite a common
idiom.  I do not know of a compiler which does warn about this particular usage
(gcc doesn't).

On codesets, the functions I have proposed are clearly documented as only
dealing with unicode (ie utf-8<=>utf-16/utf-32 codesets), and if anything else
is tried a conversion exception is thrown.  That seems to me to be acceptable,
and iconv() does not cover every codeset known to the world anyway so there is
always going to be the risk of an excluded case.  Sometimes the best is the
enemy of the good (particularly if the best cannot reasonably be achieved), and
it seems to me that the approach should be to document clearly the cases it
will cover.

As it happens, if you cover unicode you will get 99.9% of the cases (a
percentage which will also increase over time).  Possibly if you really think
this is an issue the functions could be put into the unicode namespace as well
as the unicode module to make the point even clearer.[1]

On a linked issue, I have noticed one other point which is that to catch
Glib::ConvertError you need to include glibmm/convert.h, and a user might
expect unicode.h to do that for her.  However, including it directly in
unicode.h causes the cyclical header problems I have referred to.

[1]  Yes, the functions don't cover UTF-7 but no-one uses that and it is
irrelevant to std::wstring and Glib::ustring.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583992.



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

Message: 5
Date: Wed, 27 May 2009 17:58:59 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583657] A patch to build static
	libraries	correctly under MinGW
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527175859 DF14F23F59F label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583657

  glibmm | build | Ver: unspecified

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |armin arbur net,
                   |                            |murrayc murrayc com




------- Comment #2 from Murray Cumming  2009-05-27 17:58 UTC -------
I'm not convinced that a static glibmm library is a particularly good idea, but
I doubt this can hurt much. Thans. I'd be interested to know what you need it
for.

I'll let Armin review the patch because he's doing Windows stuff.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583657.



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

Message: 6
Date: Wed, 27 May 2009 19:43:25 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583992] Provide conversion between wide
	and	narrow unicode strings in glibmm
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527194328 AC17C23EF5F label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583992

  glibmm | strings | Ver: 2.20.x




------- Comment #5 from Daniel Elstner  2009-05-27 19:43 UTC -------
(In reply to comment #4)
> The trouble with using Glib::ustring::format() is that it only goes one way.

Yes, I know.  I just mentioned it because I didn't know if you were aware of
it.  Of course conversion into the other direction is important as well.

> On SIZEOF_WCHAR_T, ustring.cc itself has a conditional inclusion of config.h
> and my recollection is that this is something to do with MSVC builds.

Ah, right, it doesn't use glibmmconfig.h but config.h (which is not installed
anywhere), for which it is customary to make the include conditional.  But
there is no reason to not add config.h to the MSVC builds if one is needed, or
alternatively, just define SIZEOF_WCHAR_T using command line arguments.  (We
know it is always 2 for MSVC builds).

> I do not know of a compiler which does warn about this particular usage
> (gcc doesn't).

It depends on the warning settings, I guess.  I definitely have seen GCC warn
on unreachable code before.

> On codesets, the functions I have proposed are clearly documented as only
> dealing with unicode (ie utf-8<=>utf-16/utf-32 codesets), and if anything else
> is tried a conversion exception is thrown.  That seems to me to be acceptable,
> and iconv() does not cover every codeset known to the world anyway so there is
> always going to be the risk of an excluded case.

This is not really about codesets but about std::wstring.  If we provide a
function that operates on std::wstring or returns std::wstring, we should make
a reasonable attempt to actually do just that.  We really shouldn't have
platform-specific API unless absolutely necessary.

> As it happens, if you cover unicode you will get 99.9% of the cases (a
> percentage which will also increase over time).  Possibly if you really think
> this is an issue the functions could be put into the unicode namespace as well
> as the unicode module to make the point even clearer.

Have you seen the implementation in ustring.cc?  It just falls back to iconv
and uses the generic charset alias WCHAR_T.  Everything else is then up to
iconv.  It's quite likely that there are iconv implementations which don't
support this alias, but for GNU iconv it seems to work.  As an attempt to cover
the generic case, I considered this to be good enough.  If it happens to not
work on some odd platform, we still handle it as a special case as soon as we
know about it.

> On a linked issue, I have noticed one other point which is that to catch
> Glib::ConvertError you need to include glibmm/convert.h, and a user might
> expect unicode.h to do that for her.  However, including it directly in
> unicode.h causes the cyclical header problems I have referred to.

I haven't looked into the dependency problem at all yet.  Let's get the
behavior sorted first.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583992.



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

Message: 7
Date: Wed, 27 May 2009 19:47:50 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 583657] A patch to build static
	libraries	correctly under MinGW
To: gtkmm-forge lists sourceforge net
Message-ID: <20090527194750 EDD2823F59F label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583657

  glibmm | build | Ver: unspecified




------- Comment #3 from Alexander Shaduri  2009-05-27 19:47 UTC -------
Well, from the top of my head, I can give you two reasons:

1. The zip distribution of my program went down from 2.9MB to 1.7MB. I would
say that's a nice improvement.

2. For some reason, purify refuses to load *mm dlls (no such problems with gtk
dlls). Having a statically linked binary allows people to analyze it with
purify (well, to some extent, as you still have to manually match the
instruction pointer addresses with function names), adding a nice tool to the
mingw stack (which really lacks this kind of tools), and improving
security/stability of the program, etc...

There's also the minor bonus of having a single binary, instead of a binary and
a bunch of dlls.

My program won't be able to use the system-installed glibmm/gtkmm anyway, due
to different C++ ABI (I use gcc 4.4, and there are at least 5 incompatible ABI
versions I can think of right now). So, I don't really see a point in dragging
eight or so dlls just for a single binary.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583657.



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

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 

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

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


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