Re: criticism and suggestions

[Hans-Peter Doerr <hp doerr web de>]

sorry, yesterday i sent this mail accidentially only to larry, not the list.

Am Sonntag, den 19.03.2006, 18:01 -0600 schrieb Larry Ewing:
> Thanks for the input.  When you are discussing issues on the please
> always be explicit about which version you are using CVS .10 .11 etc.
> It almost always makes a difference in how I will respond.

hi,

yes, i forgot. i was talking about the .11 release.

> > 1) slideshow.
> ...
> Slide show options just aren't a high priority of mine.  They aren't
> hard, probably less than 100 lines of code, but they aren't very
> interesting either so something else always comes up before they do.  If
> it is a priority of yours feel to comment on the appropriate bugs [1] or
> bring it up here.  If someone wants to add a time between slide
> function, I'd probably be happiest with something a slider that let you
> pick between 1 and 30 sec on a exponential scale.

well, slideshow in fact was not that important to me, if only the
fullscreen mode was working well (fast) enough :)

> > 2) general image view and fullscreen mode
> > the image brwoser is quite fast in general, but unneccessary slow in
> > actually displaying pictures. this  is annoying especially in the
> > fullscreen mode. each picture is updated three times: first, a up-scaled
> > version of the thumbnail is shown, then the up-scaled thumbnail is
> > smoothed, just before beeing replaced by the scaled full-res picture.
> > why there might be reasons to to it this way in the thumbnail view, it
> > is just unneccessary in full screen mode. why not scaling pictures
> > off-screen and show them in one go as the slideshow mode already does?
> > 
> 
> How slow is this for you? It is very fast for me [2].  

hmmm, my computer is not the fastest in theese days. ... it's a athlon
700 with 512megs and a matrox g400. i dont know of any specials problems
with the mga driver, except that the thing is actually quite old :)
but the point is that it works quite well with other image viewers, due
to pre-caching, non-progressive rendering or whatever.

> I use it all the
> time as I page quickly though images.  That said, loading a large jpeg
> is not particularly fast, f-spot trades off being very responsive for
> taking a little bit longer and that same code also allows you to see a
> raw file in a reduced resolution form long before it can be rendered.
> As to why it doesn't do the same thing as the slideshow, that view is a
> full featured view, more abilities will be showing up there, don't think
> of it as a glorified slideshow.  

ok, i see. so i think my biggest concern (flawlessy viewing images in
full screen) would be solved by just fixing up the slideshow mode a bit
so that it becomes more controllable. 

> If the current loading code is really too annoying to stand for you, I'd
> be happy to look at a patch that added precaching to those images.
> Something that stored the next and previous images and only fell back to
> the progressive loading would be a good way to handle the perception
> issue (at the cost what could be a lot of memory).

yes, that is likely to be the best option but as said above, a somewhat
more flexible slideshow mode would improve the experience of actually
watching pictures a lot, especially on comparable slow machines such as
mine ...

> > 3) sort by date
>...
> You can set the sort order now.

yes, i know. i was only thinking about a compromise between displaying
images "newest top" and "chronological". like the "threaded" view in
some email applications, for example. newest thread is always on top,
but the thread itself is chronological.

> > if these groups also would be distinguishable visually (eg. by a
> > slightly different brackground color, as in gtk's list-views for
> > example) browsing lots of pictures would even become more intuitive.
> > well, thats actually what tags are for, but as one tag may contain
> > pictures from different "events" something like this maybe would be
> > worth thinking of.
> > 
> 
> Better grouping in the icon view is in the list of things I'd like to
> see.  If interested people want to mock up some designs visually we
> could start to move forward on that.  In the past a couple of people
> have written various patches to add gouping that had rather severe
> performance implications in the IconView.  As a rule of thumb anything
> that does grouping needs to be extremely careful about not causing
> problems for the display speed. I'd be happy to go over the details of
> how I think one could accomplish that sometime if anyone is interested.

well, i'm interested in using it :) ... but neither i've got knowledge
about f-spot internals nor programming in c# at all.


hp