Re: What's the future of EOG? Has EOG a roadmap?

["Deskblue Software - Javier Sánchez" <jsanchez deskblue com>]

I send you a text file with some ideas for EOG. Review it and if you think that it would be useful add them to EOG's wiki.

 

Thanks in advance.

 

Javier Sánchez

El 26 de agosto de 2012 a las 11:43 Felix Riemann <friemann gnome org> escribió:

> (* Sorry for double-sending but Evo sent an incomplete message *)
>
> I'll take a look at your headers.
>
> For now I've rebooted the Roadmap wiki page:
> https://live.gnome.org/EyeOfGnome/Roadmap
>
> Let's see if I manage to find my way into IRC this week.
>
> Felix
>
> Am Freitag, den 24.08.2012, 23:24 +0200 schrieb "Deskblue Software -
> Javier Sánchez":
> >
> > El 24 de agosto de 2012 a las 21:21 Felix Riemann <friemann gnome org>
> > escribió:
> >
> > > Am Donnerstag, den 23.08.2012, 20:20 +0200 schrieb Deskblue Software
> > -
> > > Javier Sánchez:
> > > > Hi guys,
> > >
> > > Hi!
> > >
> > > > After some bugs fixed and some time working on a patch to fix the
> > bug
> > > > #321603 preload files, I have some questions:
> > > >
> > > > 1) I think that it's necessary to refactor some components. For
> > example:
> > > > Make a change into EogWindow is a knightmare because it has a lot
> > of
> > > > older and tangled code.
> > >
> > > Another prime example of stuff you don't want to touch in its
> > current
> > > state would be the image loading code.
> > >
> > > > 2) Other components, like EogScrollView, contain some deprecated
> > code. I
> > > > think that it's necessary to update this components as is proposed
> > by
> > > > the bug #546504 - clutter backend.
> > >
> > > Hmm,
> > >
> > > > 3) Fix bugs like #321603 - preload files is very difficult if we
> > don't
> > > > change the current architecture. For example: We can replace
> > > > EogListStore, EogThumbNav and EogThumbView with the new
> > components
> > > > EogNavigator and EogNavigatorView which have an API for image
> > > > management, image collection management and image navigation.
> > >
> > > The job running system is also in the way of quite some feature
> > > requests/bugfixes as it is very limited (only one job at a time,
> > pretty
> > > much uninterruptible). It is also very decoupled from the objects
> > it
> > > works on. For example there exists no direct connection from an
> > image to
> > > the job that does the loading/saving/transforming/etc.
> > >
> > > I wanted to refactor it for quite some time (I think it's years
> > > already), but never really found the necessary time for it. :(
> > >
> > > The *Navigator* classes are something you wrote for the preloading
> > > feature?
> > 
> >
> > Yes, it's my solution for preloading. I'm writing two classes
> > EogNavigator and EogNavigatorView which act as model and view of a
> > component based on a MVC pattern. You could say that EogNavigator is
> > an EogListStore with more responsabilities because it contains data
> > access and business logic (preloading feature is included here). In
> > the other hand EogNavigatorView is the component responsible for
> > displaying the thumbnails and interact with the user. Basically I'm
> > replacing EogListStore, EogThumbNav and EogThumbView with EogNavigator
> > and EogNavigatorView. What's my problem? EogWindow acts as controller
> > in my MVC pattern and replace components it's a hard work.
> >
> > 
> >
> > Furthermore, we will define a correct API for this components. Maybe,
> > we will include methods which fix bugs like Bug 567581 - Navigate
> > between images by specifying image number (image x -> image y).
> >
> > 
> >
> > Anyway, I include as attachment of this mail EogNavigator.h and
> > EogNavigatorView.h, review it and tell me what do you think about it.
> >
> > 
> >
> > > > 4) Eog hasn't had major changes since 2.20, when was include
> > support for
> > > > plugins, editable toolbar or printing for multiple images.
> > >
> > > Well, I'd say this depends on how you define major. For example the
> > move
> > > from 2.x to 3.x also brought an improved drawing system with it.
> > The
> > > change wasn't very huge codewise but was still quite intrusive as
> > it
> > > touched some of our "inner-core" functions.
> > >
> > > Also eog-2.20 was a really huge refactoring and was actually in
> > > development for roughly 1.5 years before the first stable release
> > came
> > > out. Not sure if it's a good comparision point.
> > >
> > > > For this reasons, I think that it would be a good idea to define
> > our
> > > > roadmap and update the eog wiki. Maybe, we have to discuss what's
> > the
> > > > future of EOG and what we can to do to have a modern image
> > viewer.
> > > >
> > > > What do you think?
> > >
> > > Very good idea.
> > > I'm absolutely open for this. Might actually help getting ideas a
> > bit
> > > more lined out and maybe even attract other/new contributors.
> > 
> >
> > Well, I have some ideas:
> >
> > 
> >
> > - EOG would have a new image view components based on clutter. This
> > way we could apply not intrusive cool effects to the displayed image
> > like do cheese.
> >
> > - EOG would have a unique component for image management and
> > navigation (EogNavigator)
> >
> > - We would refactor some components to make code more readable for new
> > contributors.
> >
> > - We would add new basic image transformation operations like resize,
> > crop, ...
> >
> > - We would add new hooks for plugins. This way, the new plugins would
> > be more powerful.
> >
> > 
> >
> > Anyway, I think that we could express our ideas in EOG wiki or discuss
> > it on eog chat room.
> >
> > 
> >
> > > Regards,
> > >
> > > Felix
> > >
> > >
>
>

Attachment: eog-ideas
Description: Binary data