On ne 1. března 2009, Ruben Stein wrote: > Thanks Laurent for your instant adjustments. > > From: Vladimir Nadvornik - 2009-03-01 11:03 > > > - editors.c - Geeqie now uses desktop files and it is not possible to add > > non-standard parameters directly on commandline. It should be possible to > > export the coordinates in environment variables however. > > BTW, which editors can use this? > > I see, the simple and fast custom commands are one feature I love at > gqview. ;) I use it for scripts and home grown applications. So I can > use GQView for watching the pictures my algorithms produced, and start > own analysis tools using the custom commands. Do you plan to support > custom commands in the future again?
The single-line commandline from GQView has several problems: - it is hard to set distribution defaults - it uses non-standard macros - it is hard to edit more complicated commands - it is hard to contribute the good commands upstream Desktop files fixes these problems and adding new applications is not much harder, just edit a template desktop file and copy it to ~/.geeqie/applications. When I think about it, it would be easy to add the "copy and edit template" function directly to Geeqie. > Maybe I will find the time to read through the destop-files approach > and try to do it with this, but for my purposes of prototyped scripts > the simple commandline from gqview is easier to use. > > > - layout.c - IMO the menu is not needed. > > Thought it would raise the willingness to integrate the feature. After > all it flashes permanently. > The flashing really does not look very good. Maybe use fixed-size formatting? Another possibility would be to add it to sidebar. It would have more room there and the enabling and disabling would work automatically. > > - pixbuf-renderer.c - does it have to store everything? IMO mouse > > coordinates should be enough and the pixel coordinates and RGB can be > > computed on demand. > > I changed it in this patch so rgb-data is only calculated in the > getter. Anyway - I would hold the pixel coordinates. I would do so > because there is no need to call the layout_status_update_pixel if the > mouse points still to the outside of the buffer. So store only pixel coordinates then? Having both means extra care to keep them synchronized. BTW, hardcoded layout_status_update_pixel call is not very good. IMO correct way would be to use a signal (grep for "scroll_notify" to see how to implement this): layout will register a callback when it wants to be informed about pixel changes and from the callback queries the pixbuf-renderer for details. > But to know this, you > first have to calculate the pixel data. So they are computed anyway > before calling the statusbar-update and calculating them a second time > from the layout_status_update_pixel would not make sense imho. > > I also changed sth in the zoom-function so the pixelinfo gets updated > if the picture is changed e.g. by scrollwheel. Additionally there was > an off-by-1-fault in the color-update guard. > Vladimir ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
