903: Sourcen und SDK?

[Seneca]

Originally Posted by Writer

Danke für deinen Einsatz Forkosigan!

Schade dass die scribble sourcen nicht dabei sind, das wäre ein guter Ausgangspunkt für mich gewesen. Aber alle notwendigen Calls scheinen in inkview.h zur Verfügung zu stehen, mal sehen auf was man da kommt.
Jetzt heißt es erst mal die Tool-Chain aufzusetzen. Auch wenn ich dieses Wochenende nur begrenzt Zeit habe - gibt es einen Sparringpartner, der das auch gerade angeht?

Tool-Chain scheint ja dabei zu sein (habs aus Zeitmangel noch nicht probiert), ansonsten ist MeesaYousa ja schon mal tätig geworden. Was mich zum nächsten Punkt bringt ...

Originally Posted by Writer

Gibt es schon ein Wiki um Erfahrungen und HowTos auszutauschen? Wurde ja schon vor längerem angeregt, wird aber erst jetzt wirklich relevant

Ich denke es macht keinerlei Sinn wenn jeder für sich hinbastelt, und jede Erkenntnis dreimal gewonnen werden muss.

Ich möchte daher vorschlagen, das SDK und insbesondere weitere verbesserte Apps, verbesserte Doku etc. zentral in ein SVN oder Git Repository abzulegen, und das Wiki hier zu nutzen um HowTos o.ä. abezulegen die nicht direkt Sourcen dokumentieren, sofern Mobilereads nichts dagegen hat. Alternativ bietet auch GitHub ein Wiki.

Bei Konsens kann ich mich gern Ende der Woche darum kümmern.

Mein ersten "Opfer" in den SDK Quellen soll jedenfalls der Kalender sein: Ich will den so umbauen, das ich Termine eintragen kann. Vorzugsweise im .ics Format zum einfachen Austausch mit iCal, Thuderbird/Lightning etc.

Grüße
Björn

[MeesaYousa]

Originally Posted by Seneca

Tool-Chain scheint ja dabei zu sein (habs aus Zeitmangel noch nicht probiert), ansonsten ist MeesaYousa ja schon mal tätig geworden. Was mich zum nächsten Punkt bringt ...

Hallo Björn,

ich würde dazu gerne Launchpad verwenden. Hatte damit bisher nur peripher zu tun aber war bei dem was ich bisher davon verwendet hatte begeistert. Quasi alles dabei. Das VC system nennt sich bazaar und funktioniert ähnlich wie git oder hq.

Was nett ist zb, wer will kann nen branch anlegen und fleissig committen und dann wird gemerged oder abgestimmt ob der code gut ist und dementsprechend gemerged. Dadurch sind alle Änderungen gleich für jedermann zugänglich (wenn er der dev möchte) auch wenn sie noch nicht in der mainline sind.

Habe mal
https://launchpad.net/openbookus/
registriert - ich möchte da nicht gleich ins offene Messer laufen bezüglich Markenrechte etc. dh. nix mit Pocketbook. Wenn euch das passt pm't mir euren Usernamen auf der Platform und ich gebe euch gleich Rechte um da rumzufummeln.

Ein paar weitere Infos habe ich schon zusammengetragen, hoffe auch aufs WE um das alles einzupflegen.

Grüße
meesa

[MartinZ]

Hallo meesa,

also es geht mir nur um das Script "makepc.sh" nicht um "makearm.sh".
Denn makearm.sh funktioniert soweit. Das entstandene File (z.B. "calc") kann dann in "calc.app" umbenannt und auf das Pocketbook kopiert werden.

Aber makepc.sh (was ja wohl eine auf dem PC ausführbare app erzeugen soll - also irgendwie emuliert-) scheitert mit Fehler:

skipping incompatible /root/projects/sources/calc/../../FRSCSDK/lib/libinkview.so when searching for -linkview

Ich schließe daraus, das es sich bei "libinkview.so" wohl um die Emulator-Library handelt, die aber inkompatibel ist. Vielleicht ist sie nur mit meinem 64-Bit OpenSuse inkompatibel und würde auf 32Bit laufen?

Was genau ist denn "libinkview.so"? Und woher stammt das? Gibt es das evtl. als Source oder in anderen Versionen?

Ein weiteres Problem scheint es mit der Struktur "iconfigedit" beim "inkdemo.c" zu geben:

static iconfigedit testce[] = {

  { "About device", NULL, CFG_INFO, "Name: PocketBook 310\nSerial: 123456789", NULL }, ...

Hier wird ein Array des Typs iconfigedit mit Daten initialisiert, die zu diesem Typ nicht passen, sondern zum Typ "oldconfigedit".

Ist inkdemo.c wohl für eine ältere Version von inkview.h gemacht, bei der diser alte Typ als "iconfigedit" verwendet wurde?


Gruß, Martin

[troll05]

Moin, das hier wurde heute im Internationalen PB Forum gepostet. Ist da vielleicht der ganze Kram bei, der euch noch fehlt?

[MartinZ]

Nein, dass das SDK zur Zeit nur für's Pocketbook selbst, nicht aber für Emulator auf dem PC kompilieren kann, geht aus dem P.S. hervor.

P.S. This SDK contains the new native linux emulator (libinkview.so) but for i386-based linux only. Building with emulator will be available in the next versions of this SDK.

Es macht die Programm-Entwicklung zur Qual, wenn man nicht interaktiv arbeiten kann, sondern jede Änderung, jeden kleinen Versuch erst zum Gerät transferieren muss, um auszuprobieren.

Ich bemängele außerdem, dass es keinerlei IDE (integrierte Entwicklungsumgebung) gibt, wo man z.B. bei Click auf eine Compiler-Fehlermeldung direkt an die entsprechende Stelle im Editor springt, oder Code-Vervollständigung bzw. Funktions-Parameter-Infos bekommt.
Vielleichnt hat ja schon mal jemand versucht, es in die Netbeans-IDE oder Eclipse o.ä. einzubauen?

Außerdem fehlen nach wie vor Zugriffs-Funktionen auf den "Framebuffer", so dass man (wie die Midori-Version), näher an übliche GUI-Programme herankommt. Hätte man dies oder noch besser etwas wie "Xlib" / "X11" , dann könnte man z.B. die FOX - Bibliothek porten und hätte sofort Zugriff auf viele bestehende Programme.

Bis zu einem halbwegs brauchbaren SDK ist es noch ein weiter Weg.

[Seneca]

Originally Posted by MartinZ

Ich bemängele außerdem, dass es keinerlei IDE (integrierte Entwicklungsumgebung) gibt, wo man z.B. bei Click auf eine Compiler-Fehlermeldung direkt an die entsprechende Stelle im Editor springt, oder Code-Vervollständigung bzw. Funktions-Parameter-Infos bekommt.
Vielleichnt hat ja schon mal jemand versucht, es in die Netbeans-IDE oder Eclipse o.ä. einzubauen?

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.)

Originally Posted by MartinZ

Außerdem fehlen nach wie vor Zugriffs-Funktionen auf den "Framebuffer", so dass man (wie die Midori-Version), näher an übliche GUI-Programme herankommt. Hätte man dies oder noch besser etwas wie "Xlib" / "X11" , dann könnte man z.B. die FOX - Bibliothek porten und hätte sofort Zugriff auf viele bestehende Programme.

Stimmt. 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.

Originally Posted by MeesaYousa

Habe mal
https://launchpad.net/openbookus/
registriert - ich möchte da nicht gleich ins offene Messer laufen bezüglich Markenrechte etc. dh. nix mit Pocketbook. Wenn euch das passt pm't mir euren Usernamen auf der Platform und ich gebe euch gleich Rechte um da rumzufummeln.

Hmm, wie gesagt wäre mir ein Verbleiben hier auf MobileReads lieber gewesen (siehe Link ganz oben "Dev Hub"). Mein GitHub Vorschlag war auch nur als Backup gemeint gewesen, falls wir hier nichts werden können.

Bin die nächsten Tage ausgelastet, werde aber so bald als möglich mir die Sachen unter openbookus mal ansehen. Klarer Nachteil dort ist, das es nicht aus einer Hand ist, also Quellen und Tracker zwar bei launchpad, aber Wiki irgendwo anders. Ich bin generell mehr für strukturierte Ansätze und aus einem Stück, und nicht so sehr für ad hoc.

[MartinZ]

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.

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

[reader42]

Klar ist das SDK nicht der Hit, aber wer mehr erwartet hat, ist selber Schuld. Was Pocketbook unter einem SDK versteht konnte man sich ja die ganze Zeit schon anschauen. Das SDK für die alten Modelle ist ja genauso.

[MartinZ]

Klar ist das SDK nicht der Hit, aber wer mehr erwartet hat, ist selber Schuld. Was Pocketbook unter einem SDK versteht konnte man sich ja die ganze Zeit schon anschauen. Das SDK für die alten Modelle ist ja genauso.

Diese Logik erschließt sich mir nicht.
Warum sollten die Anwender daran schuld sein, dass der Hersteller etwas unzureichendes liefert oder allzu minimalistische Vorstellungen hat?
Ist hier plötzlich die große Bescheidenheit ausgebrochen ?

Und nur weil auch das alte SDK unbefriedigender Murks war, muss das neue ja nicht auch so sein.

Es geht auch nicht darum, wie man nun SDK definiert, sondern darum, was wir Anwender (ich denke nach den Werbeversprechen berechtigterweise) erwarten dürfen.
Wenn Dir jemand 100Euro schuldet und gibt Dir nur 10 dann sagst Du auch nicht, "selbst schuld, warum habe ich 100 Euro erwartet, beim letzten Mal hat er mir auch nur 10 gegeben..."

[MeesaYousa]

Originally Posted by Seneca

Hmm, wie gesagt wäre mir ein Verbleiben hier auf MobileReads lieber gewesen (siehe Link ganz oben "Dev Hub"). Mein GitHub Vorschlag war auch nur als Backup gemeint gewesen, falls wir hier nichts werden können.

Da es noch kein Feedback gab auch noch nichts eingestellt.
Mir wäre es wichtig es unabhängig von dieser Seite zu machen, hier haben wir keine Rechte und sind von anderen Leuten abhängig.

[SkyDream]

Originally Posted by MartinZ

Diese Logik erschließt sich mir nicht.
Warum sollten die Anwender daran schuld sein, dass der Hersteller etwas unzureichendes liefert oder allzu minimalistische Vorstellungen hat?

Ich kann dem gut folgen.
Natürlich ist nicht der Anwender schuld.
Aber wer sich anschaut wie PB den 903 beworben und gelobt hat, und was man dann bekommen hat, dann sollte man vom SDK (bzw. PB) nicht sehr viel verlangen. Selbst heute gibt es einige beworbene Features nur in einer Alpha-Firmware...

[Seneca]

Originally Posted by MartinZ

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.)

FOX kenne ich nicht. Hast Du einen Link dazu?

Originally Posted by MeesaYousa

Da es noch kein Feedback gab auch noch nichts eingestellt.
Mir wäre es wichtig es unabhängig von dieser Seite zu machen, hier haben wir keine Rechte und sind von anderen Leuten abhängig.

Abhängig sind wir fast überall. Selbst wenn ich's selber hosten würde (keine Sorge, hab ich nicht vor) wäre ich immer noch vom Betreiber des RZ abhängig, bei dem meine Server stehen.

Aber zurück zum eigentlichen Punkt:
Ich war die die letzten zwei Wochen beruflich ausgelastet und hab ein bisschen den Überblick verloren: Hast du schon irgendwo ein Repository aufgesetzt?

Und mindestens so wichtig: Was passiert eigentlich im Englischsprachigen Teil des Forums? Es macht keinen Sinn wenn wir hier im DE Teil unser eigenes Süppchen kochen und die Leute im EN teil ihres. Ich werde da gleich mal schauen gehen.

Nochmal Sorry für das lange Schweigen meinerseits. Leider kann und wird das immer wieder wieder vorkommen, MobileRead & Co sind nun mal Freizeit, und die ist rar.

[MartinZ]

Hallo Seneca,

FOX kenne ich nicht. Hast Du einen Link dazu?

http://www.fox-toolkit.org/

Das Gute an FOX ist, dass es komplett in C++ durchstrukturiert ist, also
nicht aus Klassen besteht, die eigentlich nur eine Kapselung für nicht-objektorientierte Funktionen darstellen.

Außerdem setzt FOX auf nur sehr wenigen "Low-Level"-Funktionen des jeweiligen Betriebssystems auf. Das wäre also ganz passend.
Selbst wenn wir keine offizielle Schnittstelle zum Framebuffer und / oder "xlib" bekommen (auf das FOX normalerweise aufsetzt), könnte ich mir vorstellen, dass man FOX statt auf "xlib" sogar auch auf "inkview" obendrauf setzen könnte. Dann wäre es aber vermutlich durch die "Zwischenschicht" inkview insgesamt langsamer.

@MeesaYousa:

Ich denke es macht keinerlei Sinn wenn jeder für sich hinbastelt, und jede Erkenntnis dreimal gewonnen werden muss.
Ich möchte daher vorschlagen, das SDK und insbesondere weitere verbesserte Apps, verbesserte Doku etc. zentral in ein SVN oder Git Repository abzulegen, und das Wiki hier zu nutzen um HowTos o.ä. abzulegen die nicht direkt Sourcen dokumentieren, sofern Mobilereads nichts dagegen hat. Alternativ bietet auch GitHub ein Wiki.

Volle Unterstützung!

Habe mal
https://launchpad.net/openbookus/
registriert

Das habe ich ja jetzt erst gesehen!
Ich bin gerne bereit dort meine Erkenntnisse einzubringen (sofern ich zu welchen gelange)

Bin z.B. gerade dabei, das inkview.h mal mit Hilfe von Doxygen und eigenen Kommentaren als Doku aufzubereiten. (Das hat schon mal jemand für 14.1. gemacht, da konnte ich für das aktuelle - erweiterte - inkview.h anknüpfen)
Nur, dass Doxygen eigentlich nicht so geeignet ist, da alle Erläuterungen im Quellcode liegen müssen (also hier inkview.h). Wenn davon eine neue Version kommt, muss man alle Kommentare umkopieren.


___________________________________
Probiert mal meinen erweiterten Taschenrechner "CALCPLUS" aus.

[MartinZ]

Hi Leute,

hier mal ein paar Rechercheergebnisse zum SDK zum hoffentlich allgemeinen Nutzen.

Wer mehr oder richtigeres weiß als ich, der melde sich bitte und erkläre es mir

Wer weiß z.B., was FRSC bedeutet ?

Edit:
Neue Version. Falsche Aussagen korrigiert. Deutlich erweitert.
Weitere offene Fragen:
Was heißt "Platform_NX" / "Platform_FC"?

[MeesaYousa]

Hallo,

bei mir ist es nicht anders mit der Zeit und kam auch zu wenig die letzten Wochen.

Klar ist man im Rechenzentrum auch von jemanden abhängig, aber die haben im Zweifel andere Prioritäten als hier bei MobilRead.

Am Ende ist dem Betreiber hier es wichtiger PocketBook zufrieden zu stellen als uns und löscht/sperrt unsere Beiträge weil PocketBook etwas gegen die Entwicklung bestimmter Funktionen hat. (Theoretisch gesprochen.. und dann fehlt auf einmal die zentrale Anlaufstelle und wir können alles neu aufsetzen)

Daher die Idee das gleich wo anders aufzumachen, an einem Ort der nicht als offizielles PocketBook Forum dient. PocketBook hilft ja nicht mal mit besseren Details zu Hardware und an OpenSource Lizenzen hält sich da ja
auch niemand. Wer weiss wann ihnen irgend welche nicht-gängel Features dann doch sauer aufstossen.

An dem Launchpad/Openbookus habe ich bisher nichts gemacht da ich von euch bisher kein positives Feedback bekam. Möchte nichts im alleingang "dürchdrücken". Aber wenn Ihr mir jeweils eure Loginnamen der seite Pm't dann kann ich euch die nötigen Rechte geben um da auch was zu machen.


Also macht einen Account und schickt mir die Infos. Wenns umbedingt nötig ist könnte ich auch eine ganze Umgebung auf einem Server installieren - also mercurial, mediawiki, phpbb etc.pp aber würde das doch lieber auf öffentlichen Resourcen machen wie zb. launchpad.

grüße
meesa