.koa ist der "standard", in der tat
Hallo Besucher, der Thread wurde 4,5k mal aufgerufen und enthält 59 Antworten
letzter Beitrag von skoe am
Neues altes Grafikprogramm veröffentlicht
- skoe
- Erledigt
-
-
Kann noch einmal jemand eine Mac Binary zur Verfügung stellen?
-
Und schon gibt's die nächste Version, die ein paar weitere Unschönheiten ausbügelt.
0.2.1 - 12.03.2009
* Freehand tool sets a pixel at the first click
* Freehand tool is default after program start
* Koala uses .koa as default, .kla still works, of course
* Fix MSW focus problem after minimize/restoreWieder auf:
https://developer.berlios.de/p…wfiles.php?group_id=10470Warum schon wieder? - Mich nervt es, etwas mit bekannten Fehlern in der Öffentlichkeit stehen zu lassen.
Eine Mac-Version kann ich leider nicht kompilieren. Demnächst wird jemand eine kleine Anleitung dazu schreiben. Prinzipiell sollte es so ähnlich gehen wie unter Linux. Vielleicht findet sich ja jemand, der eine bauen kann.
-
ich wäre demjenigen sehr verbunden der mir erklärt wie ich unter linux einen crosscompiler baue der osx binaries ausspuckt ...
-
Also google spuckt was aus, was zumindest die Möglichkeit dazu vermuten lässt:
http://saladwithsteve.com/osx/…-binaries-from-linux.html
Aber wahrscheinlich steckt da der Teufel im Deteil. Und ich könnte es nichtmal selbst testen. Aber schön wäre es schon...
edit: Und einen *compiler* zu haben hilft vielleicht auch noch nicht weiter, falls es keine entsprechendesn System-Includes und Libs gibt. Mingw hat da ja einiges dabei. distcc zieht die sich wahrscheinlich temporär vom Mac.
-
bei distcc wird (in dem fall) auf dem osx rechner gelinkt.
und ja, es geht natürlich um ein komplettpacket aus compiler+libs ... nen ppc compiler zu bauen ist kein problem, das krieg ich grad noch hin
-
funktioniert einwandfrei so weit
jetzt noch circle, breitere pinsel/mischfarben und eine verschmierfunktion - dann wäre für mich alles andere obsolet
allerdings - die clone brush handhabung verstehe ich nicht so ganz, oder funktioniert das nicht richtig?
-
und ja, es geht natürlich um ein komplettpacket aus compiler+libs
Mein dazueditierter Satz sollte auch mehr meinen Beitrag in Frage stellen, nicht Deine ursprüngliche Frage. (Und die Header-Files müssen doch zu den distcc-Clients übertragen werden : P )allerdings - die clone brush handhabung verstehe ich nicht so ganz, oder funktioniert das nicht richtig?
Die ist auch etwas unintuitiv: Nimm ein Bild, auf dem schon WAS zu sehen ist. Dann klicke mit der rechten Maustaste mitten in das WAS und male mit der linken Maustaste in einem freien Gebiet der Grafik. Dann siehst Du da das WAS wieder entstehen.Das wäre wesentlich transparenter mit einer Kurzhilfe in der Statuszeile und einem zweiten "Maus-Fadenkreuz", dass sich mit der Quelle mitbewegt. Mal sehen.
-
Nach einer Weile rumgoogeln habe ich tatsächlich was zum Thema Mac OS X cross toolchain gefunden:
http://lilypond.org/download/gub-sources/
http://biolpc22.york.ac.uk/pub/linux-mac-cross/Werde ich bei Gelegenheit mal sezieren, aber erst kommt eine neue MinGW cross toolchain.
-
Bitte hier Bescheid sagen (und natürlich das Binary posten), wenn jemand ein OSX-Kompilat erstellt hat. Ich habe zwar Xcode auf meinem Rechner, kenne mich aber mit dem Kompilieren von Quelltexten nicht aus und habe momentan auch keine Zeit, mich da hinein zu fuchsen.
-
*theoretisch* sollte das aufm mac genauso gehen wie unter jedem andren unix auch... dh im terminal in das sourceverzeichnis wechseln und da dann "make" ausführen.
-
Moin,
hier ist eine Mac-Application!
beim beenden gibt's aber unschoene meldung(en), und das programm wird manchmal als abgestuertzt gemeldet...
hier der auszug aus dem log:skoe: ich denke ich kann eine makefile zur verfuegung stellen, was eine mac-applikation baut (kontaktiere mich bei bedarf)
Ciao, ALeX. -
Danke, funktioniert super. Beim Beenden stürzt es allerdings wirklich ab aber das ist verschmerzbar. Laden, malen und speichern funktioniert und das ist am Wichtigsten. Super Ergänzung zu unserem kommenden Konverter.
-
Mhh, stürzt beim Beenden ab? Ist mir auf Linux und Windows mit der Version noch nicht aufgefallen. Ist die Fehlermeldung da oben die einzige, die Euch auffällt oder gibt's noch andere?
wxWidgets benutzt native Controls, deshalb unterscheiden sich die Implementierungen der Lib auf den verschiedenen Plattformen. Ich google bei Gelegenheit mal. Hauptsache, es stürzt nich während der Benutzung ab. Beim Beenden geht's ja noch...
Was ist momentan eigentlich das Geläufige, Mac OS X auf x86 oder auf PPC oder ist beides in Mode? Das gibt's doch auch einzeln zu kaufen, oder? Bekommt das auch auf qemu zum Laufen (langsam aber sicher
-
So, nun hab' ich auch endlich mal Zeit gehabt mir das anzugucken.
Gut schaut's aus! Und sauberer C++ Code!
Dickes Lob an Skoe! -
Moin,
Mhh, stürzt beim Beenden ab? Ist mir auf Linux und Windows mit der Version noch nicht aufgefallen. Ist die Fehlermeldung da oben die einzige, die Euch auffällt oder gibt's noch andere?
Man kebommt beim beenden so einen requester wie im anhang gezeigt (und die 1. zeile im log). wenn man auf "Yes" klickt stuertzt das prog ab, wenn man auf "Cancel" war es das, wenn man auf "No" klickt kommt diese zeile im log:
und die box wieder, und dann wieder das selbe spiel. aber nach dem 11. versuch ist "No" wie "Cancel".
Was ist momentan eigentlich das Geläufige, Mac OS X auf x86 oder auf PPC oder ist beides in Mode? Das gibt's doch auch einzeln zu kaufen, oder? Bekommt das auch auf qemu zum Laufen (langsam aber sicher
seit 2006 ist intel das aktuelle. das aktuelle betriebssystem untersuetzt (noch) beide, das naechste system soll (wahrscheinlich) nur noch auf intel laufen. um OS X auf intel zum laufen zu bringen braucht man einen rechner mit EFI oder muss es patchen/cracken. evtl. kann vmware&co das mittlerweile auch virtualisieren...
ach ja: das binary von mir ist intel only! (ausser mir erklaert jemand, wie man fat ohne xcode kompiliert)
ALeX.
-
assert "count == 1" failed in ~wxToolBar()
Das scheint wohl ein Fehler im Mac-Port von wxWidgets zu sein: http://trac.wxwidgets.org/ticket/4468 Wenn ich das richtig verstehe, sollte das in der 2.8.9 gefixed sein.Wenn ich wirklich eine Cross-Toolchain gebacken bekomme, baue ich in Zukunft auf für Mac mit. Ist dann eine Blind-Produktion, weil ich es nicht testen kann.
ZitatUnd sauberer C++ Code!
Danke, aber da ist noch Potential -
Nach ein paar Stunden Debugging im ld aus den odcctools (cross-binutils für MacOS X) habe ich es jetzt endlich geschafft, eine Cross-Toolchain auf Linux für Mac zu bauen. Jetzt stellt sich nur noch die Frage, ob die auch lauffähige Programme erzeugt.
Kann bitte jemand probieren, ob die angehängte Datei auf einem X86-Mac läuft? Ist ein Kommandozeilenprogramm.
Der Fehler war übrigens äußerst dämlich: Er tritt nur mit glibc >= 2.8 auf. Vorher gab es die Funktion qsort_r noch nicht in der glibc. Auf BSD und Mac gibt's die schon ewig: http://www.ipnom.com/FreeBSD-Man-Pages/qsort_r.3.html
Und was machen die glibc-Autoren? Das: http://sources.redhat.com/ml/l…pha/2008-12/msg00003.html
Ist das nicht bescheuert?! Die letzten beiden Parameter sind vertauscht. Lässt sich übersetzen, läuft aber natürlich nicht.
-
Moin,
Kann bitte jemand probieren, ob die angehängte Datei auf einem X86-Mac läuft? Ist ein Kommandozeilenprogramm.
ist das richtig?
hab' grad keine zeit, scheibe dir aber morgen, mehr zu .app's.
Ciao, ALeX.
-
Ah, super. Das ist doch schonmal was.
Du meinst sicher Application Bundles. Ich lese mir später mal http://www.sandroid.org/imcross/#ApplicationBundles durch. Wenn ich dann noch fragen hab, melde ich mich nochmal.
Danke für's Ausprobieren!