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 582439] [PATCH] Fix build on maemo platform
(gnomemm (bugzilla.gnome.org))
2. [Bug 582439] [PATCH] Fix build on maemo platform
(gnomemm (bugzilla.gnome.org))
3. [Bug 582439] [PATCH] Fix build on maemo platform
(gnomemm (bugzilla.gnome.org))
4. [Bug 582439] [PATCH] Fix build on maemo platform
(gnomemm (bugzilla.gnome.org))
5. [Bug 495762] need get_pointer for RefPtr<>
(glibmm (bugzilla.gnome.org))
6. [Bug 583396] New: Missing Gdk::Bitmap::create() to create an
empty bitmap (gtkmm (bugzilla.gnome.org))
7. [Bug 583399] New: gtkmm3: add a WeakPtr?
(glibmm (bugzilla.gnome.org))
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 May 2009 08:52:05 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 582439] [PATCH] Fix build on maemo
platform
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=582439
gnomemm | gstreamermm | Ver: unspecified
------- Comment #22 from Murray Cumming 2009-05-20 08:52 UTC -------
> http://git.gnome.org/cgit/gstreamermm/tree/examples/optiongroup/main.cc does
> not follow the no space convention. Should I use it anyway, fix the whole file
> or stick with the existing style?
It mostly does. Feel free to fix the few lines where it doesn't, in a separate
commit, 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=582439.
------------------------------
Message: 2
Date: Wed, 20 May 2009 10:54:52 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 582439] [PATCH] Fix build on maemo
platform
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=582439
gnomemm | gstreamermm | Ver: unspecified
Johannes Schmid changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #134932|0 |1
is obsolete| |
------- Comment #23 from Johannes Schmid 2009-05-20 10:54 UTC -------
Created an attachment (id=135010)
--> (http://bugzilla.gnome.org/attachment.cgi?id=135010&action=view)
Updated patch
OK, this took some more iteration that I expected...
Anyway, with this patch I could successfully build gstreamermm on maemo (and
could also build the .deb).
There are some coding style inconsitances left:
- Some of the code uses "if (" and "method(", some used "if(" and "method(". I
sticked to what the rest of the file does for now.
- I will add another patch that changes everything to "if(" "and method(".
--
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=582439.
------------------------------
Message: 3
Date: Wed, 20 May 2009 11:00:48 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 582439] [PATCH] Fix build on maemo
platform
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=582439
gnomemm | gstreamermm | Ver: unspecified
------- Comment #24 from Murray Cumming 2009-05-20 11:00 UTC -------
+ try
+ {
+ pipeline->add(element_source)->add(element_filter)->add(element_sink);
+ }
+ catch (std::runtime_error& ex)
+ {
I don't understand how that could build without exceptions.
Also, exceptions should always be caught as _const_ references.
Otherwise, please commit. Thanks.
--
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=582439.
------------------------------
Message: 4
Date: Wed, 20 May 2009 17:24:11 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 582439] [PATCH] Fix build on maemo
platform
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=582439
gnomemm | gstreamermm | Ver: unspecified
------- Comment #25 from Jos? Alburquerque 2009-05-20 17:24 UTC -------
Johannes, I corrected the coding styles I could find before you submitted a
patch (I hope you don't mind). If you find any others, please feel free to
correct those also. Thanks.
--
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=582439.
------------------------------
Message: 5
Date: Thu, 21 May 2009 00:39:29 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 495762] need get_pointer for RefPtr<>
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=495762
glibmm | general | Ver: 2.14.x
Daniel Elstner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
OS/Version|Linux |All
------- Comment #20 from Daniel Elstner 2009-05-21 00:39 UTC -------
(In reply to comment #10)
> That's fairly unusual (though not totally unlikely). You'd usually connect the
> signal in a member method, where you'd have access to "this".
Usual, but by no means mandatory. Nor is it good style to introduce yet
another indirection if none is necessary. Case in point:
http://github.com/danielkitta/kcio/blob/6b0b5c49c2e9bca56b63d23efc2c2f0551c98b81/kc-keyboard/inputwindow.cc#L186
This is not something I just put in there specifically for this bug comment;
see the date of the commit.
1) There is nothing wrong or even unusual about creating a slot to a method of
another object. In fact, it is good style to avoid depending on state when you
don't have to. In my experience, this sort of cross-object connection is
actually quite common, and very often it turns out that the only reason to go
through *this is just some stupid housekeeping need.
2) It is a bit odd that we go to great lengths to use STL containers wherever
feasible, but then prevent the generic STL algorithms from being used on a
vector of RefPtr<> elements. Heck, the algorithms are actually the important
part -- they are the reason to provide STL-style interfaces to your own
container types!
3) The feared misuse of operator*() is in reality a non-issue. Consider:
void do_foo(Object& obj);
// ...
Glib::RefPtr<Object> bar = something();
do_foo(*bar);
If this is so bad; indeed bad enough to make us reduce the usability of our API
to prevent people from doing it, then what about this?
void do_foo(std::string& str);
// ...
std::string bar = "something";
do_foo(bar);
Isn't this in fact even worse, given that you don't even need to put a "*" in
there?
Now, the horror of horrors:
Glib::RefPtr<Object> something();
// ...
Object& bar = *something();
Evil? Could be. But very often, it's actually not a problem at all. It is
about as evil as
Widget* widget = bin->get_child();
.
Which is to say, it is slightly evil but pretty benign in the grand scheme of
things. Also, in those cases where it actually is an error, the failure mode
will be of the tame kind. Even if it doesn't crash right away, Valgrind will
easily detect the invalid memory access.
When it comes to messing up RefPtr<>, I'd be far more worried about unmatched
ref and unref calls. Dereferencing a RefPtr<> won't cause this sort of
problem. In fact, even putting it back into another RefPtr<> is not a problem
since the reference count is a member of the object itself. Seriously,
exposing reference() and unreference() as public API is much more dangerous and
nasty than RefPtr<>::operator*() could possibly be.
On a side note; we really should have a RefPtr<> ctor that takes a reference in
gtkmm 3.
--
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=495762.
------------------------------
Message: 6
Date: Thu, 21 May 2009 01:12:52 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 583396] New: Missing
Gdk::Bitmap::create() to create an empty bitmap
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=583396
gtkmm | gdkmm | Ver: unspecified
Summary: Missing Gdk::Bitmap::create() to create an empty bitmap
Product: gtkmm
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Keywords: API
Severity: normal
Priority: Normal
Component: gdkmm
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
GNOME version: Unspecified
GNOME milestone: Unspecified
In a project of mine, I'm forced to do the following:
// There is no Gdk::Bitmap::create() to create an empty bitmap in gdkmm.
const Glib::RefPtr<Gdk::Bitmap> bitmap = Glib::RefPtr<Gdk::Bitmap>
::cast_dynamic(Glib::wrap(gdk_pixmap_new(window->gobj(), width, height, 1),
false));
I think we should add Gdk::Bitmap::create(drawable, width, height) and probably
also the corresponding constructor to gdkmm. Implementation as above.
--
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=583396.
------------------------------
Message: 7
Date: Thu, 21 May 2009 02:42:29 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<[email protected]>
Subject: [gtkmm bugzilla] [Bug 583399] New: gtkmm3: add a WeakPtr?
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=583399
glibmm | general | Ver: unspecified
Summary: gtkmm3: add a WeakPtr?
Product: glibmm
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: general
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
GNOME version: Unspecified
GNOME milestone: Unspecified
glib has a concept of a weak pointer. boost also has a weak_ptr associated
with shared_ptr. It would be nice if glibmm provided a WeakPtr to complement
RefPtr.
--
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=583399.
------------------------------
------------------------------------------------------------------------------
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 asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
------------------------------
_______________________________________________
Gtkmm-forge mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
End of Gtkmm-forge Digest, Vol 36, Issue 12
*******************************************
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
