GNOME Bugzilla – Bug 679381
port gsrecorder to gstreame-1.0
Last modified: 2012-07-11 19:33:16 UTC
Some tags we can write only if we use gstreamer-1.0. So it is time to port it.
Created attachment 217989 [details] [review] bump gstreamer version to 1.0 Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Created attachment 217990 [details] [review] grecord: prepare to gstreamer-1.0 rename and remove some functions. make it work with gstreamer-1.0 Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Created attachment 217993 [details] [review] remove gst-mixer Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Created attachment 217994 [details] [review] remove gstreamer-properties Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Created attachment 217995 [details] [review] remove rest of gst-mixer and gstreamer-properties Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Created attachment 217997 [details] [review] grecord: remove gstreamer-properties and gst-mixer Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
I needed to split some patches, bugzilla didn't wonted to accept them. This is why they send not in correct order.
(In reply to comment #7) > I needed to split some patches, bugzilla didn't wonted to accept them. > This is why they send not in correct order. Unfortunately, the patches don't apply as is on current master. Also, if you needed to split the patches ("remove rest of") just to satisify bugzilla, I could review a branch instead. Do you have a public gnome-media.git repo with your changes? thanks!
here is a new branch http://git.gnome.org/browse/gnome-media/log/?h=gstreamer-1.0
I think we better leave gnome-media dead, as it is, with gst-0.10 deps. You should request a gnome-sound-record project/bugz/repository, move the exisiting gnome-media/grecord bug, and maintain it from there for gst-1.0. What do you think?
You right. It is the best way to do. There is too match changes to keep it as same project. I probably need to bring it in better shape before registering new project? I uploaded it here to have some thing to show for registering: https://gitorious.org/gsr I remove every thing, except grecord and rebased the source. This version is working but support only one format - ogg/vorbis. If you have some changes, you are welcome.
(In reply to comment #11) > You right. It is the best way to do. There is too match changes to keep it as > same project. I probably need to bring it in better shape before registering > new project? > I uploaded it here to have some thing to show for registering: > https://gitorious.org/gsr > > I remove every thing, except grecord and rebased the source. This version is > working but support only one format - ogg/vorbis. If you have some changes, you > are welcome. You also added a lot of auto-generated files that should never be in a repository. Many of your changes look weird: https://gitorious.org/gsr/gsr/commit/1a0958004ffdff34d66c02d5748e5f4ccb849824 \n for a filename? https://gitorious.org/gsr/gsr/commit/cb1581b2b8bd24fe6021a7343f3b5530fdd6fbd0 This looks equally strange. At the least, it looks like it might leak... https://gitorious.org/gsr/gsr/commit/fd7324d855a02657ad9a1ecc07851d94da23aba1 That you could have squashed before.. just like some of your "remove the rest of" https://gitorious.org/gsr/gsr/commit/87a204df9a26440a97018f6371bc096789b4d29e Also you should not commit a directory removal, and add it back with a different name... It will confuse git, and you'll lose history/blame. You better start from a fresh repository in this case! You can do better.
(In reply to comment #12) > > You also added a lot of auto-generated files that should never be in a > repository. done. removed. > Many of your changes look weird: > > https://gitorious.org/gsr/gsr/commit/1a0958004ffdff34d66c02d5748e5f4ccb849824 > > \n for a filename? ouch.. memo on me - do not work if you tired! > https://gitorious.org/gsr/gsr/commit/cb1581b2b8bd24fe6021a7343f3b5530fdd6fbd0 > > This looks equally strange. At the least, it looks like it might leak... this one replace this line "window->priv->extension = g_strdup (profile ? gm_audio_profile_get_extension (profile) : NULL);" which was there, before i removed it. > https://gitorious.org/gsr/gsr/commit/fd7324d855a02657ad9a1ecc07851d94da23aba1 > > That you could have squashed before.. just like some of your "remove the rest > of" done. i rebased it. > https://gitorious.org/gsr/gsr/commit/87a204df9a26440a97018f6371bc096789b4d29e > > Also you should not commit a directory removal, and add it back with a > different name... It will confuse git, and you'll lose history/blame. You > better start from a fresh repository in this case! in this repository i wont to prepare the source and learn hot to work with git :) Are there any good way to drop/squash commit history with initial commit? > You can do better. i'll do my best.
(In reply to comment #13) > > Also you should not commit a directory removal, and add it back with a > > different name... It will confuse git, and you'll lose history/blame. You > > better start from a fresh repository in this case! > > in this repository i wont to prepare the source and learn hot to work with git > :) Are there any good way to drop/squash commit history with initial commit? In this particual case, creating a new repo for sound-recorder, I would suggest you use git filter-branch, see: http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository
Ok. How it looks like now? https://gitorious.org/gsr/gsr/commits/master i tryed to split some steps to keep commit clean and readable. Side effect, the source wont compile if you go between this commits. The end result compiles and working.
(In reply to comment #15) > Ok. How it looks like now? > https://gitorious.org/gsr/gsr/commits/master > > i tryed to split some steps to keep commit clean and readable. Side effect, the > source wont compile if you go between this commits. The end result compiles and > working. Ok, it looks simpler, making review easier. Though you could make sure that each step actually still builds. Also, that's not a filtered branch. And, you still have some clean-up to do to remove and rename some documentaiton files (gnome-media.doap, some COPYING files etc). Compiling and running is one thing, you should also do a make distcheck with success. Are you sure all this porting effort is worth it? Don't you think it would be better to spend time to make a better GNOME3 app? Have you read this thread? Several people think it would be nice to work with #gnome-design people and use the rewrite from Florent. http://comments.gmane.org/gmane.comp.gnome.multimedia/1893
After you second time told me about this project, i really decided to try it. I was even able to write one patch in vala :) But there is lots of things which make me cry: - i can't use compiler warning to keep code clean. there are million of warnings. - if i pass String instead of GstStructure, vala will just compile it. And with other warnigns i do not know if there is warning about this too. - the app will just segfault, but i can't use gdb. I mean i can use it and read generated c code from vala, but have you really tried to read it? - and most important. there are no bindings for gstreamer-1.0. It mean i need first crate binding to continue working. Currently i needed to change gstreamer api to implement only one peas of my target. To push only one this part upstream, i need to decide: - extract grecord.c and keep it alive - or 1) add gstreamer-1.0 to vala, 2) then port grecord.vala to new api, 3) then remove every thing i removed from grecord.c (gnome-media-properties, gconf, gst-mixer)
Have you contacted Florent to talk about the problems you faced with vala project? I haven't checked, but I am quite sure the gst 1.0 bindings should be generetable with gir today, and you may ask on #vala or #gstreamer if somebody tried already. You shouldn't worry much about C warnings when generating vala code (in theory). Instead, focus on vala warnings and disable C warnings. You can use gdb with vala programs, even if it is somewhat harder if you use complicated construct. Tbh, when developping vala code, I very rarely need gdb, and I know some people developping in vala all day without ever running gdb (really!)