UXKit
Paisible.fr
Membre
Il semblerait que la nouvelle application Photos d'Apple soit basé sur un nouveau framework : UXKit.
Celui-ci serait:
Articles sur:
Celui-ci serait:
- Une copie du framework UIKit pour OS X
- Pour le moment privé
- Codé en Objective C
Articles sur:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
De temps en temps, je regrette l'absence de certaines applications iOS sur mon MBPr, surtout des jeux vidéos en fait ..
On approche d'une convergence, ou tout au moins une facilitation des développements OSX + iOS. C'est bien pour les développeurs.
Le truc pénible, c'est que comme le dit MacG je crois, construire une app sous Mac OS et sous iOS c'est deux philosophies différentes... et c'est long donc de tout re-apprendre rien que pour faire une application sur Mac.
Personnellement je trouve que ce UXKit est pas trop mal comme idée. Après il faut tester en vrai mais poursuoi pas c'est une idée que je trouve pas mal pour l'instant.
Par contre, en tant que programmeur Mac, ça me fait frémir: on a surtout besoin de réparer les classes actuelles et de ménage dans AppKit, après 15 ans à empiler du code suivant la mode du moment. Mais rien n'est fait parce qu'Apple n'a pas déployé les moyens humains nécessaires.
Apple est bien capable de nous pondre un nouveau framework compatible 10.11 et 10.0 uniquement, en nous disant que l'ancien est has-been.
C'est ce que je crains...
Les gestures sur trackball/magic mouse ne sont pas les mêmes que sur iOS. C'est encore une autre interface à penser.
Bah non je ne crois pas justement ! Utiliser un ordinateur avec les doigts et avec une souris, ça n'offre pas les même possibilités. Et les interfaces ne sont surtout pas les mêmes. iOS est conçu pour les doigts, Mac OS pour une souris et un clavier. Je doute qu'un Mac OS tactile soit efficace...
Bin moi je suis bluffé par le trackball de mon MBP. Franchement j'adore ! Je ne croyais pas à la possibilité d'un OS tactile pour un ordinateur avant d'avoir le MBP. Maintenant je pense que c'est envisageable.
Ha non mais je ne parle pas du trackpad ! Moi aussi j'ai un trackpad bah franchement j'adore on est plus libre en mouvement. Mais je crois encore que un trackpad et le tactile ça reste pas mal différent. Certes on reprend certains gestes du tactile pour le mettre sur le trackpad dans OS X, mais le trackpad reste aussi une souris.
En fait, actuellement, je me vois difficilement interagir sur Mac OS avec les doigts. Tout n'est pas aussi intuitif qu'iOS tactilement parlant.
Ha oui d'accord, tu parles d'un vrai OS tactile avec les doigts sur l'écran, à la sauce Windows. Effectivement c'est n'importe quoi. Passer son temps les doigts en l'air c'est bien dans une pub Windows ou un film de SF, pas dans la réalité.
J'aurais dus préciser que pour moi, un OSX tactile c'est les doigts à plat sur le trackpad ou la Magic Mouse.
Je rejoins les craintes de Céroce. Comme si on avait déjà pas assez d'applications inconsistantes (portages multi plateformes bancals) sur le Mac App Store, on va se retrouver en plus noyé par des portages à la va vite d'iOS vers OSX.
Apple ou le nivellement par le bas...
Pour moi il est urgent de rapprocher OSX d'iOS en terme d'API.
On est bientôt à iOS 9, et on a toujours UIColor et NSColor, UIImage et NSImage, ça fait désordre.
Jusqu'à maintenant, c'est iOS qui a fait le gros du chemin pour s'étoffer à mesure que les CPU progressaient, et c'était logique (CoreText, etc).
Maintenant il serait temps que la programmation OSX se simplifie un peu.
Il y a aussi SKColor depuis iOS 6 et SpriteKit !
SKColor est un alias de UIColor sous iOS et NSColor sous OS X.
Et encore t'es gentil: UIImage, NSimage, CGImage, CIImage
C'est ce qui me dérange le plus. Pondre un nouveau framework alors qu'il y a tellement d'autres choses à faire plus utiles pour uniformiser les devs...
NSImage et UIImage ne sont pas comparables, justement. UIImage est bien plus légère; je veux dire, limiter UIImage aux bitmaps et supprimer ces conneries de NSImageRepresentation fut une excellente décision. Mais de fait les deux classes sont fonctionnellement très différentes.
Personnellement, dans mes applis, j'ai ma propre classe CERImage, qui se rapproche beaucoup d'un simple wrapper autour de CGImage...
UIImage ne permet en aucun cas d'accéder aux bitmaps (les tables des pixels). C'est justement là que NSImageRep et tout particulièrement NSBitmapImageRep prend tout son sens avec NSImage.
Le problème avec NSImage c'est que c'est une classe un peu trop grosse qui contient tout, y compris les NSImageRep & co.
Côté iOS, UIImage fait le strict minimum, référencer une image, savoir la charger, la dessiner... Et les accès aux pixels par exemple c'est de la responsabilité d'un GraphicContext, ce qui est un tout autre boulot.
Séparation des responsabilités, c'est la clé d'une archi propre.
Je n'ai pas dit le contraire. Je corrige juste le fait que UIImage ne permet pas l'accès au bitmap contrairement à ce que laisse penser Céroce.
Et en ce qui concerne l'accès via GraphicContext, là on est rendu côté display en fin de chaine et plus au niveau bitmap. Ce n'est encore pas la même chose.
Je n'ai jamais rien écrit de tel.
Alors j'interprète peut-être mal cette phrase...
On est donc bien d'accord qu'UIImage ne permet en aucun cas l'accès aux bitmaps.
Oui. Je dis simplement que UIImage ne gère pas les formats vectoriels, tels que le PDF, à la différence de NSImage.
UXkit, un rapprochement entre OSX et IOS : U pour UIKit et X pour Mac OS X (le tout en un).
Si on peut le mélanger avec AppKit pourquoi pas, ça serai d'ailleurs une des solutions par Apple pour le commencement.
Et si Yosemite n'avait été qu'une refonte graphique, et qu'on verrai apparaitre une refonte niveau interface dans un prochain Mac OS ?
D'ailleurs en passant, si le UXKIT prend le dessus sur Cocoa. Comment va s'appeler le forums ?