The user interface elements in MacOS are supplied by AppKit, in iOS it's UIKit. What I expect to see is a marriage of the two with AppKit perhaps reimplemented with UIKit classes.
Fracturing UIKit isn't unprecedented, it's already done on iOS with the iPad having widgets and features not available on iPhone.
UIKit is cleaner having been redesigned after so many years and with so many other technologies baked (CGLayer & CoreAnimation for example).
AppKit would continue to exist for some time with developers having the option of mixing the two (as not all features will be available at the UIKit layer to start.)
A good example of where UIKit bests AppKit is the seemingly simple "Put an animated progress meter in a table row". This is easy in UIKit because table cells are UIViews. However, in AppKit, a table cell is a NSCell which is -not- a view.
On MacOS nearly everything has a NSView and a NSCell component (i.e. NSButton, NSButtonCell)
On iOS there are no cells. (UIButton, no UIButtonCell.)
Other AppKit classes will be implemented using their UIKit counterparts (NSView to UIView, NSWindow to UIWindow).
The result will be a much cleaner development environment for applications that favors animation, multi-touch, and code reuse with the iOS platform.
Eight O'Clock. I'll usually have two or three bags at the house (don't want to run out!) and I've found that by mixing 100% Columbian, the Original, and Dark Italian I can 'tune' the flavor exactly. A fun way to make great coffee at half price.
I ran Linux because I disliked Windows, and then all of the Linux UIs started emulating Windows. Only Windows is now emulating OS X, and now the typical Linux desktop looks like a really old version of Windows.
I blame fvwm95 and everyone who liked it. ;)
Windows has never been Unix-y, OS X is Unix-y and friendly. Steal what's worth having and then invent something totally new.
Ubuntu is on the right track here. I hope they go farther:
-> Make paste Alt-V instead of the current Ctrl-Shift-V. Make close window Alt-W (for Window) instead of Alt-Shift-F3 (or whatever it is). Generally make the keyboard friendly for Terminal users and stop using awkward chorded key combos for things people do every day.
-> Stop wasting space with a toolbar on every window and stick it on top of the screen. (For those who may complain about the position of the Mac toolbar-- remember your Linux desktop probably does -both- a toolbar on top of the screen, -and- a toolbar on every window.)
-> Go from a window-centric model to an application-centric model where I can quickly switch between applications and windows without leaving the keyboard. (i.e. Alt-tab, Alt-~)
I've tried to go back to linux desktop (kde, gnome) and it was a struggle to use, even just to manage emacs, a bunch of terminals, and a web browser. I still like e16.
I don't know what to make of xulrunner (XUL in Mozilla was too magical) but the concept is right. Native C w/ Javascript as the HLL, and wrap older applications in a Canvas... Newer apps would combine Javascript, HTML, and native code. Wrapping application dependencies (clipboard, fullscreen, etc.) in Javascript (where new standards are emerging anyway) would provide incentives for application developers (cross platform, cost savings, no qt versus gtk, web reuse, etc.) Grant you'd still need custom native widgets -and- Javascript lacks a concurrency model. Just a thought.
Fracturing UIKit isn't unprecedented, it's already done on iOS with the iPad having widgets and features not available on iPhone.
UIKit is cleaner having been redesigned after so many years and with so many other technologies baked (CGLayer & CoreAnimation for example).
AppKit would continue to exist for some time with developers having the option of mixing the two (as not all features will be available at the UIKit layer to start.)
A good example of where UIKit bests AppKit is the seemingly simple "Put an animated progress meter in a table row". This is easy in UIKit because table cells are UIViews. However, in AppKit, a table cell is a NSCell which is -not- a view.
On MacOS nearly everything has a NSView and a NSCell component (i.e. NSButton, NSButtonCell) On iOS there are no cells. (UIButton, no UIButtonCell.)
Other AppKit classes will be implemented using their UIKit counterparts (NSView to UIView, NSWindow to UIWindow).
The result will be a much cleaner development environment for applications that favors animation, multi-touch, and code reuse with the iOS platform.