Re: Module Proposal: Zeitgeist
Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise!** Now talking about Zeitgeist it seems to me that it proved stability and further adoption on other projects but not the project it was designed at the beginning (am i right Sief ?). The maintainers are very open to suggestions and to improve the adoption on more modules. So this is a big +1 for the inclusion. But still care to explain what should we do with tracker ? Should we use both ? Cheers Luis 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ 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: Module Proposal: Zeitgeist
2012/4/21 Sriram Ramkrishna s...@ramkrishna.me On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.org wrote: Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. Sriram, do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. I don't want to point fingers to companies which i have much to thank for their hard work, specially their developers, but it's too much coincidence to have all these design decisions from the same people to go against all the community and also to developers who want to share their work with the GNOME Project just because it's not planned on the Design Team. Cheers Luis This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise!** See Alan's mail in this thread. sri Now talking about Zeitgeist 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.32 tarball releases and unstable API/module usage
Ter, 2010-11-16 às 14:17 +0200, Ionuț Bîru escreveu: On 11/11/2010 01:33 AM, Matthias Clasen wrote: On Wed, Nov 10, 2010 at 6:02 PM, Jan de Grootj...@jgc.homeip.net wrote: Either these things get released as 2.33 tarballs to make clear that they're not regular 2.32 updates, or they get fixed to compile AND WORK on a stable 2.32 desktop. Releases that are meant to compile AND WORK on a stable 2.32 desktop will be included in GNOME 2.32.1. i have the feeling that this won't happen for gconf and gnome-disk-utility. correct... g-d-u requires a newer libnotify which isn't available for 2.32 but gconf isn't a problem since it contains the --with-gtk=2.0 switch. So i guess g-d-u needs a new release or simple stick with 2.32.0 and bump the current git master to 2.90.x. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.1 status
On Wed, Oct 20, 2010 at 5:39 PM, Lucas Rocha luc...@gnome.org wrote: Hi all, With all the moving parts in our platforms, I'm having a tough time building 2.91.1. Here's the list of issues I encountered so far: zenity doesn't build with libnotify 0.7. https://bugzilla.gnome.org/show_bug.cgi?id=631737 Zenity got the statusicon removed and builds with libnotify 0.7. Also i replaced a few deprecated code and released 2.91.1.1. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Additional 2.32.0 tarballs :-)
On Tue, Sep 28, 2010 at 1:04 AM, Vincent Untz vu...@gnome.org wrote: - zenity: translations, 2.31.x version Tarball released... Thanks Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GApplication is going away
On Fri, Sep 3, 2010 at 7:20 AM, Ryan Lortie de...@desrt.ca wrote: hi Andre, On Thu, 2010-09-02 at 17:15 +0200, Andre Klapper wrote: As hardcode freeze starts on September 13th, which / how many modules use GApplication and are affected by this? According to Seb (who did a quick grep) he knows of 4: totem, gnome-color-manager, eog, nautilus These apps are using GApplication without GtkApplication in their 2.31.x releases. Brasero is also using GApplication. At this time (beta stage) a few weeks before releasing 2.32.0 it's pretty bad reverting back to libunique. In the next release cycle i guess we will take more caution adopting new technologies because we spent most of the time porting to new ones (gsettings, gdbus and gapplication). Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Qua, 2010-06-02 às 12:06 +0100, Bastien Nocera escreveu: On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I'll mirror Xavier's problem that Empathy would be just as GNOME as Pidgin by adding that the same problem would happen to Totem. Is a video player that doesn't use GStreamer alright? Is a video player that doesn't follow the GNOME Schedule alright? We might have ended up with gxine in GNOME if it were the case, and I wouldn't have started Totem some 9 years ago. I agree... also that means that most of the applications out there that will be blessed by GNOME won't work on GNOME 3.0. See pidgin, gxine, gnomebaker etc... that doesn't follow GNOMEGoals and would make them broken for GNOME Releases. Also not following GNOME Schedule means that will have many problems on QA, Documentation and Translations. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Qua, 2010-04-21 às 22:41 +0200, Mikkel Kamstrup Erlandsen escreveu: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Target: desktop What's the plan to integrate zeitgeist with gnome-shell and other applications ? I mean totem, nautilus, brasero, empathy etc... Also there's a plan to rewrite some API in C so other applications can use zeitgeist API ? Or we are just suppose to interact with zeigeist via dbus ? Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: PDF Mod
On Fri, 2010-02-19 at 10:37 +, Bastien Nocera wrote: On Thu, 2010-02-18 at 19:39 -0800, Gabriel Burt wrote: Purpose: a simple tool for doing basic manipulations of PDF documents. It can rotate, move, remove, and extract pages, merge documents, edit their basic metadata (title, author, etc), and extract images. Future feature scope includes being able to change page sizes, and possibly do imposition (prep for printing). I'd say that although useful[1], it doesn't really fit with what people expect from the default applications on a Desktop. I will not be commenting on what you thought might bring a flame fest :) I have to agree with Bastien, this application is very useful, it once saved my life when i printed my thesis. But for most of our users it's not really that useful because most of people only open pdf not edit. So i think we better wait for the release team proposal [1] on this matter. It's a great application congrats! 1 - http://mail.gnome.org/archives/desktop-devel-list/2010-February/msg00046.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting an @gnome.org address?
On Tue, 2010-01-19 at 23:35 -0500, Joanmarie Diggs wrote: Hi all. Maybe I'm just a lousy googler, but how does one get an @gnome.org address? I ask because of this sort of thing: http://twitter.com/macosforge/status/7960326131 You need to be a Foundation member read: http://live.gnome.org/NewEmailRequest Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: XDG StatusNotifier Specification: Feedback Invited
On Wed, 2010-01-13 at 13:52 -0600, Ted Gould wrote: To make it simple to use for application developers we've built a small library called libappindicator [1] that makes it pretty easy to create and manage the icon and the menu an we've documented how to use it [2]. Hopefully this will become part of GTK/GNOME in the future, but obviously it won't be in the 2.30 cycle. It will provide things like transparent fallback to GtkStatusIcon for support of people who choose not to run the applet (and have a notification area one). Ok so if it won't be on 2.30 it will be done for 3.0 ? Why should module maintainers use this library if it isn't on GNOME infrastructure or even blessed ? I like the idea but so far it seems to me more a downstream development than upstream. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enabling automake silent-rules by default
On Fri, 2009-08-28 at 14:06 -0400, Behdad Esfahbod wrote: Hi, Many modules have already been adding support for automake silent rules, but turned off by default. I just pushed changes to pango and vte to enable silent rules by default. That's a much saner default, and allows catching warnings easily. I like to suggest everyone does the same. You just need to add this line to configure.ac after AM_INIT_AUTOMAKE: m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])]) That does most of the job. For custom make rules, you need to add $(AM_V_GEN) to the beginning of the rule. Read this for details: http://www.flameeyes.eu/autotools-mythbuster/automake/silent.html Hi. Why not turn this into an official GOAL for 2.30/3.0 ? This is probably too late to make every official module with silent-rules by default. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enabling automake silent-rules by default
On Fri, 2009-08-28 at 20:33 +0200, Vincent Untz wrote: Le vendredi 28 août 2009, à 14:29 -0400, Behdad Esfahbod a écrit : On 08/28/2009 02:24 PM, Luis Medinas wrote: On Fri, 2009-08-28 at 14:06 -0400, Behdad Esfahbod wrote: Hi, Many modules have already been adding support for automake silent rules, but turned off by default. I just pushed changes to pango and vte to enable silent rules by default. That's a much saner default, and allows catching warnings easily. I like to suggest everyone does the same. You just need to add this line to configure.ac after AM_INIT_AUTOMAKE: m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])]) That does most of the job. For custom make rules, you need to add $(AM_V_GEN) to the beginning of the rule. Read this for details: http://www.flameeyes.eu/autotools-mythbuster/automake/silent.html Hi. Why not turn this into an official GOAL for 2.30/3.0 ? This is probably too late to make every official module with silent-rules by default. Something like that, yeah. Feel free to write the Goal. http://live.gnome.org/GnomeGoals/NicerBuilds ? Yes i it exists already, so it will be a nice idea turning into a offical goal for the next release. Any objection ? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote: libxml = 0.6 libpng = 1.2 libuuid zlib dbus = 0.60 sqlite3 = 3.5 (built with --enable-load-extension) hal = 0.5 vala = 0.7.3 pango = 1.0.0 Is there plans to replace HAL by GIO or devicekit ? Hal will be deprecated soon afaik. /discuss ;) Also is there any plans to integrate with more applications besides nautilus ? i mean if it's for GNOME 3.0 it should be integrated with zeitgeist, gnome-shell and gnome-do if it will be proposed ? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Officially turn DropLibsexy into a GNOME Goal
On Thu, Jun 11, 2009 at 5:29 PM, Javijavierjc1...@gmail.com wrote: Hello, I've sent a mail to the gtk-devel list [3] about consolidate libsexy library in GTK+ in the context of the project Ridley [4] and seems that they agree. For that reason, I'd like to propose turn DropLibsexy [1] into a official GNOME Goal [2]. (Further, almost all the work is done :)) Any suggestion/objection? If you agree, I can update the GnomeGoal page with the new changes. +1 for me, i already helped with a patch and there isn't many modules using libsexy. So this should be a goal for 2.28. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Officially turn DropLibsexy into a GNOME Goal
On Thu, Jun 11, 2009 at 7:23 PM, Jason D. Clintonm...@jasonclinton.com wrote: On Thu, Jun 11, 2009 at 1:02 PM, Luis Medinas lmedi...@gnome.org wrote: On Thu, Jun 11, 2009 at 5:29 PM, Javijavierjc1...@gmail.com wrote: I've sent a mail to the gtk-devel list [3] about consolidate libsexy library in GTK+ in the context of the project Ridley [4] and seems that they agree. For that reason, I'd like to propose turn DropLibsexy [1] into a official GNOME Goal [2]. (Further, almost all the work is done :)) Any suggestion/objection? If you agree, I can update the GnomeGoal page with the new changes. +1 for me, i already helped with a patch and there isn't many modules using libsexy. So this should be a goal for 2.28. How 'bout 2.30 after the GTK+ release incorporating these changes is fully released and widely available? The most used libsexy features are already on GTK+ 2.16 and 2.17. So i think it's acceptable turn this into an official goal. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
On Fri, 2009-05-15 at 12:51 -0400, David Zeuthen wrote: FWIW, I wholeheartedly agree that lots of people abuse the notification area. And I'd like to point out that your own application is doing this, here's a screenshot I did a few weeks ago http://people.freedesktop.org/~david/brasero.png because the whole user experience was so.. freaking absurd.. and I was overloaded with redundant information. The whole point of notification area on Brasero is to make user able to hide the dialog (very common on big media like dvd's and bd's) and see the status on the notification area and then receive a notification when the media finish burning. Yes sometimes we are abusing notification area but the user should be able to hide the notification area icon. PS: I'm the Luis from Brasero. Our name is close but not the same. Luis Medinas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggsmclient code syncing
On Wed, 2009-04-08 at 14:38 -0400, Matthias Clasen wrote: Hey, while playing with the almost-working session saving in gnome-session 2.26.0.90, we discovered a bug in the EggSMClient code that is saving the state into .desktop files (it doesn't actually produce working .desktop files). While this is not really important (it only breaks the use case that you can copy a .desktop file out of the session-state/ directory and use it to start the client in the exact same state), it might be a good idea to sync the eggsmclient code in the modules that use it for 2.26.1, which seems to be at least the following: gnome-terminal gedit seahorse gnome-games gnome-session totem evince file-roller brasero nautilus Brasero done on trunk and gnome-2.26 branch. Thanks ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggsmclient code syncing
On Wed, Apr 8, 2009 at 7:38 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Hey, while playing with the almost-working session saving in gnome-session 2.26.0.90, we discovered a bug in the EggSMClient code that is saving the state into .desktop files (it doesn't actually produce working .desktop files). While this is not really important (it only breaks the use case that you can copy a .desktop file out of the session-state/ directory and use it to start the client in the exact same state), it might be a good idea to sync the eggsmclient code in the modules that use it for 2.26.1, which seems to be at least the following: gnome-terminal gedit seahorse gnome-games gnome-session totem evince file-roller brasero nautilus The latest eggsmclient code to sync is on gnome-session ? I'll update it for brasero before 2.26.1 Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Brasero has been branched for 2.26
Hi Brasero has been branched for gnome-2-26. This branch will continue to be developed for 2.26.x releases and trunk will be used for 2.27.x. Thanks Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Brasero improvements over the 2.26 release cycle
On Fri, 2009-01-16 at 12:29 +0100, Vincent Untz wrote: Le jeudi 15 janvier 2009, à 10:59 +0100, Josselin Mouette a écrit : Le lundi 12 janvier 2009 à 19:18 +, Bastien Nocera a écrit : - Split Brasero into a library (available on trunk) named libbrasero-media that is being documented (devhelp) and re-arranged so we can deliver a stable API. The library isn't usable in Rhythmbox or sound-juicer, as it conflicts with their license (GPLv2 vs. GPLv2 + exception). Well, they are not incompatible per se, it’s just that the exception cannot apply if rhythmbox/sound-juicer links to this library. For the record, what is making this exception necessary? I don’t think any non-GPL-compatible GStreamer plugins are required for the normal operation of rb or s-j. Let's make it clear: from what I understand, it seems it's a blocker in Bastien's mind. It is a blocker for me too. We can have some long discussion about all that, but in the end, it might cause difficulties that we don't have with the ncb library (eg, Bastien rejecting the rhythmbox plugin). Right now Brasero is currently re-licensing the library again, we already contacted the people involved asking about the change. There were some bits in the library that Philippe re-wrote (that used NCB code) to be compatible with SJ and RB. So we still expect to have all this done (of course with Bastien help to review our patches :) ) before the deadline. We have been working harder to accomplish all new features and deadlines. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Brasero improvements over the 2.26 release cycle
On Sun, 2009-01-11 at 11:35 +0100, Josselin Mouette wrote: - Lot's of bug fixes (Can be seen on NEWS and Changelog) - Submitted a Totem[1] plugin, Rhythmbox[2] plugin and Sound-Juicer[3] work to replace ncb by brasero using the new library in addiction to other applications already using Brasero (Banshee, exaile etc...). This way we can completely deprecate libnautilus-burn, I guess. The only remaining thing will be the python bindings. We have two applications using them: pybackpack and serpentine. Yes we are planning the bindings too, it seems almost every application using ncb is patched so we can safely now replace ncb. Thanks a lot for the work. I doubted that brasero could replace n-c-b that soon, and you proved me wrong. Thanks for your feedback too, it helped to archive all this goals. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Brasero improvements over the 2.26 release cycle
Hi! After the previous discussion about proposing Brasero for GNOME 2.26 the Brasero has made lot's of improvements based on some feedback from the community. So right now we released two releases during the 2.25 cycle and added this important features: - Nautilus extension (based on the current ncb), there are some applications that put the files on burn:/// with this extension Brasero replaces ncb and Burn the media. - Split Brasero into a library (available on trunk) named libbrasero-media that is being documented (devhelp) and re-arranged so we can deliver a stable API. - Lot's of bug fixes (Can be seen on NEWS and Changelog) - Submitted a Totem[1] plugin, Rhythmbox[2] plugin and Sound-Juicer[3] work to replace ncb by brasero using the new library in addiction to other applications already using Brasero (Banshee, exaile etc...). - Followed and completed Gnome Goals in time. - Consistent releases with the current unstable release cycle. With this we archived almost all feedback made by the community we always expect to improve GNOME and would be glad to help. In the future we expect to make the library better documented, add language bindings, support for more formats etc... Thanks for all the people involved on the feedback, help tested, submitted bugs and translate. Cheers Luis [1]-http://bugzilla.gnome.org/show_bug.cgi?id=536732 [2]-http://bugzilla.gnome.org/show_bug.cgi?id=565383 [3]-http://bugzilla.gnome.org/show_bug.cgi?id=567286 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [ANNOUNCE] brasero-0.8.4 released and branched
On Sun, 2008-12-14 at 19:09 +0100, Andre Klapper wrote: Hi, Am Sonntag, den 14.12.2008, 18:16 +0100 schrieb Philippe Rouquier: The title says it all: a new version of brasero has just been released. It has also been branched to start developping new features. trunk will now host development version while the stable version will be in branches/brasero_0_8. On this topic, next version of brasero should be split between a library and the application itself. A plugin for totem is also in the works. So the proposal for inclusion in GNOME 2.26 refers to the brasero_0_8 branch and not to trunk, I assume? Need to know for testing and translations. This is Philippe decision i'm not sure if we can deliver all plans for 0.9 (the library) that were proposed during the inclusion thread. Please give us a day or two to give a final answer about it. Maybe it's too late for other modules adopt the library if it's the idea. 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
On Wed, 2008-11-05 at 14:59 +0100, Josselin Mouette wrote: Le mercredi 05 novembre 2008 à 13:41 +, Luis Medinas a écrit : Again... is any regression provide a standalone application that makes users do whatever they want when they want to burn a cd/dvd ? Yes, this is a regression. NCB made the right choice to consider CD burning as a service instead of an application. I remember the time NCB was developed there wasn't any decent burning application for GNOME. And now you can use Brasero as a service too if you want it's integrated with Nautilus plus you don't need to be tied to the only backend NCB supports: cdrtools. 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
On Wed, 2008-11-05 at 13:33 +0100, Josselin Mouette wrote: Le mercredi 05 novembre 2008 à 12:48 +0100, Luca Ferretti a écrit : If so, there is no UI for this, in example a Blank Disc entry in Nautilus context menu for inserted disc, isn't it? No, but it proposes to blank the disk at the time of burning if appropriate. What exactly can the brasero front-end do that n-c-b cannot? Shouldn’t it be something that we could add to the n-c-b burn dialog? Josselin, I was speaking about frontend, i.e. provide to the end user both this[1] and this[2] UIs to collect data to burn. Yes, I understood that, and I believe the brasero frontend made some bad UI choices. Bad choices ? Like adding new features and provide a easy UI to users ? Just don't say it's bad choices help us improve that! If we change our burning software so radically, I’d like to see radically new features as well. Currently I only see a radically worse UI. Don’t get me wrong: I love to see people working on improving our CD burning suite. But thinking of it as a standalone application, à la Nero, is a regression. Again... is any regression provide a standalone application that makes users do whatever they want when they want to burn a cd/dvd ? I feel that most of the people here don't actually use Brasero and don't know how can this application improve GNOME desktop overall. ___ 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 Tue, 2008-11-04 at 15:21 +0100, Josselin Mouette wrote: Le lundi 03 novembre 2008 à 23:48 +0100, Luca Ferretti a écrit : Examples of backends are nautilus-cd-burner and brasero :-) OK, serious. From UI point of view, backend is the the dialog showing you the progress of burning process, a software between the frontend and cd*tools. Yes. There are two separate things here: a real burning backend (which currently is cdrtools/cdrkit and in the end should probably be libburn) and a base UI. NCB doesn't even support your cdrkit it still uses cdrecord so most of the distros need to symlink cdrecord-wodim which is a shame and shows that ncb needs update. Now, the question is: how many changes do we need in Brasero and other applications/libraries to achieve the goal of a flexible burning framework for GNOME? IMO the quickest way is to extend n-c-b to add the features it is missing. Why extend ncb when you have a full featured application ? Where we can add the cdrkit and most important libburnia backend that is actually MAINTAINED and solves most of the burning problems on Linux. Sparse Notes: * IMHO currently brasero (as backend) is better then n-c-b, at least 'cause brasero provides multisession and blanking/formatting AFAIK n-c-b provides blanking. I should add here that brasero seems to have some stability issues (but it is something that should go away with time). Please point us a bug and we will do the best we can to fix the bug. * About the frontend I think could be good put burn:// location and brasero side by side in the desktop, having a simple Nautilus add-in to quickly burn stuff as well as a full featured (but not bloated) application What exactly can the brasero front-end do that n-c-b cannot? Shouldn’t it be something that we could add to the n-c-b burn dialog? What about the features that nowdays every user wants ? Brasero is using almost every GNOME technology to get the best experience. In terms of front end it's simple and easy to use. ___ 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 Wed, 2008-11-05 at 00:19 +0100, Josselin Mouette wrote: Le mardi 04 novembre 2008 à 21:19 +, Luis Medinas a écrit : On Tue, 2008-11-04 at 15:21 +0100, Josselin Mouette wrote: Yes. There are two separate things here: a real burning backend (which currently is cdrtools/cdrkit and in the end should probably be libburn) and a base UI. NCB doesn't even support your cdrkit it still uses cdrecord so most of the distros need to symlink cdrecord-wodim which is a shame and shows that ncb needs update. Currently we can just patch n-c-b to that effect, it is really a minor annoyance. Of course it would be better to make it support both. Other backend that should be implemented is libburnia that imo will save the current status of burning on Linux (i said it previously). IMO the quickest way is to extend n-c-b to add the features it is missing. Why extend ncb when you have a full featured application ? Because ncb has the correct architecture to integrate into applications. If you want to do the same with brasero, you’ll end up redeveloping part of it. Yes NCB integrates better since it's contains a library that makes easier to do it but you can see the brasero can also offer this integration via nautilus and some media players that are also using it. What exactly can the brasero front-end do that n-c-b cannot? Shouldn’t it be something that we could add to the n-c-b burn dialog? What about the features that nowdays every user wants ? Which features exactly? Videocd, Videodvd, normalize audiotracks, cdtext, preview, cd covers etc... Brasero is using almost every GNOME technology to get the best experience. In terms of front end it's simple and easy to use. As a user, I find n-c-b much easier to use. At least, I’d like to see something similar to burn:/// remain, whatever solution is chosen. Brasero in svn trunk already supports burn://. 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
On Mon, 2008-11-03 at 23:48 +0100, Luca Ferretti wrote: The real issue IMHO is you can't launch brasero from burn:// location or eternal apps like Rhythmbox. This feature was landed svn trunk today that will be available on Brasero 0.8.3 (planned to be released tomorrow or next wednesday). From Rhythmbox the burning backend could be ported as parsing the playlist for the brasero commandline just like the other media players do. Or even with this burn:// . 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
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
On Sat, 2008-11-01 at 22:51 +0100, Andre Klapper wrote: Am Samstag, den 01.11.2008, 19:27 +0100 schrieb Philippe Rouquier: We'd be interested in having brasero integrated into the GNOME desktop. I'd like to see this too. :) How does Brasero *integrate* in the desktop? E.g. burning from Nautilus? From nautilus it's possible to open an iso, playlists and burn from the nautilus CD/DVD Creator. Are strings/wordings like Data disc, Video disc and Videodisk (ahem?) consistent with the terms used in gvfs? That needs review but we can easily fix this bugs. In general, the strings need of review. 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). 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 . Yes please, we need some help around here. andre Thanks 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
On Sat, 2008-11-01 at 23:07 +, Bastien Nocera wrote: 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. Having something like Brasero directly in the desktop would completely change the current usage pattern for burning, and copying discs. Either brasero should be trimmed so as to make it clear that nautilus-cd-burner is still the way to do easy CDs, or it should take over nautilus-cd-burner completely whilst offering the same functionality and integration. So, which way will you be taking brasero? The idea is to replace completely N-C-B it offers the same features and integration (besides the hardcoded link CD/DVD Creator on gnome-panel[1-2]), the same easy way to burn files and plus lot's of features that could be expected from a application like this. Currently besides nautilus, brasero is also the default burning application for Banshee and Exaile. Maybe Rhythmbox, Totem and lots of other apps could adopt it as well. [1] - http://bugzilla.gnome.org/show_bug.cgi?id=347648 [2] - http://bugzilla.gnome.org/show_bug.cgi?id=476423 ___ 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 00:33 +, Bastien Nocera wrote: On Sat, 2008-11-01 at 23:55 +, Luis Medinas wrote: On Sat, 2008-11-01 at 23:07 +, Bastien Nocera wrote: 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. Having something like Brasero directly in the desktop would completely change the current usage pattern for burning, and copying discs. Either brasero should be trimmed so as to make it clear that nautilus-cd-burner is still the way to do easy CDs, or it should take over nautilus-cd-burner completely whilst offering the same functionality and integration. So, which way will you be taking brasero? The idea is to replace completely N-C-B Did you talk to the nautilus-cd-burner devels about it? I guess not... No and it's something we should discuss because brasero inclusion would make N-C-B totally obsolete imho. 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. Well that depends of what gnome-panel developers want to do. There are a couple of options to fix this as discussed on those bugs. the same easy way to burn files and plus lot's of features that could be expected from a application like this. Currently besides nautilus, brasero is also the default burning application for Banshee and Exaile. Maybe Rhythmbox, Totem and lots of other apps could adopt it as well. Totem doesn't burn anything yet (though integration to get it to burn video-dvds or video-cds could be useful), and Rhythmbox use nautilus-cd-burner's libraries, not its interface (except for the simple copy cd functionality). Yes to make Rhythmbox use Brasero currently is to parse the playlists via cmd line like Banshee and Exaile. A Totem plugin for burning video stuff would be an interesting feature. I'd like to see some documentation (a Wiki page would be just fine), on what you want the usage pattern for CD burning to be (I'd be happy to write the current n-c-b usage pattern, along with how we want to behave in the near future[1]), but I wouldn't want Brasero to be accepted in the desktop until the integration and the usage pattern reach a better level. I think the current integration depends on other desktop modules not Brasero. We just need to discuss with the depending modules how should we improve the whole burning situation. We would be happy to start writing a draft. Cheers [1]: I'll take the executive way and fix: http://bugzilla.gnome.org/show_bug.cgi?id=119991#c25 once the dust has settled on 2.24. Thanks Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
