Software für Win und Macintosh schreiben

Virtualbox ?

Realbasic resp. RealStudio. Je nach Version kann man damit unter einem 
Betriebssystem direkt ausführbare Dateien für ein anderes Betriebssystem 
erzeugen.

Ich benutze wxWidgets, das geht auch recht gut; Qt ist jedoch etwas 
umfangreicher.

Olaf schrieb:
> Hab gelesen, es gibt ein PlugIn für VS2010 und dann
> sollte man Applications für Windows (.exe) und Macintosh erstellen
> können.

Das ist eher unwahrscheinlich, Mac-Binärdateien kann VS2010 nicht 
erzeugen. Allerdings kann ein Qt-Programm mit einem geeigneten Compiler 
auf einem Mac übersetzt werden.

Olaf schrieb:
> Auf die schönen Dialogfelder Buttons etc. werd ich hoffentlich nicht
> verzichten müssen, oder?

Nein, darauf musst Du nicht verzichten, nur sind sie anders und werden 
anders genutzt als das, was das VS2010 von sich aus macht.

> Ist Qt auch mit der MFC kompatibel

Absolut überhaupt gar nicht. Allerdings bietet auch Qt eine 
leistungsfähige Stringklasse, nur ist die natürlich auch anders als 
CString aus der MFC.

Bei wxWidgets sieht es übrigens nicht anders aus.

Olaf schrieb:
> Hoffe die Umstellung ist nicht so schwierig
> und VS2010 bietet den gleichen Support wie für die MFC classes.

VS2010 bietet exakt gar keinen "Support" für QT oder andere 
Klassenbibliotheken, aber Qt und andere Klassenbibliotheken haben ihre 
eigene Unterstützung. Oberflächen werden nicht mit dem 
Windows-Resourceeditor in VS erzeugt, sondern mit entsprechenden zu den 
anderen Klassenbibliotheken gehörenden Werkzeugen -- oder direkt im 
Quelltext.

Olaf schrieb:
> vielen Dank für diese Informationen: momentan bin ich grad dabei den
> nmake Befehl auszuführen und dieser dauert scheinbar stundenlang.... :-(

Weil er die QT neu kompiliert. Die gibts auch vorkompiliert, dann aber 
für den GCC (Mingw) und nicht den VC++.

> Kann ich anschließend auf einem Windows-System mittels QT qmake eine
> ausführbare Datei für den MAC OSX erstellen?

Kann dein VC++ - Compiler ausführbare Dateien für den Mac erstellen? 
Nein? Dann kann das auch deine QT nicht.

Könntest natürlich versuchen einen Cross-Compiler + Cross-Compilierte QT 
zu installieren. Ist aber vermutlich nicht ganz einfach.

> Oder muss ich hierfür die
> QT Library auch für den MAC auf einem MAC installieren?

Wäre der übliche und einfachste Weg.

Olaf schrieb:
> Kann ich anschließend auf einem Windows-System mittels QT qmake eine
> ausführbare Datei für den MAC OSX erstellen?

Nein.

> Oder muss ich hierfür die QT Library auch für den MAC auf
> einem MAC installieren?

Ja.

Wie ich bereits schrieb, gibt es mit Realbasic/RealStudio einen echten 
Crosscompiler, der auf einem Windows-Rechner laufend Programme für OS X 
erzeugen kann (und umgekehrt). Ob so etwas ohne genaueren 
Test/Debugsitzungen unter OS X sinnvoll ist, steht auf einem anderen 
Blatt, aber rein prinzipiell geht es damit.

Hinzu kommt, daß das halt ein Basic-Dialekt ist und nichts mit C++ am 
Hut hat.


Übrigens kann man mit Wine bzw. CrossOver auch Windows-Programme direkt 
auf einem Mac laufen lassen (sofern das ein Intel-Mac und kein alter 
PPC-Mac ist), vielleicht wäre das ja auch eine in Betracht zu ziehende 
Variante?

Olaf schrieb:
> für den User sollte das Programm (im Macintosh) ohne weitere
> Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können.
>
> Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein.

Silverlight 4 gibt's von MS offiziell für OSX. Die Tools (Blend, VS) 
natürlich nur für Windows. Falls das reicht, würde ich mir die anderen 
Sachen erst gar nicht ansehen.

Das dürfte eine Glaubensfrage sein, die in Frage zu stellen an Ketzerei 
grenzt. Software für OS X sollte mit dafür vorgesehenen Werkzeugen auf 
OS X entwickelt werden, wie sonst wollte man die Integration in die 
Betriebssystemumgebung und den Aufruf von betriebssystemspezifischen 
API-Funktionen testen?

Sven P. schrieb:
> Arc Net schrieb:
>> Olaf schrieb:
>>> für den User sollte das Programm (im Macintosh) ohne weitere
>>> Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können.
>>>
>>> Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein.
>>
>> Silverlight 4 gibt's von MS offiziell für OSX.
> Kann man denn schon ganz seriös Programme auf Silverlight aufsetzen,
> ohne Gefahr zu laufen, dass die Mac-Version oder gleich das ganze
> Silverlight wieder eingestampft wird?
>
> Ich erinnere mich so düster an OS/2...

Internal Bureaucratic Mess sagt doch eigentlich alles
Zu MS gibt's ein nettes Video (Upgrade-Prozess von DOS 5 bis Win 7)
http://www.youtube.com/watch?v=vPnehDhGa14

Ernsthaft...
- Silverlight gibt es als native (C++ nicht C++/CLI) Variante für 
Windows CE (ab 6.0)
- SL ist das Framework für Windows Phone 7 (z.Z. SL3.x, SL4 beim 
nächsten Update)
- XBOX soll wohl auch unterstützt werden
- VS LightSwitch (das Werkzeug für Geschäftsanwendungen) setzt auf SL
- Windows 8 (App-Store, Jupiter) wird wohl (zumindest in einigen 
Bereichen) auch auf SL setzen

Sven P. schrieb:
> Naja, im Wesentlichen also nur die Microsoft-Welt.

Abgesehen von OSX und dem was Novell liefert (MonoTouch/MonoDroid (iOS, 
Android) und Moonlight), ja.

> Dem gegenüber stünde QT mit Win und Mac, sowie Unix/Linux und das auf
> nahezu allen verfügbaren Rechnerarchitekturen. Dazu frei zugängliche
> Quellen und eine LGPL-Lizenzbasis.

Kurze Antwort: Ist das auch nur im entferntesten Sinne kommerziell: 
Keine Komponenten unter der GPL, LGPL oder ähnlichen (Derivaten), 
sondern nur BSD und vergleichbare.

> Wie im Thread nebenan bemerkt, bietet
> QT dann noch eine brauchbare Umgebung für Lokalisierung der Anwendungen.

siehe anderer Thread

> Sofern noch keine Quelltextbasis vorhanden ist, müsste ich ganz
> persönlich da nur kurz überlegen.

Ich auch, Produktivität, Funktionalität, Tools -> kein Qt oder Java

> Man sollte auch mal klären, um welchen Anwendungstyp es überhaupt geht.
> QT abstrahiert recht weit weg vom Betriebssystem.

Die Zeit der minimalen Wrapper ist vorbei...

> Mittlerweile
> erscheinen z.B. selbst die Knöpfe in Dialogen (Ok, Abbrechen, Schließen,
> Wiederholen...) je nach Betriebssystem in der dort üblichen Reihenfolge.

tux85 schrieb:
> Du kannst doch deine software für linux schreiben bei macos ist ein X
> server mitgeliefert (matlab macht so was weiß allerdings nicht genau
> wie)

Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden.

Andreas Schwarz schrieb:
> Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden.

Wenn sich deren Ersteller ausreichend Mühe damit gegeben hat, die 
Apple-GUI nachzubilden, dann ja, aber der Aufwand ist wohl erheblich. 
Und als Mac-Nutzer legt man Wert auf eine einheitliche und konsistente 
Benutzeroberfläche.

Rufus Τ. Firefly schrieb:
> Andreas Schwarz schrieb:
>> Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden.
>
> Wenn sich deren Ersteller ausreichend Mühe damit gegeben hat, die
> Apple-GUI nachzubilden, dann ja, aber der Aufwand ist wohl erheblich.
> Und als Mac-Nutzer legt man Wert auf eine einheitliche und konsistente
> Benutzeroberfläche.

Stell dir vor, es gibt Leute die das GUI von LTspice als toll empfinden. 
Nach der Ansage ware mir dann das Genörgel wegen meiner 
Verbesserungswünsche an LTspice klar.
Offensichtlich kennen viele Leute nichts besseres als Windows. Und 
obendrauf sind da wohl viele auch nicht in der Lage was besseres 
überhaupt zu erkennen.
Das erinnert mich stark an den Bilderqualität-Thread.

Irgendwie enttäuschend. Nicht das ich LTspice nicht toll fände was die 
eigentliche Engine angeht. Aber das Bedienkonzept ist eine Ausgeburt von 
1985 !
Mein Vorschlag, der Entwickler solle sich genau um die SPICE-Engine 
kümmern und das GUI im Sinne von Client-Server Betrieb einem 
diesbezüglichen Profi überlassen, wurde offensichtlich überhaupt nicht 
verstanden und nur provokativ aufgefasst.

Das nur so am Rande.

Hab dich schon verstanden.

Ich mache einen Dialog auf und der ist nicht skalierbar. Schon fällt bei 
mir die Klappe!

Unter der Haube siehts auch nicht besser aus:
LTspice benutzt beim Internet-Update sinnigerweise gzip Kompression, 
also '.gzip' an die Datei angehangen. Klein-Abdul also gleich 
ausprobiert: Lokal *.asc.gzip
Geht nicht! Naja, nur ein Beispiel. Es gibt sicherlich sinnigere für 
LTspice.

Auf die Idee die unsäglich vielen Anfragen nach Modell-Import in LTspice 
einfach mit einem Import Model im Datei-Dialog zu beenden, will man auch 
nicht kommen...

Einem geschenkten Gaul...


Aber der Thread hieß wohl anders ;-)

Windows war ein Fortschritt gegenüber DOS. Vor allem was die 
Druckertreiber anging. OK, befürchte, die meisten hier werden das nun 
nicht verstehen - mangels Alter.

Dann ist Windoof aber schlicht stehengeblieben! Typisch BWLer eben.

Du wirst lachen: Genau das hat mich vor einigen Minuten meine Frau 
gefragt! Meine Antwort war: Soweit ich weiß, geht das nur bei 
Postscript-Druckern wirklich.

Abdul K. schrieb:
> Dann ist Windoof aber schlicht stehengeblieben! Typisch BWLer eben.

Das ist nicht Windows in die Schuhe zu schieben, sondern den zunehmend 
unfähiger werdenden "Programmierern", die Programme für Windows 
zusammenfrickeln.

Microsoft hat schon vor Ewigkeiten mit den User Interface Guidelines ein 
sehr intensiv ignoriertes Werk veröffentlicht. Nur die 10 Gebote dürften 
noch häufiger ignoriert werden.

Unter OS X wird wesentlich mehr auf die Einhaltung der entsprechenden 
Richtlinien geachtet; so nimmt Apple Software nur dann in den AppStore 
auf, wenn sie sich an die Richtlinien hält, und in vor-AppStore-Zeiten 
sah es mit dem von Apple gepflegten Softwareverzeichnis nicht anders 
aus.

Und die Nutzer von OS X legen Wert darauf; wenn Apple selbst 
eigenmächtig die GUI ändert, gibt es teilweise erheblichen Gegenwind, 
der sich durchaus auch niederschlagen kann. Vor einiger Zeit wurde die 
Hintergrundfarbe für die Albenliste in iTunes von Schwarz auf Weiß 
geändert - nur wenig später (und viel Gefluche seitens der Anwender) gab 
es ein Update, mit dem wieder die alte Darstellung gewählt werden 
konnte.

Ergonomiekatastrophen wie üblichen Beigabenprogramme für Soundkarten 
sind unter OS X auch sehr selten.

Es ist einfach ne Frage der persönlichen Reife. Keine Frage.