FLTK Picture-See (AKA fl_picsee) - tiny GPL picture viewer using FLTK

[MikeLockmoore]

curaga:

I'd like at least a few of those too, but if we add every idea, fl_picsee won't be so small and light, you know?   

RobertS: The alpha fl_picsee is 6.2K.  What is a reasonable size budget for a more featureful version?  Any strong preferences or priorities with curaga's feature list?

Others: How would you prioritize these features?  At what size and feature list do existing picture viewers make more sense than fl_picsee?  Is there a sweet spot missed by other apps?
--
Mike L.

[jpeters]

curaga:

I'd like at least a few of those too, but if we add every idea, fl_picsee won't be so small and light, you know?



RobertS: The alpha fl_picsee is 6.2K.
What is a reasonable size budget for a more featureful version?
Any strong preferences or priorities with curaga's feature list?

Others: How would you prioritize these features?
At what size and feature list do existing picture viewers make more sense than fl_picsee?
Is there a sweet spot missed by other apps?
--
Mike L.

I'm looking at micshaw's (with help from hats)
excellent XML-viewer right now.
It's 8k, 208 lines of murgaLua code, with scrollbar, thumbnails, and main window for clicked on thumbnail.
I wouldn't get much more elaborate than that.

[roberts]

RobertS: The alpha fl_picsee is 6.2K.  What is a reasonable size budget for a more featureful version?  Any strong preferences or priorities with curaga's feature list?

Scaling & scrolling would be nice. You are currently much smaller than the command line imlib2_view (4.7k vs 9.1k). So you could double and be much better off.

With fltk in the base, there is a great advantage for making fltk based guis.
My only preference is when possible make a fluid project.

murgaLua is not an option.

Even if you should decided to make it  large, it would still be offered as an extension.

[MikeLockmoore]

roberts:

4.7K?  You must be using different compile options... or maybe my 6.2 K was not a stripped executable. 

I don't have any experience yet with FLUID, but I hope to try it out soon.  I seemed to have some initial problems running it, so I need to work through that first.  Using a GUI designer will be useful assuming we need to add some other interface elements to control additional features (e.g. scaling zoom level).

Is there an affordable (in terms of binary size and performance) way to make a few more font types and sizes available to FLTK apps in TC?  Will TC 2.x have any improvements to the fonts available to FLTK?  I experimented with the default file chooser in TC 1.3 for fl_picsee, and found I could get a somewhat better-looking font if I requested a certain size (10 pixel-size, if I remember correctly), but this added 0.5K to the binary, so I held off.
--
Mike L.

[roberts]

Seems to be a fair number of fonts and sizes available to fltk.
See the fonts program in the fltk distribution test directory.
Or just grab a compiled version from http://www.shingledecker.org/fonts

[MikeLockmoore]

Robert:  Thanks for the font demo pointer.  I had already seen that, and at least in my build, many of the fonts only come in a single size, and some fonts don't seem actually unique. (Maybe they default to a "closest match" font?)  I don't mean to make  a big issue of this, but I wanted to find out if I could be doing something simple to get higher-quality text rendering in FLTK.  ALSO, can you post your compiler settings that got the 0.8.2 version of fl_picsee under 5K in size?

All:  I've made some progress on new features for fl_picsee.  I currently can support image scrolling if the selected image is too big for the screen.  I also parse the ~/.xsession file to see how big the screen is and not make the outer window larger than this.  However, there must be an easier way to do this than the method I used, but I did not see any FLTK class or function to return the overall screen dimensions.  X11 has some API calls to get this, but I'm not sure those API headers are easily available.  Anyone have a suggestion?

I want to add a tooltip for showing long filenames.  I also want to implement at least a basic form of image scaling.  FLTK can do a basic image resize operation (of the "nearest neighbor" type), so I'm thinking of implementing perhaps just two levels of zoom... or maybe three.  Maybe instead of a full zoom menu, some kind of mouse-clicking (or scroll wheel?) will alternate between the scaling levels?

 I'll post a new version within a few days. 

[tobiaus]

can you do what mozilla does, actual size or fit in window?

[curaga]

@Mike: X headers are available and brought in by the fltk headers (otherwise you couldn't compile X apps). There's an easier way though, see Fl::h and Fl::w (in the fltk docs, class reference, fl)

Also, if the scaling of FLTK is limited/ugly, imlib2 is available. Wbar is proof that it can do high-quality fast scaling

[MikeLockmoore]

tobiaus: Yes, that's basically what I'm thinking about... with the initial window size determined by the dimensions of your xvesa screen.  Maybe left mouse click to switch back and forth.  I'm also considering adding a third scaling size that will fill the largest current window dimension and spill into scrolling for the other dimention.  Usually, our monitors are wider than they are tall, but many times we want to view an image that is taller than wide.  So, there can be a scaling determined that fill the screen horizontally, but only show a vertical portion.  Then you could scroll up and down to see the rest of the image.

So here is what I may try (thinking out loud  ):

Situation 1 - Small image (the entire native-scale image fits in a smaller than max window):
1) Initial: Image is shown at native 1:1 scaling resolution in a big-enough window
2) First Click: Image is scaled (expanded) as much as reasonable* to fill current window size with no scrolling
3) Second Click: Image scaled (expanded) to "best fit width/height" as suggested above, with scrolling is enabled in one direction
4) Next Click: Scaling goes back to step 1.

Situation 2 - Too-big image:
1) Initial: Image is scaled (shunk) to fit entirely in a maximized window with no scrolling
2) First click: Image scaled to "best fit width/height" as suggested above, scrolling is enabled in one direction
3) Second click: Image shown at full native 1:1 scaling, scrolling enabled in one or two dimensions, as needed
4) Third click: Scaling goes back to step 1, etc.

Intermediate-size images and/or user-resized windows:
Probably handled like "Too-big image" but the scaling could be either shrinking or expanding and the window size will not be maximum.  But I'll need to think that through and test it to see if it will work well and feel natural.
--
Mike L.

[MikeLockmoore]

curaga: Sure, really good results are possible.  I like the wbar zooming effect.  Also, someone wrote an article about using the "Anti-grain" graphics lib in FLTK which does an awesome job of avoiding aliasing "jaggies," but it probably requires a lot more CPU and executable size to accmplish.  I'm not familiar right now with imlib2, so I don't know how burdensome (if at all) it is.  For now, I'm inclined to just use the easy, built-in capability of FLTK to create a "nearest-neighbor" scaled image.  We can see how good or bad the visual results are and later take another step in code size and complexity if the benefit seems worthwhile.  But for now I see the reason-d'etre of fl_picsee is to be fast and light. 

[tobiaus]

sounds good. i wouldn't ever use more than 4 modes of zoom-from-single-click, the best 3 could be better.

more than 4 and you're just clicking the mouse a lot, you might as well right-click menu then.

[MikeLockmoore]

Good News!  I've been quiet lately... partly due to other activities going on at home, and partly because I've been climbing the learning curve with FLTK and figuring out how to make things work well.

EDIT: Noticed a cosmetic bug in the window title and tooltip.    Version 0.8.8 is fixed. 

I have a new version of the FLTK picture viewer with a slightly new name: "flPicSee" (or flpicsee for the executable name), Version 0.8.8, which has the following new features:

1) Three zoom levels, as described in prior postings: normal, full image, fit image to window

     Just left-click to rotate through the three zoom levels.  The title shows current zoom %.

2) When the image is first diaplayed, automatic selection of normal zoom for small-enough images, or full image zoom (shrink to fit) for too-large images

3) Automatic adjustment of the scaling for the three zoom levels whenever the overall window size is changed

4) Tool-tip over the image showing the current zoom % and the full path and name of the image

5) Revised main window title to show the following info (making the key info easier to read when the window size is small):
     [zoom%] [filename.ext]  -  flPicSee [app_version] ( [fully_qualified_path_and_filename] )

The executable as built by me is now 10.9 K bytes big... probably worth the extra size if you like the flexible zooming features.  Perhaps roberts can re-compile it smaller (as he did on the earlier version).

Attached are the updated source code, and a new .tce file, md5 file and list file.  Let me know if you have problems with it!  If the name change is a big issue, we can re-release it as fl_picsee again, but I thought people might like to get rid of the underscore in the name.

Whats next?  Some additional features I might work on sometime:

A) Unique window icon

B) Multi-image modes (enabled if multiple image filenames are passed on the command-line or if a directory is selected instead of a single file:
  i.    Thumbnails
 ii.    Click through images one at a time
iii.    Slideshow (timed transition... maybe with some pop-up adjustment controls)
--
Mike L.

[MikeLockmoore]

Here is a screenshot of flPicSee 0.8.8 in "fit window" scaling of a big image.  It also shows the tooltip.

 

--
Mike Lockmoore

[tobiaus]

that's a cool viewer. i don't want to bloat or complicate it, but now that i've used it i notice that nothing happens if i try to click and drag the image around (when it's 100% and bigger than the window.)

scrolling up and down with the mouse wheel is good for up and down, but there's no way to scroll side to side without the scroll bars. click and drag could do both. i don't know if it would be trivial to add this, only that it would be cool if it is trivial to add.

[MikeLockmoore]

New version 0.8.9 of flPicSee has the "tobiaus" UI:

1) Left-click and drag now pans the image (i.e. scrolls it) if neccessary.  The cursor changes to a four-arrow "move" shape.

2) Middle-click and drag now changes the zoom level (among the three levels), up to (generally) increase the zoom%, down to decrease (may not be exactly right if the window aspect ratio is far different than the image).  Cursor changes to a shape that I hope conveys resizing.

3) Mouse scroll wheel also changes zoom level (like 2 above).

When you first left-click or middle-click, the title bar text changes to provide some usage hint.

The exe in this beta-testing TCE is 11.8 K now, but this is about all I would want to add, other than maybe a little about/help message box, at least until I attempt multi-image viewing. 
--
Mike L.