Tiny Core Linux

General TC => Programming & Scripting - Unofficial => Topic started by: MikeLockmoore on August 26, 2010, 07:48:28 PM

Title: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: MikeLockmoore on August 26, 2010, 07:48:28 PM
EDIT: See later posts below for the latest version, 1.2.6.  Also new version of icon posted here.

Hello again.  I've not posted much recently in this programming section, but a lot has been going on behind the scenes.   8)  First up: a new beta release of the FL-PicSee picture viewer.

New features:

* Slideshow - 6 second automatic paging through multiple files
* Titlebar now shows "X of Y" when paging multiple images
* Smaller (prettier?) paging hotspots in upper left and right corners
* Improved keyboard handling
* Build-tcz.sh script - automates making the .tcz file and associated .list and .md5 files
* Icon for wbar or other window managers
* (VERSION 1.2.4+) Automatic file-type identification (filename does not need .jpg, .png, etc.)

The new keyboard handling does not automatically pop open the right-click menu when you press the Ctrl key (as in the prior version), which makes typing the normal window management key combinations in FLWM possible.  However, you can now quickly pop open the menu with the "Windows" key or the context menu key on most keyboards.  All of the normal FL-PicSee Ctrl+Key combinations now work without the right-click menu being visible.

Over time, I grew to dislike the appearance of the large paging "hotspots" on the left and right side of image window.  The hotspots are now rounded rectangles with the word "Next" or "Prev" that appear when you mouse-over the upper left and right corners of the image window.  Hopefully, these are large enough to still be easy for most people to use.  There are several keyboard equivalents for paging, including Space and Backspace, Page Down/Up, Ctrl+ArrowDown/Up.

Before I request the Core team to package this for a new official release, I would invite anyone interested to download, build, and test this beta version.  If you find bugs, please post them here.  Or if you have ideas for the future, please let me know.

Some potential future features (no promises!):
* Slideshow control: at least adjust timing of transitions
* Thumbnail view
* Animated GIF (not in FLTK... need a custom viewer class?)
--
Mike Lockmoore
Title: Re: FL-PicSee 1.2.x
Post by: tinypoodle on August 26, 2010, 11:34:47 PM
Would it be easy to also post a binary (compiled) version for testing?

An improvement I would wish for would be that flpicsee would become agnostic to filename extensions; e.g. that it would open pics which have no filename extensions at all (e.g. in browser cache directory).
Title: Re: FL-PicSee 1.2.x
Post by: curaga on August 27, 2010, 12:20:31 AM
Since you have a script to build the tcz, and the already-posted extension as guidance, I believe you can submit it when you feel it's ready. :)
Title: Re: FL-PicSee 1.2.x
Post by: jls on August 27, 2010, 01:54:46 AM
Thanx a lot for this new version.
The "windows" key doesn't work on my system.
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on August 27, 2010, 06:44:14 AM
@tinypoodle: Unfortunately, one is not allowed to post binary files to this forum.  If you want to build it yourself, you will need to install at least the compiletc.tgz and squashfs-tools-4.0.tcz extensions.  I will probably submit the new version plus any last-minute fixes as updates within a week or two, so you can get it from the official repository soon.  

As for working without file extensions, perhaps FL-PicSee could just try to create the various image types like Fl_JPEG_Image until one is successful, but that might be slow and not always work (the FL_xxx_Image object instantiates OK, but displays garbage when the image type is really something else).  To work well without file extensions, FL-PicSee will need some new code to "sniff" the image type from the file data.  Chances are, each image file structure probably has some distinctive marker data by which one can determine the image type, but I have not looked into the details for this.  Interesting idea, but I don't know how complex it would be yet.

@jls_legalize: The posted version includes a print statement that will display the key code for any key combined with Ctrl that FL-PicSee does not recognize.  You can try that with your Windows key and let me know the key code.  

However, it may be better to always print the key codes, in which case you need to make a minor modification.

Find this bit of code starting about line 616:
Code: [Select]
       case FL_KEYDOWN:
            key = Fl::event_key();
            if (key == FL_Control_L || key == FL_Control_R) {
                ctrl_pressed = 1;
            }

Insert the following printf() statement:
Code: [Select]
       case FL_KEYDOWN:
            key = Fl::event_key();
            printf("You pressed key %d (0x%4X)\n", key, key);
            if (key == FL_Control_L || key == FL_Control_R) {
                ctrl_pressed = 1;
            }

Build this version, start it from the command line, press your "Windows" key, and tell me the key code you see?  If you don't get any key code for your key, I won't be able to help.  Do you have a context menu key?  If so, does it work?  That is the more proper key for this menu, but on at least on my eeePC, the Windows key also works (returns key code 0, which triggers the context menu, as seen around line 621).
--
Mike
Title: Re: FL-PicSee 1.2.x
Post by: tinypoodle on August 27, 2010, 07:13:34 AM
@tinypoodle: Unfortunately, one is not allowed to post binary files to this forum.
Sorry, was unaware of that, my bad.  :(
Quote
To work well without file extensions, FL-PicSee will need some new code to "sniff" the image type from the file data.  Chances are, each image file structure probably has some distinctive marker data by which one can determine the image type, but I have not looked into the details for this.  Interesting idea, but I don't know how complex it would be yet.
Observation: rox-filer is displaying thumbnails for all common pic formats, regardless of missing extensions. Clicking on such when having associated flpicsee as default viewer for pic formats results in an error popup window from flpicsee. rox-filer has "file.tcz" as a dep, I could blindguess that might be involved in the mechanism of determination.

Random example:
Code: [Select]
tc@box:~$ file .opera/cache/opr00VOJ  
.opera/cache/opr00VOJ: JPEG image data, JFIF standard 1.01
but then file.tcz is of multiple size compared to flpicsee, so I guess of no practical use at all

EDIT:
Code: [Select]
tc@box:~$ strings .opera/cache/opr00VOJ |head -n 1
JFIF
Title: Re: FL-PicSee 1.2.x
Post by: Pats on August 27, 2010, 09:03:16 AM
My Wishlist:
1) Image file Drop-down feature ( one should be able to drop image-files on Picsee)
2) Basic image-file conversion facility ( Eq: BMP to JPEG etc)
3) Repeated File chooser facility
4) One should be able to set Opend Image File as Backgorund Image.
5) Image Crop-up feature.
:)
~Pats
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on August 27, 2010, 11:38:35 AM
@tinypoodle: I looked at the file formats for ways to distinguish the types from their initial content and (thankfully) it seems straightforward for all of the types of images FLTK supports.  So I implemented it (only took a few minutes  ;) ).

FL-PicSee version 1.2.4 examines the first 16 bytes of the image file content for a distinguishing tags and sets the image type accordingly.  For the most common image types, I think this will be more robust that depending on the file extension, and I think the code size is about the same.  It is possible that .xpm and .xbm formats are a little too loosely-specified for my current code.  If anyone finds an image file that FL-PicSee does not correctly  identify and open, please let me know.  Maybe post it here if it is not too big.
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: tinypoodle on August 27, 2010, 11:47:33 AM
MikeLockmoore:

That was quick...  ;D
Sounds great, thanks
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on August 27, 2010, 12:26:14 PM
@tinypoodle: Maybe too quick.  :-[  I needed to correct something, and I took the opportunity to reorganize the image-type recognition code into a separate function that can be called from two different places.  Version 1.2.4 is the latest now.

@Pats:  I would also like drag-and-drop some day.  You can already select multiple files in the file open dialog box (ctrl+click each), or if you mean add additional files to the set you are viewing, you can do that with the "Open Another" menu item.  Or did you mean something else in point 3?  As for the conversion and cropping... I'm not sure I want FL-PicSee to turn into an editing tool.  If that happens, it will be further into the future.  RobertS asked for your suggestion 4 when I first made FL-PicSee.  There were changes being made in bakground image management in the base system, so I didn't try to implement it.  I hesitate to make a feature too Tinycore-specific, but I might as a compile-time option.
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: jls on August 27, 2010, 02:57:20 PM
After the modification u suggested when I press the win key I see:
You pressed key 65516 (0xFFEC)

and when I press the menu key :
You pressed key 65383 (0xFF67)
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on August 27, 2010, 03:53:40 PM
@jls_legalize: I special-cased your keys.  I'll post a new source version later today or tomorrow.  But if you want to test it yourself, just replace:

Code: [Select]
           if (key == 0) {                
                do_menu();
                return 1;
            }

with:
 
Code: [Select]
           if (key == 0 || key == 0xFFEC || key == 0xFF67) {                
                do_menu();
                return 1;
            }

Well, only the first line changed.  This is just a bit after the area you modified.  About line 703 in the 1.2.4 version.

EDIT: version 1.2.5 is attached here.  It has the above key handling code, plus the printf() for each keystroke that jls added manually.  If anyone else sees other key codes for their special context-menu key, please let me know.  This version also handles an invalid filename or non-image file in a more user-friendly way.
--
Mike
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on August 28, 2010, 06:38:52 PM
Posted a new version of the icon, attached to the original post in this thread above. Enjoy.
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 03, 2010, 08:31:36 AM
Version 1.2.6. One more minor improvement: if you manually page forward or backward while the slideshow is running, the paging timer is reset to allow a full 6 seconds on the new page.  Before, if there was only 1 second remaining before the time for the next picture, and you page manually, the picture you paged to manually would be replaced in 1 second.
--
Mike
Title: Re: FL-PicSee 1.2.x
Post by: ixbrian on September 05, 2010, 07:52:52 PM
I tried out FL-PicSee the other day and was impressed at the functionality and ease of use for such a tiny application.  Keep up the good work!

Thanks,
Brian
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 10, 2010, 10:16:50 AM
I've set up a Google Sites website for hosting my personal software projects: [removed: see extensions submission guidelines].  You can get to it through the little globe icon under my name on postings (<---  :)).  I have a .tgz extension file for the current beta version (1.2.6) of FL-PicSee posted there and some of my other stuff.  Anyone is welcome to look at my code and try something out.

I'm pretty close to submitting this beta version of FL-PicSee for the official repository.  I might bump up the version number before I do.
--
Mike Lockmoore.
Title: Re: FL-PicSee 1.2.x
Post by: jur on September 10, 2010, 03:51:28 PM
I tried the .tcz but couldn't get next, previous or slideshow to work.
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 10, 2010, 07:52:00 PM
EDIT: corrected "Open" to "Open with..." for XFE below.

@Jur: There's a few ways to load multiple files:

1) From the command-line, you can do something like:
  $ flpicsee file1.jpg file2.png file3.gif
or
  $ flpicsee *.jpg

2) Start flpicsee with no initial file.  The file selector dialog pops up.  Control-click on multiple files and press the OK button

3) Open one file however you like.  Pop up the context menu and select the "Open another" command.

4) In XFE file manager (maybe others), highlight multiple files, then right-click and choose "Open with..." (assuming flpicsee is associated with the open command for graphic image file types)

Once you have multiple files loaded, move your mouse to the upper left or right corners and you should see the "Prev" and "Next" buttons which you should now be able to use, or just use the keyboard shortcuts.

Another thought: you don't have the old "barebones" version of FL-PicSee still around, do you?  That version was built into some of the TC 2.x releases, but did not support paging and slideshow.  You should see version 1.2.6 in the titlebar if you installed the .tcz ok.

If none of that works, can you give me a little more detail?
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: jur on September 10, 2010, 09:32:27 PM
Perhaps I misunderstood how it should work... when I loaded multiple files, the slide show worked OK. I thought that it would be an automatic thing, where it looks for the next image file in the directory.

However, one thing that didn't work was control-clicking to load multiple files. Multiple files were hi-lighted but only the last one actually loaded.
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 11, 2010, 08:02:47 AM
@Jur: Do you mean in an external file manager or the file open dialog inside FL-PicSee?  The one inside FL-PicSee works for me, as well as XFE's "Open with..." command (slight correction from what I said earlier... XFE's plain "Open" will open multiple copies of FL-PicSee).
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: jur on September 12, 2010, 06:22:01 AM
Ctrl-clicking multiple files works when starting flpicsee with no arguments, but when using the right-click menu "open another" or Ctroil-O, multiples did not work. They were highlighted but did not load.

Suggestion: Image viewers I use often (gpicview, irfanview) will automatically look for the next image in the current folder. It seems to me not all that practical to have to load all the files you want to vies into memory first. That is OK for a few files but for lots of big files, the memory quickly  fills up. I think perhaps it needs to clear the memory before loading the next one, also to handle a full keyboard buffer. I quickly crashed my netbook when viewing a large collection of holiday photos.
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 12, 2010, 08:29:24 AM
Jur: Yes, you are correct that "Open another" only adds one image file to the set.  Maybe I can change it to allow multiple files like on the no-args start.

As for automatically loading other files in the same directory... I gave it honest consideration recently.  I avoided it to so far to keep the initial load time really fast, but perhaps I can come up with an implementation that is not too slow.  Something like:
1) Get the directory name from the initially-specified file
2) Load and display the initial image file
3) If there are no other events to handle, check the directory for any other valid image files
4) Load a small number of them (4?  or based on a time limit?)
5) Keep a reasonable number (8?) of them in memory as the user or the slideshow feature pages through them: unload the least-recently used image and preload the next unloaded one in the expected sequence.

This will take a bit more logic, but it would help avoid the kind of crash you experienced.  I also had a similar crash for a really large set of large image files, so I definitely see the benefit. I just hope it does not make the code a lot bigger or slower.  ;)  However, before I work on it, I may first release the current "load everything" version, because I think it is useful in many cases as-is.  Well, maybe I can squeeze multi-selection into the "Open another" feature first before requesting official release.  Then I can attempt the "load as needed" algorithm above in the next public release.
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 12, 2010, 09:15:46 PM
@Jur: I have implemented a multi-select capable "Open another" in version 1.2.7, attached below, or check my coding website [removed: see extensions submission guidelines] for the updated .tcz. 

I also added a short blog entry about it: [removed].
--
ML


Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on September 30, 2010, 08:23:35 PM
I guess I can't talk about my development blog here?  :-X

I have not heard any further issues with FL-PicSee version 1.2.7, so I just bumped it up to 1.3.0 and submitted the extension to the TCE repository.  If there are no issues with that, it should be released to the public soon.

I've attached a copy of the source code here for the convenience of anyone wishing to stay current.
--
Mike Lockmoore

 
Title: Re: FL-PicSee 1.2.x
Post by: jls on October 01, 2010, 01:28:07 AM
double click on an image (flpicsee.png for example) on e17 file manager (I've compiled it in this days) I get an error:
Image 'file:///home/tc/flpicsee/flpicsee.png' not found or viewable.
no problem opening the image from flpicsee file browser
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on October 01, 2010, 05:59:41 AM
@jls_legalize:  I added file format "sniffing" a few beta versions ago.  For PNG images, FL-PicSee expects to see the characters P, N, G at binary file offsets of 1, 2, and 3 (the 2nd through 4th bytes).  I know there is some allowed variation in the major "standards," but I don't know about all of them.

If you can, please please post an example image that does not work here, or email me (see my profile), I'll update the code.  Maybe I can get Jason to hold up the 1.3.0 release until this is resolved.

UPDATE: jls, are you sure that the newest version (1.3.0) in running in both cases?  Perhaps, when it works, it is really the old version that only checks the file extension part of the filename?
--
ML
Title: Re: FL-PicSee 1.2.x
Post by: jls on October 01, 2010, 07:31:00 AM
the image opens well using your program file manager, I think the problem is file:/// thing
Title: Re: FL-PicSee 1.2.x
Post by: tinypoodle on October 01, 2010, 07:55:34 AM
double click on an image (flpicsee.png for example) on e17 file manager (I've compiled it in this days) I get an error:
Image 'file:///home/tc/flpicsee/flpicsee.png' not found or viewable.
no problem opening the image from flpicsee file browser

Appears to work well with rox-filer.
Title: Re: FL-PicSee 1.2.x
Post by: tinypoodle on October 01, 2010, 08:01:11 AM
@tinypoodle: I looked at the file formats for ways to distinguish the types from their initial content and (thankfully) it seems straightforward for all of the types of images FLTK supports.  So I implemented it (only took a few minutes  ;) ).

FL-PicSee version 1.2.4 examines the first 16 bytes of the image file content for a distinguishing tags and sets the image type accordingly.  For the most common image types, I think this will be more robust that depending on the file extension, and I think the code size is about the same.  It is possible that .xpm and .xbm formats are a little too loosely-specified for my current code.  If anyone finds an image file that FL-PicSee does not correctly  identify and open, please let me know.  Maybe post it here if it is not too big.
--
ML


Works fine so far.

Thanks a lot for implementing this feature, makes the app much more universally usable!  ;D
Title: Re: FL-PicSee 1.2.x
Post by: MikeLockmoore on October 01, 2010, 10:43:12 AM
@ jls_legalize: Oh, I see. Is there a way to customize the e17 file-association so it launches FL-PicSee without the "file://" prefix on the command-line argument?  If not, maybe I add some code to skip that part of the filename.

Everyone: I did find another variation of JPEG image file that was not automatically recognized.  It will be in version 1.3.1, which may contain a "file://" prefix fix.
--
ML
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: MikeLockmoore on October 01, 2010, 12:05:40 PM
@ jls_legalize: Well, I had a few free moments around lunch today and just implemented the "file://" filter.  If any filename or directory argument is prefixed with "file://", that prefix will be stripped off before further processing.  Please try it out with e17.

all:

During testing the above, I found a bug related to opening a directory.  Fixed in 1.3.1.

I found that some JPEG files do not have "JFIF" or "Exif" in the expected place, but do have 0xFF and 0XD8 in the first and second bytes.  Added in 1.3.1.

I also commented out the key-code print statement used for early testing.

I'd appreciate some additional user testing of this version before I re-submit for the TCE repository.  Thanks to those who have tested it so far, and those who will in the future!
--
Mike L.
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: jls on October 02, 2010, 12:44:25 AM
now I can open pictures with efm (e17 file manager), thanx Mike
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: tinypoodle on November 18, 2010, 04:15:29 PM
flpicsee 1.3.0 appears to segfault when attempting to open pics with long filenames, while there is no such issue with flpicsee integrated in base of TC 2.10
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: ACRizona on November 29, 2010, 03:27:24 PM
Is this a bug ?
Open image#2 for viewing.
Ctl-N (next) and Ctl-P (prev)  do nothing  ???

Next, Ctl-O to open another image#3.
Now,  Ctl-N & P work  :o

                                                                                             
payable  to author:   1 ATTA BOY
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: MikeLockmoore on November 30, 2010, 10:51:49 AM
@ tinypoodle: Can you provide a specific sample filename that causes a problem?

@ ACRizona: Could very well be a bug.  Let me try to reproduce and if I see the same thing, I'll work on a fix.

Everyone: Most of my spare time for FLTK apps at the moment is devoted to Fluff file manager.  I should have time over the Christmas holidays to work some other things.  Or perhaps another person could volunteer to look into these and post code suggestions?
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: tinypoodle on November 30, 2010, 11:35:00 AM
@ tinypoodle: Can you provide a specific sample filename that causes a problem?

@ ACRizona: Could very well be a bug.  Let me try to reproduce and if I see the same thing, I'll work on a fix.

Everyone: Most of my spare time for FLTK apps at the moment is devoted to Fluff file manager.  I should have time over the Christmas holidays to work some other things.  Or perhaps another person could volunteer to look into these and post code suggestions?

little-man-in-the-boat-fisherman-mike-is-the-little-man-in-t-demotivational-poster-1263914605-big.jpg

The threshold of still working appears to be when removing 4 characters.

Note: I would have refrained from reporting this as bug and just have seen it as a software limitation, would it not work without any issue with flpicsee as shipped in base of TC 2.10.

Not saying fixing that would be of any high priority...   ;)
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: MikeLockmoore on December 01, 2010, 07:45:10 AM
@ACRizona: I'm not able to reproduce the problem so far with Fl-PicSee 1.3.1.  Is that the version you had trouble with?  If so, can you tell me exactly what steps you take when you see the problem?  E.g. do you initially start Fl-PicSee on the command line? With or without an argument for the first image file?  Do you use the menu item "Open another" for the second... and so on. 

@Tinypoodle: Sheesh.  ::)  I had to add a little more to the filename to get the crash on my computer.  Fl-PicSee can internally handle filenames up to 127 characters long, but somewhere less than that, the fully populated window title is more than FLTK can handle (title > 2 * filename len).  I think we can fix it by truncating the displayed file name in the window title to something reasonable, say about 60 characters.  By testing this I also found a length-related crash in Fluff, so thanks for that.  :)
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: ACRizona on December 01, 2010, 02:33:21 PM
@ACRizona: I'm not able to reproduce the problem so far with Fl-PicSee 1.3.1.  Is that the version you had trouble with?  If so, can you tell me exactly what steps you take when you see the problem?  E.g. do you initially start Fl-PicSee on the command line? With or without an argument for the first image file?  Do you use the menu item "Open another" for the second... and so on. 
- Starting from Wbar... no commandline.
 - Menu/Open file #22 for viewing.
 - Try Ctl-N next & Ctl-P previous. ???
 - Menu/Open another file#23 for viewing.
 - Ctl-N next & Ctl-P previous now work. :)

Back in the 60's -  IBM called these odd bugs "FAD" because
they Function-As-Designed.    ;D
Title: Re: FL-PicSee 1.2.x / 1.3.x PRE-RELEASE
Post by: tinypoodle on December 01, 2010, 11:22:34 PM
@ACRizona: I'm not able to reproduce the problem so far with Fl-PicSee 1.3.1.  Is that the version you had trouble with?  If so, can you tell me exactly what steps you take when you see the problem?  E.g. do you initially start Fl-PicSee on the command line? With or without an argument for the first image file?  Do you use the menu item "Open another" for the second... and so on. 

@Tinypoodle: Sheesh.  ::)  I had to add a little more to the filename to get the crash on my computer. 

Hmm... wondering then if perhaps the length of the absolute path could play a role, as opposed to filename only.
Which in consequence also makes me wonder about the different behaviour of flpicsee current vs. flpicsee as shipped in base of TC 2.10.
Could there be any chance that the different absolute path of both executables might play any role?
Or the fact that flpicsee in base is in $PATH, while flpicsee is not, but just designed as image viewer in rox file associations?