Wünsche an den neuen Besitzer von PC/GEOS

Vielleicht wird es Zeit für eine neue Kalender-App. Ich glaube, R-BASIC enthält auch ziemlich ausgefeilte Funktionen für die Datums- und Zeitberechnung. Das müsste allerdings jemand in die Hand nehmen, der tatsächlich programmieren kann. Also nicht jemand wie ich.

Ich glaube, die Zeit- und Datumsfunktionen wären noch das Wenigste. Die größten Aufgaben würden für mich im Bereich Oberflächengestaltung und Speicherung liegen. Ich bin z.B. nur gewöhnt, mit Datenbanken zu arbeiten. In Geos müßte man alles in einer normalen Datei speichern und dann dort die gewünschten Daten oder Positionen zum Lesen oder Schreiben schnell finden. Und dort können ja die Kalenderdaten und Termine für etliche Jahre liegen usw.

Ne neue Kalender-App wäre ja ein riesen Projekt! Aber ziemlich cool. Auch wenn R-BASIC wahrscheinlich performant genug für eine solche App ist, sollte sie doch mit dem SDK (GOC) geschrieben werden, weil man da noch mehr Möglichkeiten hat. Vorher liegt ganz viel Planung zur UI und den Funktionen an. Also viel Arbeit, viele Diskussionen und viel Zeit.

Quote from sebi

In Geos müßte man alles in einer normalen Datei speichern und dann dort die gewünschten Daten oder Positionen zum Lesen oder Schreiben schnell finden.

Die R-BASIC VM-Arrays bzw. die dahinter liegende SDK-Struktur HugeArray bietet hier einen guten Ansatzpunkt. Schnell, dynamisch in der Größe änderbar und Zugriff über einen Index. Und wenn man will kann man ganze Baumstrukturen erzeugen. Der Uni-Installer und R-BASIC selbst nutzen das intensiv. Aber auch hier müsste man sehr sorgfältig planen, was man will und wie man es strukturiert.

Rainer

Wenn der Kalender einfach nur tageweise Termine anzeigen soll, könnte man sich auch mit „CSV-Datei pro Tag“ retten (20240229.CSV, 20240301.CSV, …).

Wenn die Applikation dann jedoch eine Suche nach allen Zahnarztterminen der letzten fünf Jahre und/oder eine „Autovervollständigung“ (Übernahme von Details aus alten Terminen) anbieten soll, dann wird die CSV-Ablage schnell seeeeeehr laaaaaangsam.

Und wenn dann die Applikation noch Adressen aus dem Adressbuch übernehmen soll, dann stößt man mit R-Basic vermutlich an die Grenzen. (à la „Ich gebe <<Montag, 15 Uhr Zahnarzt>> ein und der Kalender übernimmt dann automatisch die Adresse der Praxis aus dem Adressbuch in die Termindetails.“)

As I gathered, it is impossible to make the calendar more flexible? Is it possible to at least change the display to follow the ISO standard, and make Monday the first day of the week in the calendar layout? I find it disturbing that the layout differs in Geos compared to my calendar in my phone.

I wouldn't say it's impossible, but it just needs more work than a quick: "just start on monday" in code...

Frage eines Amateurs: Kann man die Kalender-App evtl. "quick & dirty patchen"? Dann gäbe es zwar ne 2. Version, die sich in dem Punkt unterscheidet. Aber vielleicht ist das einfacher und mit weniger Aufwand umzusetzen, als die App oder das System "korrekt" anzupassen, um den ersten Tag der Woche auszuwählen?

Es gibt mehrere Schleifen, die von 0 bis 6 laufen. Und das ist leider von Sonntag bis Samstag. Diese Schleifen müsste man auf „1-6 und dann hinterher alles nochmal für die 0“ umstellen. Möglich wäre es, aber aufwändig. Die Stellen, die ich bislang gesehen habe, habe ich nur gefunden, weil es im Quelltext entsprechende Kommentare gab.

Das Abarbeiten in zwei Phasen wäre sehr unpraktisch.

Man könnte die Schleife vergrößern: anstand 0-6 dann 0-12, so daß sogar jeder Wochentag der Wochenbeginn sein kann. Dann speichern zwei Variablen die jeweilige Ober- und Untergrenze. Diese müßten dann in die ganzen Schleifen übernommen werden.

Oder man definiert das Ursprungs-Array je nach gesetzter Option von So bis Sa oder Mo bis So. Dann funktioniert der Rest (vielleicht) einfach so.

Alles spontane Ideen, ohne je den Code gesehen zu haben :).

Quick&Dirty hat eben immer den Dirty-Anteil. Wenn z.B. irgendwo eine Null steht, weist du ohne nähere Analyse nie, ob es wirklich nichts = leer sein soll, oder eben Sonntag.
Rainer

If we want to solve this question once and for all, sound like Sebis suggestion (0-12, or 0-13) is the smartest as the first day of the week varies over the world. I like proper solutions that is thought through and makes the problem solved once and for all. Check this Wiki: https://en.m.wikipedia.org/wiki/Week

MODULE: Calendar/UI
FILE: uiStrings.ui

AUTHOR: Don Reeves, 2-23-91

REVISION HISTORY:
Name Date Description
---- ---- -----------
Don 2/23/91 Initial revsion - moved from calendar.ui
Richard 4/12/95 Make Monday first day of week for Responder <<<< WAS IST DAS HIER !!!
RR 6/8/95 Variable length event error messages

DESCRIPTION:
Contains the string and data resources for the GeoPlanner application
        
$Id: uiStrings.ui,v 1.2 97/07/01 12:12:11 newdeal Exp $

Sieht so aus, als würde die Nokia-Version mit Montag als erstem Tag arbeiten… Die Frage wäre, ob das ohne die ganzen Foam-Libraries funktioniert und ob die Variante komplett im Repository enthalten ist.

Ich habe die Geoplan aus dem NokiaSDK gefunden ist 140.07KB dagegen ist Geoplan aus dem FreeSDK nur 65.91KB nur kompilierte Geode da ist dann doch viel mehr Code drin , leider kein Sourcecode !

Keine foam-Libraries im Repository .

Unschuldige Zwischenfrage: Was sind Foam-Librarys? Klingt so schaumig

System Libraries aus den Nokia Communicator (Geos). "foam.geo foamdb.geo response.geo und andere.."

von Nico

Die Dinger heißen Foam, weil sie extra für einen Einsatz auf einem „Telefoam“ entwickelt wurden - kleiner Insiderwitz der damaligen Entwickler bei den Erdarbeitern.

Mmmh, da steh ich noch immer auf dem Schaumschlauch: Ist „Telefoam“ nun auch bereits ein Wortspiel oder bedeutet das im Englischen irgendwas (Technisches)?

So richtig weiß ich es auch nicht. Aber ich meine mich zu erinnern, dass es damals so interpretiert wurde, dass die Schaumstofflibraries die Härten der GEOS Systemprogrammierung für normale Programmierer (erbärmliche Sterbliche) etwas abmildern sollten. Marcus meinte dazu später dann aber mal mit Bedauern in der Stimme, dass sie damit einige der besten GEOS Eigenschaften verbastelt hätten. Außerdem liefern die Libs natürlich einige Communicator-spezifische Funktionen. Ich hab damit nie garbeitet und kann das alles nicht beurteilen.

Hallo!

Gute Frage, auf die es mindestens drei mögliche Antworten gibt:

Hielten die Geoworks-Entwickler die Abkehr vom generischen Ansatz hin zu einem speziellen Telefon-Gedöhns für „Schaumschlägerei“ der Marketingabteilung? (Weil in den meisten Fällen einfach nur das „Gen“ durch ein „Foam“ ersetzt wurde. Es gab in der Realität nur wenige Erweiterungen/Anpassungen.)

Oder hielten sie die Smartphones für etwas, dass keiner brauchen und in 1-2 Jahren wieder verschwinden würde? (So à la „Träume sind Schäume.“ oder „Diese Blase wird bald wieder platzen!“)

Oder haben sie einfach nur eine “Verballhornung“ des Telefons aufgegriffen, die es in den USA schon seit mindestens den 1920ern gab? http://www2.iath.virginia.edu/crocker/