FL-PicSee 1.2.x / 1.3.x PRE-RELEASE

[MikeLockmoore]

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.

[jur]

I tried the .tcz but couldn't get next, previous or slideshow to work.

[MikeLockmoore]

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

[jur]

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.

[MikeLockmoore]

@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

[jur]

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.

[MikeLockmoore]

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

[MikeLockmoore]

@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

[MikeLockmoore]

I guess I can't talk about my development blog here?  

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

 

[jls]

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

[MikeLockmoore]

@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

[jls]

the image opens well using your program file manager, I think the problem is file:/// thing

[tinypoodle]

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.

[tinypoodle]

@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! 

[MikeLockmoore]

@ 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