Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.
Anders Ödlund
  • Registrerad 2001-05-17
  • Senast aktiv 2008-02-22
  • Antal inlägg 444

Foruminlägg

De senaste inläggen Anders Ödlund har skrivit i forumet.

Cocoa är ett Objective-C API. Anledningen till att man kan använde Java är att Apple hare byggt en Java/Objective-C Brygga.

Så som sagt var, ska du koda Cocoa och något derivat av C är det Objective-C som gäller.

Om du ändå måste lära dig ett nytt API så är det väl lika bra att lära sig språket API:t är skrivet för...

Vad jag försöker säga är inte att man ska använda Objective-C för språkets skull... utan för att det är det språk som funkar bäst för Cocoa utveckling

[ 19-08-2001: Meddelandet ändrat av: odlund ]

Jag förstår inte riktigt motståndet mot Objective-C, och framförallt inte nu när Ojbective-C++ fungerar. Varför vill man "slippa" använda Objective-C?

Ska man koda Cocoa är det Obj-C som gäller (eller iofs java), vill man inte använda något av dessa språken får man hålla sig till Carbon

kolla in url:en xml.apache.org... men visst är det opensource

ja... kanske inte per default, men man kan ju lätta bygga ett perlscript eller en javaservlet, eller varför inte ett C++ cgi script som använders sig av xalan/xerces för att göra det...

IE5 på pc klarar det iaf... vet inte hur det är med IE5 på Mac OS X, den visar XML filer på samma sätt som IE5 på pc... så då antar jag att den kan visualisera med XSL också...

Anars finns Xalan och Xerces som är Java XML/XSL parsrar

xml.apache.org

Vad det programmet gör är att det lägger in .jar filen i en .app katalog så det ska gå att starta via Finder, men det är fortfarande en javaapplikation.

Har iaf för mig att det är så det funkar. :rolleyes:

Det fungerar inte "out of the box i PB" (ännu) men det finns en Tab Kompleterings Input Manager att ladda ner (Listades på VersionTracker för ett tag sedan har jag för mig) som gör just det. Den utgår från vad som redan skrivits i dokumentet / källkodfilen och använder de orden att kompletera med.

Input Managers i övrigt är en av de saker som dokumenterats med orden "Description Forthcoming" men det följer med exempel för HEX inmatning med DevTools

Project Builder är helt okej som texteditor, man har mycket kvar att önska. Personligen stör jag mig mest på att det inte (mig veterligen) finns något sätt att köra PageUp och PageDown.

Är du van vid Emacs kommer du nog dock vilja stanna kvar där. Det finns ju inget som hindrar dig från att bygga upp dina dependencies och targets i PB, men sedan använda Emacs som editor och pbxbuild för att kompilera.

Gällande möjligheter att customiza editor tillhandahåller Cocoa en väldig tuff feature som kallas "Input Managers", vilka är Obj-C program som tar hand om inmatningen i textfält som man kan bygga hur avancerade som helst (i teorin), själv började jag på ett "vi mode" - mest för att testa, och hade jag gett det mer tid hade det säker varit användbart... (iaf rent tekniskt )

Det ÄR så lätt och smidigt!

lite onödigt inlägg kanske, men jag jobbar på min status

Du kan använda Objective-C hur mycket du vill. Det beror på om du vill skriva Carbon eller Cocoa applikationer. I Cocoa använder man Obj-C framförallt till GUI, men det finns även massa trevliga hjäpklasser, i stil med de man kan förvänta sig i ett väl genomtänkt klassbibliotek.

Obj-C är ju ett rent superset av C, så du kan använda all c kod du har redan nu. Jag har för mig att apple är på gång att tweaka till gcc så att man kan blanda C++ och Obj-C, men just för tillfället är jag ganska säker på att det inte funkar.

Du kan ju annars använda Carbon som är C/C++ rakt av, men får du väl smak för Objective C kommer du inte se det som ett alternativ

Okej, Men varför inte bygga det ovanpå Carbon då istället för Cocoa?

Känns som det är lite vettigare att bara använda C/C++ och inte blanda in Obj-C.

Vad jag menar är att du kommer ju gå miste om alla fördelar Obj-C har att erbjuda, jag förespråkar inte Carbon framför Cocoa om man vill utveckla för Mac OS X

Du vet inte om GNUStep finns för BeOS, då kan du ju koda Obj-C på bägge plattformarna

[ 17 Juni 2001: Meddelandet ändrat av: odlund ]

Varför detta?

Objective-C API:et är redan väldigt bra. Förtsår inte nyttan med att lägga ett till lager ovanpå?

Om du förklarar lite mer om vad det är du tänkt göra kanske det blir lättare för oss att förstå hur du menar...

[ 17 Juni 2001: Meddelandet ändrat av: odlund ]

Jag tycker det det verkar vara ganska fel... Det ser ut som du försöker använda Objective-C klasser som C++ klasser och det kommer inte funka.

Rätta mig gärna om jag har fel, har kodat alldelles för lite för Mac OS X, blir inte tid för det när man måste hitta buggar i sin PocketPC applikation

yacc, bison, flex, och lex finns med.

Det intressant är väl först och främst vilka funktioner som bör finnas med.

* Skicka meddelanden
* Skicka Filer
* Dela PasteBoard
* Automatisk "Detection" av andra noder på lokala nätet

Gällande kents frågor. Jag tror på ett system i stil med Gnutella med enbart massa fristående klienter och inga servrar. Någon form av PKI tror jag skulle vara det bästa för krypteringen, men kryptering ska inte vara obligatorisk. PKI kan man ju använda även för användarverifiering.

email är bra för användärnamn, det är av sin natur ganska unika.

ja, lite tankar iaf.

:rolleyes: