Menu
▾
▴
gstreamer-gstmm — GStreamer gstmm C++ bindings
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(5) |
Mar
(53) |
Apr
(6) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(11) |
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(8) |
May
(9) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <MHL...@t-...> - 2003-03-18 16:20:56
|
Hi! You should notice that I made some rather big commits over the past days. Some parts of the API should be fairly complete now: Gst::Format, Gst::QueryType, Gst::Props*, Gst::Caps, Gst::Index*, Gst::PluginFeature. pad and element still don't compile, but that's a matter of time. Apropos time: I won't be working on gstmm until the weekend. By the way, after a fresh checkout, my ChangeLog commit problems have gone. Cheers, Martin |
|
From: Christian M. <chr...@un...> - 2003-03-13 18:59:21
|
On Thu, 13 Mar 2003 18:03:07 +0100 MHL...@t-... (Martin Schulze) wrote: > We are to use _CLASS_GOBJECT if we force the usage of Glib::RefPtr<> > on the user. I stayed with _CLASS_GTKOBJECT for now because I want > to try out, whether this is working, too. We cannot say until we have > something that compiles. Ok, that's fine with me. I just couldn't remember if there's any difference ;-) Greetings, Christian |
|
From: <MHL...@t-...> - 2003-03-13 18:38:01
|
Am 2003.03.12 23:34 schrieb(en) Christian Meyer: > Hi! > > Is there any reason why we're using _CLASS_GTKOBJECT in some classes? I > can't remember why we're using it instead of _CLASS_GOBJECT. > Martin, Murray? We are to use _CLASS_GOBJECT if we force the usage of Glib::RefPtr<> on the user. I stayed with _CLASS_GTKOBJECT for now because I want to try out, whether this is working, too. We cannot say until we have something that compiles. Regards, Martin |
|
From: Christian M. <chr...@gn...> - 2003-03-13 17:33:58
|
On Thu, 13 Mar 2003 17:53:38 +0100 MHL...@t-... (Martin Schulze) wrote: > Unfortunately this doesn't change a thing. I still have to do > > cvs [...] commit ChangeLog > > afterwards to get ChangeLog committed. That's odd; I recently did: cvs -z3 -d:ext:chr...@cv...:/cvsroot/gstreamer commit -m "..." and it worked. Greetings, Christian |
|
From: <MHL...@t-...> - 2003-03-13 17:00:55
|
Am 2003.03.12 21:49 schrieb(en) Christian Meyer: > Hi! > > I just fixed a typo in pad.hg. I also hacked configure.in to check for > gstreamer-0.6.pc which is included in debian (other dists seem to have > gstreamer.pc). > gstmm doesn't compile yet: > > No conversion from GstCaps to Caps defined (line: , parameter name: > gobj()->filter) m4 failed with exit code 1. Aborting... > > I will check that now, though I can't promise any fix. Martin? This is fixed now. gtkmmproc still doesn't pass everything because of the outdated gst_methods.defs. We have to regenerate this file. I'm working on it. Regards, Martin |
|
From: <MHL...@t-...> - 2003-03-13 16:36:13
|
Hi!
Murray, could you please add a verion of h2defs.py that is working
with gtkmmproc to gtkmm2 cvs module? I tried to generate an
up-to-date gst_methods.defs with the current CVS version of
h2defs.py and gtkmmproc goes haywire with the new file:
/usr/local/lib/gtkmm-2.0/proc/gtkmmproc -I ../../tools/m4 --defs .
propsentry . ./../gstmm
Broken lisp definition for function __volatile__.
unknown token (c-name "__volatile__")
unknown token (return-type "__asm__")
unknown token (parameters '("-"1:-lwarx" "%0") '("%3-#-atomic_add\n-add"
"%0") '("%0\n"" "PPC405_ERR77(0") ))
[and so on ....]
Also I don't find the "tools/generate_defs utility" that is mentioned in
"using_gtkmmproc.txt" for the creation of [...]_signals.defs.
Regards,
Martin
|
|
From: <MHL...@t-...> - 2003-03-13 16:04:10
|
Hi! Does anybody have an idea why I always have to commit ChangeLog seperately? When I type cvs [...] commit ChangeLog [some_other_file] [some_other_file] is committed, but not ChangeLog. I have to type cvs [...] commit ChangeLog afterwards to get my ChangeLog entry into CVS. Regards, Martin |
|
From: Christian M. <chr...@gn...> - 2003-03-12 22:33:33
|
Hi! Is there any reason why we're using _CLASS_GTKOBJECT in some classes? I can't remember why we're using it instead of _CLASS_GOBJECT. Martin, Murray? Greetings, Christian |
|
From: Christian M. <chr...@gn...> - 2003-03-12 20:48:27
|
Hi! I just fixed a typo in pad.hg. I also hacked configure.in to check for gstreamer-0.6.pc which is included in debian (other dists seem to have gstreamer.pc). gstmm doesn't compile yet: No conversion from GstCaps to Caps defined (line: , parameter name: gobj()->filter) m4 failed with exit code 1. Aborting... I will check that now, though I can't promise any fix. Martin? Greetings, Christian |
|
From: Christian M. <chr...@gn...> - 2003-03-12 19:31:15
|
Hi! On Wed, 12 Mar 2003 12:01:42 +0100 MHL...@t-... (Martin Schulze) wrote: > I hesitate again about the transition to use RefPtr<> for Gst::Object. > From what Murray said, I first thought this was consensus but I > didn't > here clear statements from Murray and Christian to support this. > > I added some files I wrote over the past two days. They use > _CLASS_BOXEDTYPE[_STATIC]. They almost compile but there > are problems with the GTYPE system and a gstreamer c structure > is hidden in the source files which doesn't work with > _CLASS_BOXEDTYPE_STATIC :-( I've updated my local repository and will have a look at the code. It'll take some time. I'm going to check bugzilla and see what Peter's submitted so far. Greetings, Christian |
|
From: <MHL...@t-...> - 2003-03-12 11:01:59
|
Am 2003.03.12 07:54 schrieb(en) "N. Lundblad, Peter": > > Message: 2 > > Date: Tue, 11 Mar 2003 09:43:34 +0100 > > From: Christian Meyer <chr...@gn...> > > To: gst...@li... > > Subject: Re: [Gstreamer-gstmm] Building gstmm > > Organization: GNOME Deutschland > > > > On Tue, 11 Mar 2003 09:38:47 +0100 > > "N. Lundblad, Peter" <pn...@so...> wrote: > > > > > OK, now I am back at my mail again... Sorry for the delay. I'll send > > > you a patch in the evening. It is incomplete, since it > > takes some time > > > for me familiarizing me with how it all works together... > > > > Please send it to the list and not just to Martin. > > It is in bugzilla, see bug 108132. Please note that it is very incomplete. I > will continue, but it will be easier if someone checks the parts that seem > right into CVS. Also, I will include ChangeLog entries in future patches, > but it seems like in this stage, it isn't necessary to do detailed > documentation of all little fixes. Comments? I hesitate again about the transition to use RefPtr<> for Gst::Object. From what Murray said, I first thought this was consensus but I didn't here clear statements from Murray and Christian to support this. I added some files I wrote over the past two days. They use _CLASS_BOXEDTYPE[_STATIC]. They almost compile but there are problems with the GTYPE system and a gstreamer c structure is hidden in the source files which doesn't work with _CLASS_BOXEDTYPE_STATIC :-( Tomorrow I can do some more work. It would be fine if Christian could review and add Peters new files from the bug report. Regards, Martin |
|
From: N. L. P. <pn...@so...> - 2003-03-12 06:51:56
|
> Message: 2 > Date: Tue, 11 Mar 2003 09:43:34 +0100 > From: Christian Meyer <chr...@gn...> > To: gst...@li... > Subject: Re: [Gstreamer-gstmm] Building gstmm > Organization: GNOME Deutschland > > On Tue, 11 Mar 2003 09:38:47 +0100 > "N. Lundblad, Peter" <pn...@so...> wrote: > > > OK, now I am back at my mail again... Sorry for the delay. I'll send > > you a patch in the evening. It is incomplete, since it > takes some time > > for me familiarizing me with how it all works together... > > Please send it to the list and not just to Martin. It is in bugzilla, see bug 108132. Please note that it is very incomplete. I will continue, but it will be easier if someone checks the parts that seem right into CVS. Also, I will include ChangeLog entries in future patches, but it seems like in this stage, it isn't necessary to do detailed documentation of all little fixes. Comments? Regards, //Peter |
|
From: <MHL...@t-...> - 2003-03-11 21:59:24
|
Sorry, please ignore this. I tricked myself. m4 seems to be too tolerant for me: it simply doesn't produce an error when I add a line like "??? error ???". And also ignores type errors like "_CONSERVION" ... Martin. Am 11.03.2003 18:41 schrieb(en) Martin Schulze: > Hi! > > I have a problem with gtkmmproc in gstmm: It doesn't read > our convert.m4 file in the tools/m4 directory. When running > "make" in gst/src the following command appears: > > /usr/local/lib/gtkmm-2.0/proc/gtkmmproc -I ../../tools/m4 --defs . pad > ./../gstmm > > However, tools/m4/convert.m4 is not read. The conversion > macros defined there are not available and I can place a fake > line in convert.m4, e.g. "??? error ???", without anything happening. > > Do others have the same problem? Am I missing something? > My gtkmmproc version is from the gtkmm2 cvs module. > > Regards, > > Martin > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! Get > cracking and register here for some mind boggling fun and the chance of > winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Gstreamer-gstmm mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-gstmm |
|
From: <MHL...@t-...> - 2003-03-11 17:42:24
|
Hi! I have a problem with gtkmmproc in gstmm: It doesn't read our convert.m4 file in the tools/m4 directory. When running "make" in gst/src the following command appears: /usr/local/lib/gtkmm-2.0/proc/gtkmmproc -I ../../tools/m4 --defs . pad ./../gstmm However, tools/m4/convert.m4 is not read. The conversion macros defined there are not available and I can place a fake line in convert.m4, e.g. "??? error ???", without anything happening. Do others have the same problem? Am I missing something? My gtkmmproc version is from the gtkmm2 cvs module. Regards, Martin |
|
From: Christian M. <chr...@gn...> - 2003-03-11 08:43:06
|
On Tue, 11 Mar 2003 09:38:47 +0100 "N. Lundblad, Peter" <pn...@so...> wrote: > OK, now I am back at my mail again... Sorry for the delay. I'll send > you a patch in the evening. It is incomplete, since it takes some time > for me familiarizing me with how it all works together... Please send it to the list and not just to Martin. Thanks in advance. Greetings, Christian |
|
From: N. L. P. <pn...@so...> - 2003-03-11 08:35:40
|
> -----Original Message----- > From: MHL...@t-... [mailto:MHL...@t-...] > > Since I know that you are working on making gstmm compilable, > I'd like you to send a patch with your current results to the list. > It is perfectly okay if the patch is still incomplete but I want to > avoid double work. OK, now I am back at my mail again... Sorry for the delay. I'll send you a patch in the evening. It is incomplete, since it takes some time for me familiarizing me with how it all works together... Regards, //Peter |
|
From: Murray.Cumming@Comneon.com - 2003-03-10 08:01:33
|
> > > On a further side note, using Glib::RefPtr<> for gtkmm objects > > > requires operator*(). Otherwise you can't pass the object > to gtkmm > > > functions. > > > > It requires more than that and we won't add operator*() until it > > actually can/should be used for something. > > > > > I've been talking about that with Danielk quite some time > ago. IIRC > > > think he also proposed that but Murray didn't like it. > Seems like it > > > leads to unwanted results. > > > > There's an open bug about it - see the gtkmm bug page. > > Somehow, I can't find this bug report. Can you help me with a link? See the glibmm 2.4 bugs. There are 2 there that you will find interesting. |
|
From: Christian M. <chr...@gn...> - 2003-03-08 17:34:50
|
On Sat, 8 Mar 2003 18:18:54 +0100 MHL...@t-... (Martin Schulze) wrote: > Hi Peter! > > I'd like to look the existing gstmm code over tomorrow. > However I won't be able to run ICQ on the machine I will be > working on, so we won't be able to communicate very well. I won't be able to be online tomorrow because I have to learn for my next exam. Peter, FYI: my ICQ is 72107443 > Since I know that you are working on making gstmm compilable, > I'd like you to send a patch with your current results to the list. > It is perfectly okay if the patch is still incomplete but I want to > avoid double work. You could also send a short note about > what files I shouldn't touch because you want to work on them > yourself... and you should add comments to your code (we should also do that for the exisiting code. I really hate code without any comments.) Greetings, Christian |
|
From: <MHL...@t-...> - 2003-03-08 17:19:13
|
Hi Peter! I'd like to look the existing gstmm code over tomorrow. However I won't be able to run ICQ on the machine I will be working on, so we won't be able to communicate very well. Since I know that you are working on making gstmm compilable, I'd like you to send a patch with your current results to the list. It is perfectly okay if the patch is still incomplete but I want to avoid double work. You could also send a short note about what files I shouldn't touch because you want to work on them yourself... Regards, Martin Am 2003.03.06 07:41 schrieb(en) "N. Lundblad, Peter": > > I will try to get the whole thing to build before I tart to make changes > (will be a separate patch), but I just want to hear your opinions on this > topic. > > Best Regards, > //Peter N. Lundblad > |
|
From: Christian M. <chr...@un...> - 2003-03-08 13:28:14
|
Hi! Sorry for replying so late. Surprisingly, I was somehow unsubscribed from the mailinglist. Don't ask me how that could happen. I'll try to reply all important mails now. ----------------------------------------------------------------------- >> If I actually get it to build, what should I do about the patch? >> Should I put the "big patch" somewhere? >If you feel comfortable with your work, it would be best if you got cvs >write access. Christian, what are the necessary steps? I don't >remember who to contact for that. I have to ask Christian Schaller to set up a CVS account. Unfortunately, he's on holiday at the moment. >Christian, >do you know who to ask to add a "gstmm" component in gstreamer's >bugzilla account? I don't know who's in charge of adding a keyword in Bugzilla. Maybe it's Luis; I'm going to check that today. ----------------------------------------------------------------------- N. Lundblad Peter wrote: OK. I am working through the comp8le errors, and I am getting element.cc to build now. As an aside, the most interresting line was } /* namespace Element_Helpers which took some time to spot. (Note the missing */) Gave some interresting errors later... a bug tracking system yet. I also like the C/C++ compiler, when you miss a single token it outputs millions of errors. N. Lundblad Peter wrote: Also, I noticed that many wrapped classes use _CLASS_GTKOBJECT(...) so they will be represented by raw pointers in many cases? On the other hand, Element::get_element_factory() returns Glib::RefPtr<Elementfactory>, so I modified the ElementFactory class so it uses _CLASS_GOBJECT instead. Shouldn't we change, among others, Element to use the same? Then our wrapped gst_element_factory_make (and others) could sink the object before returning a GLib::RefPtr<Element>. I first had (and still have!) many problems understanding what gtkmm really does. I again have to study it for a while because I haven't actively been using it for about 3 months now. We're using _CLASS_GTKOBJECT() because there was no _CLASS_GSTOBJECT() (and IIRC there still isn't one). If _CLASS_GOBJECT really works we should use it. I haven't tried it, but if it works for you and if Murray thinks that it's ok, I don't see any problems there. Maybe we should create a _CLASS_GSTOBJECT() macro which does the same as GOBJECT() plus some additional stuff which is needed for gstreamer. I'm not sure though! ----------------------------------------------------------------------- Martin wrote: This is a difficult issue. There was quite some argument between Murray, the maintainer of gtkmm, and myself about this. My point of view used to be that as opposed to gtk+, gstreamer has quite a clean reference counting system that allows for more flexibility in the language bindings: Wim has fixed our reported issues so the reference counting stuff should be fixed now. We'll certainly run into more problems, if so we can still file a bug report. The gstreamer guys want to fix such inconsitencies ASAP. Martin wrote: It is still not decided which approach ( a) + b) + c) or only c) ) we should choose. Christian, who is our maintainer, had quite some work to understand our different points (it took me some time to work them out, too :) ) and therefore doesn't seem to have come to his own opinion, yet. Probably we should sort this out before doing a lot of extra work in the end... It was really hard for me to understand the different ways to create and destroy objects in gtkmm/gstmm. Unfortunately, glib/gtk+ has many inconsistencies so that there's no real sane solution possible in gtkmm (Murray, correct me if I'm wrong. I only know little about the technical stuff in gtk+/gtkmm). If it's possible for us to create a better/nicer approach in gstmm we should make that reality. ------------------------------------------------------------------------ Murray wrote: I supect that the lifetime code in gst is not as clear as you hope. I suspect that it only works for some specific techniques as used by the gstreamer C code. This doubt was reinforced when the gst developers were not able to explain how gst lifetimes work. Murray, as far as I'm informed, Wim has solved all problems which we have file to bugzilla. If we'll ran into new ones, we should again file bugreports. That's the only way to improve gstreamer and make life easier for us and others. I concluded that we can't decide what's best so we should choose something simple and see if it works. That's fine. I think that's the best solution for now. - If it doesn't work then we can try again and/or ask for improvements in gst. ACK! - If it does work then we can try the other stuff too. That's really the way to go for now. So, quite arbitrarily, I suggested using Glib::RefPtr<> almost everywhere. I did that in a couple of classes hoping that Christian would understand how to do the same for other classes. I'm sorry that this isn't all in the archive. Christian seems to prefer IRC. I think that I do understand Glib::RefPtr<> now. But, I'll still have to look at some examples to get used to it (I know how smartpointers work, Josuttis' book is great!) The reason why I wasn't replying to all the mails is that I was accidently unsubscribed from the mailinglist; sorry :( ----------------------------------------------------------------------- Martin wrote: If you intend to use this concept for unmanaged objects, gtkmm containers would have to reference() and unreference() unmanaged objects just like Glib::RefPtr<> does. I remember a recent gtkmm bug report on that topic. I will have a look at it. Who knows, in the end this might also be the way to go in gstmm. I can't follow you there... On a further side note, using Glib::RefPtr<> for gtkmm objects requires operator*(). Otherwise you can't pass the object to gtkmm functions. I've been talking about that with Danielk quite some time ago. IIRC think he also proposed that but Murray didn't like it. Seems like it leads to unwanted results. Christian has a flat rate ... :) (monthly fee for unlimited time in the internet) Yeah, I have. But I'm also doing other things in my spare time *g* So, it seems like we have to decide where we'll go concerning Glib::RefPtr<>. I won't be against Murray's or Martin's decision. It just needs dicussion :-) Greetings, Christian P.S. I hope that I don't have missed important points in all the emails. |
|
From: <MHL...@t-...> - 2003-03-06 10:16:04
|
Am 2003.03.06 07:41 schrieb(en) "N. Lundblad, Peter": > > [snip] > > OK. I am working through the comp8le errors, and I am getting element.cc to > build now. As an aside, the most interresting line was > } /* namespace Element_Helpers > which took some time to spot. (Note the missing */) Gave some interresting > errors later... Sorry :) > OK, you asked me to ask questions. So, could someone please clarify the > plans regarding the use of smart pointers? When is the included RefPtr > supposed to be used and when could we use Glib::RefPtr? (I know there is a > FAQ, but I don't read German very well:-( > > Also, I noticed that many wrapped classes use > _CLASS_GTKOBJECT(...) > so they will be represented by raw pointers in many cases? On the other > hand, Element::get_element_factory() returns Glib::RefPtr<Elementfactory>, > so I modified the ElementFactory class so it uses _CLASS_GOBJECT instead. > Shouldn't we change, among others, Element to use the same? Then our wrapped > gst_element_factory_make (and others) could sink the object before returning > a GLib::RefPtr<Element>. This is a difficult issue. There was quite some argument between Murray, the maintainer of gtkmm, and myself about this. My point of view used to be that as opposed to gtk+, gstreamer has quite a clean reference counting system that allows for more flexibility in the language bindings: Like in gtkmm it is technically possible for gstmm to leave it a user's choice whether gstmm objects should a) reside on the stack, b) be allocated on the heap and destroyed manually (using delete), c) be allocated on the heap and managed by a reference counting system, i.e. destroyed automatically when their reference count reaches 0. Unlike in gtkmm there is also the possibility to reference an object that is marked for auto-destruction (option c) ) meaning that some gstmm container referencing the object won't force the destruction of the object as long as there are still other references. Handling these additional references would be the point of Gst::RefPtr<elem>. Glib::RefPtr<elem> can't be used for this approach because our functions would need to take "elem*" while Glib::RefPtr<elem> only allows for "const Glib::RefPtr<elem>&" (because Glib::RefPtr<elem> doesn't have operator*()). Murray's argument is that it is - simpler to code - easier to understand for the user using Glib::RefPtr<elem> throughout gstmm (which would only allow for c) ). In fact he pointed out that he would do the same in gtkmm if it where not for the fact that during destruction gtk+ containers _force_ destruction of their children disregarding their reference count. gtkmm users knowing this should be able to expect the same from gtkmm when they tell it to manage the life time of their objects. (This behaviour is of course not compatible with Glib::RefPtr<elem> which expects that the reference counter is used). It is still not decided which approach ( a) + b) + c) or only c) ) we should choose. Christian, who is our maintainer, had quite some work to understand our different points (it took me some time to work them out, too :) ) and therefore doesn't seem to have come to his own opinion, yet. Probably we should sort this out before doing a lot of extra work in the end ... Cheers, Martin |
|
From: N. L. P. <pn...@so...> - 2003-03-06 06:38:00
|
> -----Original Message----- > From: MHL...@t-... [mailto:MHL...@t-...] > Sent: den 5 mars 2003 09:37 > To: N. Lundblad, Peter > Cc: gst...@li... > Subject: Re: [Gstreamer-gstmm] Building gstmm > > > > My concern though is that it will be a big > > monolithic patch, since I want it to actually build before > I send something > > in. Do you have any problems with reviewing such a beast? > > No, this will be okay. It's not your fault that gstmm is in > such a hairy state > ... Fine...:-) > However, ask questions before you are stuck :-) > OK. I am working through the comp8le errors, and I am getting element.cc to build now. As an aside, the most interresting line was } /* namespace Element_Helpers which took some time to spot. (Note the missing */) Gave some interresting errors later... OK, you asked me to ask questions. So, could someone please clarify the plans regarding the use of smart pointers? When is the included RefPtr supposed to be used and when could we use Glib::RefPtr? (I know there is a FAQ, but I don't read German very well:-( Also, I noticed that many wrapped classes use _CLASS_GTKOBJECT(...) so they will be represented by raw pointers in many cases? On the other hand, Element::get_element_factory() returns Glib::RefPtr<Elementfactory>, so I modified the ElementFactory class so it uses _CLASS_GOBJECT instead. Shouldn't we change, among others, Element to use the same? Then our wrapped gst_element_factory_make (and others) could sink the object before returning a GLib::RefPtr<Element>. I will try to get the whole thing to build before I tart to make changes (will be a separate patch), but I just want to hear your opinions on this topic. Best Regards, //Peter N. Lundblad |
|
From: <MHL...@t-...> - 2003-03-05 08:37:12
|
Am 2003.03.04 10:47 schrieb(en) "N. Lundblad, Peter": > > If you feel comfortable with your work, it would be best if > > you got cvs > > write access. Christian, what are the necessary steps? I don't > > remember who to contact for that. > > > > However, since you seem new to gtkmmproc you might want your > > first patch to be reviewed yourself. So best use a bug tracker. > > Hm, it seems like we don't have a bug tracking system yet. Christian, > > do you know who to ask to add a "gstmm" component in gstreamer's > > bugzilla account? > > > I think I can wait some time before I get CVS write access, so I don't break > anything unnecessarily. My concern though is that it will be a big > monolithic patch, since I want it to actually build before I send something > in. Do you have any problems with reviewing such a beast? No, this will be okay. It's not your fault that gstmm is in such a hairy state ... However, ask questions before you are stuck :-) Cheers, Martin |
|
From: N. L. P. <pn...@so...> - 2003-03-04 09:44:17
|
> If you feel comfortable with your work, it would be best if > you got cvs > write access. Christian, what are the necessary steps? I don't > remember who to contact for that. > > However, since you seem new to gtkmmproc you might want your > first patch to be reviewed yourself. So best use a bug tracker. > Hm, it seems like we don't have a bug tracking system yet. Christian, > do you know who to ask to add a "gstmm" component in gstreamer's > bugzilla account? > I think I can wait some time before I get CVS write access, so I don't break anything unnecessarily. My concern though is that it will be a big monolithic patch, since I want it to actually build before I send something in. Do you have any problems with reviewing such a beast? Regards, //Peter N. Lundblad |
|
From: <MHL...@t-...> - 2003-03-04 09:36:13
|
Am 2003.03.04 07:41 schrieb(en) "N. Lundblad, Peter": > Hi, > > > Date: Fri, 28 Feb 2003 23:04:08 +0100 > > From: MHL...@t-... (Martin Schulze) > > To: "N. Lundblad, Peter" <pn...@so...> > > Subject: Re: [Gstreamer-gstmm] Building gstmm > > > > Am 2003.02.27 12:47 schrieb(en) "N. Lundblad, Peter": > > > > It's not supposed to build at the moment because > > a) it was started some time before gstreamer 0.6 > > a) nobody is working on it these days > > b) a lot of API has to be wrapped before anything compiles > > because the structures to wrap depend on each other. > > > > OK. That was exactly my impression, so I wasn't doing something very > stupid:-) > > > I'm planning to dig into this in about ten days after my last exam > > for this semester :-) You are very welcome to start yourself, however. > > Actually I already started trying to get it to build by modifying the .hg > and .ccg files. My strategy is to include enough so that it builds, but let > some classes be just skeletons. Then, when it build, one could add the > wrapper methods and so on. Does this sound like something doable? Sounds great! > If I actually get it to build, what should I do about the patch? Should I > put the "big patch" somewhere? If you feel comfortable with your work, it would be best if you got cvs write access. Christian, what are the necessary steps? I don't remember who to contact for that. However, since you seem new to gtkmmproc you might want your first patch to be reviewed yourself. So best use a bug tracker. Hm, it seems like we don't have a bug tracking system yet. Christian, do you know who to ask to add a "gstmm" component in gstreamer's bugzilla account? Regards, Martin |
35 messages has been excluded from this view by a project administrator.