Gtkmm-forge Digest, Vol 34, Issue 2



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 570943] Windows: GtkEntry can't input when	toggling
      visibility twice (gtk+ (bugzilla.gnome.org))
   2. [Bug 572978] Glib::ustring allows comparison to 0
      (glibmm (bugzilla.gnome.org))
   3. [Bug 572978] Glib::ustring allows comparison to 0
      (glibmm (bugzilla.gnome.org))
   4. [Bug 572978] Glib::ustring allows comparison to 0
      (glibmm (bugzilla.gnome.org))
   5. [Bug 572978] Glib::ustring allows comparison to 0
      (glibmm (bugzilla.gnome.org))
   6. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   7. [Bug 573713] Method lookup fails when trying to	wrap the
      gstreamermm Gst::Object class (glibmm (bugzilla.gnome.org))


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

Message: 1
Date: Tue,  3 Mar 2009 09:32:32 +0000 (UTC)
From: "gtk+ (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 570943] Windows: GtkEntry can't input
	when	toggling visibility twice
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303093232 7D1F723F545 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=570943

  gtk+ | win32 | Ver: unspecified

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gtkmm-                      |gtk-win32-maint gnome bugs
                   |forge lists sourceforge net |
           Severity|critical                    |normal
          Component|general                     |win32
           Priority|High                        |Normal
            Product|gtkmm                       |gtk+
          QAContact|gtkmm-                      |gtk-bugs gtk org
                   |forge lists sourceforge net |
            Summary|GtkEntry can't input when   |Windows: GtkEntry can't
                   |toggling visibility twice   |input when toggling
                   |                            |visibility twice
            Version|2.4                         |unspecified




------- Comment #10 from Murray Cumming  2009-03-03 09:33 UTC -------
You have proved that there is a problem with GTK+ rather than with gktmm. Why
would you want to close the bug report. Reassigning to GTK+.

It does seem strange Armin can't reproduce this.


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



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

Message: 2
Date: Tue,  3 Mar 2009 11:04:50 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 572978] Glib::ustring allows comparison
	to 0
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303110450 A8BDD23F52F 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=572978

  glibmm | strings | Ver: unspecified




------- Comment #6 from Daniel Elstner  2009-03-03 11:05 UTC -------
(In reply to comment #5)
> So I guess that means there is not much we can do about this, right?

Well, we could remove the shortcut overloads for 'const char*' arguments and
rely on the implicit conversion from 'const char*' to Glib::ustring.

However, while this would work, I'm not sure it's actually worth it. Actually,
I don't think the problem you hit even qualifies as a bug. You could still pass
a nil pointer indirectly. It's just a quirk of the C++ language that it doesn't
have a context-independent literal for the nil pointer.

So, personally, I'd prefer to close this as either WONTFIX or NOTABUG. Any
objections?


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



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

Message: 3
Date: Tue,  3 Mar 2009 11:18:38 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 572978] Glib::ustring allows comparison
	to 0
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303111839 0083E23F52F 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=572978

  glibmm | strings | Ver: unspecified




------- Comment #7 from Armin Burgmeier  2009-03-03 11:19 UTC -------
Can we maybe add a g_assert or a g_return_val_if_fail to the comparison
operator if the const char* parameter is 0? There is already a warning from
g_utf8_collate in that case, but this would make it easier to find out where
the warning comes from. It would probably have saved me an hour.

Otherwise, I agree that it's not worth removing the const char* overload, also
considering that it's probably inefficient to creating a temporary ustring just
for comparison.


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



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

Message: 4
Date: Tue,  3 Mar 2009 11:46:56 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 572978] Glib::ustring allows comparison
	to 0
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303114656 5541023F536 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=572978

  glibmm | strings | Ver: unspecified




------- Comment #8 from Daniel Elstner  2009-03-03 11:47 UTC -------
Definitely not to operator==(), because that's an inline function living in the
header file. g_return_if_fail(), g_assert(), g_warning() and the like should
never be used in a header file, since the string literals passed to it would no
longer live in the library but pollute every single object file which makes use
of the inline function in any way.

It could be added to Glib::ustring::compare(const char* rhs), however. But
would that actually have helped? I like using g_return_if_fail(), but in this
case it seems a bit arbitrary to put it here but not anywhere else. Generally
we don't duplicate assertions of the underlying C functions, as a back trace in
gdb would immediately reveal the caller anyway.

Would you have been any faster to find the source of the problem if the
assertion had been in ustring::compare() instead of g_utf8_collate()?

I'm not totally opposed to the idea of adding a g_return_if_fail(), but I'm not
convinced yet that there is much of a point in doing so.


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



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

Message: 5
Date: Tue,  3 Mar 2009 12:21:41 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 572978] Glib::ustring allows comparison
	to 0
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303122141 A3F2723F52E 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=572978

  glibmm | strings | Ver: unspecified




------- Comment #9 from Armin Burgmeier  2009-03-03 12:22 UTC -------
(In reply to comment #8)
> Would you have been any faster to find the source of the problem if the
> assertion had been in ustring::compare() instead of g_utf8_collate()?

I basically ignored the warning from g_utf8_collate since I was looking for a
network problem, not for a string issue. Until I realized that I thought the
string variable which I compared to 0 was an integer.

It would have let me know that the problem is somewhere in the C++ part of the
code. It might have helped, but I'm not sure. Maybe not.

> I'm not totally opposed to the idea of adding a g_return_if_fail(), but I'm not
> convinced yet that there is much of a point in doing so.

Yeah, maybe let's wait. We can still add it later when others hit the same
problem (and believe it helped).


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



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

Message: 6
Date: Tue,  3 Mar 2009 15:51:10 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090303155110 9EB1A23EF8E 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #5 from Stas Sergeev  2009-03-03 15:51 UTC -------
I should probably clarify why I implemented
the string-based lookup, as it seems you are
getting me wrong all the time.
Glade saves the handler info in the form of:
<signal name="clicked" handler="on_button_clicked" object="NULL"/>
When you read this xml, you have only those
names in a string form. So, you need a mapping
to get the handler by its name. That's what
my patch currently does. It seems you are
expacting something else - what exactly then?
Of course, you can't make it more "automatic"
or compile-time type-safe, simply because the
xml is being loaded at runtime. The runtime
type-safety is, however, guaranteed.
So could you please explain what you see wrong
with my patch or approach?


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



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

Message: 7
Date: Wed,  4 Mar 2009 05:29:58 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573713] Method lookup fails when trying
	to	wrap the gstreamermm Gst::Object class
To: gtkmm-forge lists sourceforge net
Message-ID: <20090304052958 C248D23F520 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=573713

  glibmm | build | Ver: unspecified

Jos? Alburquerque changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG




------- Comment #2 from Jos? Alburquerque  2009-03-04 05:30 UTC -------
I just realized that GstObject only has four signals and two virtual methods
and they can be handwritten.

Closing.


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



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

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

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

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


End of Gtkmm-forge Digest, Vol 34, Issue 2
******************************************


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]