Wish A skin to darken the pop-up windows for Preset/Amp/Cab pickers

H3O2 said:
Would seem a simple request. How about just not "stark white" #FFFFFF, at least? Off-white? Ivory? The guys who can afford an Axe Fx tend to be a bit older like me(eyes need a break ;)), maybe, but there are a number of us, who are able to afford this great tech. I bought new every model new, since the Ultra. My favorite modeler for sure. FAS is second to none.
Click to expand...
I usually use #F8F6F0 for white and leave the retina-frying TiO2 #FFFFFF WHITE!!!!! for times when subtle highlighting is needed....
 
Greg Ferguson said:
I'm not sure. I looked at the development environment, HTTP://juce.com, and it seems to be configured from inside the code. If it's not set up for skins then adding them would require refactoring the GUI code.
Click to expand...
I may be asking for the glass of milk then? I once broke down the exe a long time ago to peer into it... I don't do software development, but I get what you're saying. thanks Greg.
PS. I appreciated your story about not working for apple.
 
laxu said:
JUCE supports themes via the LookAndFeel classes.
Click to expand...
Yes, I found that.

So far, when watching their tutorials and reading the class documentation, I only found how skins/themes are made at compile time and saw nothing about being able to use them at run-time and what the underlying definition is based on. There was a discussion that started in 2012 and had entries into 2019 that mentioned using a CSS-like language, but didn’t point to documentation or classes in the framework itself that implemented it.

Being compile-time-only fits with what I see when nosing around in the app folders. There are no support files, just the binary and OS-required files, so graphic elements and definitions are seemingly embedded into the code as char * arrays and are not available for end-user fiddling.

Obviously other open-source applications allow that ability, and the appropriate source code from them could be imported, but I wouldn’t go there if I was in charge of development of the editors at Fractal because they are a busy group as is. Adding the ability for users to fiddle with the look doesn’t directly improve the functionality of the Editor.
 
Greg Ferguson said:
Yes, I found that.

So far, when watching their tutorials and reading the class documentation, I only found how skins/themes are made at compile time and saw nothing about being able to use them at run-time and what the underlying definition is based on. There was a discussion that started in 2012 and had entries into 2019 that mentioned using a CSS-like language, but didn’t point to documentation or classes in the framework itself that implemented it.

Being compile-time-only fits with what I see when nosing around in the app folders. There are no support files, just the binary and OS-required files, so graphic elements and definitions are seemingly embedded into the code as char * arrays and are not available for end-user fiddling.

Obviously other open-source applications allow that ability, and the appropriate source code from them could be imported, but I wouldn’t go there if I was in charge of development of the editors at Fractal because they are a busy group as is. Adding the ability for users to fiddle with the look doesn’t directly improve the functionality of the Editor.
Click to expand...
That's not really what I was going for. The LookAndFeel classes should allow Fractal themselves to implement different themes if they feel like it - or just improve the styling of the pickers to go with the darker theme of the rest of the editor.
 
laxu said:
That's not really what I was going for. The LookAndFeel classes should allow Fractal themselves to implement different themes if they feel like it - or just improve the styling of the pickers to go with the darker theme of the rest of the editor.
Click to expand...
Yes, that is the point of the classes.

The UI needs to implement the underlying OS’ accessibility hooks so it reacts to the user’s defined needs. That would allow color-sensitivity, font sizing, all sorts of creature-comfort things.
 
I use dark mode on EVERYTHING, all the time. The cab selector window is absolutely blinding. Why it isn't fixed is beyond me.
 
Musikron said:
I use dark mode on EVERYTHING, all the time. The cab selector window is absolutely blinding. Why it isn't fixed is beyond me.
Click to expand...

Totally agree. It's disappointing that this hasn't been implemented. Every software developer and their dog has accessibility options these days, very surprised FA are lagging behind on this one.

Greg Ferguson said:
....Adding the ability for users to fiddle with the look doesn’t directly improve the functionality of the Editor.
Click to expand...

I'm not being at all pedantic when I say that the current look directly affects functionality of the editor for me and I assume, many others.
 
Greg Ferguson said:
Obviously other open-source applications allow that ability, and the appropriate source code from them could be imported, but I wouldn’t go there if I was in charge of development of the editors at Fractal because they are a busy group as is. Adding the ability for users to fiddle with the look doesn’t directly improve the functionality of the Editor.
Click to expand...

Accessibility issues do not affect the functionality of the editor, but they can affect the functionality of the user.
 
You must log in or register to reply here.
Back
Top Bottom