Been setting up your Sixelgallery utility on my board, as a door. Working great when I define a single directory for viewing (in paths.json). However, if I point it to a directory with it's own subdirectories (such as a GIFs Galore), it not only doesn't display a list of subdirs to choose from, but it actually deletes ALL of those subdirs and their contents. Wondering if I'm missing something; or it doesn't allow browsing subdirectories.
Codefenix wrote to Gamgee <=-
Re: Sixelgallery question
By: Gamgee to Codefenix on Fri Feb 09 2024 01:59 pm
Been setting up your Sixelgallery utility on my board, as a door. Working great when I define a single directory for viewing (in paths.json). However, if I point it to a directory with it's own subdirectories (such as a GIFs Galore), it not only doesn't display a list of subdirs to choose from, but it actually deletes ALL of those subdirs and their contents. Wondering if I'm missing something; or it doesn't allow browsing subdirectories.
I'll have a look soon. I suspect the script is incorrectly
recognizing your subdirectories as temporary directories created
from zip extractions, in which case you can probably work around
the issue for now by setting cleanup_zip_subdirs to false in your paths.json file.
I honestly don't recall whether I had browsing subdirectories in
mind when I put this together. I think it should be able to do it
though.
I'll straighten this out. Thanks for letting me know.
YES! I hadn't thought of that, but changed that setting and it browses down into subdirectories now.
notice that every now and then it only shows a GIF very briefly and fails back to the dir listing; and after that any/all GIFs do that, until exiting the door and returning. I suspect that might be an "animated" GIF that "breaks" it, but not completely sure.
Thanks for looking into it some more. It is working pretty well now with the setting changed to "false". Appreciate it!
Codefenix wrote to Dan Clough <=-
Re: Re: Sixelgallery question
By: Dan Clough to Codefenix on Fri Feb 09 2024 04:03 pm
YES! I hadn't thought of that, but changed that setting and it browses down into subdirectories now.
This subdirectory deletion issue is fixed. Grab the latest
sixelgallery.js file from https://github.com/codefenix-ConChaos/SixelGallery and overwrite
your old one.
notice that every now and then it only shows a GIF very briefly and fails back to the dir listing; and after that any/all GIFs do that, until exiting the door and returning. I suspect that might be an "animated" GIF that "breaks" it, but not completely sure.
Interesting. I did actually play around with displaying multiple
output frames generated by ImageMagick, but I don't think I ever
pushed those changes to GitHub before today, so this may actually
be fixed now as well. Give it a try and let me know.
Thanks for looking into it some more. It is working pretty well now with the setting changed to "false". Appreciate it!
No problem, thanks again for providing feedback. Sorry about your
deleted subdirectories. Hopefully you were able to recover them.
You should be able to safely make that setting "true" now and
only delete temporary paths created as a result of unzipping
files. I tried it with my fsxNet NASA images today and it indeed
deleted those paths as indicated, but left all my other
subdirectories alone.
Gamgee wrote to Codefenix <=-
Codefenix wrote to Dan Clough <=-
Re: Re: Sixelgallery question
By: Dan Clough to Codefenix on Fri Feb 09 2024 04:03 pm
YES! I hadn't thought of that, but changed that setting and it browses down into subdirectories now.
This subdirectory deletion issue is fixed. Grab the latest
sixelgallery.js file from https://github.com/codefenix-ConChaos/SixelGallery and overwrite
your old one.
Fantastic, I'll do that. Thanks for the quick response!
I've got the new one installed, but have noticed something that's changed... The (S)caling toggle is no longer displayed on the main screen, and Scaling seems to be defaulted to OFF, as most images are too large for the screen now...
Codefenix wrote to Gamgee <=-
Re: Re: Sixelgallery question
By: Gamgee to Codefenix on Sat Feb 10 2024 09:12 pm
I've got the new one installed, but have noticed something that's changed... The (S)caling toggle is no longer displayed on the main screen, and Scaling seems to be defaulted to OFF, as most images are too large for the screen now...
Ah right, this is now controlled with the "resize" setting in
your paths.json file.
{
"name": "fsxNet Images",
"path": "c:\\files\\fsxnet_imge",
"cleanup_zip_subdirs": true,
"resize": true
}
I figured it was better to let the sysop control resizing on a
per-path basis, rather than having the user control it globally.
I updated the README.md this morning.
Yep, OK that works now. Thanks.
Thanks again. One last (minor cosmetic) thing I noticed - the "S" for scaling option is still displayed on the user prompt on main page. ;-)
Re: Re: Sixelgallery question
By: Gamgee to Codefenix on Sun Feb 11 2024 02:32 pm
Yep, OK that works now. Thanks.
Great!
Thanks again. One last (minor cosmetic) thing I noticed - the "S" for scaling option is still displayed on the user prompt on main page. ;-)
Dah... Ok, that's gone now. Thanks again.
I'm now trying the sixel viewer (as a door) on a directory with ZIP files in it, and when I choose a ZIP file (by pressing Enter on it), the screen blinks quickly but nothing else seems to happen. Choosing GIF or JPG files works fine, but not ZIPs. Don't think I missed anything config-wise, as I don't see anything related to this in the settings file. Any clues? Thank you.
Codefenix wrote to Gamgee <=-
Re: Re: Sixelgallery question
By: Gamgee to Codefenix on Fri Mar 01 2024 01:03 pm
I'm now trying the sixel viewer (as a door) on a directory with ZIP files in it, and when I choose a ZIP file (by pressing Enter on it), the screen blinks quickly but nothing else seems to happen. Choosing GIF or JPG files works fine, but not ZIPs. Don't think I missed anything config-wise, as I don't see anything related to this in the settings file. Any clues? Thank you.
Hmmm..
Are you running Windows or Linux out of curiosity? Either way, do
you have an "unzip" utility located in /sbbs/exec? The script
calls unzip to open the ZIP files. So if for some reason you
don't have unzip in this path, that might explain the problem.
(side note to self: I realize Synchronet now uses libarchive for
direct ZIP file handling, so I really should update the script so
it doesn't need to call unzip anymore. But I'm getting ahead of
myself)
Anyway, if you're using the Windows version of SBBS, then
unzip.exe *should* already be in /sbbs/exec. I don't know if it's
there on Linux; if it's not, then try installing it (i.e.: sudo
apt install unzip) and see if that fixes you up.
For grins, I copied 'unzip' to my /sbbs/exec directory, and... it now works as expected. But that surely isn't the "normal" way to use unzip, as it's defined in my system's $PATH already (to be in /usr/bin).
I think the issue is that Sixelgallery should be checking the $PATH to call 'unzip', rather than needing it to reside in /sbbs/exec. ...
I think the issue is that Sixelgallery should be checking the $PATH to
call 'unzip', rather than needing it to reside in /sbbs/exec. ...
Codefenix wrote to Gamgee <=-
For grins, I copied 'unzip' to my /sbbs/exec directory, and... it now works as expected. But that surely isn't the "normal" way to use unzip, as it's defined in my system's $PATH already (to be in /usr/bin).
Oh, agreed. I really only wanted to ascertain whether it would
"fix" the problem.
I think the issue is that Sixelgallery should be checking the $PATH to call 'unzip', rather than needing it to reside in /sbbs/exec. ...
The thing is though, SBBS for Windows ships with unzip.exe in
/sbbs/exec (at least it did in the latest non-dev release), so
this would end up breaking it in Windows, where unzip.exe is
expected to be found there.
ANSIview opens ZIP files the same way, so I imagine you're almost certainly having the same issue there opening ZIP files
containing packed artwork.
A long-term solution will ultimately involve removing external
calls to unzip altogether, and instead using the Archive class
which was introduced into SBBS as of 3.19. I'll have to ponder
this more though, since I don't want to break the script for
folks who might still be running <= 3.18.
So for now, as an inelegant workaround, we'll have SixelGallery
test for the existence of unzip.exe in /sbbs/exec before calling
it, and if it does not exist, then we'll simply call unzip
without supplying its path, assuming the utility exists in the
system path.
When you get a chance, remove the copy of unzip you put in your
/sbbs/exec directory and try the latest update I just made. If
all goes well, it should create a temporary subdirectory
containing your unzipped files, let you browse them, and then
remove them when you go back to the menu.
Digital Man wrote to Gamgee <=-
Re: Re: Sixelgallery question
By: Gamgee to Codefenix on Sat Mar 02 2024 07:47 am
I think the issue is that Sixelgallery should be checking the $PATH to
call 'unzip', rather than needing it to reside in /sbbs/exec. ...
Ideally, it'd use the built-in Archive class instead. But if it's
going to execute unzip, executing the command-line "%@unzip ..."
would expand to "\sbbs\exec\unzip ..." on Windows and "unzip ..."
on *nix: https://wiki.synchro.net/config:cmdline
Ideally, it'd use the built-in Archive class instead. But if it's going to execute unzip, executing the command-line "%@unzip ..." would expand to "\sbbs\exec\unzip ..." on Windows and "unzip ..." on *nix: https://wiki.synchro.net/config:cmdline
Re: Re: Sixelgallery question
By: Digital Man to Gamgee on Sat Mar 02 2024 01:20 pm
Ideally, it'd use the built-in Archive class instead. But if it's going to execute unzip, executing the command-line "%@unzip ..." would expand to "\sbbs\exec\unzip ..." on Windows and "unzip ..." on *nix: https://wiki.synchro.net/config:cmdline
Should %@ apply to system.exec calls as well?
e.g.: system.exec( '%@unzip -o -qq "zipfile.zip" -d "c:\tempdir"' );
Because this does not seem to work for me (Windows).
I probably will switch to using the Archive class eventually, but for now I don't want to break compatibility with <= SBBS 3.18.
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 719 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 189:14:12 |
| Calls: | 9,288 |
| Files: | 5,288 |
| D/L today: |
10 files (411M bytes) |
| Messages: | 467,688 |