|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Ristretto 1.0 - Functional Requirements (1/3)Hi guys,
After a couple of years of development, I am getting tired of the ad-hoc hacker style development model I have been using for ristretto. This development model was the cause of several issues which were not easy to solve. - Returning bugs (memory usage, thumbnails, slow UI) - Constant rewrites whenever a new feature was being worked on - and a few other things... When this keeps happening, the fun of coding tends to go away... To prevent that stuff from happening again, I have decided to first put up a decent specification of what Ristretto should do and how it should look like(1/3), then actually make a proper design based on those specifications(2/3) and finally start coding (3/3). You can find a mockup of the functional specification document for Ristretto 1.0 on the wiki[0]. I would like you all to look at the specification, and if you have any suggestions on features and functionality, please post them on this list. Then we can discuss the direction that the development of Ristretto is going to take. Kind regards, Stephan Arts [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 10:51 AM, Stephan Arts <stephan@...> wrote: Hi guys, Well... If you are allowing the user to rotate the image himself, then that already is a form of editing, just without saving the edits. Perhaps it would be less confusing if you also provided the user with the option to save the rotation, warn the user that his changes *aren't* saved, or disallow manual rotation in general (I don't think this is a good option, of course, but as the alternative does entail editing, I'd say that you might as well let the user save those edits). Oh, and it'd be nice if the "Set as wallpaper" option is only available if this is actually possible (i.e. xfdesktop is used). And finally, perhaps it is confusing to put the navigation bar on the bottom (with the left and right arrows) when the thumbnails are listed vertically on the right (so clicking right will skip to the image below). Not sure if that's how you designed it to look, but if it is, then that might not be a good idea ;-) Best, -- Vincent _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Stephan Arts wrote:
> Hi guys, > > After a couple of years of development, I am getting tired of the > ad-hoc hacker style development model I have been using for ristretto. > This development model was the cause of several issues which were not > easy to solve. > > - Returning bugs (memory usage, thumbnails, slow UI) > - Constant rewrites whenever a new feature was being worked on > - and a few other things... > > When this keeps happening, the fun of coding tends to go away... > > To prevent that stuff from happening again, I have decided to first > put up a decent specification of what Ristretto should do and how it > should look like(1/3), then actually make a proper design based on > those specifications(2/3) and finally start coding (3/3). > > You can find a mockup of the functional specification document for > Ristretto 1.0 on the wiki[0]. > > I would like you all to look at the specification, and if you have any > suggestions on features and functionality, please post them on this > list. Then we can discuss the direction that the development of > Ristretto is going to take. > > Kind regards, > Stephan Arts > > [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 Thanks for taking the initiative to ask for user input. So I have had some thoughts on this in the past. What makes gqview good. It has very vast rendering in a way it show partial image as soon as possible and increases the quality later this is great. It also has to remember the mode the image is shown, fit, full, zoomed, rotated. What I would like from ristretto is very basis controls and some smart exif rotations. Toolbar on the top and no thumbnail previews. I want to be possible to browse 4MB pictures as fast as possible with usability for myself as expert user but also for people with very very limited computer experience. Beside this it needs a good simple printing feature users want there picture to be able to print as simple as possible, maybe the mac or windows default wizards can show some reference models. I also use the app to give picture presentations, so preloading in memory options, and back and forward with up down keys and full screen options. Hope this give you some pointers, Best regards, Jelle de Jong _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Hi,
How about deleting an image? I've found this as a major shortcoming of Ristretto, that while watching a set of photos, I can't delete some of them right away. I noticed that there is an icon which could look like an delete icon in mockup section, so maybe it is already planned / existing feature, but at least in version 0.0.22 there isn't (which I do have in Arch Linux). The other feature that could be very useful, is sorting / grouping images by date - like Google Picasa does it. If I remember correctly, DigiKam does something similar - it can show images in calendar view. I can pick a day and see which images are taken in that day. I'm not reallt sure how it should be implemented at the moment - Picasa does index the images before and DigiKam needs to import images aswell before - but if the feature is considered worth implementing, then I hope we can think up some nice way to that. best regards Rain Viigipuu _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Hi Stephen,
On Sat, Jul 4, 2009 at 05:51, Stephan Arts<stephan@...> wrote: > You can find a mockup of the functional specification document for > Ristretto 1.0 on the wiki[0]. I think this is a good idea, and thanks for starting up a discussion around it. One section I didn't find clear was "Export collections". Could you explain how Ristretto will store a collection and how users will manage these? -Diego _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 8:15 PM, Diego Ongaro<ongardie@...> wrote:
> Hi Stephen, > > On Sat, Jul 4, 2009 at 05:51, Stephan Arts<stephan@...> wrote: >> You can find a mockup of the functional specification document for >> Ristretto 1.0 on the wiki[0]. > > I think this is a good idea, and thanks for starting up a discussion around it. > > One section I didn't find clear was "Export collections". Could you > explain how Ristretto will store a collection and how users will > manage these? I am not quite sure how to do this either. It could be done as followed, I think: A playlist-like file, or XML file (depending on the extra metadata you want to put in) could be stored to disk somewhere, referencing all the images you want to be in your collection: <?xml version="1.0"?> <collection name="Joe's first birthday"> <description>Pictures of Joe's first birthday</description> <image uri="file://path/to/file_1.png"/> <image uri="file://path/to/file_2.png"/> <image uri="file://path/to/file_3.png"/> <image uri="file://path/to/file_4.png"/> </collection> These could be stored in the users home-dir and opened by ristretto. It's just a thought, I am personally getting tired of the folders with > 500 pictures whenever I empty my CF-cards. :-) What do you think? Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 5:49 PM, Rain Viigipuu<rain.viigipuu@...> wrote:
> Hi, > > How about deleting an image? I've found this as a major shortcoming of > Ristretto, that while watching a set of photos, I can't delete some of > them right away. > > I noticed that there is an icon which could look like an delete icon > in mockup section, so maybe it is already planned / existing feature, > but at least in version 0.0.22 there isn't (which I do have in Arch > Linux). This is already available in git. And yes, the mockup contains that image because it's picked from a screenshot of that version. It is still missing from the document-description though, I'll fix that. > The other feature that could be very useful, is sorting / grouping > images by date - like Google Picasa does it. If I remember correctly, > DigiKam does something similar - it can show images in calendar view. > I can pick a day and see which images are taken in that day. I'm not > reallt sure how it should be implemented at the moment - Picasa does > index the images before and DigiKam needs to import images aswell > before - but if the feature is considered worth implementing, then I > hope we can think up some nice way to that. I think we could see that as a complicated version of sorting by date. Which is mentioned in the document. I can see why you want this, but a timeline widget might be a little out-of-scope for the time being, we'll see. Do you have any suggestions on how it would look (without cluttering the interface)? - Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 2:18 PM, Vincent<mailinglists@...> wrote:
> > > On Sat, Jul 4, 2009 at 10:51 AM, Stephan Arts <stephan@...> wrote: >> >> Hi guys, >> >> After a couple of years of development, I am getting tired of the >> ad-hoc hacker style development model I have been using for ristretto. >> This development model was the cause of several issues which were not >> easy to solve. >> >> - Returning bugs (memory usage, thumbnails, slow UI) >> - Constant rewrites whenever a new feature was being worked on >> - and a few other things... >> >> When this keeps happening, the fun of coding tends to go away... >> >> To prevent that stuff from happening again, I have decided to first >> put up a decent specification of what Ristretto should do and how it >> should look like(1/3), then actually make a proper design based on >> those specifications(2/3) and finally start coding (3/3). >> >> You can find a mockup of the functional specification document for >> Ristretto 1.0 on the wiki[0]. >> >> I would like you all to look at the specification, and if you have any >> suggestions on features and functionality, please post them on this >> list. Then we can discuss the direction that the development of >> Ristretto is going to take. >> >> Kind regards, >> Stephan Arts >> >> >> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 > > > Well... If you are allowing the user to rotate the image himself, then that > already is a form of editing, just without saving the edits. Perhaps it > would be less confusing if you also provided the user with the option to > save the rotation, warn the user that his changes *aren't* saved, or > disallow manual rotation in general (I don't think this is a good option, of > course, but as the alternative does entail editing, I'd say that you might > as well let the user save those edits). I disagree, rotation just changes the way the image is displayed. When I place a printed photo on my desk, and I rotate it, nothing really changes to the image. I just look at it differently. > > Oh, and it'd be nice if the "Set as wallpaper" option is only available if > this is actually possible (i.e. xfdesktop is used). You mean remove it instead of disabling it? Yeah, good idea. > > And finally, perhaps it is confusing to put the navigation bar on the bottom > (with the left and right arrows) when the thumbnails are listed vertically > on the right (so clicking right will skip to the image below). Not sure if > that's how you designed it to look, but if it is, then that might not be a > good idea ;-) I agree with you there, I think the thumbnail-bar should be movable (top, bottom, left and right) Pretty much as it is today, but more intuitive and flexible. By DnD maybe? Do you have any ideas? - Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 4:48 PM, Jelle de Jong<jelledejong@...> wrote:
> Stephan Arts wrote: >> Hi guys, >> >> After a couple of years of development, I am getting tired of the >> ad-hoc hacker style development model I have been using for ristretto. >> This development model was the cause of several issues which were not >> easy to solve. >> >> - Returning bugs (memory usage, thumbnails, slow UI) >> - Constant rewrites whenever a new feature was being worked on >> - and a few other things... >> >> When this keeps happening, the fun of coding tends to go away... >> >> To prevent that stuff from happening again, I have decided to first >> put up a decent specification of what Ristretto should do and how it >> should look like(1/3), then actually make a proper design based on >> those specifications(2/3) and finally start coding (3/3). >> >> You can find a mockup of the functional specification document for >> Ristretto 1.0 on the wiki[0]. >> >> I would like you all to look at the specification, and if you have any >> suggestions on features and functionality, please post them on this >> list. Then we can discuss the direction that the development of >> Ristretto is going to take. >> >> Kind regards, >> Stephan Arts >> >> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 > > Thanks for taking the initiative to ask for user input. > > So I have had some thoughts on this in the past. What makes gqview good. > It has very vast rendering in a way it show partial image as soon as > possible and increases the quality later this is great. > > It also has to remember the mode the image is shown, fit, full, zoomed, > rotated. > > What I would like from ristretto is very basis controls and some smart > exif rotations. Toolbar on the top and no thumbnail previews. > > I want to be possible to browse 4MB pictures as fast as possible with > usability for myself as expert user but also for people with very very > limited computer experience. > > Beside this it needs a good simple printing feature users want there > picture to be able to print as simple as possible, maybe the mac or > windows default wizards can show some reference models. > > I also use the app to give picture presentations, so preloading in > memory options, and back and forward with up down keys and full screen > options. I don't want to sound rude, but did you actually read the document? - Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sun, 5 Jul 2009 00:47:32 +0200
Stephan Arts <stephan@...> wrote: > On Sat, Jul 4, 2009 at 5:49 PM, Rain > Viigipuu<rain.viigipuu@...> wrote: > > Hi, > > > > How about deleting an image? I've found this as a major shortcoming > > of Ristretto, that while watching a set of photos, I can't delete > > some of them right away. > > > > I noticed that there is an icon which could look like an delete icon > > in mockup section, so maybe it is already planned / existing > > feature, but at least in version 0.0.22 there isn't (which I do > > have in Arch Linux). > > This is already available in git. And yes, the mockup contains that > image because it's picked from a screenshot of that version. It is > still missing from the document-description though, I'll fix that. > > > The other feature that could be very useful, is sorting / grouping > > images by date - like Google Picasa does it. If I remember > > correctly, DigiKam does something similar - it can show images in > > calendar view. I can pick a day and see which images are taken in > > that day. I'm not reallt sure how it should be implemented at the > > moment - Picasa does index the images before and DigiKam needs to > > import images aswell before - but if the feature is considered > > worth implementing, then I hope we can think up some nice way to > > that. > > I think we could see that as a complicated version of sorting by date. > Which is mentioned in the document. I can see why you want this, but a > timeline widget might be a little out-of-scope for the time being, speaking, preview bars (like RsttoPreviewBar). You could then provide a simple GTypeModule extension API for it. With that it wouldn't matter if the preview bar is just a file listing (like in gqview), a grouped view of the loaded images or a even a fancy touchscreen-enabled thumbnail bar. That shouldn't be too hard if the preview bar interface is well-designed. - Jannis _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sun, 5 Jul 2009 00:52:54 +0200
Stephan Arts <stephan@...> wrote: > On Sat, Jul 4, 2009 at 2:18 PM, Vincent<mailinglists@...> wrote: > > > > > > On Sat, Jul 4, 2009 at 10:51 AM, Stephan Arts <stephan@...> > > wrote: > >> > >> Hi guys, > >> > >> After a couple of years of development, I am getting tired of the > >> ad-hoc hacker style development model I have been using for > >> ristretto. This development model was the cause of several issues > >> which were not easy to solve. > >> > >> - Returning bugs (memory usage, thumbnails, slow UI) > >> - Constant rewrites whenever a new feature was being worked on > >> - and a few other things... > >> > >> When this keeps happening, the fun of coding tends to go away... > >> > >> To prevent that stuff from happening again, I have decided to first > >> put up a decent specification of what Ristretto should do and how > >> it should look like(1/3), then actually make a proper design based > >> on those specifications(2/3) and finally start coding (3/3). > >> > >> You can find a mockup of the functional specification document for > >> Ristretto 1.0 on the wiki[0]. > >> > >> I would like you all to look at the specification, and if you have > >> any suggestions on features and functionality, please post them on > >> this list. Then we can discuss the direction that the development > >> of Ristretto is going to take. > >> > >> Kind regards, > >> Stephan Arts > >> > >> > >> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 > > > > > > Well... If you are allowing the user to rotate the image himself, > > then that already is a form of editing, just without saving the > > edits. Perhaps it would be less confusing if you also provided the > > user with the option to save the rotation, warn the user that his > > changes *aren't* saved, or disallow manual rotation in general (I > > don't think this is a good option, of course, but as the > > alternative does entail editing, I'd say that you might as well let > > the user save those edits). > > I disagree, rotation just changes the way the image is displayed. When > I place a printed photo on my desk, and I rotate it, nothing really > changes to the image. I just look at it differently. angle felt (or actually *was*) wrong. And in most situations you'll feel the urge to correct this again and again whenever you browse to that image. Thinking about my own behaviour I can say that I'd almost always want to save the image after a manual rotation. - Jannis _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sat, Jul 4, 2009 at 17:42, Stephan Arts<stephan@...> wrote:
> On Sat, Jul 4, 2009 at 8:15 PM, Diego Ongaro<ongardie@...> wrote: >> One section I didn't find clear was "Export collections". Could you >> explain how Ristretto will store a collection and how users will >> manage these? > > I am not quite sure how to do this either. It could be done as > followed, I think: > > A playlist-like file, or XML file (depending on the extra metadata you > want to put in) could be stored to disk somewhere, referencing all > the images you want to be in your collection: > > <?xml version="1.0"?> > <collection name="Joe's first birthday"> > <description>Pictures of Joe's first birthday</description> > <image uri="file://path/to/file_1.png"/> > <image uri="file://path/to/file_2.png"/> > <image uri="file://path/to/file_3.png"/> > <image uri="file://path/to/file_4.png"/> > </collection> > > These could be stored in the users home-dir and opened by ristretto. > > It's just a thought, I am personally getting tired of the folders with >> 500 pictures whenever I empty my CF-cards. :-) I guess the playlist/XML idea would be fine, except people might run into problems if they move their pictures directory/directories. I think the more difficult challenge is how to present management of collections to the user. Presumably what I'm looking at (all of the thumnails I now see) makes up my active collection. Then I need to be able to save and load collections, and I need to be able to add and remove images from the active one. It might get hairy. -Diego _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Le dimanche 05 juillet 2009 01:04:42, Jannis Pohlmann a écrit :
> On Sun, 5 Jul 2009 00:52:54 +0200 > > Stephan Arts <stephan@...> wrote: > > On Sat, Jul 4, 2009 at 2:18 PM, Vincent<mailinglists@...> wrote: > > > On Sat, Jul 4, 2009 at 10:51 AM, Stephan Arts <stephan@...> > > > > > > wrote: > > >> Hi guys, > > >> > > >> After a couple of years of development, I am getting tired of the > > >> ad-hoc hacker style development model I have been using for > > >> ristretto. This development model was the cause of several issues > > >> which were not easy to solve. > > >> > > >> - Returning bugs (memory usage, thumbnails, slow UI) > > >> - Constant rewrites whenever a new feature was being worked on > > >> - and a few other things... > > >> > > >> When this keeps happening, the fun of coding tends to go away... > > >> > > >> To prevent that stuff from happening again, I have decided to first > > >> put up a decent specification of what Ristretto should do and how > > >> it should look like(1/3), then actually make a proper design based > > >> on those specifications(2/3) and finally start coding (3/3). > > >> > > >> You can find a mockup of the functional specification document for > > >> Ristretto 1.0 on the wiki[0]. > > >> > > >> I would like you all to look at the specification, and if you have > > >> any suggestions on features and functionality, please post them on > > >> this list. Then we can discuss the direction that the development > > >> of Ristretto is going to take. > > >> > > >> Kind regards, > > >> Stephan Arts > > >> > > >> > > >> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 > > > > > > Well... If you are allowing the user to rotate the image himself, > > > then that already is a form of editing, just without saving the > > > edits. Perhaps it would be less confusing if you also provided the > > > user with the option to save the rotation, warn the user that his > > > changes *aren't* saved, or disallow manual rotation in general (I > > > don't think this is a good option, of course, but as the > > > alternative does entail editing, I'd say that you might as well let > > > the user save those edits). > > > > I disagree, rotation just changes the way the image is displayed. When > > I place a printed photo on my desk, and I rotate it, nothing really > > changes to the image. I just look at it differently. > > While that is true, you often rotate for a reason: because the original > angle felt (or actually *was*) wrong. And in most situations you'll > feel the urge to correct this again and again whenever you browse to > that image. Thinking about my own behaviour I can say that I'd almost > always want to save the image after a manual rotation. Saving the rotation is something useful indeed. Rstto should ask if the image must be saved with a checkbox "don't ask again". The less casual "editings" are Resize and Cropping. Btw, I wonder if it is possible to save the rotation with Exif instead of overwritting the jpeg with another quality and size. Mike _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Mike Massonnet wrote:
> > Saving the rotation is something useful indeed. Rstto should ask if the image > must be saved with a checkbox "don't ask again". The less casual "editings" > are Resize and Cropping. Btw, I wonder if it is possible to save the rotation > with Exif instead of overwritting the jpeg with another quality and size. this is the preferred method - you don't touch the original data and basically "correct" the exif rotation field instead (and then redisplay using that value). anything else is a bitmap edit and IMO ristretto should not do - that is what image manipulation programs are for... Auke _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sun, Jul 5, 2009 at 9:49 AM, Auke Kok<auke@...> wrote:
> Mike Massonnet wrote: >> >> Saving the rotation is something useful indeed. Rstto should ask if the >> image must be saved with a checkbox "don't ask again". The less casual >> "editings" are Resize and Cropping. Btw, I wonder if it is possible to save >> the rotation with Exif instead of overwritting the jpeg with another quality >> and size. > > this is the preferred method - you don't touch the original data and > basically "correct" the exif rotation field instead (and then redisplay > using that value). > > anything else is a bitmap edit and IMO ristretto should not do - that is > what image manipulation programs are for... I agree on this one. I don't want to touch the bitmap with ristretto, other apps like the gimp are much more suitable for this purpose. That is the reason current versions of ristretto have an open-with menu, and listen for filesystem-changes. - Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sun, Jul 5, 2009 at 8:56 AM, Stephan Arts <stephan@...> wrote:
That would definitely be the preferred method. Like Jannis said, whenever you rotate an image it's like that you'll want it in that orientation every time you look at it. It's not like if you look at your pictures on your desk and you rotate them that you rotate them back when you're done viewing them ;-) Anyway, as for the location of the thumbnail bar, I don't think you'd change that often enough to warrant drag and drop - a simple drop-down menu under Preferences would be enough I think. But to make sure the arrow buttons aren't confusing you might want to make them part of the thumbnail bar so that, when moved to a vertical orientation, they also adjust to that. By the way, there are probably also some nice things Ristretto could integrate with (though it should only introduce optional dependencies of course), like Tracker integration or something. I really have too little knowledge to be able to say anything sensible on this, but perhaps other people have some cool ideas. Otherwise, just disregard this remark ;-)
-- Vincent _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Stephan Arts wrote:
> On Sat, Jul 4, 2009 at 4:48 PM, Jelle de Jong<jelledejong@...> wrote: >> Stephan Arts wrote: >>> Hi guys, >>> >>> After a couple of years of development, I am getting tired of the >>> ad-hoc hacker style development model I have been using for ristretto. >>> This development model was the cause of several issues which were not >>> easy to solve. >>> >>> �- Returning bugs (memory usage, thumbnails, slow UI) >>> �- Constant rewrites whenever a new feature was being worked on >>> �- and a few other things... >>> >>> When this keeps happening, the fun of coding tends to go away... >>> >>> To prevent that stuff from happening again, I have decided to first >>> put up a decent specification of what Ristretto should do and how it >>> should look like(1/3), then actually make a proper design based on >>> those specifications(2/3) and finally start coding (3/3). >>> >>> You can find a mockup of the functional specification document for >>> Ristretto 1.0 on the wiki[0]. >>> >>> I would like you all to look at the specification, and if you have any >>> suggestions on features and functionality, please post them on this >>> list. Then we can discuss the direction that the development of >>> Ristretto is going to take. >>> >>> Kind regards, >>> Stephan Arts >>> >>> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 >> Thanks for taking the initiative to ask for user input. >> >> So I have had some thoughts on this in the past. What makes gqview good. >> It has very vast rendering in a way it show partial image as soon as >> possible and increases the quality later this is great. >> >> It also has to remember the mode the image is shown, fit, full, zoomed, >> rotated. >> >> What I would like from ristretto is very basis controls and some smart >> exif rotations. Toolbar on the top and no thumbnail previews. >> >> I want to be possible to browse 4MB pictures as fast as possible with >> usability for myself as expert user but also for people with very very >> limited computer experience. >> >> Beside this it needs a good simple printing feature users want there >> picture to be able to print as simple as possible, maybe the mac or >> windows default wizards can show some reference models. >> >> I also use the app to give picture presentations, so preloading in >> memory options, and back and forward with up down keys and full screen >> options. > > I don't want to sound rude, but did you actually read the document? To be honest the implication does sound rude :-) I actually did read the wikipage, there was nothing about progressive loading of images and increase quality in phases. The exif rotation thing was explained, but i find this very important. Printing needed info so I provided them. The preloading works different when you work with presentations, last viewed images should stay in the memory buffer and and indication of the preloading should be indicated somewhere (see ooimpress) Beside this there is no such thing as bad feedback when you discuss app functionality, we are a community and should stimulate everybody to give there opinions and views not discourage them. No hard feeling here, just keep the discussion about ristretto rolling. Best regards, Jelle _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On Sun, Jul 5, 2009 at 5:37 PM, Jelle de Jong<jelledejong@...> wrote:
> Stephan Arts wrote: >> On Sat, Jul 4, 2009 at 4:48 PM, Jelle de Jong<jelledejong@...> wrote: >>> Stephan Arts wrote: >>>> Hi guys, >>>> >>>> After a couple of years of development, I am getting tired of the >>>> ad-hoc hacker style development model I have been using for ristretto. >>>> This development model was the cause of several issues which were not >>>> easy to solve. >>>> >>>> �- Returning bugs (memory usage, thumbnails, slow UI) >>>> �- Constant rewrites whenever a new feature was being worked on >>>> �- and a few other things... >>>> >>>> When this keeps happening, the fun of coding tends to go away... >>>> >>>> To prevent that stuff from happening again, I have decided to first >>>> put up a decent specification of what Ristretto should do and how it >>>> should look like(1/3), then actually make a proper design based on >>>> those specifications(2/3) and finally start coding (3/3). >>>> >>>> You can find a mockup of the functional specification document for >>>> Ristretto 1.0 on the wiki[0]. >>>> >>>> I would like you all to look at the specification, and if you have any >>>> suggestions on features and functionality, please post them on this >>>> list. Then we can discuss the direction that the development of >>>> Ristretto is going to take. >>>> >>>> Kind regards, >>>> Stephan Arts >>>> >>>> [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 >>> Thanks for taking the initiative to ask for user input. >>> >>> So I have had some thoughts on this in the past. What makes gqview good. >>> It has very vast rendering in a way it show partial image as soon as >>> possible and increases the quality later this is great. >>> >>> It also has to remember the mode the image is shown, fit, full, zoomed, >>> rotated. >>> >>> What I would like from ristretto is very basis controls and some smart >>> exif rotations. Toolbar on the top and no thumbnail previews. >>> >>> I want to be possible to browse 4MB pictures as fast as possible with >>> usability for myself as expert user but also for people with very very >>> limited computer experience. >>> >>> Beside this it needs a good simple printing feature users want there >>> picture to be able to print as simple as possible, maybe the mac or >>> windows default wizards can show some reference models. >>> >>> I also use the app to give picture presentations, so preloading in >>> memory options, and back and forward with up down keys and full screen >>> options. >> >> I don't want to sound rude, but did you actually read the document? > > To be honest the implication does sound rude :-) > > I actually did read the wikipage, there was nothing about progressive > loading of images and increase quality in phases. The exif rotation > thing was explained, but i find this very important. Printing needed > info so I provided them. The preloading works different when you work > with presentations, last viewed images should stay in the memory buffer > and and indication of the preloading should be indicated somewhere (see > ooimpress) > > Beside this there is no such thing as bad feedback when you discuss app > functionality, we are a community and should stimulate everybody to give > there opinions and views not discourage them. No hard feeling here, just > keep the discussion about ristretto rolling. Fair enough :-), I had the wrong impression with your first mail, sorry 'bout that. Loading in different phases is kinda silly, but in git I have something similar though. 1) Initiate the loading of the image 2) Show the thumbnail if the image is not available but the thumbnail is 3) Show the image once it's completely loaded It is not the same as progressive loading, but it gives a similar feel to it. I am not yet sure what a correct preloading algorithm is, could you elaborate your idea on this a bit? Regards, Stephan _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)On dim, 2009-07-05 at 00:49 -0700, Auke Kok wrote:
> Mike Massonnet wrote: > > > > Saving the rotation is something useful indeed. Rstto should ask if the image > > must be saved with a checkbox "don't ask again". The less casual "editings" > > are Resize and Cropping. Btw, I wonder if it is possible to save the rotation > > with Exif instead of overwritting the jpeg with another quality and size. > > this is the preferred method - you don't touch the original data and > basically "correct" the exif rotation field instead (and then redisplay > using that value). > > anything else is a bitmap edit and IMO ristretto should not do - that is > what image manipulation programs are for... TopLeft you should rotate the picture (at display time) accordingly. When the user wants to rotate an image, you could do it (rotation is non destructive) and reset the Orientation tag. GThumb does that, for example. Cheers, -- Yves-Alexis _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
|
|
Re: Ristretto 1.0 - Functional Requirements (1/3)Stephan Arts wrote:
> Hi guys, > > After a couple of years of development, I am getting tired of the > ad-hoc hacker style development model I have been using for ristretto. > This development model was the cause of several issues which were not > easy to solve. > > - Returning bugs (memory usage, thumbnails, slow UI) > - Constant rewrites whenever a new feature was being worked on > - and a few other things... > > When this keeps happening, the fun of coding tends to go away... > > To prevent that stuff from happening again, I have decided to first > put up a decent specification of what Ristretto should do and how it > should look like(1/3), then actually make a proper design based on > those specifications(2/3) and finally start coding (3/3). > > You can find a mockup of the functional specification document for > Ristretto 1.0 on the wiki[0]. > > I would like you all to look at the specification, and if you have any > suggestions on features and functionality, please post them on this > list. Then we can discuss the direction that the development of > Ristretto is going to take. > > Kind regards, > Stephan Arts > > > [0] http://wiki.xfce.org/releng/fsd/ristretto/1.0 > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev@... > http://foo-projects.org/mailman/listinfo/xfce4-dev > by the provided specs): Will it watch the filesystem and reload the image if it changes on disk? While working with some command-line tools that don't show the resulting image, I've found that most image viewers don't usually automatically reload the image if it changes, and don't always provide a Reload button, forcing me to do anything from switching images away and back to closing the viewer and starting over. Thanks, Daryl. _______________________________________________ Xfce4-dev mailing list Xfce4-dev@... http://foo-projects.org/mailman/listinfo/xfce4-dev |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |