Re: 3.6 Feature: Totem - Videos
On 24/04/12 13:51, Luca Ferretti wrote: 2012/4/23 Bastien Nocerahad...@hadess.net: Work is on-going to make Totem into that: https://live.gnome.org/Design/Apps/Videos#Tentative_Design I like the mock ups. Looks cool, the only issue I can see is actual video files may have weird names (such as VID_20120424_123212.mp4 or [Freedom] Mobile Suit Gundam Unicorn - 03 (1920x1080 X264 AAC) Sub Ita.mp4) and I suspect there is no (simple) way to re-tag them. Not really. With Tracker on the N9 and earlier devices we attempted to put something in place to work around this, but it never catches all cases and depending on how you use that code can impact performance. Unfortunately, correct metadata/file names for media is something we will always battle, not just for videos, but also music, etc. I am also of the view that much of the video information (like the extension, the format, resolution, etc) is not really useful a lot of the time (especially to non-tech users) but should be available through some interface (menu, dialog, etc). -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On 25/04/12 23:38, Marina Zhurakhinskaya wrote: Hi! Hello, - have a limited number of status icons displayed I like everything I see from the mock ups with the exception of changing the network connection. If I am downloading something in the background, I really don't want someone to be able to come along and disrupt that without having login credentials. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Mon, 2012-04-30 at 10:50 +0100, Martyn Russell wrote: On 25/04/12 23:38, Marina Zhurakhinskaya wrote: Hi! Hello, - have a limited number of status icons displayed I like everything I see from the mock ups with the exception of changing the network connection. If I am downloading something in the background, I really don't want someone to be able to come along and disrupt that without having login credentials. And I don't think you'd be able to either. The status icon is probably a locked down one (and it's still useful to know how you're connected, and if you are). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing ostree
On Sun, Apr 29, 2012 at 12:56 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Hello fellow developers, I've recently tried ostree, the new project to build parallel operating systems in subfolders. I must say I like the idea, but I found a few problems with the current implementation, like missing packages or incompatibilities between the host system and the ostree. Since I'd really like to use it and replace jhbuild, is there a central place to coordinate development on ostree (in particular, on the gnome os part)? A mailing list would be the best. Also, where is defined what goes on ostree.gnome.org and when is it updated? Are there plans to add 3.6 branches? ostree is Colins playground; it is not quite ready for widespread use yet. I'm sure he will announce it more widely when he considers it ready. For now, https://live.gnome.org/OSTree is the best place to learn more about it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing ostree
On Sun, 2012-04-29 at 18:56 +0200, Giovanni Campagna wrote: Hello fellow developers, I've recently tried ostree, the new project to build parallel operating systems in subfolders. I appreciate the interest! But it's not yet at a state where I myself find it to be better (overall) than your traditional choices of jhbuild, sudo make install, or mashing git repositories into debs/rpms. I'll let interested parties know when I think it's reached that state, or is close enough. I must say I like the idea, but I found a few problems with the current implementation, like missing packages or incompatibilities between the host system and the ostree. What packages and incompatibilities? Since I'd really like to use it and replace jhbuild, is there a central place to coordinate development on ostree (in particular, on the gnome os part)? A mailing list would be the best. I'll request one. Also, where is defined what goes on ostree.gnome.org and when is it updated? Are there plans to add 3.6 branches? I'm personally working on a developer workflow, since it's a blocker for people contributing and using the system. See https://live.gnome.org/OSTree/Ostbuild/DeveloperWorkflow Once I have something reasonably sane here, I'll look at turning on 3.6 builds. And finally, a curiosity: what do downstreams say of ostree (if they are aware of it)? Did someone consider building a traditional distro on top of ostree, or is it something for developers / testers only? My primary goal for the next 6 months say is to simply have it as an option (alongside jhbuild) during the development process, in other words, from their view, nothing changes, except hopefully the tarballs uploaded are better tested, and some things become better defined, like what version of GCC and X.org is GNOME tested with?. Or at least, a concrete version they're tested with, in addition to current distribution releases. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
2012/4/27 Allan Day allanp...@gmail.com: On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. Wait. I never said to keep apart designers and developers. As communty we have the great advantage and opportunity to work together. But while some developers and some designers could need or like to be closer in order to produce a better software or experience, I believe it's also fair to let other contributors and community members to be well informed about what's happening and why. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. So, for example, as release team member, all I currently know about new Videos app proposal, based on availabe info on mailing list and wiki, is: * will resemble similar existing apps for tablets, but GNOME style * will use clutter APIs * will be developed inside totem source tree (replacing?) If I'm right there is no code yet available on git to check. I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Now, do I have to ping people involved or simply I've to trust them? Can we be helpful each other writing more informations (neither final in stone, nor iperdetailed, just more) somewhere? Or a different proposal path (the one suggested by Rodrigo, for instace) could be more effective? Cheers, Luca [1] https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00135.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: 2012/4/27 Allan Day allanp...@gmail.com: On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. Wait. I never said to keep apart designers and developers. As communty we have the great advantage and opportunity to work together. But while some developers and some designers could need or like to be closer in order to produce a better software or experience, I believe it's also fair to let other contributors and community members to be well informed about what's happening and why. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. So, for example, as release team member, all I currently know about new Videos app proposal, based on availabe info on mailing list and wiki, is: * will resemble similar existing apps for tablets, but GNOME style * will use clutter APIs Totem already uses Clutter. * will be developed inside totem source tree (replacing?) Yes. I think both the feature page and the mail to this list made it pretty clear, even if glibly. If I'm right there is no code yet available on git to check. All the code that's been written is available in master. The new optical media plugin for grilo is in grilo-plugins master, the merge into the video widget of the OSD is done is in totem master, etc. I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. And the reason why I did not answer your mail is because the questions were already answered in my original mail. Now, do I have to ping people involved or simply I've to trust them? Can we be helpful each other writing more informations (neither final in stone, nor iperdetailed, just more) somewhere? Or a different proposal path (the one suggested by Rodrigo, for instace) could be more effective? Cheers, Luca [1] https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00135.html ___ 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: Design in the open
On Mon, 2012-04-30 at 16:36 +0100, Bastien Nocera wrote: On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. I don't think it's a matter of blocking the will of the designers or developers. The release team should, of course, follow the consensus of the community. But we do need to be able to judge whether the implementation is up to standards for inclusion. It's not a matter of saying We won't include this feature. It's a matter of saying This feature is not ready yet. The problem with the feature proposal process is that we're approving wiki pages. But implementation matters. We have something like three months before we start hitting freezes. That's not a lot of time, and sometimes we just can't do everything we'd like. I'm not opposed to feature proposals, but I think they need to come with a detailed proposal for implementation, including all necessary new dependencies, and a deadline by which the release team can judge the implementation, not the design. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Mon, 2012-04-30 at 12:05 -0400, Shaun McCance wrote: On Mon, 2012-04-30 at 16:36 +0100, Bastien Nocera wrote: On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. I don't think it's a matter of blocking the will of the designers or developers. The release team should, of course, follow the consensus of the community. But we do need to be able to judge whether the implementation is up to standards for inclusion. It's not a matter of saying We won't include this feature. It's a matter of saying This feature is not ready yet. That's fair. Fedora already has a tick for that particular part of the process. It's the Contingency plan section: http://fedoraproject.org/wiki/Features/Policy/Proposals In Videos' case, if it looks like a finished version won't make it in time, we'll fork a 3.6 branch from 3.4, cherry-pick the most interesting and tested changes, and ship that as 3.6. The problem with the feature proposal process is that we're approving wiki pages. But implementation matters. We have something like three months before we start hitting freezes. That's not a lot of time, and sometimes we just can't do everything we'd like. I'm not opposed to feature proposals, but I think they need to come with a detailed proposal for implementation, including all necessary new dependencies, and a deadline by which the release team can judge the implementation, not the design. If we wanted to be able to judge the implementations when the feature proposals are made, then we'd need to push them all back 6 months. I'm not sure how we get to a discussion about the feature process in a thread called design in the open though... Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing ostree
On Mon, 2012-04-30 at 10:41 -0400, Colin Walters wrote: Since I'd really like to use it and replace jhbuild, is there a central place to coordinate development on ostree (in particular, on the gnome os part)? A mailing list would be the best. I'll request one. https://mail.gnome.org/mailman/listinfo/ostree-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
