Featurerequest RESIDENTS

[alanblack]

Habe gerade mal nachgeschaut. Ich habe noch ein Attribut gesetzt

attr NAME rr_locations atwork,home,wayhome,underway

Ja, es geht ja. Aber wenn ich es so nutze, wie es die Doku vom RESIDENTS/ROOMMATE nahelegt, bin ich quasi wieder bei

Die Geschichte mit rr_locations, rr_locationWayhome und Co. ist für meine Begriffe zu strikt. Abgesehen davon, dass ich "leaving" damit eh nicht abbilden kann, ist das Verfahren rr_locations e.al. passend zu füllen, schwierig und langwierig:

Denn die 3 km-Lösung von Dir ist mir zu statisch. Erstens bin ich mit dem Auto zu schnell da durch, dass es steuerungstechnisch für mein Haus Sinn ergibt, und zweitens habe ich Freunde und Verwandte innerhalb der näheren Umgebung, wo ich dann gar nicht erst raus wäre aus so einem Umkreis.
Ich hätte halt gerne nur die ganz einfache Lösung mit "leaving" und "arriving". Die kann ich - in seltenen Fällen - automatisch durch unsere Handys (hier mit Tasker, aber das nur am Rande), automatisch über die Terminkalender etc. oder teilautomatisch (Handy raus, das richtige Icon antippen, fertig) setzen kann.

Noch einmal: ich weiß, dass zumindest das "arriving" jetzt prinzipiell schon abbildbar ist. Das nervigste dabei ist einfach nur, dass ich an vielen Stellen nicht nur den State auswerten muss, sondern

Code Auswählen Erweitern


...
elseif $state eq "absent" {
if $wayhome = 1 {
  ...
}
else
{
  ...

einbauen muss.
Ich kann das auch in eine sub packen. Es ist für mich nur logischer und konsequenter, wenn es ein "asleep => awoken => home" und ein "home => gotosleep => asleep" gibt, dass es dann auch sowohl ein "home => leaving => absent" als auch ein "absent => arriving => home" gäbe.
Ich habe es oben schon gesagt, dass es nur Sinn macht, das ins RESIDENTS-Modul einzubauen, wenn es einfach zu lösen ist. Ich könnte es auch selbst in eine Kopie des RESIDENTS-Moduls einbauen. Dann fehlen mir darin aber in Zukunft die Updates.

Vielleicht meldet sich der Maintainer ja mal dazu. Wäre ich dankbar für.

[CoolTux]

Ich habe es oben schon gesagt, dass es nur Sinn macht, das ins RESIDENTS-Modul einzubauen, wenn es einfach zu lösen ist. Ich könnte es auch selbst in eine Kopie des RESIDENTS-Moduls einbauen. Dann fehlen mir darin aber in Zukunft die Updates.

Vielleicht meldet sich der Maintainer ja mal dazu. Wäre ich dankbar für.

Vorschlag. Julian ist immer recht beschäftigt. Daher meine Empfehlung, implementiere Deine Idee als Code ins Modul und erstelle einen Patch den Du Julian zu Diskussion anbietest.
Denke bitte daran wenn Du es so machst das Du die Commandref auch erweiterst.

Grüße

[alanblack]

Vorschlag. Julian ist immer recht beschäftigt.

Abgesehen davon, dass ich auch alles andere als Langeweile habe, dürfte Julian die Änderungen mit seiner Kenntnis des Codes schneller fehlerfrei implementiert haben - oder zumindest mal vorab den Zeitbedarf bzw. den Aufwand abschätzen können. (Warum auch immer Du für ihn sprichst.)
Für mich ist es wahrscheinlich mehr Arbeit, die beiden Module zu ändern, als wenn ich die beiden Stati in meinem Code abfange - zumindest für den Moment. Langfristig ist es wahrscheinlich verkehrt, aber das weiß ich eh erst hinterher.

Nachtrag: ich habe mal in den Sourcecode geschaut. Zum Glück ist Perl meist leicht lesbar, denn die Inline-Doku ist "spärlich". 

[CoolTux]

Also bis vor 3 Stunden warst Du der einzige mit dem Wunsch und daher erwarte, zu mindest ich, das der jenige wenn er schon von eigener Anpassung spricht ein Patch bereit stellt. Aber das ist meine Meinung.

Der Code wie du sagst gut lesbar ist, wieso sollte er dann noch mal Dokumentiert sein. Was bringt ein Kommentar welches das sagt was man im Code eh sieht.
Aber wie auch immer. Du machst das schon.

Ach und ich spreche nicht für ihn sondern mein Vorschlag ist einer der gängigen Wege im Open Source Bereich.


Grüße