GNOME.org
 

Gtkmm-forge Digest, Vol 30, Issue 16

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 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)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
	gstreamerbasemm
To: gtkmm-forge lists sourceforge net
Message-ID: <20081116205926 9640F23F512 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=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)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
	gstreamerbasemm
To: gtkmm-forge lists sourceforge net
Message-ID: <20081117050054 33E0023EFEF 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=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)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 560601] gstreamermm uses symbols of
	gstreamerbasemm
To: gtkmm-forge lists sourceforge net
Message-ID: <20081117091557 5A7D223F513 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=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)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 561228] New: Wrong documentation
	generated	for enum
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-561228-5595 http bugzilla 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=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: gtkmm-forge lists sourceforge net
        ReportedBy: agliv123 gmail com
         QAContact: gtkmm-forge lists sourceforge net
     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)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 561227] New: Wrong documentation
	generated	for enum
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-561227-5595 http bugzilla 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=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: gtkmm-forge lists sourceforge net
        ReportedBy: agliv123 gmail com
         QAContact: gtkmm-forge lists sourceforge net
     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
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 30, Issue 16
*******************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]