Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
C'mon. Even you don't believe this

The mouse isn't an archaic way of navigating a desktop, it is the way one navigates a desktop.

I personally swapped the Magic Mouse out that came with my iMac for a high end desktop mouse, and I am very happy with the experience.

It even has extra buttons that I've programmed features like mission control and cmd+h to.

If Apple released an iMac that called for the use of a touchscreen (on the screen??) I really believe that would be the end of the iMac. You'd look preposterous arching yourself onto your desk to tap your iMac screen.

Previously I have been very happy that Apple hasn't attempted a touch screen desktop.
Which mouse did you get? I'm sick of Logitech's crap software support. Though I do love my Performance MX. I'm thinking of trying a Razer Naga Hex...

Can't stand the new Magic Keyboard 2 either...but I like my current Mechanical Keyboard the CODE Keyboard from WASD.
 
Which mouse did you get? I'm sick of Logitech's crap software support. Though I do love my Performance MX. I'm thinking of trying a Razer Naga Hex...

Can't stand the new Magic Keyboard 2 either...but I like my current Mechanical Keyboard the CODE Keyboard from WASD.
I've been using Logitech mice a for a long time, I went with their high end gaming mouse (even though I don't game) the g700s because after comparing it with the mx master, I actually liked it better.

They're shaped very similarly, but the g700s has a nice grip on it and I preferred the clicker. I also preferred having extra buttons in place of a second scroll wheel.

The software seems glitchy at times but otherwise I haven't experienced too many issues with it. I just use it to map key commands and adjust sensitivity, things like that.

I'm open to looking into new brands as I have heard there are some brands that compete with or are supposedly better than Logitech.

A friend of mine has been raving to me about mechanical keyboards so I will probably be looking into one when I get the new iMac, as I am not crazy about the new magic keyboard either. I liked the previous magic keyboard but I have found the newest one to be harder to type on.
 
  • Like
Reactions: danielwsmithee
I've been using Logitech mice a for a long time, I went with their high end gaming mouse (even though I don't game) the g700s because after comparing it with the mx master, I actually liked it better.

They're shaped very similarly, but the g700s has a nice grip on it and I preferred the clicker. I also preferred having extra buttons in place of a second scroll wheel.

The software seems glitchy at times but otherwise I haven't experienced too many issues with it. I just use it to map key commands and adjust sensitivity, things like that.

I'm open to looking into new brands as I have heard there are some brands that compete with or are supposedly better than Logitech.

A friend of mine has been raving to me about mechanical keyboards so I will probably be looking into one when I get the new iMac, as I am not crazy about the new magic keyboard either. I liked the previous magic keyboard but I have found the newest one to be harder to type on.
If you are looking at suggestions for a Mechanical keyboard that works well with Macs, I looked around quite a bit before choosing mine. Here are my suggestions:

If you like keyboards with 10 keys. The DAS Keyboard 4 Professional Mac.
http://www.daskeyboard.com/daskeyboard-4-professional-for-mac/

If you prefer a 10-keyless keyboard the CODE keyboard 87-key version.
http://www.wasdkeyboards.com/index.php/products/code-keyboard.html

They are expensive but a good mechanical keyboard will last...
 
  • Like
Reactions: varian55zx
...I can't see Apple not going touch screen as it opens up a lot of cool possibilities for a desktop.....

It's not about the hardware to implement touch. For an optimal touch experience, the underlying OS and app ecosystem must be designed for touch. They must be able to process "touch events" not just keyboard and mouse events. The OS X API system nor Microsoft's Windows desktop API is designed for this.

You must have new APIs, a new OS paradigm, training and incentive for developers to use those new features, then it takes years for the apps to materialize. In short like iOS or Windows Metro/Modern apps.

It's true you can bolt on a touch screen, crudely remap some touch events to keyboard/mouse events, and run existing desktop software. That is what Microsoft does for older Windows desktop apps. E.g, a "long press" is remapped to right click or long press on a window corner is sometimes remapped to left click -- it is a clunky experience. Apple is not about doing things in a clunky, slipshod manner.

iOS and Microsoft's Metro/Modern API allows totally new apps running in a new, different ecosystem to use touch effectively. However they are totally different apps from the previous desktop environment. They are designed for mobile devices and do not have the API infrastructure or UI constructs to support a complex professional app. Nobody -- not Apple, not Adobe, not Microsoft -- has demonstrated the ability to port a full-featured professional app like Photoshop or Excel to a mobile environment.

So from a superficial hardware standpoint it is easy to create a touch-enabled desktop or laptop. That is not the problem. The difficulty is the software infrastructure to effectively harness this. There is no easy quick solution. Apple realizes this.
 
They are designed for mobile devices and do not have the API infrastructure or UI constructs to support a complex professional app. Nobody -- not Apple, not Adobe, not Microsoft -- has demonstrated the ability to port a full-featured professional app like Photoshop or Excel to a mobile environment.

Eh, I somewhat disagree with the assertion in the first sentence. The raw capability is there, but it is very expensive to develop an app as complex as Photoshop and Excel, which have both grown organically for decades on the desktop platform. And if you have to start from scratch on the UI part, you are looking at an awful lot of time investment to bring that touch UI up to the level of the desktop one. And to resolve scaling issues in a UI that complex a second time. It isn't so much a port as a reinvention of the UI, while porting the bits underneath the perform the internal logic.

The underlying code backing the application's logic isn't the biggest hurdle. It is one, but very straightforward compared to reinventing the interface for touch. But do consider that in the case of both Photoshop and Office, they have code legacy dating back to the 80s. These aren't modern apps by any stretch of the imagination, but they are valuable ones.
 
joema2 said:
They are designed for mobile devices and do not have the API infrastructure or UI constructs to support a complex professional app. Nobody -- not Apple, not Adobe, not Microsoft -- has demonstrated the ability to port a full-featured professional app like Photoshop or Excel to a mobile environment.

Eh, I somewhat disagree with the assertion in the first sentence. The raw capability is there, but it is very expensive to develop an app as complex as Photoshop and Excel....to resolve scaling issues in a UI that complex a second time. It isn't so much a port as a reinvention of the UI, while porting the bits underneath the perform the internal logic...The underlying code backing the application's logic isn't the biggest hurdle. It is one, but very straightforward compared to reinventing the interface for touch.

It has thus far proven impossible to port a full-featured complex professional app such as Photoshop, Excel, Premiere, etc. to a mobile device using the mobile UI. If anybody had the incentive to do this, it was Microsoft. The initial purpose of the "Metro/Modern" interface was to take over desktop development, not supplement it.

It will probably never be done on anything like the current iOS or Windows mobile platforms. A full-featured pro app like Photoshop or Excel has *hundreds* of menu options spread across various UI constructs -- multilayer fly out menus, pop-up menus, pick lists, large scrolling panes full of sliders, twirl-down arrows, preview thumbnails, etc.

You cannot access the full functionality of the product without these. It is not a matter of re-imagining the UI -- each current UI element must map to some simplified mobile UI element. But there is no place to put it all. The mobile UI is simply not designed to support that. Mobile devices also lack the richness and complexity of UI constructs to handle it. The UI "widgets" just aren't there for the developer to use.

You can definitely do a watered-down version on a mobile UI. Adobe initially did Photoshop Touch for iOS, which although not *remotely* equal to desktop Photoshop, at least had layers. It has been discontinued and the replacement Photoshop Express for iOS is much simpler still. So this rate of backward "progress" does not support the idea that mobile platforms will ever be able to run an app equivalent in functionality and UI richness to a complex desktop version.

Some future more sophisticated mobile platform with a more complex UI paradigm and richer UI constructs might achieve this, but it will be nothing like the iOS and Windows mobile platforms we are familiar with today.

Re the underlying code, you're right that is probably less a problem but typical high-end desktop apps are highly multithreaded and make extensive use of many different low-level concurrency mechanisms: spinlocks, thread pools, mutexes, etc. Such apps can be ported between Windows and Mac since the underlying API infrastructure has similar capability at the lowest level. However it is unclear whether *current* mobile device operating systems can handle that -- either at all or without a total re-think of how the core algorithms map to the API surface.
 
It has thus far proven impossible to port a full-featured complex professional app such as Photoshop, Excel, Premiere, etc. to a mobile device using the mobile UI. If anybody had the incentive to do this, it was Microsoft. The initial purpose of the "Metro/Modern" interface was to take over desktop development, not supplement it.

It will probably never be done on anything like the current iOS or Windows mobile platforms. A full-featured pro app like Photoshop or Excel has *hundreds* of menu options spread across various UI constructs -- multilayer fly out menus, pop-up menus, pick lists, large scrolling panes full of sliders, twirl-down arrows, preview thumbnails, etc.

You cannot access the full functionality of the product without these. It is not a matter of re-imagining the UI -- each current UI element must map to some simplified mobile UI element. But there is no place to put it all. The mobile UI is simply not designed to support that. Mobile devices also lack the richness and complexity of UI constructs to handle it. The UI "widgets" just aren't there for the developer to use.

You can definitely do a watered-down version on a mobile UI. Adobe initially did Photoshop Touch for iOS, which although not *remotely* equal to desktop Photoshop, at least had layers. It has been discontinued and the replacement Photoshop Express for iOS is much simpler still. So this rate of backward "progress" does not support the idea that mobile platforms will ever be able to run an app equivalent in functionality and UI richness to a complex desktop version.

Some future more sophisticated mobile platform with a more complex UI paradigm and richer UI constructs might achieve this, but it will be nothing like the iOS and Windows mobile platforms we are familiar with today.

Re the underlying code, you're right that is probably less a problem but typical high-end desktop apps are highly multithreaded and make extensive use of many different low-level concurrency mechanisms: spinlocks, thread pools, mutexes, etc. Such apps can be ported between Windows and Mac since the underlying API infrastructure has similar capability at the lowest level. However it is unclear whether *current* mobile device operating systems can handle that -- either at all or without a total re-think of how the core algorithms map to the API surface.

I think I said something similar to this earlier. I find it difficult to see how complex software would be delivered in a touch environment. And yes, Microsoft were / are the ones who should have the most incentive to deliver, but have come up far short of this, from my experience with the Surface.
Someone may do resolve this in an imaginative way that surprises us, but the current set up wont work. It is clear from a lot of iOS apps that the developer has struggled to get all features in the app in comparison to the desktop app, and these are not even close to the sophistication of apps like photoshop etc.

One thing to note is the user interface of Fusion 360. This could be transferred over and is the first app I have used where it feels like there is a possibility it could be used fully on a tablet. Still quite sophisticated though.

We will see I guess.
 
It has thus far proven impossible to port a full-featured complex professional app such as Photoshop, Excel, Premiere, etc. to a mobile device using the mobile UI. If anybody had the incentive to do this, it was Microsoft. The initial purpose of the "Metro/Modern" interface was to take over desktop development, not supplement it.

It will probably never be done on anything like the current iOS or Windows mobile platforms. A full-featured pro app like Photoshop or Excel has *hundreds* of menu options spread across various UI constructs -- multilayer fly out menus, pop-up menus, pick lists, large scrolling panes full of sliders, twirl-down arrows, preview thumbnails, etc.

You cannot access the full functionality of the product without these. It is not a matter of re-imagining the UI -- each current UI element must map to some simplified mobile UI element. But there is no place to put it all. The mobile UI is simply not designed to support that. Mobile devices also lack the richness and complexity of UI constructs to handle it. The UI "widgets" just aren't there for the developer to use.

Except, you can make those accessible, and while the OS may not provide the widget for it, you can always build your own. In fact, talking about Photoshop, Excel and Premiere, an awful lot of it is custom widgets. Neither Windows or Mac has a "Ribbon" control, for example, but Excel uses it. Hell, when all three of these were first being built (think 80s and 90s), the expectation in many cases was that if you wanted to do anything fancy, you were on your own. So you will actually see a lot of this stuff built up using a lot of custom UI code anyhow. And I'd be surprised if a lot of it has changed, since rewriting the code comes with a cost.

But I've worked with iOS enough to know that you can build out custom UI without breaking the model of how iOS handles drawing and input as the model is very similar to AppKit, and in some ways is cleaner to work with than AppKit since it lacks the legacy of OS X pre-Core Animation. But custom UI is not cheap. It can take months to build something out. And that's on top of the time it takes just to bootstrap this stuff.

And when I think about reimagining the UI, I'm thinking more about how to effectively use the space on a small screen, and how to leverage gestures as contextual cues. Or even just better ways to integrate a hierarchal toolbar into the screen so that it doesn't dominate the content you are working on. Office seems to think the right approach is to keep the ribbon. I'm not sure it is enough on its own though, but it is a starting point.

You can definitely do a watered-down version on a mobile UI. Adobe initially did Photoshop Touch for iOS, which although not *remotely* equal to desktop Photoshop, at least had layers. It has been discontinued and the replacement Photoshop Express for iOS is much simpler still. So this rate of backward "progress" does not support the idea that mobile platforms will ever be able to run an app equivalent in functionality and UI richness to a complex desktop version.

Some future more sophisticated mobile platform with a more complex UI paradigm and richer UI constructs might achieve this, but it will be nothing like the iOS and Windows mobile platforms we are familiar with today.

Yet, if we want to use Excel as an example, it has been gaining features from the desktop over time, not shedding them. Some of this is companies trying to figure out what people want to actually do on tablets and the idea that these are still companion devices, rather than something someone wants to use in a full-featured way.

Honestly, I'm scratching my head on where Adobe is going with their stuff. It suggests more that they don't know where to take their iOS apps more than anything else. But hey, I can edit RAW on iOS now with Lightroom, and that's meant it is finally part of my photography workflow the way I wanted it to be. So it's not all muddled wandering.

But I don't think we need a "more modern" mobile platform to achieve this any more than you needed Windows to be anything other than a box of legos to do the same. But again, you have to have developers heading in the direction of richer apps (which the market data currently seems to point away from at the moment, yay?) and actually incentivized to invest the time and money required to deliver such a beast. There really isn't anything complex about the desktop paradigm, just that there's been 3 decades of work building up on that foundation that has given us what we have today, a lot of it coming from 3rd parties.

Honestly, if I wasn't tied to the company I work for at the moment, and money was no object, I'd be interested in pursuing the answers to the UI hurdles. But then I look at the size and scope of the multi-platform project I do work on (with both desktop and mobile apps sharing the same codebase), and accept that it's well beyond the scope of what one person can contribute on their own.

Re the underlying code, you're right that is probably less a problem but typical high-end desktop apps are highly multithreaded and make extensive use of many different low-level concurrency mechanisms: spinlocks, thread pools, mutexes, etc. Such apps can be ported between Windows and Mac since the underlying API infrastructure has similar capability at the lowest level. However it is unclear whether *current* mobile device operating systems can handle that -- either at all or without a total re-think of how the core algorithms map to the API surface.

I recommend reading up on this before making comments like this, since it exposes the gaps in your knowledge. If we want to talk about that, then I'll simply point out that those mechanisms, using Mac and iOS as the example, are identical between the two. GCD, which is your thread pool mechanism for Apple platforms has identical functionality in both places, you have your normal atomics in the OS API, and the usual pthread stuff works in both places if you really need to write some POSIX-level stuff to try to avoid rewriting it too heavily for other platforms. On Win Mobile, you have the usual .NET stuff, including modern techniques like async/await if that's your ball of wax.

I'd actually go so far to say there's more difficulty porting between Win and Mac than there is Mac and iOS. Why? Because the approach to how Microsoft and Apple build their APIs is drastically different and you have to build layers that account for both approaches. If you don't, you find yourself sacrificing one platform's abilities to support the other. If going between Mac and iOS, the biggest difference is UIKit vs AppKit, and you can even smooth some of those over if that's your goal.

And the irony here is that the more established these apps are, the less likely it is actually multithreaded well, due to legacy code from decades ago. Yet, you will actually do better on iOS if you can at least be running on two threads instead of just one.

The one area I can think of that is a hurdle is things like enforced entitlements on iOS. When your app was written in an era where you kinda expected to be able to read/write any file you want, and not expecting APIs to fail due to the user blocking your access, it can be somewhat expensive to work through the issues.
 

Hi, you seem like you really know what you are talking about on these issues.

When I first thought of touch, my instinct was not necessarily touch, but more for integration with apple pencil. Which would in essence make it a touch screen.

Would it be possible for Apple to easily add hover function to the screen, so nothing changes, only the screen recognises Apple pencil hovering over it, so a person could just use pencil nib to tap icons, for example, and not click and point with the mouse.

That way, it's the best of both worlds. Designers/artists could, in theory, lower the iMac and draw directly into apps like Photoshop, Painter etc, and others who are not design orientated could carry on with click and point?
 
joema said:
It has thus far proven impossible to port a full-featured complex professional app such as Photoshop, Excel, Premiere, etc. to a mobile device using the mobile UI.

Except, you can make those accessible, and while the OS may not provide the widget for it, you can always build your own.

Then why has nobody done it? Neither Apple nor Microsoft with their vast resources have been able to port a full-featured desktop professional app to a mobile platform. They have had *years* to do this. I submit it is likely impossible and will *never* be done, not on mobile platforms as they now exist.

But the "proof is in the pudding" as they say. If you are right then we will have 100% full-featured versions of Photoshop and Excel on current-architecture mobile platforms. I suggest you mark this down on your calendar and start counting the years until it happens.

joema said:
Re the underlying code, you're right that is probably less a problem but typical high-end desktop apps are highly multithreaded and make extensive use of many different low-level concurrency mechanisms: spinlocks

....I recommend reading up on this before making comments like this, since it exposes the gaps in your knowledge...

Look up how to implement a spinlock in iOS and report back on that. If the answer is "Oh, just don't use spinlocks and don't use synchronous requests, re-write them to something else" -- yes that can be done but the problem is it MUST be done. Porting between Win and Mac does not require this degree of re-writing because the OS sophistication is similar on either side.

....On Win Mobile, you have the usual .NET stuff, including modern techniques like async/await if that's your ball of wax.

Similar limitations exist in Win Mobile which inhibit porting a full-featured professional desktop app: See: http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/6/

...I'd actually go so far to say there's more difficulty porting between Win and Mac than there is Mac and iOS....

We are talking exclusively about porting high-end, full-featured desktop apps between Mac and Win or iOS. How can you say there is more difficulty porting these between Win and Mac when these are ported routinely, yet NOBODY has EVER ported one to iOS? I would submit it is not only more difficult for this class of application but it has thus far proved impossible.
 
An iMac Pro would be great, though 'better speakers' and touchscreen would be the last things on the list.

Most audio Pro's will have an external sound card hooked up to monitor speakers...

Stick two SSD's in there with a decent graphics card and you'all have your iMac Pro...it would need to be thicker with better fans/cooling also...
 
  • Like
Reactions: danielwsmithee
As a digital artist, and an avid iPad Pro user, I can see a definite reason for Apple to expand into the area of touch screens on iMacs. They seem to be going hard after the concept of completely shutting down Wacom, and Wacom has actually been experiencing a surge of interest in digital artists wanting to use their products, from my understanding. The booming "fan art" community has given a tremendous amount of exposure to digital artists and the tools they uses to make digital art.

So, while I don't know if Apple would incorporate it into their main SKU of apple monitor or reserve it for their external display, I do think we'll see Apple pencil functionality make the jump from mobile to desktop at some point.
 
As a digital artist, and an avid iPad Pro user, I can see a definite reason for Apple to expand into the area of touch screens on iMacs. They seem to be going hard after the concept of completely shutting down Wacom, and Wacom has actually been experiencing a surge of interest in digital artists wanting to use their products, from my understanding. The booming "fan art" community has given a tremendous amount of exposure to digital artists and the tools they uses to make digital art.

So, while I don't know if Apple would incorporate it into their main SKU of apple monitor or reserve it for their external display, I do think we'll see Apple pencil functionality make the jump from mobile to desktop at some point.
I could see that as a possibility. I'm actually hoping that Apple/Adobe will develop simultaneous realtime editing between both a desktop and iPad Pro. For example using an iPad Pro with an Apple Pencil as a Wacom tablet, where the same file was open on both at the same time and allowed you to use whichever tools makes most sense for the operation in a seamless manner.
 
Then why has nobody done it? Neither Apple nor Microsoft with their vast resources have been able to port a full-featured desktop professional app to a mobile platform. They have had *years* to do this. I submit it is likely impossible and will *never* be done, not on mobile platforms as they now exist.

But the "proof is in the pudding" as they say. If you are right then we will have 100% full-featured versions of Photoshop and Excel on current-architecture mobile platforms. I suggest you mark this down on your calendar and start counting the years until it happens.

"Vast resources" can also be called "too many cooks in the kitchen". On this front, just read up on the mythical man month to understand why "vast resources" is not a good reason to claim that this should magically exist because it has been X amount of time. And you can't expect a company to pour 100% of their resources into one piece of software to make it happen either. Not when customers would then say "why are you abandoning us?" when you ignore the desktop for the many years it would take.

But as I keep pointing out (and this is the last time I'll do it, since you never seem to respond directly to it): Porting a giant app to a fundamentally similar platform can be done yes. However, when you are porting to a very different paradigm, you have to rework a lot more code. And in the case of touch, you are basically building your UI from scratch, and a lot of it is built on top of custom UI code that was written decades ago for platforms like Win 95 and "System 7". It isn't well separated. You cannot take a UI that's grown organically since the 80s and expect it to just poof over to tablets fully intact.

Look up how to implement a spinlock in iOS and report back on that. If the answer is "Oh, just don't use spinlocks and don't use synchronous requests, re-write them to something else" -- yes that can be done but the problem is it MUST be done. Porting between Win and Mac does not require this degree of re-writing because the OS sophistication is similar on either side.

You do realize the QoS spinlock problem isn't unique to iOS right? OS X has the same QoS behaviors, and in the case of the 12" MacBook, you can run into the same types of deadlocks as it is the easiest to get into this state.

And "OS sophistication" in this case really comes across as "legacy behavior" if this is your best example. But the degree of re-writing is partly my argument for why we don't see the numbers of features yet (but my claim is the bigger cost is the UI portions, not the lower level code behind it). That and a mix of developers trying to get something out in a reasonable time to customers rather than ignoring it, or ignoring their existing users. The irony here is that if we had QoS and GCD 10 years ago, devs would be complaining about the impact to their legacy apps. The early Core Duo stuff really could have used it though to get more responsive behaviors from the system and apps.

Similar limitations exist in Win Mobile which inhibit porting a full-featured professional desktop app: See: http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/6/

We are talking exclusively about porting high-end, full-featured desktop apps between Mac and Win or iOS. How can you say there is more difficulty porting these between Win and Mac when these are ported routinely, yet NOBODY has EVER ported one to iOS? I would submit it is not only more difficult for this class of application but it has thus far proved impossible.

Yeah, WinRT makes it harder than it has to be. But so did Cocoa. Those ports still happened, eventually.

But fundamentally, WinRT isn't a "touch" framework. It isn't a mobile framework either (but aspires to be used there and on Windows Phone/Mobile it has displaced the Silverlight-based API from the earlier days). It is a full framework that was originally envisioned to be a modern replacement for the aging Win32 API set. Much like Cocoa is for Mac, and Carbon was supposed to be the bridge into that new world. But the reality is, it's not a framework I actually like. There are some nice modern features that are utterly missing from Win32 if you need to build a new app, and the integration with .NET is nice. But it is really easy to find yourself in "build everything yourself" mode like with Win32 if your code is C/C++. It's not a great tablet framework either due to these issues. Something Apple is much better about, IMO.

You also mis-read my claim. My claim is that the APIs are more different between Windows and Mac, than Mac and iOS. The fact that they are ported routinely is not something I'm contesting, although I might contest the quality of some of those routine ports that actually bring along parts of the OS with it. Hell, the fact that ports of some of these apps bring pieces of their OS with them helps back my claim. Apple brings parts of CoreGraphics with them for iTunes and Safari on Windows. Microsoft does the same the other way (I invite you to look at the framework list sometime in Office). It's the fact that the devices are wholly different paradigms that poses the problems. It is not a technological hurdle in that "if only the APIs did X" we'd be able to do it, but one of creativity and time spent building out the application on the platform. And the fact that these apps have grown organically for decades should give you an idea that the timeframe isn't short to reinvent the UI for mobile platforms, software keyboards, etc.

And again, Adobe appears to be trying to explore the mobile space rather than port their app. Maybe that leads to a version of Photoshop written more cleanly that catches up to the desktop version eventually. All I know is that Lightroom Mobile is certainly capable at this point, if they would add more fine tuning features rather than giant sliders as the only UI mechanism to adjust settings.

Anyhow, this is the last time I'll post on this topic. But suffice it to say, this is an area of passion for me because I work in this space. These problems are the problems I work on each day.

Hi, you seem like you really know what you are talking about on these issues.

When I first thought of touch, my instinct was not necessarily touch, but more for integration with apple pencil. Which would in essence make it a touch screen.

Would it be possible for Apple to easily add hover function to the screen, so nothing changes, only the screen recognises Apple pencil hovering over it, so a person could just use pencil nib to tap icons, for example, and not click and point with the mouse.

That way, it's the best of both worlds. Designers/artists could, in theory, lower the iMac and draw directly into apps like Photoshop, Painter etc, and others who are not design orientated could carry on with click and point?

It's possible to do hover. But you still need to detect a tap being different from hover, so at that point it is still touch driven. The real issue I think is: is it worth building the iMac into a Cintiq for the subset of customers who will use the feature? My own thoughts tend to be in the vein of probably not. Of course, if there was enough data otherwise, I could be convinced otherwise. But it boils down to the iMac tends to come with one flavor and multiple performance levels. Would there be enough benefit to roll this out and make every customer buying this flavor pay for the technology?
 
...Porting a giant app...to a very different paradigm, you have to rework a lot more code. And in the case of touch, you are basically building your UI from scratch...

I am definitely not contesting that *attempting* to port a high-end professional desktop app to iOS would take a lot of work. Rather your statement "The raw capability is there, but it is very expensive".

I don't think we will *ever* see a complex full-featured desktop app ported to a mobile OS as mobile platforms now exist. Each little dark corner of that legacy app -- spread across hundreds or thousands of deeply nested interface elements -- is connected to some functionality which serves some customers. There is simply no UI space to put all that in a current mobile OS. You can water down the app and produce a lightweight version -- that has already been done. But it's not expensive to port such an app to iOS -- I submit it's practically impossible. Nobody has done it so far, despite tremendous incentive. Time will tell if it's *ever* done on current mobile platforms, but I don't think so.

..."OS sophistication" in this case really comes across as "legacy behavior" if this is your best example.

I agree that non-UI core OS features are more doable on a mobile device. I only mentioned various legacy synchronization mechanisms as an example of something that complicates porting to a mobile OS, not to indicate that one aspect is impossible.

....Windows and Mac...The fact that they are ported routinely is not something I'm contesting...

Yes, complex desktop apps are routinely ported between Windows and Mac. Examples are Excel, Photoshop, Premiere CC, etc. None of these have ever been ported in full-featured status to a mobile OS. No developer has even articulated a credible path or timeframe for doing this. And I use the term "port" loosely here. Even expanding the definition to include a totally different, re-imagined, fundamentally rearchitected mobile app which has feature parity with the desktop version -- no developer has achieved that or even outlined a plan for getting there. I don't think it's expensive, I think it is practically impossible as mobile platforms currently exist.

This is an issue because there's a widespread viewpoint that touch-oriented mobile platforms can completely take over all or most desktop functions. Tim Cook himself said (within the last year) about the iPad Pro: "Why would you buy a PC anymore?". Simple: current tablets -- even the iPad Pro -- cannot run applications that equal the functionality of full-featured desktop apps like Excel, Premiere and Photoshop. This is not some tiny little niche of users. There is thus far no indication that current mobile platforms can run apps of this UI complexity, however drastically they are redesigned. Nobody has even demonstrated a mock up of how the UI might work, much less produce an actual product.
 
Yeah, I said I wouldn't respond anymore, but I can't resist the bait...

I am definitely not contesting that *attempting* to port a high-end professional desktop app to iOS would take a lot of work. Rather your statement "The raw capability is there, but it is very expensive".

I don't think we will *ever* see a complex full-featured desktop app ported to a mobile OS as mobile platforms now exist. Each little dark corner of that legacy app -- spread across hundreds or thousands of deeply nested interface elements -- is connected to some functionality which serves some customers. There is simply no UI space to put all that in a current mobile OS. You can water down the app and produce a lightweight version -- that has already been done. But it's not expensive to port such an app to iOS -- I submit it's practically impossible. Nobody has done it so far, despite tremendous incentive. Time will tell if it's *ever* done on current mobile platforms, but I don't think so.

Tell me what the incentive is. When I look at the tablet market today, there's a lot of developers asking how they can monetize the platform for anything beyond the 0-5$ range. There's certainly niches that will welcome them, including me, but it isn't like Adobe is going to be able to market to people who wind up using less expensive competitors. Hell, I'd love to know how Pixelmator for iOS is actually doing in terms of sales and if it actually funds further development yet.

I'll also argue that there are apps that already share their code with their desktop counterparts on the market today. But because all the user sees is the UI, and we aren't in the habit of deep analysis of binaries, you don't even notice when you are using one of them.

And here's the biggest problem with your argument. You are basically claiming that because someone hasn't cracked problem X yet, the problem must be impossible to solve. As it has been said in the past, absence of evidence is not evidence of absence. Especially when you later claim that developers aren't articulating a plan, which is demonstrably a bad argument since it is obvious that these developers have plans. The public just isn't privy to the details of those plans. In part because plans tend to turn into nooses in the court of public opinion, and free research for competitors. So if you want to demonstrate that there is no tablet roadmap, you have to actually cough up evidence. Otherwise you are appealing to your own ignorance of the work actually being done.

About the only other point brought up that I'll respond to, because I've either responded to it by now and would be repeating myself, or it starts getting wider field than the topic at hand is the definition of port you give:

Yes, complex desktop apps are routinely ported between Windows and Mac. Examples are Excel, Photoshop, Premiere CC, etc. None of these have ever been ported in full-featured status to a mobile OS. No developer has even articulated a credible path or timeframe for doing this. And I use the term "port" loosely here.

If your definition of port is like that, I can list a few desktop ports that don't even meet the criteria. Mac Office being one of them.

For me, the key criteria for a port is: Is the codebase fundamentally identical between the two platforms, minus the parts that must change to support the new platform? If that is true, that to me is a port. And those kinds of ports do exist already on iOS at all scales (Simple stuff like Doo, to more complicated stuff like OmniFocus, and behemoths like Office). Yes, the definition I'm using is a bit fuzzy, but the goal of a good port is to be able to reuse as much code as possible, so that features accrue to all platforms as equally as possible. You can do sloppy ports that are faster, but I've already pointed out some of the problems with both Apple and Microsoft on that front. Adobe is probably the better set of multi-platform apps from an engineering perspective, but they seem to be in hobby mode when it comes to tablets. That said, again, Lightroom Mobile is featured enough for me to now use it in the field as a companion with my LR catalog at home, which meets how I would use it primarily on the tablet.

I've commented in other threads (over in the iPad Pro threads) on this topic as well in the past saying I think the bigger, established players are actually at a disadvantage. Larger codebases that date back further, and tend to pepper the entire codebase with platform-isms that are more expensive to solve. While a startup like Pixelmator can grow their apps on both platforms more organically. My own bet is that if it were a race to who could develop a full featured Photoshop-type app on iOS and solve the UI hurdles, Adobe itself would probably lose to a well-funded competitor that was much younger. We'll see if Affinity can deliver a shipped product after their demos.
 
My guesses are Apple will bring the iMac in line with the iPads and MacBooks and introduce a Pro model to the lineup.

The current lineup is a mess, with no clear distinction made between the top models and the budget models.

The 'Pro' tag will also allow Apple to play around a bit more with the iMac, and possibly even do the unthinkable and allow upgradeability to the CPU or GPU in a limited way. Of course this will only happen if they manage to find an extremely elegant way of doing it, akin to sim card changes in the iPhone.

More realistically however, is for the iMac Pro to have touch screen, be VR ready, have much better speakers, SSD's and probably much better Siri integration like the Amazon Echo where it is always listening even when in sleep mode.

Anyone else think iPad Pro is a probability, and if so, what will it need to earn the tag 'Pro?
More realistic?! Apple allowing easy access to the internals is more likely than a touchscreen on a iMac!

If we see a redesign, the speakers will get better following the trends of the iPads and MacBooks.
SSDs are already great and have been for a long time. The next step for storage is Optane (3D X-Point) which we won't see in large capacities soon.
Always active Siri is quite likely, using an improved microphone array but it would be for all iMacs.

The Pro market still want both internal upgradeability and internal expandability.

They already have a new Mac Pro ready in the pipeline, an iMac Pro could harm sales, and it wouldn't fit with Apples Pro upgrade cycle.
[doublepost=1475522743][/doublepost]
Whether we like it or not, touchscreen is coming. I was killing time at a Costco, and saw a Wintel machine with a touchscreen and started swiping away, and didn't see any problem with it. Now, we might like a pristine screen, but a finger isn't the only means to use a touchscreen, so ready or not, here it comes, with your usual Apple bells and whistles to make it seem like they think they invented it.
You didn't see any problem with it because you were killing time at Cosco, likely standing up. That's not the same as using a touchscreen all-in-one at your desk. If people wanted it on the iMac, there would be demand but there isn't. Touch on an iMac would be a novelty, although you might use it every now and then, it really becomes a hassle to constantly reach out and tap the screen.
 
  • Like
Reactions: imanidiot
Force trackpad with ability to mimic 3D Touch on the iMac screen and compatibility with pencil to draw so it shows up on iMac screen.
 
More realistically however, is for the iMac Pro to have touch screen,
I can't even imagine trying to be productive on a touch screen mac. Lots of Macs are used in offices where they manipulate large documents ( envision a spreadsheet 2000 rows by 200 columns or larger and this is just one sheet in a group of several ). Can you imagine how long it would take for me to put my big finger on the screen to identify ( let's say ) 15 or 20 non-continguous cells that are each 1/8th the size of my finger tip? With a mouse I can do this in a few seconds ( and probably quicker if I'm really pressed ) but I'd make many mistakes using my finger plus I'd have to clean the finger prints off the screen to see what I'd selected. Factor in hundreds of spreadsheets by thousands of users and you have the making of a complete revolt. And that's just the spreadsheet users....
 
Touch screen iMac is a horrible idea. I respect apple for not putting touch on MacBooks, I hope to never see this. Pros wouldn't use it and casual computers aren't going to drop $3k on a computer to browse the web with their finger. VR also seems like a waste, as macs have never been focused on gaming. Not sure why else you would buy VR but maybe I'm just out of the loop. This is all speculative clutter in the forum of which I'm now adding to. Nobody knows what apple will release and if they'll even release it. Patience young grasshopper lol
 
It would be better to allow the ipad pro to pair with the imac pro for use as a drawing pad, versus the touchscreen.

TB3 ports out the ying yang, xeon, ecc ram and a pro gpu - all doable on iMac and rMBP.

Pretty safe bet the Mac Pro is dead soon. Yearly iMac update and mobile workstations make more sense. Kills two products; MP and Display.
 
The mouse is an archaic way of navigating a desktop. It's click and point with no dexterity at all, the human hand, either on its own, or holding a pen, is the most natural and intuitive way of navigating because it's so much more precise.

A very basic usage would be ability to simply scribble on the desktop screen while working, like you would on a wall, or whatever. Pointless but many of the features are gimmicks like that.

The real benefit of a touch screen would come to designers and others who want to utilise touch over old ways of navigating. Of course, the iMac would have to have the ability to gracefully slide down to an angle similar to an architects desk. That would transform the desktop experience for many, many users.


The future is touch, and the desktop navaigation is stuck in the 70s. Limiting the experience massively.
[doublepost=1475536407][/doublepost]A touch screen works great if you are holding the device in your hands. But if the screen is sitting on a desktop at arms length, it takes more time to reach out and touch the screen in the proper place and manner than it takes to position the mouse and click. Two words sum it up. DUMB IDEA.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.