Mac os X .app equivalent

[SeySayux]

Hallo,

Zoals jullie weten (en kunnen zien aan mijn avatar) ben ik een Mac OS X fan (ook Linux fan hoor ). Daarom wil ik iets equivalents maken aan een Macintosh applicatie.

Voor diegenen die niet weten hoe een mac-app werkt: hier is hoe:

Je gaat naar de map /Applications (dit kan ik eventueel linken met mijn K-menu) daar staan allemaal bestanden die applicaties voorstellen. Zo'n bestand is (mits de juiste libs geinstalleerd zijn) perfect portable: je kan het gewoon van de ene naar de andere pc kopieren (tenzij de producenten een of andere gore hack er in hebben gestopt) Deze bestanden zijn dus allemaal programma's, gewoon te openen met een dubbelklik.

Het Linux equivalent: een beetje in /usr/lib, nog wat in /usr/bin en /usr/share, en soms moet je daar nog local tussen voegen. Liefst openen met een terminal.

Het eerste principe is, in mijn ogen tenminste, superieur. Daarom zou ik dit graag naar de linux-wereld brengen.

Hoe werkt zo'n mac os applicatie nu? Wel, dit is vrij simpel. Zo'n applicatie is feitelijk een map die een .app extensie heeft. In die map zit een XML bestand waarin beschijvingen over het icoontje, welk bestand het moet uitvoeren, etc in staat. Hier kan ik een .directory bestand voor gebruiken. Er staan natuurlijk ook de programmabestanden in, hoor.

Nu heb ik geprobeerd een nieuw mime-type te definieren (inode/seoapp) die de .app extensie heeft en dit te koppelen aan mijn .app parser (die dat .directory bestand dan leest en parst), maar ja, moest weer eens koppig zijn en alle directories het inode/directory mime-type geven.

Hoe kan ik, met zo min mogelijk te hacken aan de broncode (dit zal dus kio-file zijn, of zelfs de kernel? -- dat doet mac os ook niet, gewoon wat in finder, want in konqueror voor mac gaat het niet) er voor zorgen dat hij die .app mappen als applicaties herkent, en bijgevolg niet gewoon de map opent, maar de seoapp parser (zo heet ie) erop af stuurt?

- SeySayux

[zappa]

Ik denk dat dit zal helpen:

http://www.blogmanno.com/?q=node/66

Maar dpkg doet dat helemaal niet zo slecht hoor, Zelfs niet voor het icoontje :p

[SeySayux]

Ik denk dat dit zal helpen:

http://www.blogmanno.com/?q=node/66

Maar dpkg doet dat helemaal niet zo slecht hoor, Zelfs niet voor het icoontje :p

Heb ik geprobeert.

En wat heeft dpkg daarmee te doen? daar hebben we op Mac Installer voor. (.pkg)

- SeySayux

[profoX]

Misschien is het beter om eens te kijken naar bestaande alternatieven, zoals bijvoorbeeld Autopackage en Klik.



Het grootste nadeel van dit type architectuur is echter dat het redelijk onveilig is omdat er geen gebruik gemaakt wordt van gedeelde bibliotheken. Als de Mac nog meer marktaandeel wint zal deze onveiligheid ook gaan blijken, want er zal op die manier altijd wel één of ander pakket zijn waarvan de bibliotheek (library/object) niet goed wordt geüpdatet, het veiligheidsprobleem wordt ook vergroot doordat er telkens verschillende varianten/versies van dezelfde bibliotheek (library/object) aanwezig zijn.

edit: Door de modulariteit van Linux zijn de distrospecifieke pakketten nog steeds beter (en een stuk sneller bij het bepalen van afhankelijkheden [dependancies]) dus een vervanging voor apt/dpkg is Autopackage/Klik zeker niet. Wel eventueel een aanvulling op het ontbreken van extra software die je niet kan vinden in de repositories.

[SeySayux]

Misschien ben ik hier niet duidelijk in, maar ik wil geen vervanging voor dpkg! (waarom staat dpkg hier in't rood? en mijn vlaams ook? of is dat omdat ik in konqueror zit?) Ik wil gewoon een .app applicatie op Linux hebben die gewoon libraries kan installeren via dpkg. Dus in plaats van via dpkg een beetje in /usr/bin, een beetje in /usr/share en een beetje in /usr/lib te zetten, wordt gewoonweg het programma zelf in een .app map gezet (die vrij kan verplaatst worden over het hele systeem) en de lib's in /Library (/lib, /usr/lib, /usr/local/lib, ... worden hiernaar gesymlinkt en onzichtbaar gemaakt in de Find... ik bedoel Dolphin, uiteraard -- kwas vanochtend beter niet naar die Mac beurs geweest...). Nu wil ik dat als je in Dolphin, konqueror, of zelfs je zelfgemaakte filebrowser (zo lang ie maar qt/kde gebaseerd is) als je dubbelklikt op zo'n .app bestand, hij de parser (als je't echt wilt weten: /System/SubCore/bin/seoapp) uitvoert met als enige parameter het absolute pad naar de .app map, ipv de inhoud van die map weer te geven. Uiteraard kan je, mbv een rechts-klik optie, de inhoud van de map zien (gewoon: "openen met: dolphin -- maar dan heet het "Pakketinhoud weergeven", I <3 Mac). De parser zal dan een info-bestand (nu ja, zou ik het info.plist noemen of niet???) lezen, en de juiste binary uitvoeren. Een voorbeeld: Gebruiker wilt myapp gebruiken en installeert dit via Synaptic, en krijgt de library mylib, waarvan myapp gebruik maakt, erbij en deze wordt geinstalleerd in /Library. Gebruiker klikt dubbel op /Applications/MyApp.app. Parser wordt gelanceerd: seoapp /Applications/MyApp.app. Parser leest /Applications/MyApp.app/.directory. Daar staat een flag "Exec=bin/myapp" (samen met een flag Type=Seoapp, en Icon=path/to/icon.png). Programma /Applications/MyApp.app/bin/myapp wordt uitgevoerd, slechts als dit executable is aangevinkt (dit kan gedaan worden via eigenschappen, of chmod, uiteraard). Nu is de vraag: gaat dit zonder in de broncode te prullen (behalve dingen zoals het eigenschappen-venster aanpassen en andere minimale dingen)?

- SeySayux

EDIT: nu heb ik de juiste reply

[zappa]

Dus je wil eigenlijk dat alles wat het programma nodig heeft in 1 map zit?

Dan moet je dat inderdaad in de code aangeven (en zelf compileren). dpkg, en andere varianten trachten een code na te leven (een die trouwens wordt geuniformiseerd) om alles op een bepaalde plaats te zetten. 1 keer dus, niet per programma opnieuw dezelfde libs.

Maar eigenlijk zie ik het voordeel niet in van wat je wil. Maar dat zal wel aan mij liggen

[SeySayux]

Wacht even, ik heb hier wat problemen met de reply, ik zal hem eens tegoei zette (de helft staat hier niet)

[SeySayux]

Dus je wil eigenlijk dat alles wat het programma nodig heeft in 1 map zit?

Dan moet je dat inderdaad in de code aangeven (en zelf compileren). dpkg, en andere varianten trachten een code na te leven (een die trouwens wordt geuniformiseerd) om alles op een bepaalde plaats te zetten. 1 keer dus, niet per programma opnieuw dezelfde libs.

Maar eigenlijk zie ik het voordeel niet in van wat je wil. Maar dat zal wel aan mij liggen

Libs worden in /Library gezet. Dus niet meerdere keren een library per bestand. Als ik voor iedere KDE-prog alle QT en KDE libs er telkens weer moest bijvoegen, man wat een gigantische harddisk heb je dan nodig! En alle X Libs! en de kernel headers! en ik weet niet wat! Nee, libs gaan in /Library. Het voordeel is dat je een gemakkelijk overzicht hebt van je programma's, dat alles bij elkaar staat en het niet uitvissen is welk bestand hoort nu bij welk programma, wat doet die map hier en welk programma gebruikt het, ... Je kan je programma's per categorie ordenen en je K-Menu hieraan koppelen. Het verspreiden van prog's wordt ook eenvoudiger: Alles wat je nodig hebt is een ge-tarball'd .app bestand dat de gebruiker gewoon sleept en neerzet. Over slepen en neerzetten gesproken; dit is ook een voordeel. Je hebt een html-document en wilt dit openen met openoffice writer? No problemo, sleep't gewoon naar het OpenOffice writer icoontje. Natuurlijk is dit veel handiger als je een dock hebt, maja we mogen apple niet te veel gaan naapen. Of onderaan je taakbalk een starter maken dan. En portabiliteit. Zolang alle libs geinstalleerd zijn, kan je de app verplaatsen over verschillende computers. En je kan het vanuit je File Manager openen in plaats van die domme, ouderwetse terminal te gebruiken. Wij willen toch geen nerds lijken die voortdurend naar een terminal-venstertje staren en geheimzinnige, schijnbaar onbeduidende codes intypen? Dan klik je toch liever dubbel op een mooi icoontje om een app te starten? En als je toch graag door je jampotbodems naar dat terminalvenstertje staart terwijl je allerlei techtalk uitkraamt, wel, dan kun je toch symlinks maken, niet?

- SeySayux

[phalkone]

Ik ben zelf ook mac en linux gebruiker en snap wat je bedoelt. Ik denk dat je je misschien minder moet focussen op het feit dat mac .app's mappen zijn. Het zal simpeler zijn om een nieuw bestandstype te definieren dat bijvoorbeeld gebaseerd is op het tarball formaat. Je kan de hele applicatie dan in één tarbal steken, je geeft deze tarball een .app extensie en je parser kan dan een speciaal bestand inlezen dat aangeeft welk bestand uitgevoerd moet worden.
Deze methode wordt al gebruikt door Java programma's. Bij java heb je een JAR bestand, wat eigenlijk gewoon een tarball is met alle class en resource bestanden en een manifest dat aangeeft welke class de de main class is.
Het enige dat volgens mij niet zo simpel zal zijn is elk .app bestand een apart icoontje te geven. Normaal gezien krijgen bestanden met dezelfde extensie hetzelfde icoontje. Informatie over icoontjes wordt onder Mac Os X anders opgeslagen.

[zappa]

En je kan het vanuit je File Manager openen in plaats van die domme, ouderwetse terminal te gebruiken. Wij willen toch geen nerds lijken die voortdurend naar een terminal-venstertje staren en geheimzinnige, schijnbaar onbeduidende codes intypen? - SeySayux

Neen, echt niet? :p

Nah, snap eerlijk gezegd maar half wat je bedoelt. Ik raad Apple aan aan de sixties generatie. Het werk, en nog goed ook, zonder dat je moet weten wat er gebeurd. Een beetje zoals de meeste autobestuurders

Feit, dat slepen en doen wordt meer en meer ondersteund, ook onder linux. Echt intuïtief. Bv. plaatjes uit mozilla slepen of url's naar je bookmarks folder. Ben daar touwens echt fan van. Anyway, de reply hierboven lijkt mij afkomstig van iemand die beter weet wat je wil

Succes!

[SeySayux]

Ik ben zelf ook mac en linux gebruiker en snap wat je bedoelt. Ik denk dat je je misschien minder moet focussen op het feit dat mac .app's mappen zijn. Het zal simpeler zijn om een nieuw bestandstype te definieren dat bijvoorbeeld gebaseerd is op het tarball formaat. Je kan de hele applicatie dan in één tarbal steken, je geeft deze tarball een .app extensie en je parser kan dan een speciaal bestand inlezen dat aangeeft welk bestand uitgevoerd moet worden.
Deze methode wordt al gebruikt door Java programma's. Bij java heb je een JAR bestand, wat eigenlijk gewoon een tarball is met alle class en resource bestanden en een manifest dat aangeeft welke class de de main class is.
Het enige dat volgens mij niet zo simpel zal zijn is elk .app bestand een apart icoontje te geven. Normaal gezien krijgen bestanden met dezelfde extensie hetzelfde icoontje. Informatie over icoontjes wordt onder Mac Os X anders opgeslagen.

Ja, hieraan had ik al gedacht als alternatief. Maar dan moeten we bepaalde dingen opgeven die ik wel handig vond:
* De mogelijkheid om via de terminal te cd'en naar in de app
* De mogelijkheid om symlinks te maken
* De mogelijkheid om icoontjes toe te kennen
* De mogelijkheid om namen te vertalen

Nah, snap eerlijk gezegd maar half wat je bedoelt. Ik raad Apple aan aan de sixties generatie. Het werk, en nog goed ook, zonder dat je moet weten wat er gebeurd. Een beetje zoals de meeste autobestuurders wink

Ik behoor nog niet tot die groep, maar ik wil wel graag een systeem dat vanzelf werkt.

-SeySayux