(* 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 <[email protected]> > 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 > > > > _______________________________________________ eog-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/eog-list
