Re: [Geeqie-devel] Geeqie++ fever dreams (+Win32)

2016-12-28 Thread Josef Kufner
Ian Zimmerman wrote, on 29.12.2016 02:26:
> On this topic, would it be interesting to create pipelines for editors,
> rather than just invoking them 1 by 1?  For example, we could make it
> possible to create a pipeline where an intricate batch imagemagick
> command is called on the current image, the output is saved to a
> temporary file, and then gimp is immediately called on the temporary to
> allow for manual postprocessing.  Can we imagine a GUI for defining such
> pipelines?  

It would be very messy. Leave that to command line.

What can be done quite easily is to invoke a command on a selection of
images (something like xargs):

  1. Select images
  2. Hit "Batch processing" button
  3. Dialog window will appear. User selects the command and
 reviews list of images.
  4. Hit "Execute" button
  5. Progress is shown in the dialog.
  6. Go to 3.

Question is about the form of the command selection. Geeqie has list of
editor commands wich are available in the popup menu. These should be
available here too. Maybe we can do the same as e-mail clients do with
filters. It would look familiar, but also it would be limited just like
these filter GUI are. Basically a list of commands may be sufficient,
but it is hard to specify inputs and outputs.

I think there is a better way, but it would be a bit more  complicated
to implement. I wonder if it is a bit too complex for a simple
use-cases. It is called "block programming". It is quite an old idea:
Each block (a filter) has inputs and outputs. These I/O are connected
together and blocks form directed acyclic graph. User draws such graph
using palette of predefined blocks and then executes it. I wrote a paper
about modification of this approach for web applications, but it can be
easily adapted to any non-interactive use, just like this one. See the
paper:
https://josef.kufner.cz/publications/2014.kufner.cascade.pdf

Benefit over unix pipelines is in easy dealing with multiple inputs and
outputs. You can have a block to merge multiple images with aplha
channel, or to split color image into three by RGB channels and process
them separately.

If you want complex shell for batch processing, this is the way to go.
If you want something simple, just run one command on a set of images.

Have a nice day!
Josef Kufner

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Geeqie++ fever dreams (+Win32)

2016-12-28 Thread Ian Zimmerman
On 2016-12-28 19:35, Roger wrote:

> Linux is a different story, as most easy image viewers are heavy on
> system resources or (more currently) depend upon clunky and heavy
> resource usage Python scripting.  For those of us that are a little
> more computer literate, ImageMagick display does just fine, but for
> photography image browsing, GView/Geeqie was a God send.  God send
> because GView/Geeqie is light and simple to use.
> 
> I also think if Geeqie keeps gaining more image editing functions with
> those functions not having switches for deactivating of such image
> editing functions, users may start to sway towards other more heavier
> applications.  (eg. If user is already loading an image editor, they
> may just opt to load some other heavy XYZ application.)  Just guessing
> on the later here.  I'm one of those, if I need image editing, I
> immediately use the more defacto imagemagick or The Gimp.

While I also much prefer Geeqie to stay just a viewer, plus maybe a kind
of "shell" for editors [1], I disagree that Linux lacks lightweight
viewers.  feh is currently my other favorite.

[1]
On this topic, would it be interesting to create pipelines for editors,
rather than just invoking them 1 by 1?  For example, we could make it
possible to create a pipeline where an intricate batch imagemagick
command is called on the current image, the output is saved to a
temporary file, and then gimp is immediately called on the temporary to
allow for manual postprocessing.  Can we imagine a GUI for defining such
pipelines?  

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Geeqie++ fever dreams (+Win32)

2016-12-28 Thread Roger
>Back in 2006 someone made a port of Gqview to windows. It died pretty quickly. 
>Was this because:
>
>a) GTK's cross platform capability is a bit of a fiction
>
>b) Gqview/Geeqie was too complex to port successfully
>
>c) Windows users are happy with what they have, and would not bother 
>with Geeqie

My bets are on option "c) Windows users are happy with what they have."  
They're happy with the default Windows' image viewer.  The default viewer is 
extremely easy and apparently light in resource usage.

I usually then resort to The Gimp under Windows for further image editing 
functions.  The Gimp GTK interfaces seems to work just fine under Windows.

Linux is a different story, as most easy image viewers are heavy on system 
resources or (more currently) depend upon clunky and heavy resource usage 
Python scripting.  For those of us that are a little more computer literate, 
ImageMagick display does just fine, but for photography image browsing, 
GView/Geeqie was a God send.  God send because GView/Geeqie is light and simple 
to use.

I also think if Geeqie keeps gaining more image editing functions with those 
functions not having switches for deactivating of such image editing functions, 
users may start to sway towards other more heavier applications.  (eg. If user 
is already loading an image editor, they may just opt to  load some other heavy 
XYZ application.)  Just guessing on the later here.  I'm one of those, if I 
need image editing, I immediately use the more defacto imagemagick or The Gimp.


-- 
Roger
http://rogerx.freeshell.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel


Re: [Geeqie-devel] Geeqie++ fever dreams (+Win32)

2016-12-28 Thread Colin Clark
On 24/12/16 15:39, Alexander Antimonov wrote:
> While porting to C++1x it is good chance to make Geeqie more
> cross-platform. But it seems Gtk is becoming (has become) an auxiliary
> tool for the "GnomeOS". And some of the well-known projects was/is
> migrating from Gtk. Maybe we should consider Qt instead? Anyhow, I
> guess it's more correct to talk about re-implementation than just
> port.
>
I apologise for asking some questions that are no doubt totally obvious 
to those of you who have current knowledge, however...

Back in 2006 someone made a port of Gqview to windows. It died pretty 
quickly. Was this because:

a) GTK's cross platform capability is a bit of a fiction

b) Gqview/Geeqie was too complex to port successfully

c) Windows users are happy with what they have, and would not bother 
with Geeqie


I guess that the reason is b) but I'd be grateful if someone would 
confirm that.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel