Re: Disabling localisation for an app

2008-10-17 Thread Paul Davis 
On Thu, 2008-10-16 at 22:07 +0200, Søren Hauberg wrote:
 2008/10/16 klaus triendl [EMAIL PROTECTED]:
  Søren Hauberg schrieb:
  Thanks. I didn't know the 'setlocale' function, which was the one I
  needed. I've just added a 'setlocale (LC_ALL, C);' to my code, as I
  don't want any locale changes anywhere in the application.
 
  Beware, c++ functionality like iostreams uses its own locale.
  So you need to call additionally std::locale::global(C) to change the
  c++ locale to C on a global scale.
 
 Thanks for the heads up -- I'm sure that one probably have confused me
 at some point in the future. For the record, it seems
 std::locale::global expects a std::locale and not a string, so the
 extra needed line is 'std::locale::global (std::locale (C));'

one small note on this: one of the reasons why i prefer to use locale
settings for stdio (C) only is that it allows me to leave iostreams free
to take of localization for actual user interaction. i simply ensure
that i use stdio to store configuration data etc etc, and iostreams to
present and collection from the user. i would not have commented on this
until recently, when i was using ebay.de which insisted that i enter 1
euro and 50 cents as 1,50 rather than 1.50. although the error
message was not helpful, i believe the behaviour was correct given
national conventions. if you switch all of iostreams to C as well, its
becomes a bit more problematic to parse user input in a way that takes
localization into account, or present it to them in the typical way.

but it might not matter :)

--p


___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: [newbie questions]

2008-10-17 Thread Igor Mironchick 

Thx, guys, for uors replies. They was very helpfull.

And sorry for my english :)

--
Regards,
Igor Mironchick,
Intervale

___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Gtkmm-forge Digest, Vol 29, Issue 8

2008-10-17 Thread gtkmm-forge-request 
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 556387] FileEnumerator::next_file reference  counting
  problems (glibmm (bugzilla.gnome.org))
   2. [Bug 556387] FileEnumerator::next_file reference  counting
  problems (glibmm (bugzilla.gnome.org))
   3. [Bug 556315] Extra defs generation utility forgetsto
  generate signals for interfaces (glibmm (bugzilla.gnome.org))
   4. [Bug 556560] New: gtk_source_language_manager_guess_language
  wrapper missing (gnomemm (bugzilla.gnome.org))
   5. [Bug 556560]  gtk_source_language_manager_guess_language
  wrapper missing (gnomemm (bugzilla.gnome.org))
   6. [Bug 556570] New: Version 0.9.7 fails to build dueto call to
  ``GstBase::wrap_init()'' in gstreamer/gstreamermm/init.cc
  (gnomemm (bugzilla.gnome.org))
   7. [Bug 556570] Version 0.9.7 fails to build due to  call to
  ``GstBase::wrap_init()'' in gstreamer/gstreamermm/init.cc
  (gnomemm (bugzilla.gnome.org))


--

Message: 1
Date: Wed, 15 Oct 2008 14:44:37 + (UTC)
From: glibmm (bugzilla.gnome.org)
[EMAIL PROTECTED]
Subject: [gtkmm bugzilla] [Bug 556387] FileEnumerator::next_file
reference   counting problems
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
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=556387

  glibmm | giomm | Ver: unspecified

Murray Cumming changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Comment #5 from Murray Cumming  2008-10-15 14:44 UTC ---
I guess this isn't documented properly for the C function:
http://library.gnome.org/devel/gio/unstable/GFileEnumerator.html#g-file-enumerator-next-file
Maybe it should say you should unreference this with g_object_unref() or
suchlike. Could you file a bug for that, please?


-- 
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=556387.



--

Message: 2
Date: Wed, 15 Oct 2008 15:30:55 + (UTC)
From: glibmm (bugzilla.gnome.org)
[EMAIL PROTECTED]
Subject: [gtkmm bugzilla] [Bug 556387] FileEnumerator::next_file
reference   counting problems
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
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=556387

  glibmm | giomm | Ver: unspecified




--- Comment #6 from Armin Burgmeier  2008-10-15 15:30 UTC ---
I filed bug #556422.


-- 
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=556387.



--

Message: 3
Date: Wed, 15 Oct 2008 16:05:10 + (UTC)
From: glibmm (bugzilla.gnome.org)
[EMAIL PROTECTED]
Subject: [gtkmm bugzilla] [Bug 556315] Extra defs generation utility
forgets to generate signals for interfaces
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
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:

Removing a widget

2008-10-17 Thread Germán Diago 
Hello. I would like to know how to remove a widget from a container in
order to replace it by
 other widget when a button is pushed. Is hiding and unparenting the
widget the correct way to
do it? Because the widget is still shown. Thanks in advance.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Using gtkmm with Visual C++ and _SECURE_SCL=0

2008-10-17 Thread Thomas Frank 

Hallo.

I'm trying to introduce gtkmm (also) on windows as GUI to my non-GUI 
libraries. As many other users of Visual C++ I need to #define 
_SECURE_SCL=0 for the Release-versions of my libraries and any 
application that uses them, to ensure a satisfying performance of the 
STL-containers.


It turns out that _SECURE_SCL=0 is incompatible with gtkmm from the 
windows installer-package. All the release-versions of the libraries 
here are compiled with the default (and slow) _SECURE_SCL=1. This 
would be no problem at all, if no public interfaces would instantiate or 
exchange any STL-containers. But a sigc::signal for example, uses 
std::list to store slots connected to signals and returns a 
list::iterator with the connect()-function. This produces linker errors 
when calling signal::connect() and compiling and linking an application 
with #define _SECURE_SCL=0 against gtkmm.


Has anybody ever ran into the same kind of problem(s) and found a 
workaround other than recompiling gtkmm and all its dependant 
C++-libraries?


I would like to enjoy the comfort and reliability of the installers both 
for development and deployment. Using _SECURE_SCL=1 with my own 
source-code is definitely not an option, due to the absolutely 
disappointing performance of the STL-containers in this mode.


I searched for _SECURE_SCL in the archives but didn't get any results. 
Has this ever been a topic?



thanks in advance and regards
Thomas
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list