Feature Suggestions: Hidden menu w/ active key shortcuts, Option select not allowed outside image, canvas resize, remember last crop AR, save as JXL

[mdnava]

I just noticed issue #142 titled "Summary: Roadmap + Feature Request + Known Issues"..

So I though I gave my thoughts and suggestions:

1. Hidden menu items with active keyboard shortcuts. This could help to reduce (or prevent cluttering) the menu size of both "Open image with" and "User commands".
2. An option in JPEGView.ini for selection/crop to not overflow outside the image as it currently does. This would make it much easier to crop wallpapers with the right dimensions.
3. Canvas resize (man!! this is needed).
4. An option in JPEGView.ini to remember the last aspect ratio used when selecting/cropping.
5. Save as JPEG XL (.jxl) – it would likely also require preset options in the JPEGView.ini file.
6. Rename InputBox: Auto-select the image base name when the rename InputBox is opened/set on focus.
   (Perhaps also an option in JPEGView.ini?)
7. An option in JPEGView.ini to allow moving the window by holding the mouse left click, when IDM_HIDE_TITLE_BAR is enabled.
   » This currently works with ALT+LeftClick
8. FIX?: Slideshows don't seem to recognize any image path with Unicode characters (Korean, JP, UA, RU, etc..)

Once read and considered, perhaps this ticket can be closed.
If some or all of these features are chosen they could be mentioned over at #142.

Best regards!...

[sylikc]

Interesting ideas...

1. Backlog: The way it's designed right now already has minimal user feedback... start adding hidden items and everyone's going to get confused. Right now, for toggle items, people already either have to look at the menu checkbox or F1 to see what the option is set to. As power users, we might be able to remember what keys we hit and why... but yeah... I wouldn't say a never feature, but let's say backlog
2. Backlog for now, could be considered. The next upcoming feature for crop is crop to image AR
3. Backlog
4. Semi-Backlog Possible, and likely when I figure out the whole JPEGView.ini nightmare... it could be added later after the whole revamp is done
5. I put it in the feature list, but it'll be backlog for now
6. Done This could be possible, similar to the way FSViewer or other programs do it these days
7. wontfix: Holding the left mouse click is reserved for panning an image in default configuration. how do you pan an image if you zoomed in and left click now moves the window? ALT+LCLICK was the best compromise for retaining the current functionality, while adding that new feature
8. not a bug this might be a bug depending on how you're starting the slideshow... are you using a slideshow file? or how are you starting the slideshow? can you give me an example how to reproduce this bug? aka, what were the filenames in the folder, and I can reproduce the bug in my environment (don't even need to send me the files, tell me what to name them)

[sylikc]

I pushed a fix that exhibits this behavior to add the feature in (6)

[mdnava]

@sylikc

1. Backlog: The way it's designed right now already has minimal user feedback... start adding hidden items and everyone's going to get confused. Right now, for toggle items, people already either have to look at the menu checkbox or F1 to see what the option is set to. As power users, we might be able to remember what keys we hit and why... but yeah... I wouldn't say a never feature, but let's say backlog

Well, to avoid confusion, perhaps consider a new category for user commands with shortcuts only, and without any menu. Something like "User customized shortcuts", or just "User shortcuts". It could be a simple but very relevant and defining brand new feature. But I think JPEGView is somewhat limiting its potential with the current menus, which BTW are one of its best features. However, if this is considered I do think there should be a limit, like 32 or 64, or something like that. Whatever prevents the user from cluttering the configuration too much. Although, I'd bet that, once a feature like this is embraced there will be requests to upper or remove the limit.

I can still work without this feature though. I do use AutoHotkey a lot.

2. Backlog for now, could be considered. The next upcoming feature for crop is crop to image AR

Yes please! (to "crop to image AR").
Not overflowing selection/cropping would still be desirable.

Possible, and likely when I figure out the whole JPEGView.ini nightmare... it could be added later after the whole revamp is done

I mentioned adding the option to JPEGView.ini to offer the new feature as optional and not impose ir to the user.
But if it were me, I'd just set it to remember always the last used AR.

6. This could be possible, similar to the way FSViewer or other programs do it these days

Exactly.

7. wontfix: Holding the left mouse click is reserved for panning an image in default configuration. how do you pan an image if you zoomed in and left click now moves the window? ALT+LCLICK was the best compromise for retaining the current functionality, while adding that new feature

Makes sense. Perhaps the middle click then?
I don't actually need this feature at all.
It just made sense me to have it along with the IDM_HIDE_TITLE_BAR feature.

8. this might be a bug depending on how you're starting the slideshow... are you using a slideshow file? or how are you starting the slideshow? can you give me an example how to reproduce this bug? aka, what were the filenames in the folder, and I can reproduce the bug in my environment (don't even need to send me the files, tell me what to name them)

Yes, I'm using a slideshow file automatically created with a simple batch file from selected folders thru file explorer context menus. The Slideshow file is UTF-8 and characters show up correctly, but JPEGView seems to ignore any image path with foreign Unicode characters in it (for example: київ). Which is weird because the program can open them directly.

I have a folder with 980 wallpapers from an Ukrainian photographer. When trying to run a Slideshow with its contents it only recognizes 124 images; the ones that happen to not contain foreign words/chars like "Дима" or "Катя".

Best regards..

[sylikc]

Yes, I'm using a slideshow file automatically created with a simple batch file from selected folders thru file explorer context menus. The Slideshow file is UTF-8 and characters show up correctly, but JPEGView seems to ignore any image path with foreign Unicode characters in it (for example: київ). Which is weird because the program can open them directly.

I have a folder with 980 wallpapers from an Ukrainian photographer. When trying to run a Slideshow with its contents it only recognizes 124 images; the ones that happen to not contain foreign words/chars like "Дима" or "Катя".

I just tested this and it works fine. Please post more info, like your ini, show the behavior in a screen capture, etc...

I created a folder structure with

Дима.DNG
Катя.png
has spaces\Катя.avif
київ\Дима.jpg

I fed that into a text file, and then used the /slideshow parameter, and all 4 images cycled

[mdnava]

@sylikc

I just tested this and it works fine. Please post more info, like your ini, show the behavior in a screen capture, etc...

After this comment I did some testing.

The slideshow file is indeed read in full when saved as UTF-8+BOM and UNICODE, but fails if saved as simple UTF-8 without BOM, likely (I think) because JPEGView doesn't recognize it as UTF-8.

I attach an example:

Fail: Shows only 3 images (the ones without foreign chars)
$ jpegview64.exe Slide1-UTF8.show

Works: Shows all 8 images
$ jpegview64.exe Slide2-UTF8+BOM.show

Works: Shows all 8 images
$ jpegview64.exe Slide3-UNICODE.show

JPEGview-Slide-Test.zip

[Hrxn]

Yes, I'm using a slideshow file automatically created with a simple batch file from selected folders thru file explorer context menus. The Slideshow file is UTF-8 and characters show up correctly, [..]

Dunno, but how exactly are you creating such a slideshow file? Maybe something unusual happening at this step?

[mdnava]

@Hrxn @sylikc I create slideshow file with a simple Cmd Dir command within an AutoHotkey script:

pTmpSlideFile := EnvGet("APPDATA") . "\Slide.show"
FileDelete %pTmpSlideFile%
Sleep 25

; This loop allows to handle multiple arguments and path locations (dirs are appended to the slideshow file)
For n, sCurParam In A_Args {
	;
	; (some other code to handle other arguments, like, slideshow OrderBy and SlideTime)

	If Not DirExist(sCurParam)
		Continue

	; List image files recursively and append to slideshow file
	; We skip folders that start with a dot "." or between brackets "[*]"
	RunWait cmd.exe /c dir /s /b /a-d "%sCurParam%\*.avif" "%sCurParam%\*.jp*" "%sCurParam%\*.jf*" "%sCurParam%\*.jxl" "%sCurParam%\*.png" "%sCurParam%\*.webp" "%sCurParam%\*.heic" "%sCurParam%\*.heif" "%sCurParam%\*.gif" "%sCurParam%\*.bmp" "%sCurParam%\*.ti*" | findstr /i /v /R /C:"[\\][\.]" /C:"[." /C:"cmd.exe" >> %pTmpSlideFile%,, Hide
}

I tested the Slide.show text file and is recognized as UTF-8 by all editors I have available. But JPEGView for some reason just skips any path with foreign characters as I've mentioned.

Now, I did try to use AutoHotkey native code to create the Slide.show text file:

For n, sCurParam In A_Args {
	Loop %sCurParam%\*.*, 0,1
	{
		If (A_LoopFileExt In avif,bmp,gif,heic,heif,jfif,jif,jpg,jpeg,jpe,jxl,png,tif,tiff,webp) {
			FileAppend %A_LoopFileFullPath%`n, %pTmpSlideFile%, UTF-8
		}
	}
}

That works fine. The slideshow file created is also UTF-8, but JPEGView shows all image files correctly. However, this has the caveat that takes forever to handle a huge number of files. The AHK file loop is slow to a crawl. While the CMD dir command takes only a few seconds to populate 22.000 files into the Slide.show file, the AHK code takes several minutes.

Now. I've found a solution by prepending BOM to the Slide.show text file with printf:

FileDelete %pTmpSlideFile%
RunWait cmd.exe /c printf '\xEF\xBB\xBF' > %pTmpSlideFile%,, hide

For n, sCurParam In A_Args {
	RunWait cmd.exe /c dir /s /b /a-d "%sCurParam%\*.avif" "%sCurParam%\*.jp*" "%sCurParam%\*.jf*" "%sCurParam%\*.jxl" "%sCurParam%\*.png" "%sCurParam%\*.webp" "%sCurParam%\*.heic" "%sCurParam%\*.heif" "%sCurParam%\*.gif" "%sCurParam%\*.bmp" "%sCurParam%\*.ti*" | findstr /i /v /R /C:"[\\][\.]" /C:"[." /C:"cmd.exe" >> %pTmpSlideFile%,, Hide
}

This creates a Slide.show file as UTF-8+BOM which works fine with JPEGView. Is faster than pure AHK, and my problem is now solved. But I still think it would be best if JPEGView could handle a Slideshow file created by the Cmd Dir command output.

I did consider replacing the AutoHotkey script with a PowerShell script, which is also faster than AHK, and more flexible than Cmd to handle output and file creation. But AHK is just convenient. I can easily use hotkeys to start slideshows whenever I want to. I can also use the same script to start Slideshows from Explorer context menus.

Best regards!.

[sylikc]

@mdnava ah ha... that's where your problem lies.

Your cmd.exe script, while simple, has an error. You need to add the /u flag

[mdnava]

@sylikc

@mdnava ah ha... that's where your problem lies.

Your cmd.exe script, while simple, has an error. You need to add the /u flag

I tried the /U flag and it seemed to work at first try. But it stopped working when I removed printf. The slideshow file created with the /U flag seems to be UTF-8+BOM but for some reason still fails. JPEGView still ignores any path with foreign chars.

nDirCount := 0
pTmpSlideFile := EnvGet("APPDATA") . "\Slide.show"

For n, sCurParam In A_Args {
	;
	; (some other code to handle other arguments)

	If Not DirExist(sCurParam)
		Continue

	If (nDirCount == 0)
		FileDelete %pTmpSlideFile%

	RunWait cmd.exe /u /c dir /s /b /a-d "%sCurParam%\*.avif" "%sCurParam%\*.jp*" "%sCurParam%\*.jf*" "%sCurParam%\*.jxl" "%sCurParam%\*.png" "%sCurParam%\*.webp" "%sCurParam%\*.heic" "%sCurParam%\*.heif" "%sCurParam%\*.gif" "%sCurParam%\*.bmp" "%sCurParam%\*.ti*" | findstr /i /v /R /C:"[\\][\.]" /C:"[." /C:"cmd.exe" >> %pTmpSlideFile%,, hide
	
	nDirCount++
	Sleep 50
}

I attach the resulting slideshow file:

Slide4-U_PARAM.show.txt

But keeping the printf command to add BOM solves the issue for me:

For n, sCurParam In A_Args {
	;
	; (some other code to handle other arguments)

	If Not DirExist(sCurParam)
		Continue

	If (nDirCount == 0) {
		FileDelete %pTmpSlideFile%
		RunWait cmd.exe /c printf '\xEF\xBB\xBF' > %pTmpSlideFile%, , Hide
		Sleep 25
	}
	
	RunWait cmd.exe /c dir /s /b /a-d "%sCurParam%\*.avif" "%sCurParam%\*.jp*" "%sCurParam%\*.jf*" "%sCurParam%\*.jxl" "%sCurParam%\*.png" "%sCurParam%\*.webp" "%sCurParam%\*.heic" "%sCurParam%\*.heif" "%sCurParam%\*.gif" "%sCurParam%\*.bmp" "%sCurParam%\*.ti*" | findstr /i /v /R /C:"[\\][\.]" /C:"[." /C:"cmd.exe" >> %pTmpSlideFile%,, hide
	nDirCount++
	Sleep 25
}

Best regards!.

[sylikc]

Unfortunately, I'm going to have to defer to someone else to debug this... while I know about autohotkey, I don't use it myself...

I'm not quite sure how the interaction ... especially with findstr might work.

I created my list with cmd.exe /u and then same dir /b ... and it worked, so...

[mdnava]

Unfortunately, I'm going to have to defer to someone else to debug this

I understand. At first I thought it was an actual issue with JPEGView.
But I see now it can handle paths in slideshows with foreign characters just fine.

I created my list with cmd.exe /u and then same dir /b ... and it worked, so...

That's interesting. I might do some more testing later on. Or move on to PowerShell.
But for me, now is working. Albeit with a workaround.