Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: MikeLockmoore on April 13, 2009, 10:51:49 PM
-
Hello! I did not see (or perhaps I overlooked) a simple graphics image viewer applet in TC base or in the TCE/TCZ appbrowser, so I coded up one in FLTK.
This program's executable is tiny (> 6K! ;D) and loads images really fast. It supports:
* .JPG / JPEG
* .GIF
* .PNG
* .BMP
* .XBM
* .XPM
It can be also launced from the command line. Assuming it is placed in /usr/local/bin, or some other place in the search path, simply invoke:
# fl_picsee {{filename, which may include path}}
It works well with Rox-Filer if you set the run action to launch it. In Rox, right-click, select "Set Run Action...", then put something like the following in the "Enter a shell command" text field:
/usr/local/bin/fl_picsee "$@"
Downsides? It does not support scrolling and will not resize the image if it is too big to see on your screen. The full path and file name in the title will be clipped if the window title bar is not long enough (especially true for small images), and the window maximizing button does not really work. As I learn more about FLTK, I will try to address these shortcomings.
This 0.8.0 version is an alpha release only. I have not learned fully how to make a .tce or .tcz distribution, so I am posting the GPL source code. Perhaps Jason can package it for me once until I learn how to do it myself. Or if given permission, I can attach the binary directly.
This requires the 1.1 version of FLTK, which is standard in TC 1.3 (and earlier, I assume).
Please address bug reports and and comments to this thread. Hope you like it!
Source Code (EDIT, updated to version 0.8.1, which has some modifications to handle filenames that are too short or too long):
// fl_picsee -- A FLTK-based picture viewer
#define appver "0.8.1"
/* -------------------------------------------------------
Copyright 2009 Michael A. Losh
"FLTK Picture-See" (also known as "fl_picsee") is free software:
you can redistribute it and/or modify it under the terms of
the GNU General Public License as published by the
Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
FLTK Picture-See is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with FLTK Picture-See. If not, see <http://www.gnu.org/licenses/>.
-----------------------------------------------------------------*/
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#include <FL/Fl.H>
#include <FL/fl_ask.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Shared_Image.H>
#include <FL/Fl_BMP_Image.H>
#include <FL/Fl_GIF_Image.H>
#include <FL/Fl_JPEG_Image.H>
#include <FL/Fl_PNG_Image.H>
#include <FL/Fl_XBM_Image.H>
#include <FL/Fl_XPM_Image.H>
#include <FL/Fl_Box.H>
int main(int argc, char** argv) {
int h, w;
int len = 0;
Fl_Image * fi_p = NULL;
char title[128] = "";
char filename[256];
char ext[8];
fl_register_images(); // initialize image lib
if (argc > 1) {
memset(filename, 0, 256);
strncpy(filename, argv[1], 255);
len = strlen(filename);
}
if (len > 4) {
printf("Loading image '%s'\n", filename);
sprintf(title, "%120s - FLTK Picture-See %s", filename, appver);
ext[0] = toupper(filename[len - 4]);
ext[1] = toupper(filename[len - 3]);
ext[2] = toupper(filename[len - 2]);
ext[3] = toupper(filename[len - 1]);
ext[4] = 0;
printf("File type appears to be '%s'\n", ext);
if (!strcmp(ext, ".JPG") || !strcmp(ext, "JPEG")) {
fi_p = new Fl_JPEG_Image(argv[1]);
}
else if (!strcmp(ext, ".PNG")) {
fi_p = new Fl_PNG_Image(argv[1]);
}
else if (!strcmp(ext, ".BMP")) {
fi_p = new Fl_BMP_Image(argv[1]);
}
else if (!strcmp(ext, ".GIF")) {
fi_p = new Fl_GIF_Image(argv[1]);
}
else if (!strcmp(ext, ".XBM")) {
fi_p = new Fl_XBM_Image(argv[1]);
}
else if (!strcmp(ext, ".XPM")) {
fi_p = new Fl_XPM_Image(argv[1]);
}
else {
fl_alert("File with name ending '%s' is not a known type. FLTK Picture-See will exit.\n", ext);
return -1;
}
h = fi_p->h();
if (h < 80) h = 80;
w = fi_p->w();
if (w < 120) w = 120;
Fl_Window win(w + 24, h + 24, title);
Fl_Box box(10,10, w + 2, h + 2);
box.image(fi_p);
win.show();
return(Fl::run());
}
}
--
Mike "Lockmoore" Losh
-
This reminds me of mikshaw's(?) fltk icon viewer app.
That, and the Fl_Shared_Image class may be of interest. (There's also some code problems that could be improved upon, fwiw)
-
@thehatsrule: I'm not familiar with those so far. Viewing icons might be a nice additional feature.
All:
When I build fl_picsee, I dynamically link to libfltk.so and libfltk_images.so. I'm not sure that libfltk_images.so is in the TC core (I'll check soon). If not, maybe fl_see should be statically linked to the image functions? Or some of the additional fltk libs be available as a extension without needing all of compiletc.tce?
-
- libfltk_images is in the base
- imlib2_view may be of interest ;)
Currently your app is pretty similar in functionality, but it will quite soon surpass the imlib2 app I believe.
-
- imlib2_view may be of interest
I guess I did overlook something in the base. :-[ I'm not trying to duplicate what is already available, expecially if it available in the base! If it's open-source, maybe I can offer a patch based on a new feature in my viewer (if any).
I mostly wrote fl_picsee as an warm-up exercise with FLTK.
--
Mike L.
-
imlib2_view could use a GUI.
A native fltk image viewer would be very nice.
I encourage you to continue.
Note: boot tinycore base norestore nolocal
Then try to run program program.
Doing such will show if it is dependent on compiletc or any other extension.
Whenever possible I would also encourage the use of fluid projects.
That way it is easy to add/adjust GUI elements.
-
roberts:
I tested my latest version, 0.8.2, using the 'base norestore nolocal' and it runs fine! I have not tried fluid yet, since fl_picsee does not really have much of a designed GUI, but I would like to try it out when I port my hexadecimal file viewer app.
Version 0.8.2 of fl_picsee will open the FLTK file chooser if no command-line parameter is available (e.g. if it were in the app menu?). In this file chooser, a thumbnail preview is available as an option! The nice thing is that this comes with the standard FLTK file chooser and FLTK image library for free. My compiled executable has bloated up to 6.2K, but I think the extra file chooser feature is worth 1K or so. Even at 6.2K, it is smaller than imlib2_view. ;) If there is a file passed as a command-line parameter, the image opens immediately, as in the earlier versions.
One issue is that the file chooser dialog itself has some very jagged fonts in the file selection list and other fields. I would guess this is because FLTK as built into TC base has very limited fonts, which get stretched when needed.
I'll attach my updated source file and my makefile. Maybe Jason W. can build it and make an initial beta-test .tce/.tcz that people can try? I would like to learn how to make extension files myself in the near future. I understand most of the steps documented in the Wiki, but I have not used autoconf, so the configure stuff does not apply to building and installing this app.
--
Mike L.
-
I'll make an extension of this and post it if you would like.
-
Jason:
Yes, please! And if you could describe how you made the extension from this stuff, I would appreciate it. Then I could try to make the next version for this or other simple apps. Thanks!, Mike L.
-
I am posting the extension now, and here is a script that builds it into a tce:
#!/bin/bash
#required extensions: compiletc, bash, advcomp
make
mkdir -p picsee/usr/local/{bin,tce.menu}
cp fl_picsee picsee/usr/local/bin/
echo "<JWM>" > picsee/usr/local/tce.menu/fl_picsee
echo "<Program label=\"FL_picsee\">/usr/local/bin/fl_picsee</Program>" >> picsee/usr/local/tce.menu/fl_picsee
echo "</JWM>" >> picsee/usr/local/tce.menu/fl_picsee
cd picsee
find usr -not -type d > /tmp/list
tar -T /tmp/list -czvf /home/tc/fl_picsee.tce
cd /home/tc
advdev -z4 fl_picsee.tce
#create info file manually
md5sum fl_picsee.tce > fl_picsee.tce.md5.txt
tar -ztf fl_picsee.tce > fl_picsee.tce.list
-
See the wiki entry on creating extensions for more info.
-
I appreciate seeing the script, Jason. The Wiki document is great, but it covers many scenarios. Seeing how this script works for a simple case helps make the Wiki info more clear. I'll be able to manage this easily in the future. Maybe a generic version of this script could be added to the text in the Wiki? Like so? (Maybe my comments are not 100% accurate, but I hope they are close).
#!/bin/bash
#required extensions: compiletc, bash, advcomp
#Script to package a simple application as a Tiny Core Extension
THE_APP=your_app_name_here
THE_APP_LABEL='Your label here'
#Create the binary version of the application
make
#Create a directory tree mimicking the installed files
mkdir -p ${THE_APP}/usr/local/{bin,tce.menu}
#Copy the application binary to the install tree
cp ${THE_APP} ${THE_APP}/usr/local/bin/
#Create a menu entry file
echo "<JWM>" > ${THE_APP}/usr/local/tce.menu/${THE_APP}
echo "<Program label=\"${THE_APP_LABEL}\">/usr/local/bin/${THE_APP}</Program>" >> ${THE_APP}/usr/local/tce.menu/${THE_APP}
echo "</JWM>" >> ${THE_APP}/usr/local/tce.menu/${THE_APP}
#Make a list of the files to be installed
cd ${THE_APP}
find usr -not -type d > /tmp/list
#Archive and compress the files in the installation list
tar -T /tmp/list -czvf /home/tc/${THE_APP}.tce
#Further compress the .tce file
cd /home/tc
advdev -z4 ${THE_APP}.tce
#Create md5 checksum and info files manually
md5sum ${THE_APP}.tce > ${THE_APP}.tce.md5.txt
tar -ztf ${THE_APP}.tce > ${THE_APP}.tce.list
As I said in the News forum, thanks for helping with this! I hope some people find this app and the discussion on making extensions useful. :)
--
Mike L.
-
Adding fl_picsee to the next cut of the base system. Replaces imlib2_view.
-
RobertS: Wow, I'm humbled and honored. Let me know if you think any changes are needed. We can bump up the version number prior to release.
--
Mike
-
Some ideas:
- scaling, and when not scaled, scrolling
- have the filename of the pic as the tooltip of the image
- clicking on the image could open the file selector (or maybe have a separate button for it?)
- handling of the case where several pics have been entered on the command line: either the way of showimage of sdl_image (pressing the right or left keys would go to the next/prev image), or arrow buttons
- slideshows :)
-
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.
-
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: 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.
-
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.
-
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
-
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. :)
-
can you do what mozilla does, actual size or fit in window?
-
@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 ;)
-
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.
-
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. ;D
-
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.
-
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.
-
Here is a screenshot of flPicSee 0.8.8 in "fit window" scaling of a big image. It also shows the tooltip.
:)
--
Mike Lockmoore
-
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.
-
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.
-
i cannot get it to zoom now unless i use a scroll mouse. this is fine... i like the pan feature.
when you've made it multi-image, i hope it's possible to select a different zoom with a right-click menu. but whether a right-click menu is ideal depends on how multi-image works.
-
Tobiaus: Yes, I've thought about that. Maybe I could also see if the left-click release is very close to the where the mouse was when the button was first pressed (and there fore the drag distance is zero or very small). But would it be confusing to have many different options for zooming?
Others: What do you think about the middle-button drag and scroll wheel for changing the zoom level? Would you prefer to use left-click for zoom changes? Or all three?
For multi-image viewing, I might have a pop-up area on the left and right side of the image that you can left-click to page through the different images (like some websites use). In particular, if you hover over these areas, you will see some kind of arrow (like a big '>' for the "next" image on the right side) appear over the image, and maybe the tool tip text will change to "view (next-image-filename)".
For more advanced kinds of multi-image viewing, I'm starting to think that there should be two versions of flPicSee, and only put the features like thubnails and slideshow in the "flPicSee Delux" version. That way, if roberts prefers to have in TCB an image-viewer that is small and streamlined, the base version of flPicSee will still meet that objective, while if someone wants the delux version, he or she could load it as a TCE/TCZ. The delux version could have fancier zooming features too.
--
Mike L.
-
Maybe I could also see if the left-click release is very close to the where the mouse was when the button was first pressed (and there fore the drag distance is zero or very small).
i hate to nitpick further, but now you seem to be asking, and i'm always happy to answer. i don't think you want to check for a drag distance to make it "tolerant" of drag, because this is better for the person zooming, but the person panning will now experience "jumps" (like when a wm snaps to edge. nothing against snap to edge.)
i've been using a mouse since the mid 80's, when they were a lot less sophisticated, but almost as accurate as they are now. it's very possible to click without dragging. only accept a left click if the drag is 0.
i have nothing against middle click except that the only time i've found it easy to do is on xterm and the like, and then just because it's easier, i use shift insert instead. i think of people who have trouble double clicking, even though it's very easy, and for them simulating a middle click would be a lot to ask.
if you do put in a left-click-drag tolerance and do it your way, make the tolerance range 2 pixels. then it would be tolerable for both those panning and zooming. my first goal is to make everything easy for the user, but with all the work you've put in i'd like to make it very easy for you, too. originally i figured a drag tolerance of zero (for left click, versus left button drag) would suffice.