Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Open a file through ShaderGlass + suggested menu structure #123

Open
taitox opened this issue Feb 25, 2025 · 3 comments
Open
Labels
suggestion Suggestion

Comments

@taitox
Copy link

taitox commented Feb 25, 2025

Instead of selecting a window for input, it might be more intuitive to open a file via ShaderGlass and automatically capture its window, as it currently does with jpg/jpeg files.

As an addendum, I have been using this software for quite a while and just now noticed this feature for jpg/jpeg files, which impressed me and is very welcome. However, it also confused me at first. The "File..." label is ambiguous, leading to this suggestion, but renaming it to "Open image..." for now could clarify it's purpose for the user. This also made me think, as an interface designer, that the whole structure of the menu could benefit from a redesign for better intuitiveness.

(I will, stealthly, add to the "Open file" request a "Recent files" feature request. 👀 doforgiveme)

Here's my proposed menu structure, assuming it still opens in desktop mode:

  • File

    • Open file... (or Open image... if only capable of doing so)
    • Recent files > [List]
      Divider
    • Load profile...
    • Save profile as...
    • Recent profiles > [List]
      Divider
    • Exit
  • Capture

    • Capture desktop > [Same] (Lock is disabled if a file/window is focused)
    • Capture window > [Same]
    • Capture cursor (If this is about rendering or not the cursor)
      Divider
    • Pause (Boolean to avoid cluttering with two options)
    • Stop (Unsure why this exists tbqh)
      Divider
    • Fullscreen mode)
    • Take snapshot...
  • Settings

    • Input pixel size > [Same] (Renamed from Pixel size)
    • Window scale > [Same] (Renamed from Scale)
    • Force aspect ratio > [Same] (Renamed from Aspect Ratio Correction)
    • Frames per second > [Same] (Please use only %, eg, 100% Vsync, 50%, 33%, 20% etc)
    • Flip > [Same]
      Divider
    • Disable mouse click (Boolean, takes the place of Window > Click, Solid through)
    • Remove yellow border (Does this do anything?)
  • Shader

    • Favorite shaders > [List] (Mirrors the Favorite folder in the Choose Shader list)
    • Choose shader...
      Divider
    • Active (Comes before the others to mirror Play's position)
    • Next
    • Previous (Another stealth request forgiveme)
    • Random
      Divider
    • Parameters...
  • Help

    • Visit the project on GitHub
    • Frequently Asked Questions
      Divider
    • ShaderGlass vX.X (Beta) (Disabled)

Settings > Mode > Glass, Clone was ignored due to it being redundant if the options for Window or Desktop capture exist.
Help > README was ignored due to it being literally in the home of the GitHub project.

This suggestion is based on how menus work in other software. "File" is an important staple to find open/save/load/exit options. "Capture" could be called Play, but I avoided media playback terminology since we're not really playing media. "Play" then could work as a new menu if media-backend support is added later.* "Settings" consolidates input/output options into a simpler pipeline, and "Help" stays self-explanatory.

*I thought about making a Feature Request, but your hands are probably full, there's a request for cropping anyway and RetroArch is already able to handle videos.

Feel free to discuss or reject these suggestions. Either way, thank you greatly for this wonderful little piece of software. I really like to revisit old software so it has brought me and my 4K screen much joy :)

@mausimus
Copy link
Owner

Thanks for the suggestions, the menu has grown a bit over the years and its design has always been more technical-focused with deliberately separated Input and Output menus; and yes I was in a bind whether to have the omnipresent "File" menu or not. People use ShaderGlass in so many different ways it's hard to design it so that it works naturally for every use case, having it mirror the technical design was the easier way out. I'm also not sure if I want to continue going into Windows menus/dialogs or redo everything using an on-screen overlay, using ImGui or perhaps some custom display reminiscent of TV overlays. I'll keep the issue open and revisit when something bigger comes up, like loading custom shaders (technically they will also be files...)

@mausimus mausimus added the suggestion Suggestion label Feb 26, 2025
@taitox
Copy link
Author

taitox commented Feb 26, 2025

I'm also not sure if I want to continue going into Windows menus/dialogs or redo everything using an on-screen overlay, using ImGui or perhaps some custom display reminiscent of TV overlays.

If you proceed with this, I would ask that you consider keeping the current interface, unhidden by default but hideable per a toggle.

For example, Steam's interface was not replaced by the Big Picture view. While it could certainly be fun to navigate and use novel interfaces, providing new users with unorthodox ways to interact with a tool* will overly complicate it when compared to familiar experiences. This could make the user feel less secure when interacting with it, which is especially important for a tool.

*As opposed to a game, a ludic experience based on friction.

That said, it could certainly be fun. I just ask that you don't trash the current interface, if possible - both can easily coexist :) if you need my input as an interface designer with a passion for retro computers and software, I will be here to help.

like loading custom shaders (technically they will also be files...)

🙏

@IceLancerS
Copy link

IceLancerS commented Mar 3, 2025

Thanks for the suggestions, the menu has grown a bit over the years and its design has always been more technical-focused with deliberately separated Input and Output menus; and yes I was in a bind whether to have the omnipresent "File" menu or not. People use ShaderGlass in so many different ways it's hard to design it so that it works naturally for every use case, having it mirror the technical design was the easier way out. I'm also not sure if I want to continue going into Windows menus/dialogs or redo everything using an on-screen overlay, using ImGui or perhaps some custom display reminiscent of TV overlays. I'll keep the issue open and revisit when something bigger comes up, like loading custom shaders (technically they will also be files...)

Hello. This is not directly related to OP. But more on what you were saying.
I have big 21:9 screen and while your shader works wonders on native/ports/recompilation PC games as fullscreen shader it doesnt really fit into emulation (4:3/1:1PAR) scene
Mainly because emulators for those use some kind of overlay(bezel) and when this tvglass hooks into that, bezel becomes engulfed and changed as well. You have some tv bezels incorporated in some of shaders that glass offers. But they dont fit on anything that isnt 16:9 , because image stretches and as result game screen no longer fits inside bezels.

TLDR: What i am saying is what you said, really need some kind way to separate bezel from actual game render. Or maybe way to hook into render process of the app directly. So overlays(bezels) are not affected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Suggestion
Projects
None yet
Development

No branches or pull requests

3 participants