Text fields behave poorly, not like any other OS textfields

I’ve noticed that text fields in Roon behave unlike any other text field on MacOS.

If a field is unfocused and text is in it, I should be able to double-click on a word in the field and have that selected and ready for type and replace. In Roon, double-clicking a word actually does nothing at all! The first click enters edit mode, the second click clears it, so you’re back to where you started. The same is true with clicking and dragging.

It appears I first have to “activate” a text field by clicking in it, at which point it changes from static text to editable text, which on 10.11 is both a different color (blue) and a different size. This is janky and unintuitive and violates all kinds of interface guidelines, as well as muscle memory and expectation.

Is this fixable? Please?

Hi Mike,

Roon is a cross-platform application and one of the design goals is to have a common UI experience regardless of the operating system the application is running on. Roon is intended to be OS agnostic. Sometimes that means that there are features of an OS that are not implemented in the Roon UI under that OS.

I don’t know if this particular issue falls into that category. Let’s leave a flag for @brian to see if he can tell us.

@Mike_Pinkerton – it seems like you are pretty technical, so I’m going to respond with the reality of our situation, and maybe we can do some changes to make this a bit better…

The problem is that we are not a native Cocoa UI app – we are OpenGL based. The entire application is one big NSOpenGlView and then our own rendering engine fills that in. This was a decision we made early on for performance reasons and cross platform portability. The reason our Windows, iOS, and Android apps all look the same as our Mac OS X app is because it is truly the same application inside, just a different shell.

This works pretty well, but there are 2 places where this sucks for our UI toolkit: scrolling and text input.

We go through quite a bit of trouble to handle the scroll events in such a way that they mimic the native toolkits, but we are not always 100%.

We could have implemented our own text controls too, but then we would have lost input languages/IME support from the OS, plus any native OS-level hooks for input. This is a huge deal on Windows, as there have been input systems for Japanese back from the MSDOS days that still work there, and there is no way we could implement the auto-completion stuff of Chinese.

So the mechansim we came up with is this:

  1. the inputs, as rendered in app are our own renderings.
  2. when you activate one, whether that be via tabbing or clicking or some other action, a Cocoa input control is overlaid in a new CALayer on top of the NSOpenGlView. When you leave that input, it is hidden and the CALayer is no longer applicable.
  3. we do a bunch of things to figure out font sizing and text selection so the experience is pretty close to the right thing.

Obviously we will never make it 100%, but the goal here is to be good enough.

So, given that… what irks you the most? It may or may not be fixable… let’s see.

1 Like

Thanks for the info @danny , that makes sense. I have a lot of experience working in cross-platform codebases (Mozilla, Chrome), so I get that there are tradeoffs. I also agree that trying to implement your own text fields is a non-starter, for the reasons you mention, especially IME. Thankfully, text editing isn’t part of the core user flows, but every time I do need it, I seem to stumble on it.

I think the two biggest things that destroy the illusion for me are 1) double-clicking a word not working and 2) having the text turn a different color and resize on focus/blur. A good demonstration of (2) is the Focus text field. If you type something in it, the text is blue and small. When you click outside it into the Focus area, the text turns black and grows in size. I think it’s actually a different font (look at the “a” in both). If the intent is to match what’s in the OpenGL view, then that area needs some more work.

Here’s an image of what I mean:

unfocused text field

focused text field

-mike

the font, I know… and it’s hard because 1) we dont subpixel render fonts in GL, but also 2) we use a different font than the system font, 3) we mix and match fonts for internationalization on display, but unsure how various system inputs work for mixed script fonts. For example, we pick a great japanese font on your system if you have it, but if you don’t, we back off to less good fonts. Either way, our Latin font is always ours. This is important since we dont ship anything but a free font.

the blue color thing is because our designer made the active state of inputs be blue. @brian2 – comment?

(btw, it looks like he missed the search input, which stays black)

Textfields definitely aren’t our finest point, I’ve made the input active state black now which makes this a little better. @Danny, if there’s other improvements we can make we should talk about them.