Hey,
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
Matthias
On 03/13/2010 09:57 AM, Matthias Clasen wrote:
Hey,
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
Does it replace only Gthumb or F-Spot as well?
Rahul
On Sun, 2010-03-14 at 13:22 +0530, Rahul Sundaram wrote:
On 03/13/2010 09:57 AM, Matthias Clasen wrote:
Hey,
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
Does it replace only Gthumb or F-Spot as well?
All I have done is move gthumb from default to optional in the gnome-desktop group, and move shotwell the other way.
f-spot is not on the desktop spin anyway.
On 03/14/2010 06:08 PM, Matthias Clasen wrote:
All I have done is move gthumb from default to optional in the gnome-desktop group, and move shotwell the other way.
f-spot is not on the desktop spin anyway.
Yes, I am aware of that but the question was related to the regular installation DVD/ CD set where if you pick the defaults, you will end up with both Shotwell and F-Spot, right? There seems to be significant amount of overlap between those and I am wondering if that makes sense or whether we should pick Shotwell alone.
Rahul
On Sun, 2010-03-14 at 18:42 +0530, Rahul Sundaram wrote:
On 03/14/2010 06:08 PM, Matthias Clasen wrote:
All I have done is move gthumb from default to optional in the gnome-desktop group, and move shotwell the other way.
f-spot is not on the desktop spin anyway.
Yes, I am aware of that but the question was related to the regular installation DVD/ CD set where if you pick the defaults, you will end up with both Shotwell and F-Spot, right? There seems to be significant amount of overlap between those and I am wondering if that makes sense or whether we should pick Shotwell alone.
We don't really control or design the 'regular installation' in any form.
On 03/14/2010 07:40 PM, Matthias Clasen wrote:
Yes, I am aware of that but the question was related to the regular installation DVD/ CD set where if you pick the defaults, you will end up with both Shotwell and F-Spot, right? There seems to be significant amount of overlap between those and I am wondering if that makes sense or whether we should pick Shotwell alone.
We don't really control or design the 'regular installation' in any form.
You can modify the comps groups though.
Rahul
On 03/14/2010 07:40 PM, Matthias Clasen wrote:
Yes, I am aware of that but the question was related to the regular installation DVD/ CD set where if you pick the defaults, you will end up with both Shotwell and F-Spot, right? There seems to be significant amount of overlap between those and I am wondering if that makes sense or whether we should pick Shotwell alone.
We don't really control or design the 'regular installation' in any form.
To expand on what I said earlier, all you need do is to edit the comps file based on the defaults you want for certain groups and if those are not the groups, you control and in this case I think you do, the procedure is outlined in
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou...
In short, if users are going to end up two programs that have a broad overlap in functionality, we need to fix that.
Rahul
On Tue, 2010-03-16 at 01:53 +0530, Rahul Sundaram wrote:
On 03/14/2010 07:40 PM, Matthias Clasen wrote:
Yes, I am aware of that but the question was related to the regular installation DVD/ CD set where if you pick the defaults, you will end up with both Shotwell and F-Spot, right? There seems to be significant amount of overlap between those and I am wondering if that makes sense or whether we should pick Shotwell alone.
We don't really control or design the 'regular installation' in any form.
To expand on what I said earlier, all you need do is to edit the comps file based on the defaults you want for certain groups and if those are not the groups, you control and in this case I think you do, the procedure is outlined in
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_grou...
In short, if users are going to end up two programs that have a broad overlap in functionality, we need to fix that.
I know what comps is, and I have edited the gnome-desktop group to reflect the change for the desktop spin.
But as I said earlier, nobody is in charge of designing the DVD install. Just making some undirected changes to comps groups is not a fix for this problem.
On 03/16/2010 02:47 AM, Matthias Clasen wrote:
I know what comps is, and I have edited the gnome-desktop group to reflect the change for the desktop spin.
But as I said earlier, nobody is in charge of designing the DVD install. Just making some undirected changes to comps groups is not a fix for this problem
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
Alternatively, if noone is responsible for it, why are we still doing it?
Rahul
On Tue, Mar 16, 2010 at 02:52:56AM +0530, Rahul Sundaram wrote:
On 03/16/2010 02:47 AM, Matthias Clasen wrote:
I know what comps is, and I have edited the gnome-desktop group to reflect the change for the desktop spin.
But as I said earlier, nobody is in charge of designing the DVD install. Just making some undirected changes to comps groups is not a fix for this problem
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
Alternatively, if noone is responsible for it, why are we still doing it?
Correction to above -- actually, direct download numbers I pull from the HTTP logs show that the Desktop Live image far outnumber the DVD. Mo's survey shows that the majority of respondents to her survey continue to download the DVD image. :-)
On 03/17/2010 09:26 PM, Paul W. Frields wrote:
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
Alternatively, if noone is responsible for it, why are we still doing it?
Correction to above -- actually, direct download numbers I pull from the HTTP logs show that the Desktop Live image far outnumber the DVD. Mo's survey shows that the majority of respondents to her survey continue to download the DVD image. :-)
Sorry but I don't see the correction. Aren't you agreeing with on Mo's survey?
Rahul
On Wed, Mar 17, 2010 at 10:10:52PM +0530, Rahul Sundaram wrote:
On 03/17/2010 09:26 PM, Paul W. Frields wrote:
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
Alternatively, if noone is responsible for it, why are we still doing it?
Correction to above -- actually, direct download numbers I pull from the HTTP logs show that the Desktop Live image far outnumber the DVD. Mo's survey shows that the majority of respondents to her survey continue to download the DVD image. :-)
Sorry but I don't see the correction. Aren't you agreeing with on Mo's survey?
I'm saying that like most surveys that aren't truly random, you can't rely on its results as representing anything about all our users. The intentions of the survey as I recall were to find out what lots of people in some core communities -- the people who would see it on Planet Fedora and Planet GNOME -- were doing as far as downloads and installations go. So that's why I said, it shows something about the majority of respondents to the survey, not the majority of users in general. That was why I brought up HTTP logs, which give objective results about what people are downloading directly.
Although BitTorrent stats lean toward the DVD, the number of weekly direct downloads is much higher than BitTorrent, bringing the ratio back far in favor of the Live image.
On 03/17/2010 11:43 PM, Paul W. Frields wrote:
. Although BitTorrent stats lean toward the DVD, the number of weekly direct downloads is much higher than BitTorrent, bringing the ratio back far in favor of the Live image.
Only if you discount the fact that most magazines tend to distribute DVD images and atleast in India, that's how Fedora users get their copies of Fedora. Downloads don't tell you all of the details.
Rahul
On Wed, Mar 17, 2010 at 11:50:23PM +0530, Rahul Sundaram wrote:
On 03/17/2010 11:43 PM, Paul W. Frields wrote:
. Although BitTorrent stats lean toward the DVD, the number of weekly direct downloads is much higher than BitTorrent, bringing the ratio back far in favor of the Live image.
Only if you discount the fact that most magazines tend to distribute DVD images and atleast in India, that's how Fedora users get their copies of Fedora. Downloads don't tell you all of the details.
Good point -- do you have circulation numbers for those magazines that I could figure into our statistics/reports?
On 03/19/2010 08:04 AM, Paul W. Frields wrote:
Good point -- do you have circulation numbers for those magazines that I could figure into our statistics/reports?
LFY was well over 50000 copies all over Asia last I heard. I don't have any detailed stats on rest of the magazines. We could get them by contacting the magazines on a individual basis but that isn't the only factor to consider. There are folks who skip the mirror list entirely and just go to one mirror that they know is fast for them based on the past experience. Many organizations and even colleges here have a single local mirror where hundreds or thousands of people get their local copies from. None of our methods (smolt, ip counts) have a way to differentiate between what method the users choose to use and whether we can change that is something to think about. .
Rahul
On 03/17/2010 08:13 PM, Paul W. Frields wrote:
Although BitTorrent stats lean toward the DVD, the number of weekly direct downloads is much higher than BitTorrent, bringing the ratio back far in favor of the Live image.
My assumption is that a good part of those downloading the Live image are doing this only to see what is about in that new Fedora thingy and a good part of those downloading the DVD image are doing so because they want to install and use it.
You may count the downloads, not caring what happen with them after or you may try to learn how the people actually using Fedora got to install it.
PS: when I directly download an image, I do it by directly accessing a local mirror, a download not counted by our system.
On Tue, 2010-03-16 at 02:52 +0530, Rahul Sundaram wrote:
On 03/16/2010 02:47 AM, Matthias Clasen wrote:
I know what comps is, and I have edited the gnome-desktop group to reflect the change for the desktop spin.
But as I said earlier, nobody is in charge of designing the DVD install. Just making some undirected changes to comps groups is not a fix for this problem
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
You can take the state of affairs that many people are downloading the DVD image as saying two different things - first that we need to make the DVD image experience better, or second that we need to discourage people from it better.
If you go with the first approach, then you quickly get to the question of what the DVD image experience is supposed to be.
It woud be great if you didn't touch any knobs, the DVD installer gave you exactly the same bits as the Desktop live image (but more slowly). Why should you have to choose between btrfs and a package set that has been selected with care?
However, to me there seems to be significant hurdles to that vision:
* There would have to be community-wide buy-in to that idea to begin with. That people aren't going to flame when xsane, and minicom, and system-config-boot (and so forth and so on) are removed from comps and nss-mdns is added.
* There would have to be community-wide buy-in to the idea that the settings that are packaged are the settings that make sense for the desktop, and an server install done through the Anaconda GUI might have a few settings that need modification.
How are people (include the openssh package maintainer) going to react if sshd packaging is changed to disable the service by default?
With the current situation - if something could either be added to @gnome-desktop in compos or directly to the live CD kickstart, sure it makes sense to do it in @gnome-desktop. But nobody is paying close attention to what you get when you install off the DVD image and nobody even agrees on what you *should* get.
So, my feeling is that right now if you need a DVD with a somewhat arbitrarily selected subset of the Fedora packages on it because you want to kickstart a machine with no network, then download the DVD. And it's a fine alternative to pre-upgrade if you have limited bandwidth and your friend has a lot of bandwidth. But you are doing a fresh install of Fedora on a laptop or desktop computer, there is one right answer - the live image.
- Owen
On 03/18/2010 06:30 PM, Owen Taylor wrote:
There would have to be community-wide buy-in to that idea to begin with. That people aren't going to flame when xsane, and minicom, and system-config-boot (and so forth and so on) are removed from comps and nss-mdns is added.
There would have to be community-wide buy-in to the idea that the settings that are packaged are the settings that make sense for the desktop, and an server install done through the Anaconda GUI might have a few settings that need modification.
How are people (include the openssh package maintainer) going to react if sshd packaging is changed to disable the service by default?
You will never know unless someone explains what is being needed and propose such changes. I am not sure you can convince everyone to go with the live dvd image instead at this point and I think we need to be able to tweak the comps with small changes when it has good benefits without thinking about tackling all the issues at the same time. There are good points being raised but ignoring the regular dvd installation experience doesn't seem like the right answer yet.
So bring it to down to a single item that I want to see happen, any objections to me making f-spot a optional package in the graphics group for Fedora 13?
Rahul
On Thu, 2010-03-18 at 18:35 +0530, Rahul Sundaram wrote:
So bring it to down to a single item that I want to see happen, any objections to me making f-spot a optional package in the graphics group for Fedora 13?
None here. It might be the last mono needing item on the default DVD install.
On 03/18/2010 10:08 PM, Jesse Keating wrote:
On Thu, 2010-03-18 at 18:35 +0530, Rahul Sundaram wrote:
So bring it to down to a single item that I want to see happen, any objections to me making f-spot a optional package in the graphics group for Fedora 13?
None here. It might be the last mono needing item on the default DVD install.
I have added shotwell as a default package and made f-spot a optional package in graphics group for Fedora 13. Updated the desktop beat
https://fedoraproject.org/wiki/Documentation_Desktop_Beat
Rahul
On Thu, 2010-03-18 at 09:00 -0400, Owen Taylor wrote:
On Tue, 2010-03-16 at 02:52 +0530, Rahul Sundaram wrote:
On 03/16/2010 02:47 AM, Matthias Clasen wrote:
I know what comps is, and I have edited the gnome-desktop group to reflect the change for the desktop spin.
But as I said earlier, nobody is in charge of designing the DVD install. Just making some undirected changes to comps groups is not a fix for this problem
The current DVD image is basically defined by comps and if you edit comps, you can control the result and since rel-eng does the compose, aren't they responsible for it? If not, how do we fix it? We cannot just ignore that experience. The desktop live image despite being the default doesn't cover a bunch of use cases (ability to select a different package set or even a different filesystem for example) and Mo's survey shows that the majority of users continue to download the DVD image and while taking the step of moving to a large image and offering a better out of box experience solves some of that, it doesn't make the proble go away.
You can take the state of affairs that many people are downloading the DVD image as saying two different things - first that we need to make the DVD image experience better, or second that we need to discourage people from it better.
If you go with the first approach, then you quickly get to the question of what the DVD image experience is supposed to be.
It woud be great if you didn't touch any knobs, the DVD installer gave you exactly the same bits as the Desktop live image (but more slowly). Why should you have to choose between btrfs and a package set that has been selected with care?
However, to me there seems to be significant hurdles to that vision:
There would have to be community-wide buy-in to that idea to begin with. That people aren't going to flame when xsane, and minicom, and system-config-boot (and so forth and so on) are removed from comps and nss-mdns is added.
There would have to be community-wide buy-in to the idea that the settings that are packaged are the settings that make sense for the desktop, and an server install done through the Anaconda GUI might have a few settings that need modification.
How are people (include the openssh package maintainer) going to react if sshd packaging is changed to disable the service by default?
With the current situation - if something could either be added to @gnome-desktop in compos or directly to the live CD kickstart, sure it makes sense to do it in @gnome-desktop. But nobody is paying close attention to what you get when you install off the DVD image and nobody even agrees on what you *should* get.
So, my feeling is that right now if you need a DVD with a somewhat arbitrarily selected subset of the Fedora packages on it because you want to kickstart a machine with no network, then download the DVD. And it's a fine alternative to pre-upgrade if you have limited bandwidth and your friend has a lot of bandwidth. But you are doing a fresh install of Fedora on a laptop or desktop computer, there is one right answer - the live image.
- Owen
Personally I would really like the experience you get after installing from live and the experience you get after installing (default) from DVD to be the same, or as close to the same as we can make it. It would make sense to drive this effort for F14 and start looking at the differences and how they can be resolved, while still allowing the choose your own adventure folks to have a reasonably good experience as well.
A re-focus of the DVD offering has been long overdue and I'll be right there to help with the effort if we do this for F14.
On Thu, Mar 18, 2010 at 12:40 PM, Jesse Keating jkeating@redhat.com wrote:
Personally I would really like the experience you get after installing from live and the experience you get after installing (default) from DVD to be the same, or as close to the same as we can make it. It would make sense to drive this effort for F14 and start looking at the differences and how they can be resolved, while still allowing the choose your own adventure folks to have a reasonably good experience as well.
I 100% agree with this. I've added it to my plate, since I've been a broken record about it in the past.
On 03/18/2010 04:40 PM, Jesse Keating wrote:
A re-focus of the DVD offering has been long overdue and I'll be right there to help with the effort if we do this for F14.
Has rel-eng defined it's target audience with the DVD Spin?
Is it going to be made up of the desktops spins essentially containing the live bits of Gnome KDE XFCE LXDE and thus be a image that includes preview of each desktop the project offers?
Is it going to target more corporate/mass deployment desktop workstation installs ( One Desktop including office and bits more commonly used in corporate environments?
Is it going to target SysAdmins and consisting a bunch of tools and service?
Is it going to target Developers and thus consist of one Desktop and bunch of devel bits?
For instance what is the criteria to get stuff on the DVD spin as in what do DE and other SIG need to do to get bits include on the image?
JBG
On Thu, 2010-03-18 at 17:40 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/18/2010 04:40 PM, Jesse Keating wrote:
A re-focus of the DVD offering has been long overdue and I'll be right there to help with the effort if we do this for F14.
Has rel-eng defined it's target audience with the DVD Spin?
No, that's not really our right. We compose and deliver the product, as defined by more appropriate folks, like the Board or FESCo.
Is it going to be made up of the desktops spins essentially containing the live bits of Gnome KDE XFCE LXDE and thus be a image that includes preview of each desktop the project offers?
Is it going to target more corporate/mass deployment desktop workstation installs ( One Desktop including office and bits more commonly used in corporate environments?
Is it going to target SysAdmins and consisting a bunch of tools and service?
Is it going to target Developers and thus consist of one Desktop and bunch of devel bits?
For instance what is the criteria to get stuff on the DVD spin as in what do DE and other SIG need to do to get bits include on the image?
In the past, the answer to all of these was "yes". The DVD tried to be everything to everybody, because it came from the Red Hat Linux days where everything could fit on the DVD. When we merged core/extras we didn't change the DVD much, and still haven't. So for now, I don't have an answer for the above, other than the Fedora Board has defined a target audience, and our (default) offerings should cater to that target audience as best it can.
On 03/13/2010 06:27 AM, Matthias Clasen wrote:
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
I am not on Rawhide yet (I have a ton of things to do these days and can't afford to do this) but checked the website (http://trac.yorba.org/wiki/UsingShotwell0.5) to learn a bit about it.
For me Shotwell fails the usefulness test very quickly as it has to "import" the photos, by copying them in the Pictures dir on my home. For me this is unworkable, as having tens of thousands of photos, summing hundreds of GB stored on external drives, I need to keep the files into place.
It would also be not useful for a photographer organizing and keeping his photos on DVDs, as many do... it would be a lot more useful if the application keep the image files into the original place and only create a database of filenames and metadata (but for that we don't have tracker?)
This is also a problem when the user will launch the application from Live media, as the Desktop spin is, in many cases he won't have persistent write access to /home so the import in Pictures will be only temporary (and limited in size).
In my opinion, if eog would have a few editing features, then a combination of eog, nautilus and tracker would do anything that shotwell do. But this is just my opinion, I use "photo organizers" very little, my workflow is like this: organizing with Nautilus and eog, a few custom imagemacick scripts to help with organizing and editing, gthumb *only* for its nice "create web album" feature and Gimp for *everything* else.
In my opinion, if eog would have a few editing features, then a combination of eog, nautilus and tracker would do anything that shotwell do.
I do not intend to hijack this thread, but you can probably try out Solang some time. It fetches all the meta-data (ie. tags, Exif, etc.) from Tracker. So there is no need to import anything.
Right now the editing features are not too good as we want to implement them using GEGL, which is still not mature. That way it becomes easy to implement a RAW processing pipeline and we do not want to do it the way F-Spot does it now. It is still under heavy development and definitely not feature complete, so ... :-)
Cheers, Debarshi
On Mon, 2010-03-15 at 16:57 +0200, Debarshi Ray wrote:
In my opinion, if eog would have a few editing features, then a combination of eog, nautilus and tracker would do anything that shotwell do.
I do not intend to hijack this thread, but you can probably try out Solang some time.
Let me hijack it back...I noticed the other day that solang is not present in comps at all. Maybe you should add it.
On Mon, 2010-03-15 at 13:50 +0200, Nicu Buculei wrote:
On 03/13/2010 06:27 AM, Matthias Clasen wrote:
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
I am not on Rawhide yet (I have a ton of things to do these days and can't afford to do this) but checked the website (http://trac.yorba.org/wiki/UsingShotwell0.5) to learn a bit about it.
For me Shotwell fails the usefulness test very quickly as it has to "import" the photos, by copying them in the Pictures dir on my home. For me this is unworkable, as having tens of thousands of photos, summing hundreds of GB stored on external drives, I need to keep the files into place.
I haven't given it a shot either, but... I just cannot help but remind you of mount --bind... But more seriously -- If you read the page more throughout you'd know it actually does not need to copy the photos to ~/Pictures:
" If you hold down Ctrl+Shift while dragging photos in, Shotwell will import the photos without copying them."
But indeed, at the very least on live spin, the default behaviour should be to import the photos *without* copying them.
Regards, Martin
On 03/15/2010 05:25 PM, Martin Sourada wrote:
On Mon, 2010-03-15 at 13:50 +0200, Nicu Buculei wrote:
For me Shotwell fails the usefulness test very quickly as it has to "import" the photos, by copying them in the Pictures dir on my home. For me this is unworkable, as having tens of thousands of photos, summing hundreds of GB stored on external drives, I need to keep the files into place.
I haven't given it a shot either, but... I just cannot help but remind you of mount --bind... But more seriously -- If you read the page more throughout you'd know it actually does not need to copy the photos to ~/Pictures:
" If you hold down Ctrl+Shift while dragging photos in, Shotwell will import the photos without copying them."
I am sorry, I read the page extremely briefly I am swamped with a taks somewhat related to the topic: have a massive photo set (over 3500 images) made over the last week-end and try to put some sanity into it (so I *do* care about managing photos).
But indeed, at the very least on live spin, the default behaviour should be to import the photos *without* copying them.
On Fri, 2010-03-12 at 23:27 -0500, Matthias Clasen wrote:
Hey,
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
I just tried uploading a picture to Facebook, creating a new album named 'Miscellaneous'. It created the album, but didn't upload the picture, as far as facebook.com claims. I tried several times and it never worked. Uploading a smaller version of the picture via the Facebook web site worked.
I wonder if it was too big? It's a 2MB, 10 megapixel image. Anyone know if Facebook has a limit?
On Tue, Mar 23, 2010 at 3:17 AM, Adam Williamson awilliam@redhat.com wrote:
I just tried uploading a picture to Facebook, creating a new album named 'Miscellaneous'. It created the album, but didn't upload the picture, as far as facebook.com claims. I tried several times and it never worked. Uploading a smaller version of the picture via the Facebook web site worked.
I wonder if it was too big? It's a 2MB, 10 megapixel image. Anyone know if Facebook has a limit?
I am on F12, build from srpm [1], uploaded a 4MB file of 10.2 megapixel to facebook.
[1] http://kojipkgs.fedoraproject.org/packages/shotwell/0.5.0/1.fc13/src/shotwel...
Kushal
On Sat, Mar 13, 2010 at 9:57 AM, Matthias Clasen mclasen@redhat.com wrote:
Hey,
I've just built shotwell 0.5 for F13, the build should show up in updates-testing in a bit. This is the release that has all the features that we wanted when we decided to make it the default photo app in the desktop spin: upload to various web services, printing, tagging, etc.
It would be great if the photo-minded among us could give it some testing.
Also, I can not find the Editing options as given in the website "exposure, saturation, tint, and temperature" in shotwell, may be because I am in F12. Can someone please verify this ?
Kushal
On Tue, Mar 23, 2010 at 10:37 AM, Kushal Das kushaldas@gmail.com wrote:
Also, I can not find the Editing options as given in the website "exposure, saturation, tint, and temperature" in shotwell, may be because I am in F12. Can someone please verify this ?
Found them :)
Kushal
desktop@lists.fedoraproject.org