More > JRiver Media Center 25 for Mac

UX issues - menu selection?

(1/2) > >>

goatherder:
Is there a timeline of when MC Mac menus not working like Mac menus (i.e. you can't drag down on selections and release instead of clicking) would be addressed?

I always find it super distracting when I have to switch to "using like other OSs" mode when I'm on MacOS, since MC is completely unique in this respect among all the apps I use.

blgentry:
I don't work for JRiver.  I don't speak for them.  I'm just a customer.

My perspective is that it is a super duper low priority for them.  They wrote their own Mac toolkit in order to port MC over to Mac.  This kind of change would require them to go back into that toolkit layer and make it emulate the Mac look and feel.  I don't know how much work that entails.  It might be a lot. 

I can tell you there have been dozens of complaints about this in the past few years and so far no talk of changing it.

Brian.

goatherder:

--- Quote from: blgentry on October 22, 2019, 08:09:44 am ---I don't work for JRiver.  I don't speak for them.  I'm just a customer.

My perspective is that it is a super duper low priority for them.  They wrote their own Mac toolkit in order to port MC over to Mac.  This kind of change would require them to go back into that toolkit layer and make it emulate the Mac look and feel.  I don't know how much work that entails.  It might be a lot. 

I can tell you there have been dozens of complaints about this in the past few years and so far no talk of changing it.

Brian.

--- End quote ---

The more I come across how it's implemented, the more I feel like it could actually kill several birds at once if they fixed it at a fundamental level.

I have a major issue with the Windows version, which is centred around the lack of awareness for the actually modern OS UX (i.e. the Surface and its ilk way) which undoubtedly comes from having to address last-gen OS's like MacOS and Linux in the same presentation layer codebase. If they separated it out they could conceivably achieve a more OS-consistent look and feel.

Either way, neither application works like a current application should at this point in time on either OS.

blgentry:

--- Quote from: goatherder on October 22, 2019, 09:29:15 am ---I have a major issue with the Windows version, which is centred around the lack of awareness for the actually modern OS UX (i.e. the Surface and its ilk way)
--- End quote ---

I just read some of your comments over in the Windows version 26 forum.  I think touch screens on laptops are weird and a gimmick.  But you obviously disagree since you have owned them for many years, continue to buy more, and expect windows programs to behave nicely with touch screen.

Interestingly enough, I know someone who frequently demonstrates JRiver MC using a large (24" ?) external touch screen display.  He gets rave reviews from those that use it.  Maybe they are only doing the basics, like finding albums and artists and playing songs.  It seems to work quite well for that use.


--- Quote ---which undoubtedly comes from having to address last-gen OS's like MacOS and Linux in the same presentation layer codebase. If they separated it out they could conceivably achieve a more OS-consistent look and feel.
--- End quote ---

Let me tell you what I know about this.  Understand that I'm just a customer and have no real inside knowledge.  When MC was going to be ported to OSes other than Windows, the programmers wrote a shim layer for most (all?) graphical and audio calls.  Things that had originally been sent directly to windows components got turned into "JRiver_display" and "JRiver_audio" calls.  *those* calls are then passed on to a JRiver toolkit which is OS specific.  So, on Windows there's a JRiver_draw_window.  On Mac there's also JRiver_draw_window.  But the underlying code is different because the two OSes use different system calls to draw windows.

JRiver chose to write their own low level display library bypassing things like the Microsoft Foundation Classes and whatever the Mac equivalent is.  So the window drawing, menu handling, etc all actually look very similar across Windows, mac, and Linux.  But... none of them look exactly like the host OS.  It doesn't look like Windows.  It doesn't look like Mac.  It looks like... JRiver.

In order to make them look more native to each OS, that OS specific layer would have to be rewritten.  I think that would probably require a lot of work.  But I have no idea.  I just know this story at a very high level.  I hope I'm not making any major mistakes.

If I am, maybe Bob or one of the other developers will step in with a correction and/or opinion on the matter.

In conclusion I think it's unlikely that you'll see a "native look and feel" makeover for any of the OSes that JRiver works on.  But I could be wrong!  That's just my opinion looking in from the outside.

Brian.

Awesome Donkey:

--- Quote from: blgentry on October 22, 2019, 02:34:15 pm ---Microsoft Foundation Classes and whatever the Mac equivalent is.
--- End quote ---

Cocoa, I believe it is.

Navigation

[0] Message Index

[#] Next page

Go to full version