Ristretto 1.0 - Functional Requirements (1/3)

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Ristretto 1.0 - Functional Requirements (1/3)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Vincent T :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



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).

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)

by Jelle de Jong :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Rain Viigipuu :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Diego Ongaro-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Jannis Pohlmann-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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,
You could implement an interface for thumbnail, or more generally
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

signature.asc (204 bytes) Download Attachment

Re: Ristretto 1.0 - Functional Requirements (1/3)

by Jannis Pohlmann-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

  - Jannis


_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

signature.asc (204 bytes) Download Attachment

Re: Ristretto 1.0 - Functional Requirements (1/3)

by Diego Ongaro-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Mike Massonnet-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Auke Kok-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Vincent T :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Sun, Jul 5, 2009 at 8:56 AM, Stephan Arts <stephan@...> wrote:
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.

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 ;-)


-
Stephan


--
Vincent

_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

Re: Ristretto 1.0 - Functional Requirements (1/3)

by Jelle de Jong :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Stephan Arts-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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)

by Yves-Alexis Perez-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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...
And you should look at the Exif Orientation tag. If it's present and not
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

signature.asc (204 bytes) Download Attachment

Re: Ristretto 1.0 - Functional Requirements (1/3)

by Daryl Van Humbeck :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
>  
I have a slightly unusual question (and it doesn't appear to be covered
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 >