Gtkmm-forge Digest, Vol 9, Issue 4
- From: gtkmm-forge-request lists sourceforge net
- To: gtkmm-forge lists sourceforge net
- Subject: Gtkmm-forge Digest, Vol 9, Issue 4
- Date: Sun, 11 Feb 2007 20:03:18 -0800
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 336598] Glib option parser: Default arguments are
overwritten (glibmm (bugzilla.gnome.org))
2. [Bug 384092] test does not build (glibmm (bugzilla.gnome.org))
3. [Bug 394907] delete the class which inherit from gtk has some
memory leak. (gtkmm (bugzilla.gnome.org))
4. [Bug 394907] delete the class which inherit from gtk has some
memory leak. (gtkmm (bugzilla.gnome.org))
5. [Bug 406825] New: i18n chapter update (gtkmm (bugzilla.gnome.org))
6. [Bug 406825] i18n chapter update (gtkmm (bugzilla.gnome.org))
7. [Bug 406825] i18n chapter update (gtkmm (bugzilla.gnome.org))
8. [Bug 399216] New feature: Glib::ustring::compose()
(glibmm (bugzilla.gnome.org))
----------------------------------------------------------------------
Message: 1
Date: Sat, 10 Feb 2007 19:28:21 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 336598] Glib option parser: Default
arguments are overwritten
To: gtkmm-forge lists sourceforge net
Message-ID: <20070210192821 D7F9A6C416D 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=336598
glibmm | general | Ver: 2.8.x
Murray Cumming changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Comment #7 from Murray Cumming 2007-02-10 19:26 UTC -------
I have restored the changes to the glibmm-2-8, glibmm-2-10 and glibmm-2-12
branches. They had survived in trunk (future glibmm 2.13/2.14). It was my
fault.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 2
Date: Sat, 10 Feb 2007 19:29:17 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 384092] test does not build
To: gtkmm-forge lists sourceforge net
Message-ID: <20070210192917 7A82A6C416C 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=384092
glibmm | build | Ver: 2.10.x
Murray Cumming changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |murrayc murrayc com
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Comment #1 from Murray Cumming 2007-02-10 19:27 UTC -------
You'll need to update your glibmm version.
Sorry about that. There was no configure check that would have been reliable in
this case.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 3
Date: Sun, 11 Feb 2007 05:53:19 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 394907] delete the class which inherit
from gtk has some memory leak.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070211055319 C3DAA6C41C4 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=394907
gtkmm | general | Ver: 2.8.x
------- Comment #3 from simon 2007-02-11 05:51 UTC -------
(In reply to comment #2)
> Furthermore, I see no rectangle as described in your step 3.
>
> Please simplify your test case to a single simple-as-possible .cc file and
> attach it, after reopening this bug. I want to help but I'm not prepared to do
> all your debugging for you.
>
Thank you for your reply.
It may gtk+ not properly to use directfb . I thanged the gtk source code as
follow:
gdkwindow-directfb.c
void
_gdk_windowing_window_destroy (GdkWindow *window,
gboolean recursing,
gboolean foreign_destroy)
{
GdkWindowObject *private;
GdkWindowImplDirectFB *impl;
g_return_if_fail (GDK_IS_WINDOW (window));
private = GDK_WINDOW_OBJECT (window);
impl = GDK_WINDOW_IMPL_DIRECTFB (private->impl);
_gdk_selection_window_destroyed (window);
if (window == _gdk_directfb_pointer_grab_window)
gdk_pointer_ungrab (GDK_CURRENT_TIME);
if (window == _gdk_directfb_keyboard_grab_window)
gdk_keyboard_ungrab (GDK_CURRENT_TIME);
if (window == gdk_directfb_focused_window)
gdk_directfb_change_focus (NULL);
if (!recursing && !foreign_destroy && impl->window ) {
impl->window->SetOpacity (impl->window,0);
impl->window->Close(impl->window);
impl->window->Release(impl->window);
}
/* follow line is added by simon that refers from debian installer
* this change make the leak very samller , but it still has.
*/
g_object_unref (window);
#if 0 /* let the finalizer kill it */
if (!recursing && !foreign_destroy)
{
if (impl->window)
impl->window->Destroy (impl->window);
impl->window = NULL;
}
#endif
}
I am not familiar with the gtk source. I think may be the some directfb surface
or widow ref not properly destroy. If you have any good idea, let me know ,
thank you !
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 4
Date: Sun, 11 Feb 2007 10:50:40 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 394907] delete the class which inherit
from gtk has some memory leak.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070211105040 A41C86C41B7 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=394907
gtkmm | general | Ver: 2.8.x
------- Comment #4 from Murray Cumming 2007-02-11 10:48 UTC -------
> It may gtk+ not properly to use directfb . I thanged the gtk source code as
> follow:
1. That's not a patch (try "svn diff"), so it's not easy to see what you
changed.
2. If a fix is necessary in GTK+ then please submit a patch to a GTK+ bug.
Please do mention the bug number here.
3. I am surprised that DirectFB is relevant here, but even for fixing a
DirectFB problem, you need a simple test case to demonstrate the problem. This
test case is not simple enough.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 5
Date: Sun, 11 Feb 2007 20:39:30 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 406825] New: i18n chapter update
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-406825-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=406825
gtkmm | documentation | Ver: 2.10.x
Summary: i18n chapter update
Product: gtkmm
Version: 2.10.x
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: Normal
Component: documentation
AssignedTo: gtkmm-forge lists sourceforge net
ReportedBy: marko marko anastasov name
GNOME version: Unspecified
GNOME milestone: Unspecified
Explains how to set up an autotools-based project, the use of intltool, basic
instructions how to add a translation and a resources list.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 6
Date: Sun, 11 Feb 2007 20:40:03 +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: <20070211204003 87E0B6C41F6 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 #1 from Marko Anastasov 2007-02-11 20:38 UTC -------
Created an attachment (id=82342)
--> (http://bugzilla.gnome.org/attachment.cgi?id=82342&action=view)
patch for gtkmm_tut.xml
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 7
Date: Mon, 12 Feb 2007 01:34:09 +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: <20070212013409 3ED9E6C41A0 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
jonner changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jonathon jongsma gmail com
------- Comment #2 from jonner 2007-02-12 01:32 UTC -------
nice. one quick comment from a brief perusal: I don't think the following
line is necessary if you're requiring intltool 0.35:
+ ALL_LINGUAS= "`cat "$srcdir/po/LINGUAS"`"
I believe that was a hack that was required before intltool was changed so that
it read the po/LINGUAS file directly (I believe that happened in 0.35).
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
Message: 8
Date: Mon, 12 Feb 2007 04:05:00 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 399216] New feature:
Glib::ustring::compose()
To: gtkmm-forge lists sourceforge net
Message-ID: <20070212040500 DE4416C417E 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=399216
glibmm | strings | Ver: 2.13.x
------- Comment #5 from Daniel Elstner 2007-02-12 04:03 UTC -------
Er, I think you misunderstood. My fault, I should probably have added a little
more context to my explanation. What ustring::format() does is this:
template <class T1> inline // static
ustring ustring::format(const T1& a1)
{
ustring::FormatStream buf;
buf.stream() << a1;
return buf.to_string();
}
ustring::format() is overloaded for up to N arguments, with N=6 in my current
patch. It simply writes each argument to a temporary stream and returns the
accumulated result as a string. The STL stream is encapsulated in a private
FormatStream class in order to move as much code out of the template as
possible. buf.stream() returns a reference to the internal STL stream. Now,
what Ole Laursen has discovered is that this internal stream must be a wide
character stream, i.e. std::wostringstream and not just std::ostringstream.
Why? Because some of the locale-defined characters that are implicitly produced
by string formatting could end up truncated otherwise. The thousands separator,
for instance, could be a code point outside the ASCII range. One realistic
example would be U+066C ARABIC THOUSANDS SEPARATOR. All is fine if you deal
with code points as a whole -- that is, when all code points have the same
fixed storage size, and an object of the stream's character type always holds
exactly one such code point.
Now, if you introduce multi-byte encodings such as UTF-8 into the picture, this
holds no longer true. An object of the stream's "character" type does not
necessarily contain a whole code point anymore. The single wchar_t object 0x66C
(assuming Unicode here) becomes a string of 2 char objects: 0xD9 0xAC. Thus,
it's no longer a single object of the stream's so-called "character" type, but
actually a string.
When internationalization was added to the STL stream interface, apparently
no-one envisioned that some day people would want to use a multi-byte encoding
as internal encoding in an application. The common mantra back then was to use
a fixed-width encoding internally and a multi-byte encoding externally. Earlier
multi-byte encodings were stateful and thus cumbersome, and often inefficient
to process -- especially if the generic C library functions were used. In no
way did the C++ standard anticipate the huge success of UTF-8, and most
importantly that applications would start using it for everything
*independently of the locale*. If UTF-8 is the only encoding, applications can
hard-code the multi-byte processing. Because of the cunningly simple design of
the UTF-8 encoding scheme, the performance considerations thus become moot.
But since noone envisioned that, we inherited the legacy of a stream locale
interface that simply doesn't allow one to use a string as the thousands
separator. It must be a single object of the stream's "character" type. See
std::numpunct::thousands_sep():
<http://www.tacc.utexas.edu/services/userguides/pgi/pgC++_lib/stdlibcr/num_2619.htm#Public%20Member%20Functionsthousands_sep()>
That's why we must use std::wostringstream to format the string. The fact that
probably only very few people will be aware of this nasty catch (I wasn't until
I read it on Ole Laursen's website) makes it all the more necessary to add this
formatting API to glibmm.
And on the implementation side, it's not so bad actually. Arguably going
through wchar_t is cleaner in some sense, as it e.g. allows for skipping the
locale conversion on modern systems (glibc always uses UCS-4 and win32 always
uses UTF-16 for wchar_t). We only need to have configure check for its
availability. In any case our users won't have to worry about it.
Pheww!
(I still intend to do the promised write-up for the mailing list about my
compose/format API split proposal. Gimme a couple of days.)
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------
_______________________________________________
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 4
*****************************************
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
