App: MagicWallpaper - feature requests?

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.
  • Hallo alle miteinander - dies ist mein erstes Posting auf Nexave :)


    Ich entwickle gerade eine neue App namens "MagicWallpaper". Der / Das Pre unterstützt ja keine Widgets auf dem Desktop, ich habe es aber ganz gerne, wichtige Aufgaben und unangenehme Aufgaben immer direkt vor der Nase zu haben, um sie nicht zu verdrängen :pfeift: . Deshalb kann man mit MagicWallpaper einfache To-Do items auf dem Desktop ablegen, dazu wird einfach auf ein Hintergrundbild gezeichnet.


    Meine Frage an Euch ist jetzt, welche Features würdet Ihr Euch für so ein Programm wünschen? Gibt es ausserhalb meiner 4-Wände überhaupt Bedarf dafür? Derzeit wird nur der Download von Wallpapers von Picasa Web Albums oder einer URL unterstützt, ein Hochladen der eingestellten Wallpaper klappt (noch) nicht - wäre das wichtig? (Verbraucht einiges an Datenvolumen). Sollte so eine App sich täglich selber aufrufen und Termine aktualisieren? Usw. usw. Ich mache das nur zum Spass und als Hobby, es wäre mir wichtig zunächst die meist-gewünschten Sachen einzubauen, damit es überhaupt irgendwann rauskommt :)


    Vielen Dank im voraus,
    BlackCatBone

  • Ein Startbildschirm wo man alle Termine, Aufgaben usw. auf einmal sehen kann, ist das was ich bei WebOS am meisten vermisse. Ich hatte jahrelang WinMob-Geräte genutzt, und hoffe mit irgendeinem Update wird sich das bei WebOS ändern.

  • WAS?? Oh das wusste ich nicht, echt jetzt...??


    ÖHM...? Das würde ja heißen, dass es keinerlei "besseren" Kalenderprogramme geben könnte?!


    Grüße

    Yup. Das ist ja das Dilemma. Du darfst zwar eigene Kalendereinträge anlegen, aber nicht die vorhandenen auslesen. Dasselbe gilt für die Kontakte, auch wenn man da einen einzelnen Kontakt durch den User auswählen lassen kann. Deshalb gibt es z.B. immer noch keine App-Katalog fähige App für Geburtstagserinnerungen. Die eine - mir bekannte - App im amerikanischen App-Store nutzt hierfür direkt die Google-Kontakte auf den Google-Servern. Das Ganze ist eine ziemlich heftige Einschränkung für Apps :peinlich:


    Bye,
    BlackCatBone

  • Ich lese gerade, dass man keine Kalendereinträge auslesen kann? Das zerstört gerade meine Idee für meine nächste App. Denn die soll genau das machen. Verdammter .... *grml* :thumbdown:


    Aber an deiner App hätte ich schon großes Interesse!! Ich hab auch immer fast alle Cards geschlossen und sehe den Hintergrund, da wäre die Anzeige der Aufgaben echt Klasse. Ist es egal, wo die Aufgaben herkommen? Ich nutze nen Exchange-Server.

  • Echt geniale IDEE!!!


    eine Frage hab ich(bitte nicht persönlich nehmen) warum werden neue apps von deutschen entwickelt und die immer auf Englisch?? wir leben zwar alle auf einer Welt die Weltsprache ist Englisch, ja das weiß ich, aber ich würde mich freuen auch mal ein app auf anhieb zu verstehn und lesen zu können! :) :thumbup:


    Musste ich kurz loswerden :)

  • warum werden neue apps von deutschen entwickelt und die immer auf Englisch?

    Weil man so nur einmal entwickeln braucht, um sie international im App Catalog anbieten zu koennen.
    Wenn es nach Oettinger ginge, sollte ohnehin jeder Deutsche Englisch koennen.
    Also ist eine englische SW-Entwicklung nur konsequent und spart nicht nur Aufwand sondern auch Zeit.

  • Weil man so nur einmal entwickeln braucht, um sie international im App Catalog anbieten zu koennen.
    Wenn es nach Oettinger ginge, sollte ohnehin jeder Deutsche Englisch koennen.
    Also ist eine englische SW-Entwicklung nur konsequent und spart nicht nur Aufwand sondern auch Zeit.

    Das ist einsichtig.
    Aber warum fangen manche, nein nur eins, mit einem Umlaut im Namen an? Ist ja schön deutsch, verhindert aber den Aufruf per Tasten aus dem Launcher, auch in D.

  • Weil man so nur einmal entwickeln braucht, um sie international im App Catalog anbieten zu koennen.
    Wenn es nach Oettinger ginge, sollte ohnehin jeder Deutsche Englisch koennen.
    Also ist eine englische SW-Entwicklung nur konsequent und spart nicht nur Aufwand sondern auch Zeit.

    <OT>
    Und das lästige Deutsch, was soundso nur die wenigsten Deutschen beherrschen, kann ENDLICH komplett abgeschafft werden !


    Sorry, I couldn't resist ....
    </OT>

  • Also ist eine englische SW-Entwicklung nur konsequent und spart nicht nur Aufwand sondern auch Zeit.


    Beim WebOS ist das Argument aber quatsch. Bei konsequenter Entwicklung mit der Maßgabe, die Anwendung in mehreren Sprachen anzubieten, ist der Aufwand nur unwesentlich höher und der Nutzen ungemein groß. Man kann mit geringem Aufwand alle Sprachen einbinden, die man möchte. Man muss für die Einbindung programmiertechnisch noch nichtmal was tun. Man muss noch nichtmal alle Sachen übersetzen. Fallback ist immer die Standardsprache.
    Im Punkt Lokalisation (zumindest was die Übersetzung betrifft) ist WebOS ganz weit vorne.


    Viele Grüße
    Frank

  • ist der Aufwand nur unwesentlich höher und der Nutzen ungemein groß. Man kann mit geringem Aufwand alle Sprachen einbinden, die man möchte. Man muss für die Einbindung programmiertechnisch noch nichtmal was tun. Man muss noch nichtmal alle Sachen übersetzen.

    Du sagst also, dass man keine weiteren Fremdsprachen beherrschen muss, das uebernimmt webOS fuer einen?


    Ich habe mich gerade noch einmal rueckversichert: Der programmiertechnische Aufwand ist wohl nicht so gross wie bei PalmOS, aber es ist nach wie vor so, dass der Programmierer Sprachtabellen in jeder Sprache anlegen muss, die er anbieten moechte. Konkret bedeutet das, dass, wenn man ein Programm in 5 Sprachen lokalisiert anbieten moechte, man diese Sprachen beherrschen muss, denn das uebernimmt webOS fuer mich nicht.


    Man kann eine Schaltflaeche auf Deutsch "Runterladen" nennen, muss aber im Programm entsprechende lokalisierte Uebersetzungen fuer Englisch "Download" und im Franzoesischen "Telecharger" selbst definieren. Und dieses fuer jede kleine Schaltflaeche, Beschreibung, Hilfeseite und daraus resultierenden Anhaengigkeiten, wie entsprechend verschiedene Datenbanken auslesen (z.B. Wikipedia), etc.
    Auch muss jede lokalisierte Seite (z.B. eine Hilfeseite) in webOS explizit und einzeln uebersetzt und angegeben werden.
    Aufgrund der Referenztabellen blendet webOS dann die entsprechende Seite und benannte Schaltflaeche je nach Systemspracheinstellung ein. Fehlt eine, gibt es Murks.


    Also, der Programmieraufwand mag geringer sein, ist aber nicht vernachlaessigbar und insb. die Fremdsprachen sind ein nicht zu unterschaetzender (menschlicher) Faktor.
    Es kann vielerorts passieren, dass man z.B. eine Programmseite vergisst zu aendern und schon hat man einen Sprachenmix, der sehr unproffessionell wirkt.


    Es gibt also gute Gruende dafuer, sich das Leben einfacher zu machen und nur eine englische Version anzubieten.
    Auch aus monetaeren Gesichtspunkten werden sich einige Programmierer ueberlegen, rein englische Versionen anzubieten.
    Der englische Markt im App Catalog ist naturgemaess der groesste und bringt damit potentiell mehr Geld.


    Ich rede nicht davon, dass eine rein deutschsprachige oder auf das Bundesgebiet reduzierte App, wie Bahnfahren oder Leo, nicht in Deutsch angeboten werden sollte. Diese in Englisch waere natuerlich Unfug.
    Aber eine weltweit allgemeingueltige App, wie Aufgabenliste, Musikprogramm, Routenplaner, etc. ist durchaus eine Ueberlegung wert, direkt in Englisch anzubieten...

  • Hallo,


    nein, die Übersetzung macht natürlich WebOS nicht für dich. Darum ging es mir auch gar nicht. Du programmierst englischen Text und schreibst im Forum deutsch. Damit hast du schonmal zwei Sprachen, die du problemlos anbieten kannst. Für die anderen Sprachen "heuert" man Leute an, die die Sprachen beherrschen. Darum gibt es ein paar englische Programme in Deutsch ;)
    Bei entsprechender Vorbereitung musst du am Programm nichts ändern. Nur darauf achten, dass alles übersetzt wurde. Sonst entsteht ein Sprachmix, das ist richtig.


    Und ob du nun schreibst "L('Click here')" oder "Click here" ist vom Aufwand her vernachlässigbar. Und da brauchst du noch nichtmal Sprachfiles für. WebOS schreibt einfach das aus, was innerhalb der Hochkommatas steht, wenn es keinen Eintrag im Sprachfile für findet. Und wenn ein deutsches Sprachfile an der richtigen Stelle im Paket hängt, wird das automatisch gezogen.


    Und WebOS hat auch gute Funktionen, um z.B. formatierte Zeichenketten auszugeben.


    Je komplexer das Programm ist, umso umfangreicher ist natürlich das Sprachfile. Aber diese "Arbeit" macht man sich nur einmal und die Programme sind dann für Nutzer in anderen Ländern interessanter. Nicht jeder kann perfekt englisch. WebOS soll ja massentauglich werden ;)



    Edit: Lese gerade:


    Zitat


    Auch muss jede lokalisierte Seite (z.B. eine Hilfeseite) in webOS explizit und einzeln uebersetzt und angegeben werden.
    Aufgrund der Referenztabellen blendet webOS dann die entsprechende Seite und benannte Schaltflaeche je nach Systemspracheinstellung ein. Fehlt eine, gibt es Murks.


    Dachte ich zuerst auch. Konnte mich aber nicht damit abfinden, dass das so gemacht wird. Man kann den Code auch sprachunabhängig machen. Ich habe die Lokalisation im Agenda-Projekt gemacht, der Hauptentwickler war skeptisch, aber es funktioniert sehr gut. "Leider" war der Programmierer nicht ganz so experimentierfreudig ;)




    Viele Grüße
    Frank

  • wenn man von anfang an vor hat, das app in verschiedenen sprachen zu veröffentlichen sollte man sich darüber im klaren sein wie man dies realisiert.


    ob man die Language Funktion gleich mit dem "heimat" string versieht, man sich der keys oder gar der view übersetzung bedient.


    ich nutze wo ich kann die normale key funktion (also anstelle von $L("Welcome Back!") etwas wie $L("greeting.welcome"))


    sollte eine sprache nicht unterstützt werden wird einfach die default strings.json verwendet


    greez
    TheRealLink

  • Um noch mal OffTopic zu werden, sorry :love:


    Das mit den Sprachen ist zwar immer noch zuviel Aufwand, aber mit pypalm, wenn man im Code konsequent ist, hat man es wirklich leichter!


    http://github.com/grundprinzip/PyPalm


    Damit definiert man in der framework_config.json ein languages Array mit den zu unterstützenden Sprachen [de_de] usw...
    Wenn man nun konsequent im Code mit $L("Download") arbeitet, und wirklich immer "doppelte Anführungszeichen" verwendet, bei einfachen strauchelt die App, dann hat man nach dem ausführen von pypalm localize im resources-Ordner für jede Sprache die man im Array angegeben hat einen Ordner und darin auch schon dir passenden Strings.


    Übersetzen muss man nun immer noch, aber das wird wohl nie ganz von selbst gehen.