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

[Felix Riemann <friemann gnome org>]

I'll take a look at your headers.

For now I've rebooted the Roadmap wiki page:


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.