Screenlets entwickeln

[Barabbas]

Hallo zusammen,

kennt einer von euch die Screenletsfür Gnome? Ich habe mir mal ein paar Plugins / Screenlets dafür angesehen - und muss sagen, dass ich etwas entsetzt bin. Kann es sein, dass die Schnittstelle völlig verhunzt ist?

Allein die Coding-Rules:

*A Screenlet's classname must end on "Screenlet" (e.g. ClockScreenlet)
*Not more than 80 chars per line (where possible).
*Tabs are 4 char-wide "\t"-characters.
*Classes MUST have a documentation-string.
*After class-headers's documentation, one separating line.
*Internal attributes MUST start with TWO leading underscores.
*Editable options NEVER have leading underscores.
*All functions that are no inherited event-handlers MUST have a documentation-string.
*Constructors of Screenlet-subclasses must implement the **keyword_args parameter as last argument to their __init__-function.
*All screenlet-files MUST have the name of the Screenlet-classes they contain (with a .py-extension).
*All Screenlets MUST have a head-comment containing license/author note,
*Screenlets need to be placed into a directory named like the Screenlet's class (without trailing "Screenlet"). This directory may contain a "themes"-directory where the Screenlet's themes are stored. It may also contain other files (of course).
*Screenlets should supply an icon named "icon.svg" or "icon.png" within their directory.
*When possible set the width and height of the screenlet matching the background theme image , to avoid confusion
*Always call super before anything else ... of course
*Never call exit() or sys.exit().But if you need to check the utils.is_manager_running_me() and only call the exit() if that returns false

Ok, ein paar davon ähneln PEP 8 - aber andere?!

Ich will ja wirklich niemanden zu nahe treten - da ich ja auch wirklich kein Profi bin. Aber das hat mich wirklich ein wenig abgeschreckt. Hat jemand von euch sich schonmal an den Screenlets versucht? Vielleicht fandet ihr die Schnittstelle ja auch super? Würde mich einfach mal interessieren....

Schöne Grüße,

Daniel

[Defnull]

Mir kommt jeder einzelne Punkt durchaus Sinnvoll vor. Die meisten behandeln sowieso übliche Konventionen. Und wenn man eine Sammlung von kleinen Programmen mit wiederverwertbarem Code zusammen stellen möchte, kann man das durchaus von den Entwicklern verlangen. Wenn ein Developer nicht einmal das anständig hin bekommt, wird sein Code auch nicht besonders toll/stabil/sicher sein.

Hauptargument für die Formatierungsregeln ist wohl die Tatsache, das nicht nur du an deinem Code arbeiten wirst, sondern auch andere den Code bearbeiten oder wieder verwerten wollen. Wenn jeder seine eigenen Formatierungsregeln umsetzt, dann macht Versionskontrolle kaum mehr Sinn, da die Patches hauptsächlich aus geänderten Whitespaces bestehen.

Und die Docstrings sind sowieso immer sinnvoll.

[Barabbas]

Naja, geschenkt... habe ich ja selbst gesagt (PEP . Einige Regeln sind aber tatsächlich eine unnötige Fesselung - wie die Benennung der Klasse, die eigentlich frei benannt werden darf, aber auf "Screenlet" enden muss.

Außerdem habe ich mich ja über die Schnittstelle geärgert - da wäre mir an einer Einschätzung sehr viel mehr gelegen

Grußn

dsn

[gerold]

Kann es sein, dass die Schnittstelle völlig verhunzt ist?

Hallo Daniel!

Nein, im Gegenteil! Ich empfinde fast alle Punkte als gute Konvention. Jeder Punkt (bis auf kleine Ausnahmen) hat seine Berechtigung.

Der Code muss ja in eine gemeinsame Codebasis eingefügt werden können. Eine saubere Ordnerstruktur und Benennung der Dateien ist dafür zwingend erforderlich.

Die Dokumentation der Klassen, Methoden,... muss eventuell auch automatisch generiert werden können. Da braucht es einheitliche Docstrings.

Dass man sich an PEP8 hält ist selbstverständlich. Dass in diesem Projekt sehr viel Wert auf gut lesbaren Code gelegt wird (80 Zeichen, 4 Zeichen zum Einrücken,...) ist nichts Verwerfliches.

Dass interne Attribute mit zwei Unterstrichen beginnen müssen, hat bei einem Projekt wie diesem sicher Sinn. So wird evt. vermieden, dass es zu Namenskonflikten mit anderen Screenlets kommt, falls Vererbung im Spiel ist.

Dass man nicht "exit()" verwenden soll, ist auch klar. Man darf nicht das komplette Screenletprogramm abbrechen -- man ist ja nur ein Teil davon.

Nur damit -- *Always call super before anything else ... of course -- kann ich nicht viel anfangen. "super" ist vielleicht nicht unbedingt die beste Idee der Python-Entwickler gewesen.

Wer ein Screenlet schreiben will, welches auch offiziell in das Projekt aufgenommen werden soll, muss sich an diese Konventionen halten.

mfg
Gerold

[lunar]

Laut dem Artikel Python's Super Considered Harmful hat "super()" in einer Basisklasse auch Auswirkungen auf die abgeleiteten Klassen. Dementsprechenden lautet eine der Schlussfolgerungen:

Use it consistently, and document that you use it, as it is part of the external interface for your class, like it or not.

Wenn also die Basisklasse für Screenlets bereits "super()" nutzt, ist die Benutzung dieser Funktion für abgeleitete Klassen verpflichtend, so dass diese Regel durchaus sinnvoll ist.

Über den Sinn der doppelten Unterstriche lässt sich streiten. In einer Basisklasse sind sie sicherlich sinnvoll, die Screenlet-Klasse selbst aber sind doch nicht als Basisklassen für Vererbung gedacht.

[Barabbas]

Ich habe doch schon lange zugestanden, dass manche Regeln durchaus ihre Berechtigung haben. Weiß gar nicht, warum ich hier als "Konventionen-Bösewicht" hingestellt werde.
Ich habe doch nicht gesagt: "Schaut euch die Regeln an, sind die doof" sondern: "Ich glaube, die Schnittstelle ist nichts, allein diese Regeln *tsts*".
Wenn ihr die Regeln nun alle supertoll findet, habe ich mich vll. etwas in die Nesseln gesetzt, aber darum geht es doch überhaupt nicht:

Meine Frage war, wie ihr die Schnittstelle findet?

So schlimm ist das ganze Programm natürlich auch nicht - aber da ihr euch hier so an meine Abneigung gegen die Regeln festklammert, muss ich ja meine Position etwas verdeutlichen: Wenn ich schlechten Code habe, der unübersichtlich bis schlecht dokumentiert ist, dann finde ich so einen Batzen Regeln mit lauter MUSTs und NEEDS und MUSTN'Ts ziemlich albern. Aber wie gesagt: So schlimm ist das alles natürlich nicht (gibt deutlich schlechtete) - Ich wollte mich doch nur über die Screenlets austauschen. . Eine meiner Vorstellung gemäße Antwort hätte etwa lauten können: "Ne, habe XY dafür geschrieben und fand das sehr übersichtlich - besonders weil...." oder "Jo, hast du dir schonmal angesehen, wie man auf die Datenbank zugreift? Da wird für jeden bla extra ein neuer blu angelegt".

Aber nichts für Ungut...

schönen Gruß,

Daniel

[lunar]

Niemand hat dich als "Bösewicht" hingestellt, und niemand hat sich an irgendetwas "festgeklammert".

Die Antworten sind die logische Konsequenz deines ersten Beitrags, der zwar die Schnittstelle erwähnt, diese Erwähnung dann aber in dem langen Zitat der Regeln untergehen lässt. Da den Regeln so großer Raum im ursprünglichen Beitrag eingeräumt wurde, ist es nicht weiter verwunderlich, wenn dieses Regeln auch in den Antworten entsprechenden Raum einnehmen Die Wahrscheinlichkeit, hier jemanden zu treffen, der sich tatsächlich damit auseinander gesetzt hat, ist angesichts der Spezialität des Themas doch recht gering, daher musst du hier auch mit Lesern rechnen, die die Schnittstelle an sich nicht kennen, und daher einzig auf den Inhalt deines Beitrags antworten.

Zeig doch mal ein Quelltext-Beispiel, und erläutere daran Details, die dich direkt stören. Dann kann man die Schnittstelle auch als Außenstehender beurteilen, ohne sich gleich tiefgehend mit der Programmierung von Screenlets auseinander zu setzen.

[Defnull]

Meine Frage war, wie ihr die Schnittstelle findet?

Wenn ich mir http://screenlets.org/index.php/Documen ... Developers so ansehe, fallen mir drei Sachen auf:

Die self.add_option(BoolOption(...)) Schnittstelle: Umständlich, aber schön Objektorientiert und erinnert mich stark an SQLAlchemy. Man könnte das vielleicht einfacher machen, aber dann würde die Schnittstelle einiges an Flexibilität verlieren. Also insgesamt OK.

Die vielen on_*() Handler: Handler dieses Typs sind sehr übersichtlich und eigentlich auch sehr angenehm für den Entwickler.

Cairo. Gewöhnungsbedürftig, aber wenn man länger mit arbeitet (was ich getan habe) eine der besten 2d Werkzeuge, die es so gibt.

Sonst ist da nicht viel. Wies jetzt nicht, was daran so vermurkst sein soll. Vielleicht gibst du ja mal ein Beispiel mit deinem Verbesserungsvorschlag?

[Barabbas]

Ich habe leider weder eine ausgiebige Quelltextanalyse vorgenommen noch habe ich ein Konzept zur Überarbeitung des Programmes entwickelt, das ich hier vorstellen kann.

Ich habe die Tage einfach mal versucht, ein paar kleine Screenlets zu schreiben und hatte an manchen Stellen den Eindruck, dass einem gewisse Sachen unnötig schwer gemacht werden.

Schöne Grüße,

dsn

[Defnull]

Du machst extra einen Thread auf, um uns zu sagen, das Schnittstelle X völlig verhunzt ist und kannst dann auf Nachfrage nicht mal ein einziges negatives Beispiel nennen? Was genau stört dich denn nun an der API? Wo waren denn diese "Stellen" an denen "gewisse Sachen unnötig schwer gemacht werden"?

Wir alle versuchen grade verzweifelt, die Diskussionsgrundlage dieses Threads zu erraten Der erste Versuch (Diskussion über die Coding-Rules) ging ja anscheinend daneben. Nun verrate uns doch endlich, worüber du diskutieren willst. Poste dein Versuchs-Screenlet und sag uns, welche Stellen dir zu Umständlich waren. Dann können wir gern darüber diskutieren, ob es sinnvollere Lösungen gibt oder eben nicht.

[Barabbas]

Naja, natürlich kann ich Beispiele dafür nennen, was ich meine, wenn ich sage, die Schnittstelle sei verhunzt. Aber um ehrlich zu sein habe ich nicht den geringsten Bock dazu, weil ich irgendwie den Eindruck habe, ihr wollt mich hier auflaufen lassen.
Wenn ich nebenbei erwähne, dass mir die Coding-Regeln etwas suspekt sind, dann wird hier gleich ellenlang darüber diskutiert, warum man sich doch bitteschön an PEP 8 zu halten habe und das es sinnvoll sei, sich auf bestimmte Richtlinien zu einigen. Als ob ich das jemals in Frage gestellt hätte.

Und begründet wird das dann damit, dass die Regeln durch das Zitat einen Zeilenumfang erreicht hätten, der den Eindruck erweckt, es ginge hauptsächlich um diese ?!?!

Ich wollte mit meinem vorherigen Beitrag diesen Strang gemütlich zu Ende bringen, weil es wenig Spaß macht, sich über so ein Thema auszutauschen, wenn die/der Gegenüber die Position des Verhörenden einnimmt.

Nichts für Ungut, ich möchte ja niemanden was Böses!

brb

P.S. Ich muss auch gestehen, dass mein anfängliches "Entsetzen" einer leichten Skepsis gewichen ist. "Völlig verhunzt" ist in diesem Sinne also sicher nichts, was ich aufrecht erhalten würde.

[lunar]

Zum zweiten Mal: Niemand will dir "Böses" und niemand will dich auflaufen lassen. Wir wissen eben nur nicht so recht, worüber du diskutieren willst

Am Anfang hast du die Regeln gepostet, über die du dann aber nicht diskutieren wolltest. Konkrete Kritikpunkte an der Schnittstelle hast du aber auch nicht genannt, sondern nur ein allgemeines "völlig verhunzt" in den Raum geworfen Für eine vernünftige Diskussion über Schwachpunkte an einer Schnittstelle ist das irgendwie ein bisschen wenig

Nimm es bitte nicht persönlich, wenn wir nicht über das diskutiert haben, was du eigentlich wolltest