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 560601] gstreamermm uses symbols of gstreamerbasemm
(gnomemm (bugzilla.gnome.org))
2. [Bug 560601] gstreamermm uses symbols of gstreamerbasemm
(gnomemm (bugzilla.gnome.org))
3. [Bug 560601] gstreamermm uses symbols of gstreamerbasemm
(gnomemm (bugzilla.gnome.org))
4. [Bug 561228] New: Wrong documentation generated for enum
(glibmm (bugzilla.gnome.org))
5. [Bug 561227] New: Wrong documentation generated for enum
(glibmm (bugzilla.gnome.org))
----------------------------------------------------------------------
Message: 1
Date: Sun, 16 Nov 2008 20:59:26 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
gstreamerbasemm
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=560601
gnomemm | gstreamermm | Ver: unspecified
------- Comment #17 from Jos? Alburquerque 2008-11-16 20:59 UTC -------
(In reply to comment #16)
> Ok, that makes sense then IMHO. One question though, how do you want to wrap
> the plugins/elements? I mean, their instance/class struct sizes are not
> guaranteed to stay the same as they're not part of the ABI.
Do you mean that their properties and signals are not guaranteed to remain the
same (ABI stable) in major releases? If so, then the plugin generation would
have to be adjusted so that ABI is not affected when gstreamermm becomes stable
(this would be something to think about). The C++ classes will only wrap the
properties and signals so if these do not change, the C++ class, I think,
should not loose ABI.
> You could only
> create hand-written wrappers that only access the elements via generic
> interfaces like GObject properties, gstreamer interfaces, etc. Also
> distributors might want to choose to not include some elements, it's not
> guaranteed that everybody has audioresample for example :)
By using introspection I think it is possible to have the generating process
generate C++ wrapper classes during the build process if things work well this
way (depending on the ABI issues you mentioned). If so, the build process can
be used to determine which ones should be generated and which ones should not.
It's a bit tricky to explain, but if you want some idea of how this might be
done, you can look at what has been done so far (the last few ChangeLog
entries). Also, keep in mind that gstreamermm is still unstable and these
things can be ironed out before it becomes stable. If plugin generation is not
possible, it will probably be abandoned.
>
> Then for gstreamer-base-0.10, you need it for Gst::BaseSrc and friends so this
> should still be linked in, IIRC you're wrapping basesrc at least.
Then it was right the first time. :-) It's a bit difficult to keep track of
which lib to include, etc. :-)
>
> Whatever, for the design you're following now, it would still mean that
> gstreamermm and gstreamerbasemm are using symbols from each other and depend
> on
> each other, right? And that this is, because you don't want the application to
> call a GstBase initialization function and because you can't let the source
> generation put everything into one library and different namespaces, right? In
> that case I guess this bug can't be properly solved ;)
>
Right. The way I thought of fixing this is to require that GstBase::init() be
called if some of the gstreamerbasemm API is used, but then not to require that
Gst::init() be called because GstBase::init() would take care of this (that way
only one initialization line would be required for developers as before).
Gst::init() would not call GstBase::wrap_init() because GstBase:init() would do
that, so the internal interdependency can be eliminated this way. Gst::init()
would still be necessary if GstBase::init() is not used.
The added benefit of this fix is that if a program only uses core stuff (and
nothing in gstreamerbasemm), they could simply use Gst::init() and their
linking and execution would probably be faster.
At first, I wanted to leave things as they are (my research tends to show that
there is no major difference in using the --as-needed flag), but since this is
the second report of this nature (as I already mentioned, a bug[1] like this
one was already reported), I think I'll fix it this way so that such confusion
can be avoided in the future from distributors that by default use the
"--as-needed" flag and the added benefit above can be provided to programs that
only use gstreamermm API.
[1] http://bugzilla.gnome.org/show_bug.cgi?id=556570
--
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=560601.
------------------------------
Message: 2
Date: Mon, 17 Nov 2008 05:00:53 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
gstreamerbasemm
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=560601
gnomemm | gstreamermm | Ver: unspecified
------- Comment #18 from Sebastian Dr?ge 2008-11-17 05:00 UTC -------
(In reply to comment #17)
> (In reply to comment #16)
> > Ok, that makes sense then IMHO. One question though, how do you want to wrap
> > the plugins/elements? I mean, their instance/class struct sizes are not
> > guaranteed to stay the same as they're not part of the ABI.
>
> Do you mean that their properties and signals are not guaranteed to remain the
> same (ABI stable) in major releases? If so, then the plugin generation would
> have to be adjusted so that ABI is not affected when gstreamermm becomes
> stable
> (this would be something to think about). The C++ classes will only wrap the
> properties and signals so if these do not change, the C++ class, I think,
> should not loose ABI.
Properties and signals must stay the same, they're part of the guaranteed API.
What can change though is the content and size of the instance and class
structs of the elements. If you don't need those in your wrappers everything is
fine ;)
This of course only applies to the elements in gstreamer core, base, good and
ugly.
> > You could only
> > create hand-written wrappers that only access the elements via generic
> > interfaces like GObject properties, gstreamer interfaces, etc. Also
> > distributors might want to choose to not include some elements, it's not
> > guaranteed that everybody has audioresample for example :)
>
> By using introspection I think it is possible to have the generating process
> generate C++ wrapper classes during the build process if things work well this
> way (depending on the ABI issues you mentioned). If so, the build process can
> be used to determine which ones should be generated and which ones should
> not.
> It's a bit tricky to explain, but if you want some idea of how this might be
> done, you can look at what has been done so far (the last few ChangeLog
> entries). Also, keep in mind that gstreamermm is still unstable and these
> things can be ironed out before it becomes stable. If plugin generation is
> not
> possible, it will probably be abandoned.
So essentially your wrapper for elements simply contains a pointer to an
instance of the element and then set_foo and get_foo methods for all properties
that internally call g_object_set? Sounds good :)
> >
> > Whatever, for the design you're following now, it would still mean that
> > gstreamermm and gstreamerbasemm are using symbols from each other and
> > depend on
> > each other, right? And that this is, because you don't want the application
> > to
> > call a GstBase initialization function and because you can't let the source
> > generation put everything into one library and different namespaces, right?
> > In
> > that case I guess this bug can't be properly solved ;)
> >
>
> Right. The way I thought of fixing this is to require that GstBase::init() be
> called if some of the gstreamerbasemm API is used, but then not to require
> that
> Gst::init() be called because GstBase::init() would take care of this (that
> way
> only one initialization line would be required for developers as before).
> Gst::init() would not call GstBase::wrap_init() because GstBase:init() would
> do
> that, so the internal interdependency can be eliminated this way. Gst::init()
> would still be necessary if GstBase::init() is not used.
>
> The added benefit of this fix is that if a program only uses core stuff (and
> nothing in gstreamerbasemm), they could simply use Gst::init() and their
> linking and execution would probably be faster.
Sounds good to me :)
--
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=560601.
------------------------------
Message: 3
Date: Mon, 17 Nov 2008 09:15:57 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
<[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
gstreamerbasemm
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=560601
gnomemm | gstreamermm | Ver: unspecified
------- Comment #19 from Murray Cumming 2008-11-17 09:15 UTC -------
> So essentially your wrapper for elements simply contains a pointer to an
> instance of the element and then set_foo and get_foo methods for all
> properties
> that internally call g_object_set? Sounds good :)
We might be deriving new GTypes from them. I guess that would be a problem. We
can maybe avoid that, though it would make it difficult to deal with signals
and vfuncs.
--
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=560601.
------------------------------
Message: 4
Date: Mon, 17 Nov 2008 15:57:57 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 561228] New: Wrong documentation
generated for enum
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=561228
glibmm | general | Ver: unspecified
Summary: Wrong documentation generated for enum
Product: glibmm
Version: unspecified
Platform: Other
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
QAContact: [EMAIL PROTECTED]
GNOME version: Unspecified
GNOME milestone: Unspecified
Please describe the problem:
typedef enum AccountDescriptor
{
///NoDescriptor
NoDescriptor///1
///PrimaryAccount
,PrimaryAccount///2
///SecondaryAccount
,SecondaryAccount///3
}AccountDescriptor;
Steps to reproduce:
1. Please look at the comments created by Doxygen for the code provided
Actual results:
Enumerator:
NoDescriptor NoDescriptor.
1 PrimaryAccount
PrimaryAccount SecondaryAccount.
2
SecondaryAccount 3
Expected results:
Enumerator:
NoDescriptor NoDescriptor.
PrimaryAccount PrimaryAccount. 2
SecondaryAccount SecondaryAccount. 3
Does this happen every time?
Yes
Other information:
--
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=561228.
------------------------------
Message: 5
Date: Mon, 17 Nov 2008 15:57:57 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
<[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 561227] New: Wrong documentation
generated for enum
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=561227
glibmm | general | Ver: unspecified
Summary: Wrong documentation generated for enum
Product: glibmm
Version: unspecified
Platform: Other
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
QAContact: [EMAIL PROTECTED]
GNOME version: Unspecified
GNOME milestone: Unspecified
Please describe the problem:
typedef enum AccountDescriptor
{
///NoDescriptor
NoDescriptor///1
///PrimaryAccount
,PrimaryAccount///2
///SecondaryAccount
,SecondaryAccount///3
}AccountDescriptor;
Steps to reproduce:
1. Please look at the comments created by Doxygen for the code provided
Actual results:
Enumerator:
NoDescriptor NoDescriptor.
1 PrimaryAccount
PrimaryAccount SecondaryAccount.
2
SecondaryAccount 3
Expected results:
Enumerator:
NoDescriptor NoDescriptor.
PrimaryAccount PrimaryAccount. 2
SecondaryAccount SecondaryAccount. 3
Does this happen every time?
Yes
Other information:
--
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=561227.
------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------
_______________________________________________
Gtkmm-forge mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
End of Gtkmm-forge Digest, Vol 30, Issue 16
*******************************************
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
