›

NSStatusItem, LSUIElement et comportement d'une app

hdexhdex Membre
18:41 modifié dans API AppKit #1
Bonjour a tous,

J'aimerai reproduire le comportement de l'application "Internet Connect" ou même iChat d'Apple. En clair, être capable de lancer l'appli et l'utiliser depuis le dock ou (via un NSStatusItem) la faire tourner dans la barre de menu sans autre élément d'interfaces (icone, fenêtre) mais avec la possibilité d'afficher l'interface à  la demande.

J'ai regarde du cote de LSUIElement et LSBackgroundOnly mais ca semble figer le comportement de l'appli (a mois d'aller bidouiller le fichier info.plist depuis l'appli).
Je ferai bien 2 applis differentes mais avec tout un tas de code redondant ça semble un peu  :)beta: ... J'avoue que la je suis preneur de toutes pistes ...

Réponses

  • BruBru Membre
    18:41 modifié #2
    Je te renvoie sur ce post à  partir duquel tu trouveras toutes les réponses.

    .
  • hdexhdex Membre
    juillet 2007 modifié #3
    Merci Bru ... j'avais cherché mais j'avais pas vu ce post :fouf):
  • hdexhdex Membre
    18:41 modifié #4
    Bon je m'excuse si je suis un peu lourd mais la j'ai les neurones qui collent  B)

    LSUIElement me permet de masquer l'UI tout en ayant un NSStatusItem, j'ai teste pas de probleme.
    Pour ce qui est du switch entre appli sans UI/appli avec UI le tout dans une meme appli, il faut creer un "helper" qui se charge de faire le switch entre les 2 modes.
    Ca veut bien dire plusieurs bundle dans une meme app histoire que mon bundle avec UI est un LSUIElement a 0.

    J'ai bon ou j'ai vraiment rien compris ?

    PS : si j'ai tout faux, vous avez le droit de  >:)   >:D
  • BruBru Membre
    18:41 modifié #5
    dans 1185230842:

    Pour ce qui est du switch entre appli sans UI/appli avec UI le tout dans une meme appli, il faut creer un "helper" qui se charge de faire le switch entre les 2 modes.
    Ca veut bien dire plusieurs bundle dans une meme app histoire que mon bundle avec UI est un LSUIElement a 0.
    J'ai bon ou j'ai vraiment rien compris ?


    En fait, il s'agit de 2 applis différentes, donc 2 bundles différents.
    Toutefois, rien ne t'interdit de déposer le 2nd bundle (celui de l'appli avec UI) dans le rép "Resources" (par exemple) du 1er bundle (celui de l'appli sans UI).
    Ainsi, lors du lancement de l'appli avec UI (après choix d'un item NSStatusItem si j'ai bien compris de l'appli sans UI), il te suffit de récupérer le chemin du bundle UI, puis de le lancer (par un -[NSWorkPlace launchApplication:] par exemple).

    L'avantage de ceci est d'avoir dans le même paquet (le bundle sans UI) tout ce qui est nécessaire pour toi, d'où une installation facile.

    .
  • hdexhdex Membre
    18:41 modifié #6
    Merci Bru

    Ca fait un peu de code redondant (a moi de faire une sorte de demon et des app qui discutent avec le demon) mais ça semble être le plus simple à  gérer.

  • BruBru Membre
    18:41 modifié #7
    dans 1185270990:

    Ca fait un peu de code redondant (a moi de faire une sorte de demon et des app qui discutent avec le demon) mais ça semble être le plus simple à  gérer.


    Le code redondant (en fait les classes communes) peuvent être dans un plugin.
    Chaque appli (la sans-UI et la avec-UI) charge alors à  son démarrage le plugin afin de disposer des classes communes.

    Le plugin est quelque chose de très facile à  faire en Obj-C dans Xcode, et c'est encore plus facile à  charger dans son appli.

    .
  • hdexhdex Membre
    18:41 modifié #8
    :adios!: o:) :adios!: o:)

    Au fin fond de l'Univers Mac, à  des années et des années-lumière de la Pomme,
    Veille celui que le debutant Cocoa appelle
    Quand il n'est plus capable de trouver une solution à  ses problèmes,
    Quand il ne reste plus aucun espoir :
    le Capitaine Bru!

    [size=5pt]A chantonner sur l'air du capitaine Flam ... pour ceux qui ont connu (oui je sais ca commence a dater)[/size]
  • elfelf Membre
    18:41 modifié #9
    C'est pas recommendé par Apple, mais à  mon avis c'est mieux comme méthode. C'est plus pratique pour l'utilisateur parce que 1. ça tourne comme sous-proccès de SystemUIServer, 2. MacOSX gère de lancer le menu au login etc., 3. c'est ce qui est utilisé par apple pour tout les menu en haut à  droite et 4. l'utilisateur peut les déplacer et enlever par commande-click:

    Créer un NSMenuExtra

    ça été le sujet de gros débats pour / contre, et mon but n'est pas du tout d'en relancer un, mais jette-y un oeuil avant de décider d'utiliser un Helper avec un NSStatusItem.
  • BruBru Membre
    18:41 modifié #10
    Juste pour polémiquer...

    dans 1185385990:

    C'est pas recommendé par Apple, mais à  mon avis c'est mieux comme méthode.


    Et pour preuve ! la méthode des MenuExtras que tu évoques utilise des méthodes non-documentées.
    Je ne suis pas contre l'utilisation des undocumented quand il n'y a pas d'autres moyens.
    Là , Apple fournit des outils (NSStatusItem/NSStatusBar) capable de faire (presque) la même chose.
    Alors, pourquoi hésiter ?



    C'est plus pratique pour l'utilisateur parce que 1. ça tourne comme sous-proccès de SystemUIServer,


    En quoi c'est pratique ?
    Que ce soit un child-process de SystemUIServer ou de LoginWindow, je ne vois pas trop la différence...



    2. MacOSX gère de lancer le menu au login etc.,


    Tout comme Mac OSX se charge de charger une appli (normale sans UI) au login (si celle ci se trouve dans les "éléments de démarrage").
    D'autre part, l'utilisateur garde la maà®trise totale de lancer a-la-mano son appli, mais aussi de la faire quitter à  tout moment.
    Ce qui est parfaitement impossible avec MenuExtra (où la même manip nécessite un redémarrage de la session).



    3. c'est ce qui est utilisé par apple pour tout les menu en haut à  droite


    Et donc ? C'est un avantage ?



    4. l'utilisateur peut les déplacer et enlever par commande-click:


    C'est le seul avantage par rapport à  NSStatusItem/NSStatusBar.
    Et encore, à  part faire mumuse pour déplacer les items...
    De plus, retirer l'item de la barre :
    1. ne fait pas quitter le process qui y est rattaché (il reste actif en mémoire).
    2. oblige de toute manière à  créer un UI (sous forme d'appli ou de pref-panel) pour manipuler le process attaché au MenuExtra.



    ça été le sujet de gros débats pour / contre, et mon but n'est pas du tout d'en relancer un, mais jette-y un oeuil avant de décider d'utiliser un Helper avec un NSStatusItem.


    Croyez un mec qui adore pourtant les undocumented... Moi j'utiliserais bien sûr NSStatusItem/NSStatusBar sans hésitation.

    .
  • elfelf Membre
    18:41 modifié #11

    Tout comme Mac OSX se charge de charger une appli (normale sans UI) au login (si celle ci se trouve dans les "éléments de démarrage").
    D'autre part, l'utilisateur garde la maà®trise totale de lancer a-la-mano son appli, mais aussi de la faire quitter à  tout moment.
    Ce qui est parfaitement impossible avec MenuExtra (où la même manip nécessite un redémarrage de la session).


    C'est possible: "killall SystemUIServer" =)



    Et donc ? C'est un avantage ?


    Bah ça montre que c'est un manière de faire très stable et tout, si c'est celle qu'Apple utilise...
    Personellement je veux pouvoir remanier mes menus dans l'ordre que je veux.

    Tu as plein de petites apps qui sont fait avec des MenuExtras: iStat Menu Pro, Menu Meters, et bien d'autre... comparé à  par ex. Skitch, qui est super mais qui s'ordonne dans ordre de lancement de l'appli au lieu de l'ordre que j'ai choisis...

    Moi je veux pouvoir avoir mes menu dans un ordre spécifique... je haid skitch / adium / et le seul menu apple fait comme ça: Airport Disk agent.


    1. ne fait pas quitter le process qui y est rattaché (il reste actif en mémoire).
    2. oblige de toute manière à  créer un UI (sous forme d'appli ou de pref-panel) pour manipuler le process attaché au MenuExtra.

    1. je te l'accorde
    2. bah non... pas du tout...

    Personellement j'avais commencé un projet avec NSStatusItem, et je l'avais recommencé avec NSMenuExtra, et j'ai vraiment préféré NSMenuExtra.

    En effet comme tu dis, utiliser des undocumented quand il est possible d'utiliser documented n'est pas bien, mais à  mon avis dans cette situation NSMenuExtra apporte bien asser d'avantage par rapport à  l'autre facon pour le rendre une alternative tout à  fait valable...

    NSMenuExtra: mieux pour l'utilisateur final, ce qui est la première priorité AMHA

    NSStatusItem: mieux pour le développeur...
  • schlumschlum Membre
    18:41 modifié #12
    Et peut-on créer un NSMenuExtra sans utiliser MenuCracker ?

    Si non, la licence "artistic" permet quoi exactement ?
  • elfelf Membre
    18:41 modifié #13
    Bah je n'ai jamais utilisé de "MenuCrack" pour créer mon NSMenuExtra... Je supose que c'est possible sans :P
  • schlumschlum Membre
    18:41 modifié #14
    dans 1186216464:

    Bah je n'ai jamais utilisé de "MenuCrack" pour créer mon NSMenuExtra... Je supose que c'est possible sans :P


    Dans le lien que t'as donné, il est dit :

    In the MacOS X 10.2, Apple made some effort to prevent third-party MenuExtra being loaded. Under MacOS 10.2, you would need to use Menu Extra Enabler from Unsanity or MenuCracker from james_007_bond


    C'est à  dire que pour 10.2 et >, il faut Menu Extra Enabler ou MenuCracker
  • hdexhdex Membre
    18:41 modifié #15
    Encore merci pour toutes ces recommendations.
    Pour le moment je vais me concentrer sur NSStatusItem. NSMenuExtra et la possibilites de planter SystemUIServer c'est un peu la grande ecole ... je suis encore en maternelle Objective-C  ;)
  • elfelf Membre
    18:41 modifié #16
    Schlum, en effet c'est marqué ça sur l'article, mais à  mon avis l'article doit se tromper.

    Je n'ai jamais rien utilisé de la sorte et tout à  fonctionné, peut-être que ça été changé depuis Tiger.

    Cet article à  été écrit à  l'époque de Jaguar, et n'est p-ê plus à  jour.
  • schlumschlum Membre
    18:41 modifié #17
    OK, merci, j'essaierai un jour alors !  :)
  • schlumschlum Membre
    18:41 modifié #18
    Il faut bien MenuCracker... Mais tu l'as probablement d'installé quelque-part sur ta machine via une application tierce (MenuMeters ?), ce qui expliquerait pourquoi tu n'as pas eu à  t'en soucier.

    Vala par exemple le message que j'ai dans la console :
    2007-08-22 13:15:42.733 SystemUIServer[209] MenuCracker: Loading &#39;LBMenuExtra&#39;.<br />2007-08-22 13:15:42.734 SystemUIServer[209] *** -[LBMenuExtraView initWithFrame:menuExtra:]: selector not recognized [self = 0x3eefa0]<br />2007-08-22 13:15:42.734 SystemUIServer[209] failed to load Menu Extra: NSBundle &lt;/Users/schlum/Desktop/LBMenuExtra/build/Release/LBMenuExtra.menu&gt; (loaded)
  • elfelf Membre
    18:41 modifié #19
    Ah ouais, tu dois avoir raison... J'ai installé MenuMeters à  une époque... Maintenant j'utilise iStats Menu, mais ça dois être pareil.
Connectez-vous ou Inscrivez-vous pour répondre.