Re: new module proposal: brasero
Bastien Nocera wrote: it offers the same features and integration (besides the hardcoded link CD/DVD Creator on gnome-panel[1-2]), That's means it doesn't use the same features. It doesn't integrate with the burn:/// usage pattern. Shouldn't both of those be configurable so one can use either NCB, or brasero, or K3B if ones bother? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Teaching GNOME to students...
Hi all, I'm associate professor at Bordeaux University and since few years I'm running a course with few other teachers about 'reading, understanding and managing _real_ code'. Since 2007, we chose to focus on the GNOME project because it matches everything we ever wanted to have for such a course: - A large amount of code, - Enough complexity to get the students over-helmed with it, - Highly documented, - A skilled and reactive community, - A bug and feature-request database (see later on), Our course is composed of a few theoretical courses and (mainly) three small projects: 1- Dig a part of GNOME and extract some technical understanding of it. Make some slides out of it and present it in front of all other students. 2- Take a bug from the issue list and dig it (bug resolution is not mandatory but at least have a deep explanation of the bug). 3- Take a feature-request from the issue list and implement it. Last year we chose the bugs almost on our own (thank a lot Vincent Untz who did provide his precious help to us when we had to sort a bit the bugs and the feature-requests). Here is the result (in French, I'm afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html For this year course it is now time for us to select bugs (not yet feature-request) and we would like to strengthen our link with the GNOME community by letting GNOME's developers suggest some bugs for our list. Benefit will be for all of us (you, students and my teachers team). First, it will let you choose bugs that you are interested to get solved (or a least... explored). Second, we noticed that our way of choosing last year made a lot of students very disappointed because nobody did get immediate interest in looking at the solution they proposed on the bugzilla (not all of them did post a patch but at least a few did). Having somebody interested in the resolution of the bug means that this shouldn't happen again. Third, browsing all these bugs, trying to evaluate their complexity, if they might be just too stupid or too difficult cost us a lot of time... where GNOME's developers could already have this knowledge. Now, let me describe the kind of bug we are looking at: - It MUST involve programming skills (fixing the spelling of a documentation is not our focus). - It MUST be confirmed, 100% reproducible and architecture independent. - It SHOULD have a medium complexity (meaning that it requires at least to browse and understand at least several hundred lines of code in the application to get a deep understanding of it... remember that our course is about reading and understanding a code which is not theirs. On the other hand, don't expect the student to be good at it, so if the difficulty is too high this might be risky). - It SHOULD not be in a high priority to fix it (if so, the students would be in concurrence with others and won't learn anything). We know by experience that choosing unsolved bugs is quite awkward because, indeed, they are 'unsolved'. So what if: - The difficulty you did expect for this bug is the wrong one: Well, this is the game. If you got misled and our team, when looking at the bug, did the same, it is up to the student to show us in his report that we did a wrong evaluation. - The bug get solved before the student give his report back: Still, he has to understand it, describe and evaluate the solution of the bug. This is not a problem. What do we expect from you... Well, submit bugs (several if you wish) that you think are relevant in this context. We need the bug ID in the bugzilla database and maybe few lines to explain why do you think this bug is relevant. The list of the bugs which will be selected will appear here: http://www.labri.fr/perso/fleury/courses/EMC08/projects.html We need about 12-15 bugs. If some students select your bug(s), just take a look at the discussion about this bug on the bugzilla from time to time. I insist on the fact that you are NOT requested to reply to the students (they are on their own concerning their relation with GNOME community). Do reply only if you want to. If a patch is posted, just do as usually... take a critical look at the patch and do what you want with it (hopefully, accept and merge it). But, you are not requested to give a mark on it (we do this internally and with our own criteria). Concerning the feature-request, the constraints will be about the same (but later... :)). Thanks in advance for your help ! Regards -- Emmanuel Fleury Associate Professor, | Room: 261 LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34 351, Cours de la Libération | Email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
Hi again, Sorry, I should have say that: - The code language must be C. - To submit a bug, just send me an e-mail at [EMAIL PROTECTED] Regards -- Emmanuel Fleury Associate Professor, | Room: 261 LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34 351, Cours de la Libération | Email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
Very cool! Good luck with the project, Emmanuel. Luis On Sun, Nov 2, 2008 at 11:57 AM, Emmanuel Fleury [EMAIL PROTECTED] wrote: Hi all, I'm associate professor at Bordeaux University and since few years I'm running a course with few other teachers about 'reading, understanding and managing _real_ code'. Since 2007, we chose to focus on the GNOME project because it matches everything we ever wanted to have for such a course: - A large amount of code, - Enough complexity to get the students over-helmed with it, - Highly documented, - A skilled and reactive community, - A bug and feature-request database (see later on), Our course is composed of a few theoretical courses and (mainly) three small projects: 1- Dig a part of GNOME and extract some technical understanding of it. Make some slides out of it and present it in front of all other students. 2- Take a bug from the issue list and dig it (bug resolution is not mandatory but at least have a deep explanation of the bug). 3- Take a feature-request from the issue list and implement it. Last year we chose the bugs almost on our own (thank a lot Vincent Untz who did provide his precious help to us when we had to sort a bit the bugs and the feature-requests). Here is the result (in French, I'm afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html For this year course it is now time for us to select bugs (not yet feature-request) and we would like to strengthen our link with the GNOME community by letting GNOME's developers suggest some bugs for our list. Benefit will be for all of us (you, students and my teachers team). First, it will let you choose bugs that you are interested to get solved (or a least... explored). Second, we noticed that our way of choosing last year made a lot of students very disappointed because nobody did get immediate interest in looking at the solution they proposed on the bugzilla (not all of them did post a patch but at least a few did). Having somebody interested in the resolution of the bug means that this shouldn't happen again. Third, browsing all these bugs, trying to evaluate their complexity, if they might be just too stupid or too difficult cost us a lot of time... where GNOME's developers could already have this knowledge. Now, let me describe the kind of bug we are looking at: - It MUST involve programming skills (fixing the spelling of a documentation is not our focus). - It MUST be confirmed, 100% reproducible and architecture independent. - It SHOULD have a medium complexity (meaning that it requires at least to browse and understand at least several hundred lines of code in the application to get a deep understanding of it... remember that our course is about reading and understanding a code which is not theirs. On the other hand, don't expect the student to be good at it, so if the difficulty is too high this might be risky). - It SHOULD not be in a high priority to fix it (if so, the students would be in concurrence with others and won't learn anything). We know by experience that choosing unsolved bugs is quite awkward because, indeed, they are 'unsolved'. So what if: - The difficulty you did expect for this bug is the wrong one: Well, this is the game. If you got misled and our team, when looking at the bug, did the same, it is up to the student to show us in his report that we did a wrong evaluation. - The bug get solved before the student give his report back: Still, he has to understand it, describe and evaluate the solution of the bug. This is not a problem. What do we expect from you... Well, submit bugs (several if you wish) that you think are relevant in this context. We need the bug ID in the bugzilla database and maybe few lines to explain why do you think this bug is relevant. The list of the bugs which will be selected will appear here: http://www.labri.fr/perso/fleury/courses/EMC08/projects.html We need about 12-15 bugs. If some students select your bug(s), just take a look at the discussion about this bug on the bugzilla from time to time. I insist on the fact that you are NOT requested to reply to the students (they are on their own concerning their relation with GNOME community). Do reply only if you want to. If a patch is posted, just do as usually... take a critical look at the patch and do what you want with it (hopefully, accept and merge it). But, you are not requested to give a mark on it (we do this internally and with our own criteria). Concerning the feature-request, the constraints will be about the same (but later... :)). Thanks in advance for your help ! Regards -- Emmanuel Fleury Associate Professor, | Room: 261 LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34 351, Cours de la Libération | Email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury ___
Re: Teaching GNOME to students...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel Fleury schrieb: Hi all, I'm associate professor at Bordeaux University and since few years I'm running a course with few other teachers about 'reading, understanding and managing _real_ code'. Since 2007, we chose to focus on the GNOME project because it matches everything we ever wanted to have for such a course: - A large amount of code, - Enough complexity to get the students over-helmed with it, - Highly documented, - A skilled and reactive community, - A bug and feature-request database (see later on), That's a wonderful idea. I always hated the programming stuff in university were you program something that's already available and once your done just through it away, because the same thing but much better already exists. I could imagine that it makes more fun when you see that a part of your code is actually included in a piece of software that is used by many people. Our course is composed of a few theoretical courses and (mainly) three small projects: 1- Dig a part of GNOME and extract some technical understanding of it. Make some slides out of it and present it in front of all other students. 2- Take a bug from the issue list and dig it (bug resolution is not mandatory but at least have a deep explanation of the bug). 3- Take a feature-request from the issue list and implement it. Last year we chose the bugs almost on our own (thank a lot Vincent Untz who did provide his precious help to us when we had to sort a bit the bugs and the feature-requests). Here is the result (in French, I'm afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html For this year course it is now time for us to select bugs (not yet feature-request) and we would like to strengthen our link with the GNOME community by letting GNOME's developers suggest some bugs for our list. Benefit will be for all of us (you, students and my teachers team). First, it will let you choose bugs that you are interested to get solved (or a least... explored). Second, we noticed that our way of choosing last year made a lot of students very disappointed because nobody did get immediate interest in looking at the solution they proposed on the bugzilla (not all of them did post a patch but at least a few did). I can understand that it's frustrating if it appears that nobody is interested in your patch. I think it's the right choice to ask for bugs developers are interested in first. Having somebody interested in the resolution of the bug means that this shouldn't happen again. Third, browsing all these bugs, trying to evaluate their complexity, if they might be just too stupid or too difficult cost us a lot of time... where GNOME's developers could already have this knowledge. Now, let me describe the kind of bug we are looking at: - It MUST involve programming skills (fixing the spelling of a documentation is not our focus). - It MUST be confirmed, 100% reproducible and architecture independent. - It SHOULD have a medium complexity (meaning that it requires at least to browse and understand at least several hundred lines of code in the application to get a deep understanding of it... remember that our course is about reading and understanding a code which is not theirs. On the other hand, don't expect the student to be good at it, so if the difficulty is too high this might be risky). - It SHOULD not be in a high priority to fix it (if so, the students would be in concurrence with others and won't learn anything). In general I think looking at gnome-love bugs will already give you plenty of bugs with different levels of difficulties. What I don't understand is why you differentiate between bugs and feature requests. From my point of view there's no big difference, especially for a programmer. In both cases you get to familiar with the code and write a patch. For Deskbar-Applet currently three bugs come to my mind: - - Adjust files modules that the query string can appear everywhere in a file's name (case in-sensitive) (see bug 491404) - - Add possibility to add/change/remove directories that the files module searches in (see bug 443975). Add home dir and XDG special dirs by default. - - Programs Handler should notice newly installed programs. Someone wanted to work on this, but I got no update from him/her. In addition, the gio port must be completed first. (see bug 343894) - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkN5YAACgkQ1ygZeJ3lLIfOsACcDyjjd8l1b/il1ntJEvqrvKmW 9eQAn3DXF25MsqVIIL5+4EAHDc+O4mss =5Mhc -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel Fleury schrieb: Hi again, Sorry, I should have say that: - The code language must be C. - To submit a bug, just send me an e-mail at [EMAIL PROTECTED] Regards Ah, that rules out Deskbar-Applet :( - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkkN5ccACgkQ1ygZeJ3lLIdHjgCcCAn8Z/MVv72Cvx4rXHeLvG3g fKcAmKBqmjR/HjT9sEBM40hNuOWt5jE= =6a30 -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
Sebastian Pölsterl wrote: In general I think looking at gnome-love bugs will already give you plenty of bugs with different levels of difficulties. Exactly, love-bugs where our major concern last year. It was really a guideline for us to find bugs matching our requisites. What I don't understand is why you differentiate between bugs and feature requests. From my point of view there's no big difference, especially for a programmer. In both cases you get to familiar with the code and write a patch. In a matter of fact, the approach is quite different (in my humble opinion). In the case of a bug, you are (most of the time) provided with a _proper_ behavior of the software and you should twist the code until you match it. In the case of the feature-request, you are actually requested to provide by your own what the proper behavior should be... and this small difference might be quite thin to skilled developer but it makes it a lot harder to students. Regards -- Emmanuel Fleury Life would be so much easier if we could just look at the source code. -- Unknown ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel Fleury schrieb: Sebastian Pölsterl wrote: What I don't understand is why you differentiate between bugs and feature requests. From my point of view there's no big difference, especially for a programmer. In both cases you get to familiar with the code and write a patch. In a matter of fact, the approach is quite different (in my humble opinion). In the case of a bug, you are (most of the time) provided with a _proper_ behavior of the software and you should twist the code until you match it. In the case of the feature-request, you are actually requested to provide by your own what the proper behavior should be... and this small difference might be quite thin to skilled developer but it makes it a lot harder to students. Well, a feature request usually comes with a guide how it should work or look like, too. Of course, often there are multiple ways to implement that feature, whereas for a bug the most difficult part is to find the cause of it. I guess it depends which one is more difficult. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkN/bkACgkQ1ygZeJ3lLIf1qwCfS6ZCPolc7TnngnJe4WxND1Q8 vZYAn3p42ADs1N/3H4pfFmCnwMHDUzmc =TG4X -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
Hi, Le samedi 01 novembre 2008 à 22:51 +0100, Andre Klapper a écrit : How does Brasero *integrate* in the desktop? E.g. burning from Nautilus? It doesn't do exactly what NCB does. Brasero is a standalone application. What I meant was a lot more basic (so basic that it probably shouldn't have been mentioned) it appears in the right click menus and also in the new nautilus stuff to handle inserted media (the one that pops up when a user inserts a new medium and which replaced gnome-volume-manager). But true, that was an overstatement since it doesn't require code. This item should be crossed off the list then. As far as nautilus integration goes, it can't compete with NCB. It supports burn:// uris though. It can display and burn the contents of burn:// but this isn't really nautilus integration here. Are strings/wordings like Data disc, Video disc and Videodisk (ahem?) consistent with the terms used in gvfs? In general, the strings need of review. agreed =(. There's lots of them (1000 to translate), many starting with Please, ... (to me this looks wrong - any folks with english mothertongue might correct me). English is not our mother tongue so yes, we could use some help here. Many strings miss Capitalization. There's a few dialogs with Rename | Don't rename or Replace | Don't replace buttons. I don't like just negating, I'd prefer e.g. Keep name. And Don't isn't proper english to me. I'll file bug reports like http://bugzilla.gnome.org/show_bug.cgi?id=558852 . andre Thanks for filing the bug about all these string problems. We'll work on them. Philippe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Sun, 2008-11-02 at 23:22 +0100, Philippe Rouquier wrote: [snip] It doesn't do exactly what NCB does. Brasero is a standalone application [snip] We need an actual list of what Brasero does that nautilus-cd-burner does not do. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
2008/11/1 Philippe Rouquier [EMAIL PROTECTED] Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1, a wonderful application. n-c-b should be completely removed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Sun, 2008-11-02 at 17:02 -0600, Jason D. Clinton wrote: 2008/11/1 Philippe Rouquier [EMAIL PROTECTED] Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1, a wonderful application. n-c-b should be completely removed. Problem is it's a stand-alone application. It doesn't integrate with the workflow or usage pattern that we set out to achieve with nautilus-cd-burner. There's no shame in brasero _not_ being in the GNOME release. And it doesn't stop distributions shipping it if they feel that their users would want more features for CD burning. Let me write the supposed workflow for CD burning in GNOME (that's not quite what it is currently): * Media is inserted first - User inserts blank media - The CD creator window opens up inviting the user to add files to the location to burn onto a CD - User clicks write to CD - nautilus-cd-burner opens, click write, done * User knows they want to create a CD: - User scours the menus, finds the CD/DVD creator under System Tools - Window is inviting the user to add files - Clicks write to CD - nautilus-cd-burner opens, click write, a disc will be requested, done The 3rd option is integration into applications. Rhythmbox allows to burn audio CDs from existing playlists, gthumb allows burning CDs/DVDs from image albums and image folders. Brasero currently only offers an answer to the second option. And what we're really looking for is an answer for option 3. I'll take patches to create Video DVDs from a Totem playlist, and I'm sure Pitivi hackers would be happy for it to have the same treatment. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Sun, 2008-11-02 at 12:56 +0100, Steve Frécinaux wrote: Bastien Nocera wrote: it offers the same features and integration (besides the hardcoded link CD/DVD Creator on gnome-panel[1-2]), That's means it doesn't use the same features. It doesn't integrate with the burn:/// usage pattern. Shouldn't both of those be configurable so one can use either NCB, or brasero, or K3B if ones bother? The link has nothing to do in Places, see my other mail and the link to bug: http://bugzilla.gnome.org/show_bug.cgi?id=119991#c25 Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Mon, 2008-11-03 at 00:52 +, Bastien Nocera wrote: On Sun, 2008-11-02 at 17:02 -0600, Jason D. Clinton wrote: 2008/11/1 Philippe Rouquier [EMAIL PROTECTED] Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1, a wonderful application. n-c-b should be completely removed. Problem is it's a stand-alone application. It doesn't integrate with the workflow or usage pattern that we set out to achieve with nautilus-cd-burner. There's no shame in brasero _not_ being in the GNOME release. And it doesn't stop distributions shipping it if they feel that their users would want more features for CD burning. Let me write the supposed workflow for CD burning in GNOME (that's not quite what it is currently): * Media is inserted first - User inserts blank media - The CD creator window opens up inviting the user to add files to the location to burn onto a CD - User clicks write to CD - nautilus-cd-burner opens, click write, done * User knows they want to create a CD: - User scours the menus, finds the CD/DVD creator under System Tools - Window is inviting the user to add files - Clicks write to CD - nautilus-cd-burner opens, click write, a disc will be requested, done Brasero can do these options as well of course it needs minor tweaks from other modules do actually behave like that. The 3rd option is integration into applications. Rhythmbox allows to burn audio CDs from existing playlists, gthumb allows burning CDs/DVDs from image albums and image folders. Banshee and Exaile already integrate Brasero, afaik because some of NCB API changes in the past, save some code/job and because it's a stand alone application that can use multiple backends with debugging and other features. Brasero currently only offers an answer to the second option. And what we're really looking for is an answer for option 3. I'll take patches to create Video DVDs from a Totem playlist, and I'm sure Pitivi hackers would be happy for it to have the same treatment. Sure Brasero already uses Totem playlists more integration in other apps could be done in the future. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
+1 And I also did some quick checks on brasero 0.8.2 a11y side on latest opensolaris, bugs were filed and most of them will get fixed in 0.8.4 or so. The issues exist in brasero bottom panel,; the cover editor, and labels in new project start pageï¼brasero failed to show its children out to ATs;. Please refer to the bug: #558205, #558207, #558212, #558213 and #558343. Except issues above, brasero supports lots of at-tools accessing, like orca screen reader/magnifier, GNOME On-screen Keyboard, GNOME a11y theme and so on. If those issue can be solved in 0.8.4 release, that would be great for accessibility accessing. Thanks, Regards. -Tim On Sat, 2008-11-01 at 19:27 +0100, Philippe Rouquier wrote: Hi, We'd be interested in having brasero integrated into the GNOME desktop. Brasero is a standalone application to burn CDs and DVDs. We have tried to make brasero as easy to use and as simple as possible. Brasero has been developped for about 4 years now and has been actively maintained ever since. Brasero supports the basic operations: - CD/DVD creation (audio, data) - CD/DVD copy - CD/DVD blanking and formatting One of the strengths of brasero is that it can use various backends through its plugin system and can easily be extended to support some more. Currently it supports growisofs, libburn, libisofs, cdrecord/mkisofs/readcd, wodim/genisoimage/readom, cdrdao. The plugin system also allows for additional features: (on the fly) checksuming, use of remote files (FTP, samba, ...), audio normalization, video DVD copy. Other features includes: full multisession support preview of audio, video files and pictures initial support for video DVD creation audio track splitting medium cover editor projects Brasero and GNOME: - we tried to stick to GNOME HIG guidelines. - brasero has tried to integrate as tightly as possible with the rest of the desktop and in particular with nautilus - it is up to date as far as GNOME goals are concerned - it uses and has been using svn.gnome.org and bugzilla.gnome.org for quite some time now - it is well translated by GNOME translator teams (btw, thanks to all of you again) - a documentation is available It supports linux, OpenSolaris and freeBSD. As far as we know, it is used as the default burning application on Ubuntu and OpenSuse; but I was told it was also considered to be chosen as the default application for OpenSolaris. Uptodate packages are also available for Fedora and Mandriva. Dependencies: - glib and gio - gtk+ - gstreamer (for all audio and video operations) - libxml2 - HAL - dbus Optional dependencies: - totem-pl-parser - beagle - dvdcss (for video DVD copy) - all burning backends (libburn, libisofs, growisofs, wodim, cdrecord, readcd, readom, mkisofs, genisoimage, ) Short term: - get ready for GTK+ 3.0 - support DVD-RAM and BDs - improvements to the video project parts - allow full multisession media edition (file removal, file renaming, ...) through libisofs Future plans: - audio on DVDs - allow to shrink video DVDs when copying - video DVD to video CD copy - backup and automatic file update on insertion - file spanning - creation of encrypted images Site: http://live.gnome.org/Brasero http://www.gnome.org/projects/brasero/ All comments and suggestions would be of course appreciated. We are willing to do whatever needs to be done to improve brasero for it to be integrated. NOTE: after the 0.8.3 release that should take place soon, we intend to branch it and use SVN trunk for the next development version. ATM trunk is the latest stable version. Regards Philippe Rouquier ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
Hi Emmanuel, This is very interesting. I wonder if it's possible to share your experience and/or teaching material with others wanting to do the same in other schools (myself included). d-d-l may not be the best place for that. academia-list [1] is. Regards, behdad [1] http://mail.gnome.org/mailman/listinfo/academia-list Emmanuel Fleury wrote: Hi all, I'm associate professor at Bordeaux University and since few years I'm running a course with few other teachers about 'reading, understanding and managing _real_ code'. Since 2007, we chose to focus on the GNOME project because it matches everything we ever wanted to have for such a course: - A large amount of code, - Enough complexity to get the students over-helmed with it, - Highly documented, - A skilled and reactive community, - A bug and feature-request database (see later on), Our course is composed of a few theoretical courses and (mainly) three small projects: 1- Dig a part of GNOME and extract some technical understanding of it. Make some slides out of it and present it in front of all other students. 2- Take a bug from the issue list and dig it (bug resolution is not mandatory but at least have a deep explanation of the bug). 3- Take a feature-request from the issue list and implement it. Last year we chose the bugs almost on our own (thank a lot Vincent Untz who did provide his precious help to us when we had to sort a bit the bugs and the feature-requests). Here is the result (in French, I'm afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html For this year course it is now time for us to select bugs (not yet feature-request) and we would like to strengthen our link with the GNOME community by letting GNOME's developers suggest some bugs for our list. Benefit will be for all of us (you, students and my teachers team). First, it will let you choose bugs that you are interested to get solved (or a least... explored). Second, we noticed that our way of choosing last year made a lot of students very disappointed because nobody did get immediate interest in looking at the solution they proposed on the bugzilla (not all of them did post a patch but at least a few did). Having somebody interested in the resolution of the bug means that this shouldn't happen again. Third, browsing all these bugs, trying to evaluate their complexity, if they might be just too stupid or too difficult cost us a lot of time... where GNOME's developers could already have this knowledge. Now, let me describe the kind of bug we are looking at: - It MUST involve programming skills (fixing the spelling of a documentation is not our focus). - It MUST be confirmed, 100% reproducible and architecture independent. - It SHOULD have a medium complexity (meaning that it requires at least to browse and understand at least several hundred lines of code in the application to get a deep understanding of it... remember that our course is about reading and understanding a code which is not theirs. On the other hand, don't expect the student to be good at it, so if the difficulty is too high this might be risky). - It SHOULD not be in a high priority to fix it (if so, the students would be in concurrence with others and won't learn anything). We know by experience that choosing unsolved bugs is quite awkward because, indeed, they are 'unsolved'. So what if: - The difficulty you did expect for this bug is the wrong one: Well, this is the game. If you got misled and our team, when looking at the bug, did the same, it is up to the student to show us in his report that we did a wrong evaluation. - The bug get solved before the student give his report back: Still, he has to understand it, describe and evaluate the solution of the bug. This is not a problem. What do we expect from you... Well, submit bugs (several if you wish) that you think are relevant in this context. We need the bug ID in the bugzilla database and maybe few lines to explain why do you think this bug is relevant. The list of the bugs which will be selected will appear here: http://www.labri.fr/perso/fleury/courses/EMC08/projects.html We need about 12-15 bugs. If some students select your bug(s), just take a look at the discussion about this bug on the bugzilla from time to time. I insist on the fact that you are NOT requested to reply to the students (they are on their own concerning their relation with GNOME community). Do reply only if you want to. If a patch is posted, just do as usually... take a critical look at the patch and do what you want with it (hopefully, accept and merge it). But, you are not requested to give a mark on it (we do this internally and with our own criteria). Concerning the feature-request, the constraints will be about the same (but later... :)). Thanks in advance for your help ! Regards ___
