Quote:
|
Das SDK ist sicher noch nicht besonders brauchbar. Aber obige Forderung verstehe ich trotzdem nicht. Ein SDK hat absolut gar nichts mit einer IDE zu tun. Ein SDK ist einfach ein Satz Header-Dateien und gegebenenfalls einige Binärbibliotheken und Tools. Das kann man dann selbstverständlich mit jeder beliebigen IDE nutzen die man will. (Sofern letztere die Sprache (C/C++/Java, ...) des SDK unterstützt.)
|
Stimmt schon, ein SDK muss nicht unbedingt selbst eine IDE enthalten, es wäre aber schön, wenn man etwas mehr Unterstützung hätte, die Einbindung selbst vorzunehmen. Aber das ganze Ding ist ja derart undokumentiert, dass das Einbinden ein eine "beliebige" IDE (wohl nicht nur mir) schwer fallen dürfte. Es ist nicht einmal klar erkennbar, welcher Ordner nun eigentlich wofür gut ist und warum man das Ganze nach ~/projects legen muss. Sprich: Die ganze Wirkungsweise muss man sich rückwärts über die Analyse von make- und cmake-files erschließen.
Ich kann ganz brauchbar programmieren. Aber muss ich mich wirklich erst durch diesen ganzen Wust quälen, bis ich damit mal anfangen darf?
Wäre doch nicht wirklich unpraktisch, wenn das SDK einfach in Form eines Eclipse- oder Netbeans-Plugins zur Verfügung stünde, oder?
Dann diese Merkwürdigkeiten wie die, dass es ein "makepc.sh" gibt, aber anscheinend kein passendes emulator-binary usw.
Quote:
|
Wobei ich dem "einfachen" Portieren fertiger z.B. GTK Programme kritisch gegenüber stehe. Ein stiftbasiertes e-Ink Gerät folgt schlicht einem anderen Bedienparadigma als ein Maus orientiertes Desktop System. Das sollten Anwendungsprogramme berücksichtigen.
|
Auch das stimmt natürlich. Aber die Schnittstelle "inkview.h" kann's ja nun wirklich auch nicht sein.
Der Midori nutzt ja wohl direkt den Framebuffer. Warum enthält man uns diese Möglichkeit vor?
Ich brauche auch nicht unbedingt GTK+. Aber es wäre schon hilfreich, wenn es zumindest ein paar grundlegende Funktionen gäbe, auf die man eine Klassenbibliothek für GUI-Programmierung aufsetzen könnte (FOX ist von den Voraussetzungen ja sehr bescheiden und ist wirklich offen, modern konzipiert, also wirklich durchgehend objektorientiert angelegt und sehr portabel. So weit ich weiß, braucht es nur "xlib" und auch davon nur einen Teil. Da es als offener C++ Quelltext vorliegt und sich auf Linux besonders wohlfühlt, könnte man es recht einfach so modifizieren, dass es die e-ink-Besonderheiten berücksichtigt.)
Martin