Artikelformat

Taskr · Open Source Task Manager für den Mac

Allen GTD-Apps zum Trotz nutze ich zum Managen meiner To-Dos seit etlichen Jahren Apples Erinnerungen-App.

Mit Taskr gibt es auf diesem Gebiet seit ein paar Tagen eine weitere Alternative, die durch ihr sehr einfaches und hübsches Interface überzeugen kann.

taskr_aguDE

Die bisherigen Features dieser noch sehr jungen und quelloffenen App konzentrieren sich auf das Wesentliche.

Man kann neue Aufgaben mitsamt einer Beschreibung einem Projekt zuordnen oder Aufgaben markieren, die “heute” erledigt werden sollen. Dazu kann man erledigte Aufgaben als unerledigt markieren oder sich überfällige Aufgaben anzeigen lassen. Außerdem arbeitet die App komplett offline und man kann Aufgaben ex- bzw. importieren.

Für zukünftige Versionen von Taskr sind ein Cloud Sync, die Unterstützung von Tags, Themes, Team Support, eine iOS App (eventuell auch Android) und der Support von Linux und Windows bereits angekündigt. Auch die Unterstützung von verschiedenen Plugins (GitHub, Slack, Erinnerungen…) ist geplant.

Wie Pliim basiert auch Taskr auf dem Electron Framework, was die für eine simple To-Do App recht beachtliche Größe von knapp 130 MB auf der Festplatte erfordert.

Der Quellcode von Taskr ist bei GitHub zu finden.

-> https://taskr.now.sh

Autor: Björn

Ich bin Björn und quasi der COO von aptgetupdateDE. Ich kümmere mich um die PR und allerlei Kontaktaufnahmen zu Herstellern und Softwareentwicklern. Erreichbar bin ich bei Twitter und natürlich per E-Mail.

6 Kommentare

  1. Na klasse, Elektron. Und schon kein interesse mehr. :(

    Kann keiner mehr nativ entwickeln? Web-Apps werden nicht besser, wenn man sie in App-Container packt. Die bedienen sich dann immer noch falsch und sind haptisch falsch.

    Was für ein elend. Dann kann ich mir auch gleich ChromeOS installieren.

    Kann mal jemand diese Hipster-Entwickler wieder einfangen, bitte? 130MB für eine simple Todo-App. Es fuckt mich schon bei den ganzen aktuellen Messenger-Clients ab…

    :(

    Antworten
      • So richtig absurd finde ich das ja bei Etcher, einem Tool zum Images auf SD-Karten und USB-Sticks schreiben. 185MB geballtes Elektron-Übergewicht. Letztlich ist es nur ein Wrapper für 1-2 Shell-Tools. Was ist das für eine Entwicklergeneration, die erstmal 20 Lagen Frameworks auf ein Problem schmeisst, für das das Betriebssystem das passende Tool hat. Am besten werfen sie diese Frameworks direkt AUF dieses Shell-Tool. :-/

        Und dieses Etcher macht zusätzlich noch 3 Helper-Prozesse auf. 73+130+75+90MB -> 368MB RAM. Mit 30+25+16+5 -> 76 Treads und 379+185+119+22 -> 705 offene Ports (Dateien und Netzwerkverbindungen). Und dabei ist Etcher nur gestartet. Es hatte noch nichts gemacht, außer warten. Und der eine Helper-Prozess saugt beständig 1,3-3% CPU. Das Ding frisst in 5 Minuten mehr Rechenzeit, als so mancher Helper-Prozess über einige Tage.

        Ich verstehe nicht, warum es so schwer sein soll eine simple native GUI um die Tools zu stricken, die sie benutzen. Besonders hier, weil sie ja eh direkt auf Systemebene herunter wollen und nicht nur einen haufen Web-Frameworks bespielen. Was wollen die Web-Entwickler alle auf unserm Desktop? Die sollen wieder weg. Die sollen Web-Kram machen. :-)

        So langsam verstehe ich, warum manche Entwickler „Web-Entwickler“ als Schmähbegriff verwenden. So würde ich vermutlich auch gucken, wenn ich sehe, wie sie einen Berg an Gerätschaften auffahren, anstatt einfach den Hammer zu nehmen, um den Nagel (die eigentliche Aufgabe) in die Wand zu schlagen. „Zu wenig facy, zu wenig bling bling“-Syndrom?

        So, das musste mal raus. Aber ich meine es durchaus ernst. Es wirkt manchmal so, als ginge es da um einen Webbewerb unter Entwicklern, wie absurd man es denn treiben könnte, bis genug Leute „Hey, was soll das“ rufen. :-)

        Und da fragt man sich, warum die Rechner immer langsamer werden…

        Antworten
      • Nur mal zum Vergleich: UNetbootin, ebenfalls ein Tool zum Images auf SD-Cards/USB-Sticks schreiben, ist nur 19MB groß, und belegt nur 38MB RAM mit einem Prozess, 3 Threads und 192 Ports. Im Vergleich zu Etcher saugt es beim Warten nur 0,3% CPU. Ich würde das ja immer noch für zuviel halten, aber im Vergleich ist das ja ein lächerlich wenig.

        Dabei benutzt Unetbootin auch ein non-native GUI-Framework, damit es plattformübergreifend funktioniert. Es ginge auch noch sparsamer, wenn man tatsächlich das systemspezifische GUI-Toolkit verwenden würde. Aber das ist ja schon Ok, weil sparsam genug und dem Zweck angemessen. Worauf ich hinaus will: um plattformübergrifend zu entwickeln, muß man nicht diesen Web-Mist benutzen. Da kann man auch GTK, QT, Java oder dergleichen benutzen. Ist vielleicht nicht ganz so bling bling, aber es geht wenigstens sparsam(er) mit meinen Ressourcen um.

        Antworten
      • Und noch einen Vergleich in Bezug auf Taskr: Mein OmniFocus, was eine ausgewachsene und full-featured GTD-Anwendung ist, die weit über Taskr (zumindest im aktuellen Zustand) hinaus geht, belegt gerade mal 61MB auf der Platte.

        Wenn OmniFocus längere Zeit nicht benutzt wurde (Fenster zu), macht es einen schlanken Fuß und belegt gerade mal <100k RAM (es läuft bei mir 24/7). Im aktiven Zustand mit geladener Datenbank komme ich auf 177MB RAM, 8 Threads und 290 Ports. Und es wartet mit 0,0%CPU auf Benutzerinteraktion. SO muß es aussehen.

        Vielleicht mag ja mal jemand, der/die Taskr ausprobiert, mal die Daten (Platz des App-Bundles auf Platte, physikalisch belegter RAM, Anzahl der Prozesse und Threads, Ports, % CPU) hier posten. Ich würde mich wundern, wenn es nicht weit mehr ist.

        Antworten
      • Warum ich so darauf herumreite: ich komme aus der technischen Informatik (hab aber seit einiger Zeit aus gesundheitlichen Gründen auf Admin umgesattelt) und da ist das Thema Ressoucen ein sehr entscheidendes. Da wird oft um jedes % gefeilscht, um harte Anforderungen (z.B. Reaktionszeit, max. RAM-Bedarf) zu erfüllen. Da lernt man jedes Bit noch einzeln kennen und man weiß genau wie so eine CPU funktioniert. Wir hatten im Studium noch eine CPU in VHDL designt.

        Aus unserer Sicht wirken diese ganzen Elektron-Entwickler wie Nicht-Informatiker, die sich ihre Apps einfach nur zusammenklicken, egal was es für die Ressourcen bedeutet. Und wenn man das ganze mal etwas globaler betrachtet, bedeutet deren Verhalten einfach auch, daß insgesamt viele Ressourcen (incl. Strom) einfach verschwendet werden. Man stelle sich vor, das eigene MacBook mit 8GB festgelötetem RAM und 256GB festgelöteter SSD würde ausschliesslich mit Electron-Apps betrieben werden… MICH würde das ärgern.

        Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.