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

[Felix Riemann <friemann gnome org>]

Hi!

Sorry for leaving you without a word for the whole week.

But now I found the time to take a look at your two new classes.


EogNavigator appears to be the replacement for EogListStore, at least
for most of the API. So far this looks pretty straight forward. The only
thing that doesn't quite fit IMHO are the functions that affect the
active image itself, like eog_navigator_save_image(). These should
rather be members of EogImage I'd say.

Then there's EogNavigatorView which seems to be the merger of
EogThumbView and EogThumbNav and so far I cannot spot anything bad.

I'm interested to see your implementations (when they're done of
course). :)

One thing you could possibly look into when refurbishing APIs is
constness at least for function parameters. For most property getters it
should be possible to make the pointer to the own object const. For
example:
gint eog_navigator_get_active_image_index (const EogNavigator
*navigator);

This was forgotten in eog's API in several places and I've come to think
it's a nice thing to have in terms of a good API.

Regards,

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 
> > 
> >