Some post-FOSDEM thoughts



Hi all,

During FOSDEM, Lucas, Felix and I had a bit of time to sit together and
talk about the things we would like to focus on for 2.28. I didn't
really make notes but I still remember in general lines what we
discussed, and thus I'm sending this email trying to summarise it before
I completely forget it. As I probably already forgot some details, I
expect my mates to complement this email. :)

Basically, we talked about:

- Improving startup time.

During startup time, eog first loads the list of images into the model
and later starts loading the image to open. When opening a single image
in a crowded directory, this gives a very bad user experience, since
loading the image takes too long.

Ideally, we would be able to start eog, load the image first, and then
the collection items. The problem with this approach is that, if the
collection widget is visible, the user would see it empty and later
being filed with elements, which is not really nice.

We need to find a balance on this. Something that came to my mind after
this meeting is that we could add dummy elements to the model before
loading the image and once the loading is done, file them with the real
data (kinda überlazy loading).

- merging the clutter backend

Before the clutter patch starts to rot in bugzilla, it would be great to
have a minimal version working that simply mimics the behaviour of the
EogScrollView widget using clutter and merge it in trunk after branching
for 2.26. Minimal effects can be added later: nice transitions for the
slideshows, for instance. Other effects can be added later, otherwise
the patch is most likely going to rot.

- eog-plugins

We have definitively sucked on maintaining eog-plugins in a decent shape
and in promoting it. Although there are many plugins around, we have not
keep a good track of these, and as a consequence we don't have much
feedback on the usefulness of the plugin engine.

An action plan for this is required. Some thoughts: Adding some of the
plugins that we have in bugzilla (the python console comes to mi mind
now), cleaning up a bit the plugins we have, and after 2.26, we release
an initial eog-plugins development tarball. This could give some
visibility to the existence of this module and hopefully attract some
new plugin contributors (and why not, even a maintainer for it :-)

- bindings

It would be interesting to experiment using gobject-instrospection in an
application like eog, to allow an easier extension of the bindings
available for plugins. I suspect there are not such use cases of
gobject-instrospection yet, thus this could be an interesting
contribution to the whole community, since other applications could base
work on this.

- image cache

One of the features that people miss the most from the pre eog-ng era is
the cache of images. Right now, response time when switching images is
not the best, since we only maintain the currently visible image data
loaded. A image cache system, that maintains a limited of images
surrounding the currently visible one in the collection, is more than
desired.

I was talking to KaL, from Evince, and they have a similar cache for the
document pages. He explicitly told me not to look at it, since it is
pretty hackish, but hey! at least it could give us some ideas :)

- animations and svg rendering support

This was not discussed in the meeting, but Felix and I were chatting
about it. The inability of rendering animated images and a native svg
rendering have been a longstanding limitation in eog. Maybe now it's the
time to dig into this.

A patch to render "moving pictures" is currently available in bugzilla.
I have reviewed it briefly and it is a good starting point, but it would
be a good idea to think further how can we take this opportunity to
implement proper svg rendering.


OK. I hope to have recollected well the main points of our discussion.
Please feel free to comment further on any of these points.

Claudio

-- 
Claudio Saavedra <csaavedra gnome org>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]