Ristretto 1.0 - Functional Requirements (1/3)

[Stephan Arts]

On Sun, Jul 5, 2009 at 5:37 PM, Jelle de Jong<jelledejong at powercraft.nl> wrote:
> Stephan Arts wrote:
>> On Sat, Jul 4, 2009 at 4:48 PM, Jelle de Jong<jelledejong at powercraft.nl> 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