Kalender und calendar.waste

[Cannon]

Was meinst Du mit „Seiten im Netz?“ Meinst Du URLs, die im Kalendereintrag stehen und dann nicht vollständig angezeigt werden? Das könnte eher ein Escaping-Problem sein. Hast Du ein Beispiel?

Nein, dass hat hiermit nichts zu tun. Das hatte ich bei einen Dienstplaner, wo immer die Namen abgeschnitten wurden, obwohl da noch genug Platz war. Das wurde dann aber mit einem Updaete behoben ....

[wvhn]

Das Feature mit dem klickbaren Info-Feld ist jetzt im Develop. Ich habe dazu eine Option angelegt, die man auf 'active' setzen kann, um dies zu nutzen. Default ist das bisherige Verhalten (Option weglassen oder '').

Cannon, konntest Du den iCal Service schon testen? Wenn Du in der Konfiguration bei den Kalendernamen die Leerzeichen hinter dem Komma weglassen musst, damit es funktioniert, dann sollte es reichen, im Regex Zeile 29 das '+' durch ein '*' zu ersetzen.

$config_calendar_names = preg_split('/,\s*/m', strtolower(config_calendar_name));

Gruß
Wolfram

[Cannon]

Cannon, konntest Du den iCal Service schon testen? Wenn Du in der Konfiguration bei den Kalendernamen die Leerzeichen hinter dem Komma weglassen musst, damit es funktioniert, dann sollte es reichen, im Regex Zeile 29 das '+' durch ein '*' zu ersetzen.

Ich habs getestet. Das Austauschen des DIenstes hatte dazu geführt, dass der gar keinen Kalender lädt. Es gab keinen Fehler und es nicht nachvollziehbar warum nicht, denn deine geänderte Zeile 29 funktionierte, wenn ich das bei mir änderte, obwohl beim Vergleich sonst kein anderer Unterschied feststellbar war. Es wurde aber mehr als nur das + und * getauscht:

alt: '/[\s,]+/m'
neu: '/,\s*/m'

Ich habe aber nicht verstanden, wie das genau geht, diese RegEx-Sachen sind echt schwer verständlich ...

Aber um es noch mal zu sagen die Änderung auf "neu" macht auch Kalendernamen mit Leerzeichen möglich.

[Cannon]

Das Feature mit dem klickbaren Info-Feld ist jetzt im Develop. Ich habe dazu eine Option angelegt, die man auf 'active' setzen kann, um dies zu nutzen. Default ist das bisherige Verhalten (Option weglassen oder '').

Habe ich mal probiert. Ist doch schon mal echt toll. Anmerkungen dazu:

- das Widget ist breiter geworden (irgendwas stimmt mit Margin oder Padding nicht)
- vielleicht sollte da nicht "Info" stehen, sondenr man nimmt ein Symbol evtl. das + Symbol, was man ja bei den Containern schon hat
- die Info evtl. nur dann sichbar, wenn nicht genug Platz ist

[wvhn]

Ich habs getestet. Das Austauschen des DIenstes hatte dazu geführt, dass der gar keinen Kalender lädt. Es gab keinen Fehler und es nicht nachvollziehbar warum nicht, denn deine geänderte Zeile 29 funktionierte, wenn ich das bei mir änderte, obwohl beim Vergleich sonst kein anderer Unterschied feststellbar war. Es wurde aber mehr als nur das + und * getauscht:

Aber um es noch mal zu sagen die Änderung auf "neu" macht auch Kalendernamen mit Leerzeichen möglich.

Verstehe ich das richtig: wenn Du die gepostete Datei verwendest (Endung umbenannt von .txt in .php), funktioniert es nicht, aber wenn Du die Änderung manuell machst, funktioniert es?

alt: '/[\s,]+/m': hier wird der String der Kalendernamen bei Leerzeichen oder Komma getrennt, oder wenn beides in beliebiger Reihenfolge vorkommt. Das geht bei Kalendernamen mit Leerzeichen schief.
neu: '/,\s*/m': hier wir beim Komma getrennt und direkt darauf folgende Leerzeichen werden entfernt.

Gruß
Wolfram

[wvhn]

Habe ich mal probiert. Ist doch schon mal echt toll. Anmerkungen dazu:

- das Widget ist breiter geworden (irgendwas stimmt mit Margin oder Padding nicht)
- vielleicht sollte da nicht "Info" stehen, sondenr man nimmt ein Symbol evtl. das + Symbol, was man ja bei den Containern schon hat
- die Info evtl. nur dann sichbar, wenn nicht genug Platz ist

Ich musste bei mir den Browser-Cache bzw. die Websitedaten für die IP des Raspberry löschen, damit es funktionierte. Grund ist eine winzige Änderung in der base.css. Die Kalenderliste wird jetzt nicht mehr als <ul> aufgebaut, sondern als <dl>, damit das Feld mit den zusätzlichen Inhalten beim Anzeigen der Seite erstmal zugeklappt ist. Wer hier eigenes css verwendet, muss das entsprechend anpassen.
Die Breite der Liste ist bei mir unverändert.

Das „+“ finde ich eine gute Idee. Ist auch eindeutiger.

EDIT: Das "+" sieht blöd aus. Das muss ich gelegentlich mal auf die jQuery Symbole umstellen. Einstweilen bleibt es bei "Info".

[Cannon]

Ich habe mal einen Screenshot gemacht über die gesamte SmartVISU. Dann sieht man das auch mit dem Kalende rim Verhältnis besser. Ich habe das Bild um die Hälfte verkleinert, wenn das so nicht gut zu sehen ist, dann lade ich noch mal die Original-Größe hoch.

smartvisu kalender.jpg

[Tom Bombadil]

- das Widget ist breiter geworden (irgendwas stimmt mit Margin oder Padding nicht)

Das hängt bestimmt damit zusammen, dass im css <ul> adressiert, jetzt aber <dl> verwendet wird.
Die Styles werden somit nicht angewendet, da das Element nicht (mehr) gefunden wird.

/tom

[wvhn]

Bei mir sah das so aus, als ich die Änderung in der base.css noch nicht gemacht hatte. Wichtig ist Zeile 1221

.calendarlist dl

anstelle …ul.

[Cannon]

Bei mir sah das so aus, als ich die Änderung in der base.css noch nicht gemacht hatte. Wichtig ist Zeile 1221

Ja ich hatte nur 2 Dateien geändert, die Base fehlte noch. Aber super. Sieht gut aus! :-)

[Tom Bombadil]

wvhn Wolfram, da Du kürzlich sowieso die Kalender am Wickel hattest - wäre es ohne größeren Aufwand möglich, einen optionalen Tag-Filter (=Kategorien) in das Widget zu integrieren? Also aus:

{{ calendar.list(id, title, count, color, repeat, calendar) }}

wird:

{{ calendar.list(id, title, count, color, repeat, calendar, optional_tagfilter) }}

Irgendwo wird da auch schon ansatzweise was gemacht, aber so recht schlau werde ich daraus nicht.

Ich hätte dafür einen konkreten Anwendungsfall, auf den mich die neuen Zusatzinfos von oben gebracht haben.

iCloud/iCal scheinen übrigens keine Kategorien zu kennen, dort werden für sowas wohl grundsätzlich verschiedene Kalender verwendet. Aber für die Caldav und GoogleV3 Services wäre das sicher eine feine Sache ...

/tom

[wvhn]

Tom Bombadil Da bei mir weitgehend Google-freie Zone ist, brauche ich als Vorarbeit von Dir ein paar Tests, denn die Kalender werden entweder durch das extern bezogene iCal-Modul geparst oder bei GoogleV3 direkt als json geliefert.
Wenn Du Kalendereinträge mit Tags/Kategorien versiehst und die Kalender-Services dann im Debug-Modus ausführst und mir die Ergebnisse schickst, dann können wir in den Rohdaten sehen, welche Daten mitkommen und ob ich die im jeweiligen Service hinzufügen kann.

Wenn die Daten da sind, ist das Filtern sicher nicht so aufwendig.

Gruß
Wolfram

[Tom Bombadil]

Ja, ich sehe mal, ob ich das irgendwie zusammenbekomme. Hier mal ein 'proof of concept', was ich eigentlich machen will (Jahreskalender mit jährlich wiederkehrenden Terminen - Werte ablesen, Reifen wechseln, Baumschnitt, Hecke düngen, Heizungs- und Entkalkerservice im September vereinbaren, TüV alle 2 Jahre etc etc):

jahreskalender.png

Im Moment überlege ich, von der Kalenderkomponente doch wieder wegzugehen und einfach eine Textanzeige zu machen. Grund: 12x Anholung desselben Kalenders von einer NextCloud im LAN dauert fast 45s. Zweiter Grund: Bei einem einfachen Textfeld muss man keine wiederkehrenden Termine im Kalender erstellen. Ich muss mal sehen, ob ich ein Item vom Typ 'string' als bulleted list in den Boxen darstellen kann.

Bisheriger Code (quick&dirty zusammengeschrieben), falls noch jemand Lust hat, da ein bisschen zu experimentieren:

{% extends "1block.html" %}

{% block one %}

    <style type="text/css">  

        .calblock {
            display: inline-block;
            vertical-align: top;
            overflow: hidden;
            height: 40vh;
            width: 15%;
            margin: 10px 10px;
        }
        
        .calueberschrift {
            text-align: center;
            /** opacity: 33%; **/
            font-weight: bold;
            line-height: 2;
        }

    </style>

    {% set months_locale = [
     'Januar', 'Februar', 'März',
     'April', 'Mai', 'Juni',
     'Juli', 'August', 'September',
     'Oktober', 'November', 'Dezember'  
    ] %}

    {% set months_calcolors = [
       '#ffe1e3, #a51610, #ffe1e3', '#fffed8, #f2652d, #fffed8', '#ffffa2, #fa9f1d, #ffffa2',
       '#ffff9e, #add133, #ffff9e', '#efffcb, #7f9e40, #efffcb', '#d6fced, #479386, #d6fced',
       '#d6f7fe, #1fa4b5, #d6f7fe', '#b0edff, #1849a5, #b0edff', '#9ddbff, #393663, #9ddbff',
       '#deedff, #6675ae, #deedff', '#ead7ff, #71357b, #ead7ff', '#ffc2ff, #9c2e87, #ffc2ff'
    ] %}
    
    {% import "calendar.html" as calendar %}

    {% for month in 1..12 %}
        {% set month_id = 'monat'~month %}
        <div id={{month_id}} class='calblock' style='border: 1px {{ months_calcolors[month-1]|slice(0,7) }} solid;'>
            <div class='calueberschrift' style='background-image: linear-gradient(0.33turn, {{ months_calcolors[month-1]}} )'>{{months_locale[month-1]}}</div>
            {{ calendar.list('clist', '', '6', 'yellow', '', 'K1') }}
        </div>
    {% endfor %}

{% endblock %}

Trotz allem wäre das Filtern nach Tags in Kalendern wohl trotzdem sinnvoll - um z.B. verschiedene Familienmitglieder in unterschiedlichen Blöcken darstellen zu können.

/tom

[Cannon]

Ich finde das mit dem Lyout des Kalenders überhaupt gut. So könnte man den als Fullscreen einbinden, evl. auch als Monatsansicht ... oder Wochenansicht.

[Tom Bombadil]

Danke - ich befülle gerade die ersten Items, stehe aber erst am Anfang, da fehlt noch jede Menge. Habe mich dann doch gegen den Kalender und für normale String-Items entschieden, weil mir die Ladezeiten zu lang waren. Kann man zwar zur Zeit nur über das Admin-Interface von shNG befüllen, aber ist ja eh statischer Content, also nur 1x notwendig - damit kann ich leben.

jahreskalender2.png

/tom