Closed ZanaGB closed 2 months ago
Is the 500% scale setting (Edit -> Preferences) not enough? Would 600-800% help you see it better? Or are you just saying you don't like pixel fonts/retro-inspired UIs? 🤔 Creating a whole new vector UI is a massive ask IMO. Not to mention potential cross-platform considerations.
I personally am perfectly fine with the design, it's valid and follows the footsteps of popular trackers like Klystrack, Lovely Composer, MilkyTracker, all which have scale options so that the text gets larger on 4K displays etc.
It technically works, but the font itself is so low resolution that the only device where i can comfortably read it is on my 34 inch monitor at 200/300% scale. Trying to comfortably use the UI on something like my Framework 13 (13.5 inches, 2256x1504) is kind of painful and takes away real state. The problem itself is the "resolution" of the font, it being 5x5, and non-monospaced makes it incredibly hard to read (i have a fairly severe visual impairment).
Do not take me wrong, i love me some pixel art, and one of my hobbies is fontmaking, a search for my name on Pouet or dA should show you all the stuff i've worked on for 8 and 16 bit machines, including monospaced 3x5 and 4x5 bitmap fonts. However i'd never dare using them on an UI knowing i can't blow their size to 5mm vertical or equivalent.
However, needing to stop and trying to decipher the glyphs slowly to scan the UI is a terrible idea altogether.
I am surprised you say using a vector UI would be problematic to cross compatibility, when Dear IMGUI (the same thing Furnace uses), or QT or GTK forms for the application (if not Win32 for Wine) could get the job done. It would kill the vibe for sure, but that's an option.
Aseprite, a project whose aesthetics have clearly influenced WaveTracker (and unfortunately, a project i can't use as-is because of the god-awful low resolution fonts and ui elements) at least offers a theme definition file where one could mangle up a color scheme and has the font definition as part of an XML file, so while making the UI actually usable takes a significant amount of effort, someone with the know how of how to get the default theme definitions and modify the XML properties for said theme (something that should NEVER be expected of end-users to do) can change the font to something different, vector based, even. They have the worst possible way to go around it, but it's at least an option.
While the project is early it would be a good idea to tackle the UX accesibility problems, before things have been fully cemented.
However, your last comment seems to point that this program is for yourself, first and foremost, accessibility be damned. So, take my feedback as you will.
Accessibility issues are something I want to take pretty seriously and I try to do what I reasonably can to accommodate. A full remake of the entire interface to support vector fonts would for sure be an enormous undertaking. However, right now, I may be able to provide an option that switches all text to a higher resolution, sans serif font that will be more legible at larger scales than the default stylized one.
That option certainly is an improvement over the current state of affairs. If it were user selectable one could adaptnit better to their needs. But i am aware the UI tooling might expect bitmaps with specific sizes and kerning. So this gets us 90% of the way.
I know a sample size of one can't say much. But placing both images at the same relative scale on an image editor, the alternate font is easier to read on a variety of devices and distances. While could use some polish for a future version, thats a good approach as it stands.
I should probably stress an option like this one was exactly what was being suggested, first and foremost, rather than a straight UI once-over.
Is your feature request related to a problem? Please describe. The UI is neigh impossible to use on high DPI displays without substantial scaling
Describe the solution you'd like Alternate, high resolution, scalable fonts would resolve part of the problem. Alternatively, a standard Win32 UI could scale to any size and keep all elements, buttons, toggles, lists readable and acceasible, style be damned (a rework of the custom UI would always lead to conflict with the low resolution appearance, more clashing than high res fonts over low res fields)
Describe alternatives you've considered Not applicable to a visual problem
Additional context Using the program as-is is quite difficult due to how hard to see the elements are. Same with reading the text.