whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
Benno-007 schrieb: Also dann mach ich hier erst mal weiter und wenn whazzup dann auch nochmal explizit hier, jetzt und dazu sein OK gibt, würde ich wieder die vorher bestehenden Überschriften einfügen und ein paar vorhandene darin einordnen, um die Liste zu kürzen.
Hau rein! Hab grad nicht so viel Zeit wie ich gern haette. Grundsaetzlich schlaegt mein Herz eher bei den Xmir Befehlen udgl hoeher und nicht so sehr bei der Struktur. Die Ueberlegung die mich zu langer flacher Liste gefuehrt hat, war eher : Schwerpunkt erst mal auf Sammeln der Inhalte und noch nicht auf strukturieren, aber wenn Du (ihr) da einen Plan habt, dann nur los. Wichtig waer mir nur auch irgendwo eine Region fuer neue Informationen zu haben, die evt noch nicht wirklich in die Struktur passen.
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Zu deiner Anmerkung im Quelltext: reset setzt sicherlich auf die Standard-App-Liste zurück, nicht auf eine leere. Oder klappt genau das auch nicht (Bug)? Ist aber nur am Rande interessant. Danke für deine Tests! Wenn wir so weitermachen, sind wir mit einer ersten veröffentlichbaren Version bald fertig! Aber da steckt noch eine ganze Menge Kleinarbeit und sowas wie deine Umsetzung von Links heute drin, was sich zeitlich dann doch aufsummiert. 😉
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
Benno-007 schrieb: Zu deiner Anmerkung im Quelltext: reset setzt sicherlich auf die Standard-App-Liste zurück, nicht auf eine leere.
klar.
Oder klappt genau das auch nicht (Bug)?
Ne, zuruecksetzen klappt (fuer mich) so nicht.
Ist aber nur am Rande interessant.
Seh ich auch so
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich hab deine Kürzungen in der desktop-Datei mal wieder eingefügt bzw. erläutert: Sprachen dringelassen, da die Dateien ja nicht kastriert werden sollen und das zusätzlicher Aufwand ist und Verwirrung stiftet, welche die Einstiegshürde unnötig erhöht. Des Weiteren passten so dann auch die Zeilennummern in der Beschreibung darunter nicht mehr. Deinen Icon-Eintrag musste ich erläutern - es nützt nix, wenn wir ein fertiges Dillo-Beispiel haben bzw. herbeimanipulieren. Wichtig ist, dass die Herangehensweise lückenlos erklärt wird. Das hab ich nun mal ergänzend versucht. Dazu musste auch meine Icon-Erklärung zu Teilen wieder rein und einigermaßen präzisiert werden. Tipp: Wenn man sowas einfügt, sollte man auch gleich den Erklärungstext dazu liefern, also in welchen Ordnern man wie die Icons findet. Ansonsten werden damit jede Menge neuer Baustellen aufgerissen und das Ding wird nie fertig. 😉 Fazit: Im Zweifel ist weniger mehr - sowohl weniger Änderungen als auch weniger Details. Die simpelste Variante muss erst mal funktionieren. Wenn es eine ohne Icon ist, dann auch die, denn es ist ja kein Artikel zu Dillo, sondern ein generischer Artikel, um sich zu allen möglichen Programmen selbst Starter anlegen zu können. Das bei manchen dann das Icon durchsichtig ist, ist ein eigenständiges Problem, welches nicht dazu führen darf, dass intransparent Texte aus der desktop-Datei und den Erklärungen dazu rausfliegen. Lass dich aber nicht entmutigen: Es liegen übrigens für Interessierte noch jede Menge Links dort rum, die eingepflegt werden müssten. Vielleicht sollten wir als Quelle auch von jemandem von der Mailingliste eine Wissenssammlung der Liste bei Links verlinken: http://www.unixarea.de/bq.txt Ich füge es eben noch hinzu. Grüße, Benno
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
Benno-007 schrieb: zusätzlicher Aufwand ist und Verwirrung stiftet, welche die Einstiegshürde unnötig erhöht.
Ich finde auch dass zusaetzlicher Aufwand verhindert werden soll und die Einstiegshuerde niedrig sein soll. Nachdem Du die .desktop Datei manipulierst, faende ich es am Besten gleiche eine (vernuenftig) minimale und einigermassen lesbare .desktop Datei anzugeben. Es macht meines Erachtens auch keinen Sinn anzugeben dass eine bestimmte Zeilennummer angepasst werden soll ... wer wird diese Nummer im Wiki maintainen wenn in der naechsten Dillo Version die .desktop Datei ein bisschen anders ausssieht.
Des Weiteren passten so dann auch die Zeilennummern in der Beschreibung darunter nicht mehr.
Stimmt. Die Beschreibung haette angepasst werden muessen. Die Zeilennummer hat in der Beschreibung sowieso nix verloren. Das was Du machst, ist die Exec Zeile anzupassen. Das ist der springend Punkt. Der verdient erklaert zu werden. Noch besser faende ich es generischer zu schreiben: "Hier Im Wiki sieht man ein Beispiel fuer ein passendes .desktop file. Unter diesem Pfad findet man die installierten .desktop files die man kopieren/bzw als Vorlage nehmen kann. Entscheidend ist hier die Exec Zeile anzupassen". Maximal so ausfuehrlich, denn in der Tat, wie Du sagst wollen wir hier ja nicht ueber .desktop Files reden sondern ueber Xmir.
Deinen Icon-Eintrag musste ich erläutern
Finde ich im Xmir Abschnitt irrelevant und unnoetig kompliziert.
- es nützt nix, wenn wir ein fertiges Dillo-Beispiel haben bzw. herbeimanipulieren.
Im Gegenteil, es ein .desktop file mit nem Bug (falscher Icon Pfad) als Vorlage zu nehmen und dann zu erklaeren wie man diesen Bug in diesem speziellen .desktop file in dieser speziellen Version dieses speziellen Programmes behebt. Maximal die typischen Pfade zu Icons angeben. Es gibt ja auch einen eigenen Artikel zu .desktop files.
Wenn man sowas einfügt, sollte man auch gleich den Erklärungstext dazu liefern,
Das fixen des Bugs WOLLTE ich ja explizit nicht erklaeren. Hat ja nicht viel mit Xmir zu tun.
also in welchen Ordnern man wie die Icons findet.
Stimmt der Pfad ist noteworthy .... "gehoert" aber vielleicht eher in den .desktop Artikel.
Fazit: Im Zweifel ist weniger mehr - sowohl weniger Änderungen als auch weniger Details. Die simpelste Variante muss erst mal funktionieren.
Stimm ich Dir zu. Nur ist das fuer mich ein (sinnvoll) minimales .desktop file. Und keine Ausfuehrlichen Anleitungen warum in welchem von Dir genutzten Template welcher Bug drin ist, der wie gefixt werden muss ....
Das bei manchen dann das Icon durchsichtig ist, ist ein eigenständiges Problem, welches nicht dazu führen darf, dass intransparent Texte aus der desktop-Datei und den Erklärungen dazu rausfliegen.
Fliegen natuerlich nicht raus, aber wenn wir sowieso das .desktop file im Wiki angeben. Und das sollten wir auch so tun! Dann einfach den minor Bug aus dem Template direkt fixen ohne die Erklaerungen die auf Xmir abziehlen sollten unnoetig zu verlaengern.
Lass dich aber nicht entmutigen:
Ach keine Angst, so empfindlich bin ich nicht. Vielleicht sollten wir als Quelle auch von jemandem von der Mailingliste eine Wissenssammlung der Liste bei Links verlinken: http://www.unixarea.de/bq.txt Ich füge es eben noch hinzu.
Quellen im Sinne einer generellen Wissenssammlung find ich gut. Interessanter unixarea Fund! Ich mach mir da mal ne Kopie am Computer - so wie ich das sehe hat der Author dieses .txt file gar nicht von seiner Seite verlinkt ... wer weiss wie lange das Ding online ist. Was meines Erachtens nicht in die Linkliste passt ist das Xmir/VNC Video. Das sollte in den entsprechenden Abschnitt. Wenn wir anfangen Hintergrundlinks aus allen Abschnitten in die Linksection zu ueberlegen wird das ein Chaos. Und wo wir gerade beim Xmir reviewen sind, nochmal hier:
whazzup schrieb: Ich denke im Wiki sollten wir auf Einfachheit des Skriptes abziehlen. Reuse ist dem oft zuwiderlaufend. Dementsprechend wuerde ich auch die Display Nummer im Skript hart codieren, so wie ja auch schon der Programmname dillo hart codiert ist. Aus der Einfachheitsperspektive bin ich mir auch nicht sicher, ob vnc da erwaehnenswert ist. Das ist schon ein relativ verspieltes Debugfeature.
Also konkret so:
#!/bin/bash
export DISPLAY=:1
Xmir $DISPLAY &
sleep 0.5
dillo &
Ein Feature, das, finde ich verdienen wuerde eingetragen zu werden ist ein Logfile. Ich hab das fuer mich mit den zwei verschachtelten .sh files erledigt - nicht sehr elegant. Im Wiki wuerde ich Leuten eventuell so was vorschlagen:
Xmir :0 > /home/phablet/.dillo.log 2>&1 & DISPLAY=$DISP dillo >> /home/phablet/.dillo.log 2>&1 & Also jeweils stderr nach stdout 2>&1 und dann stdout in ein logfile. Beim Xmir wird das logfile neugeschrieben > , bei dillo dann noch angefuegt >> Interessierte Nutzer koennen dann hier
tail -f /home/phablet/.dillo.log
dem Debug output zusehen. Bin gespannt, ob wir "Kunden" bekommen fuer Xmir ☺ PS: Weisst Du was --desktop_file_hint macht? Brauchen wir das?
Benno-007 schrieb: Na dann raus damit. Edit: dillo muss auch erst installiert werden Edit2: Multitasking Abschnitt find ich gut! Den getestete Programme Abschnitt find ich nicht gut:
Wo ist hier die Notability wenn wir Zug um Zug all X Programme fuer die es ein .deb Package gibt hier eintragen Es wird ein Wiki-maintenance nightmare. Wer wartet diese Infos? Das Wiki ist kein Bugtracker
Was meiner Ansicht nach Sinn macht: Ein paar Beispiele von getesteten Programmen. Also wenn das heute dillo ist, weil Du darauf konzentriert bist - fein. Sicher auch ein paar ausgewaehlte notable Bugs/Fixes/Workarounds. Aber keine Liste.
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich sehe schon, dass du dir Gedanken gemacht hattest und machst. Wir haben halt nur unterschiedliche. 😉 Zeilennummer bezieht sich auf's Beispiel im Wiki. "In Zeile 8" klingt einfach besser als "Da, wo Exec=... steht" und ist schneller und konkreter. Aber das kann march entscheiden, bin ja nicht im Wikiteam, um da erfahren genug zu sein. Richtig ist, dass wir desktop-Dateien nicht erklären, nur verlinken. Das Icon hätte ich gar nicht gesetzt, ich hab und brauch es nicht. Es ist auch kein Bug - auf dem PC ist es nämlich da. Das hat vielleicht irgendwas mit den Suchpfaden zu tun (PATH-Variable). Auf KEINEN Fall dürfen wir im Wiki was OHNE Hinweis manipulieren, da das dem Ziel des Erklärens und Verstehens zuwider laufen würde. Möglichst nah am Original bleiben. Beim Firefox käme man mit dem Kürzen der desktop-Datei gar nicht hinterher, schau dir die vielen Sprachen und rechte-Maus-Scripte für Unity darin an... Da ist Dillo anschaulich UND original, perfekt (trotz Zufallsauswahl). ☺
Links: Wikistandard hier, dass die alle ans Ende kommen. Es ist dafür nur einer. Sonst soll march entscheiden. Evtl. wird ja der Part Tipps & Tricks zur Verschlankung noch ausgelagert, aber das sind momentan nur 3 Seiten, am Ende vielleicht 6 oder 9? DISPLAY-Nummer im Script: Welchen Vorteil genau hat es? Was macht es einfacher? Kann man so sehen, aber ist es nicht letztlich egal und wir momentan näher an den Upstream-Erklärungen? Genau deswegen möchte ich auch den desktop-hint nicht streichen, da er evtl. was mit Berechtigungen etc. zu tun hat. Ich schlage vor, wir lassen das erst mal so, bis wir den Artikel fertig und mehr Tester haben. Jede Abweichung muss auch wieder von mehreren Testern bestätigt werden und beim nächsten Problem geht man sowieso wieder auf die Ausgangsvariante zurück. Oder es sucht jemand im Netz und findet die andere offizielle Variante, die ja auch unsere Videoreferenz in den Links ist... Letzten Endes ist es gerade völlig egal, oder? Wichtig ist: Testen und das direkt dokumentieren - und verfeinern. Mit Verfeinern meine ich, Tastaturnutzung für Pidgin optimieren, nicht ob das Display hier oder da erwähnt wird - das bringt ja keinerlei Nutzwert. 😉
Ja, es fehlen aus Zeitgründen noch einige Details wie Dillo-Installation - auf der andren Seite ist es logisch, dass man ein Programm, welches man nutzen will, erst installieren muss. Programmliste: Sehe ich wie du, nur eine kleine Auswahl, speziell auch der interessantesten Programme, wegen der Features (Firefox), Geschwindigkeit (Dillo) oder App-Lücken (Messenger, verschlüsselte Emails, Mumble...). Das lockt dann erst mal Leute an. Es wird auch sicherlich nicht so viele Tester und dazu noch Wikischreiber geben, dass die Liste 1000 Einträge lang würde. Gimp wird wohl auch kaum jemand auf dem Phone nutzen wollen - auf dem Tablet schon eher. Das Wiki ging schon immer auf Probleme und Bugs eines Programmes auf dessen Seite ein, wenn sie zur Lösung beitragen - etwa Fremdpakete. Aber march kann sich ja auch hierzu kurz äußern. Ich finde die Tabelle momentan unentbehrlich, um die ersten Erfahrungen zu dokumentieren und würde sie bis auf weiteres auch weiter pflegen. Irgendwann wird sie vielleicht in 1 Jahr gar nicht mehr nötig sein, da es Apps und Convergence gibt, dann muss alles laufen. Da schreiben wir noch dazu, dass es nur paar Beispiele sind. Sonst müsste man es in die etwa den Artikel Firefox in die Getestet-Box schreiben - das wäre dann später von der Tabelle übertragbar bzw. neu testbar, momentan finde ich diese Idee aber abstrus, für die paar Programme. Das Wiki ist halt im Fluss - momentan brauchen wir mehr Infos, wo die Möglichkeiten und Grenzen liegen. Die Tabelle ist ein Teil davon.
march Achja, dann bitte auch noch den Befehl testen, den ich dir letztens hier in der Wüste mit aufgetischt hab, wenn du schon mal hier sein solltest. 😉 Grüße, Benno
|
march
Anmeldungsdatum: 12. Juni 2005
Beiträge: 17331
Wohnort: /home/noise
|
wenn du schon mal hier sein solltest. 😉
Ja - bin ich ab und an. Jedoch sollte man den Kopf dafür frei haben und sich Zeit für den Artikel und den Thread nehmen. Ansonsten bringt das nicht viel... 😉
Am besten march, da du ein BQ und vermutlich noch nicht so viel dran rumgebastelt wie whazzup hast. 😉
Es ist fast jungfräulich. Lediglich Klingeltöne aufgespielt - ich weiß sehr radikal von mir. 😀 Ansonsten mit den apps/scopes gespielt und ein wenig davon ins Wiki/auf launchpad gebracht... Also nicht viel gemacht außer lesen, lesen, lesen... Heute - im Laufe des Abends - werde ich mich in Ruhe einlesen. ☺ Edit:
sudo tune2fs -l /dev/mmcblk0p6 | grep block
Reserved block count: 26368
Free blocks: 117563
First block: 0
Reserved GDT blocks: 128
Inode blocks per group: 485
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
Journal backup: inode blocks
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Hab deinen Edit in letzter Zeit öfters wo übersehen, da keine Meldung kommt. Ok, dann lassen sich nochmal 103 MB rausholen. ☺ whazzup: Howtos dürfen wir leider nicht verlinken. Aber ich denke, der erste Link reicht auch. Allerdings soll das da auch ausformuliert - und getestet - werden. Darum hatte ich auch keinen Stichpunkt draus gemacht, sondern es bewusst gleich roh gelassen, damit man das sieht. Aber ansonsten ging es ja wieder ein gutes Stück voran. Vielen Dank! Grüße, Benno
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
Benno-007 schrieb: whazzup: Howtos dürfen wir leider nicht verlinken.
Warum denn das? Wegen neunmonatigen Testphase für Howtos? Ist ja beinahe um.... Edit: Korrektur 9 nicht 6, link Edit: Hab den Howto Link im Artikel auskommentiert. Ich denke die Info im Howto ist schon hilfreich zum Ausformulieren des Abschnitts, denn dort beschreibt gerade jemand wie man mit nmcli einen Hotspot einrichtet. Ich koennte mir vorstellen, dass das eins zu eins auch fuer UTouch klappen wird.
|
toddy
Ikhayateam
Anmeldungsdatum: 31. Juli 2007
Beiträge: 9517
Wohnort: Lüneburg
|
In dem Update zum Ikhaya Artikel von gestern wurde das Experiment erweitert und nun dürfen Links aus dem Wiki auf Howtos verweisen. Spricht also nichts mehr gegen eine Verlinkung. ☺ Liebe Grüße, Torsten
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
toddy schrieb: In dem Update zum Ikhaya Artikel von gestern wurde das Experiment erweitert und nun dürfen Links aus dem Wiki auf Howtos verweisen.
Dann wieder rein mit dem Link 😉 @Benno: der Link ist natuerlich nicht als Ersatz fuer eine entsprechende Erklaerung gedacht!
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
Benno-007 schrieb: Beim Firefox käme man mit dem Kürzen der desktop-Datei
Find ich ein gutes Beispiel. Du wuerdest beim Firefox ja auch nicht die ganze 'original' Datei ins Wiki kopieren. Sondern entweder erklaeren welche Zeilen Du wie angepasst hast, oder ein minimales Beispiel reinstellen. Am besten beides. Naja, vielleicht kriegen wir ja eine dritte Meinung. Links: Wikistandard hier, dass die alle ans Ende kommen. Es ist dafür nur einer.
Wenn ich den Artikel so ueberfliege und vorlaeufige "Todolinks" auslasse, dann zaehle ich noch zwei in User Interface Rotation, je nachdem wie mans zaehlen will ein bis vier weitere in Browsereinstellungen und noch ein weiterer in Grafische Programme vom Ubuntu PC. Die muessten nach dem gleichen Massstabe dann ja auch ans Ende. Was wuerdest Du mit diesen Links machen?
Aeh, naja, es sind weniger Zeilen Code und weniger Shell Variablen.
Kann man so sehen, aber ist es nicht letztlich egal
Also, wie antworte ich darauf jetzt diplomatisch. Deiner Ansicht nach ist es egal, Du lehnst aber trotzdem die Anderung ab ....
und wir momentan näher an den Upstream-Erklärungen? Genau deswegen möchte ich auch den desktop-hint nicht streichen, da er evtl. was mit Berechtigungen etc. zu tun hat.
Was meinst Du mit Upstream-Erklaerung? Das Video von Cooke? Er sagt da literally "I just copied this from another dot desktop file, so there is probably some legacy stuff in there" Ich schlage vor, wir lassen das erst mal so, bis wir den Artikel fertig und mehr Tester haben. Jede Abweichung muss auch wieder von mehreren Testern bestätigt werden und beim nächsten Problem geht man sowieso wieder auf die Ausgangsvariante zurück. Oder es sucht jemand im Netz und findet die andere offizielle Variante, die ja auch unsere Videoreferenz in den Links ist... Letzten Endes ist es gerade völlig egal, oder?
Noch ein Punkt der Dir egal ist, aber trotzdem ein Veto? Weisst Du, gegebenenfalls hab ich auch noch substanziellere Anmerkungen um den Artikel voranzubringen, aber da muss ich auch erst durch meinen mentalen Stack durch. Oben auf dem Stack liegen die letzten Reviewkommentare die ich gegeben hab. So wie ich das sehe gibt es eine Stimme (meine) dafuer es zu aendern und eine Enthaltung (Deine, "gerade voellig egal"), aber trotzdem meinst Du dass es produktiver ist wenn ich mir mein Feedback erst einmal auf unbestimmte Zeit merke und dann irgendwann spaeter nochmal davon anfange? Warum machen wir die kleinen Schritte, die ja offenbar nicht mal ein Konflikt sind, nicht gleich. Das spart uns beiden Zeit und Energie und wir haben den Kopf frei fuer interessantere Dinge.
Wichtig ist: Testen und das direkt dokumentieren - und verfeinern. Mit Verfeinern meine ich, Tastaturnutzung für Pidgin optimieren, nicht ob das Display hier oder da erwähnt wird - das bringt ja keinerlei Nutzwert. 😉
Um Tester anzulocken, helfen aber denke ich die gleichen Standards wie bei fertigen Artikeln. Also wenn ich (ohne Verrenkungen) das gleich Skript auch einfacher schreiben kann UND diese Aenderung auch jetzt schon von einem Reviewer vorgeschlagen wird, warum soll sie dann nicht in den Artikel? Ich versteh Dein Beharren hier nicht. Es ist ja nicht so, dass ich sage : "Benno, das ist zu kompliziert, das musst Du noch ueberarbeiten!" Ich mache ganz konkrete Editvorschlaege und warte nur auf ein "ja", oder ein "mir wurscht".
Ja, es fehlen aus Zeitgründen noch einige Details wie Dillo-Installation - auf der andren Seite ist es logisch, dass man ein Programm, welches man nutzen will, erst installieren muss.
Noch so ein mini Editvorschlag von mir. Ich meine es wuerde Testern helfen wenn sie es einfach copy pasten koennten. No biggie. Ist der Artikel fertig nachdem ich den dillo Paketnamen hinzugefuegt hab? Natuerlich nicht. Ist der Artikel besser wenn der Paketname drin ist? Ich finde schon. Ist der Artikel schlechter wenn ich den Paketnamen einfuege? Wohl kaum. Ich wuerde den Edit normalerweise auch einfach machen, aber ich will hier nicht in nen Edit-War kommen, darum bin ich dazu uebergegangen auch solch kleine Edits erst vorzuschlagen anstatt sie direkt zu machen wenn es Abschnitte betrifft in denen Du gerade aktiv bist. Ich erwarte ja nicht, dass Du die Aenderungen machst. Aber wenn Du es hilfreich findest .... nein Korrektur ... (ich schlage es ja nur vor wenn ICH es hilfreich finde, also) wenn Du es nicht als dem Abschnitt abtraeglich findest, dann sag doch einfach "ok". Das ist alles. Aber stattdessen nimmst Du Dir die Zeit es zu lesen, darueber nachzudenken, darauf zu antworten und dann dagegen zu stimmen das es gemacht wird?!
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich meine eben, dass manche Änderungen keine Verbesserung bringen, die Änderung bei .desktop also schlicht überflüssig ist = egal sind. Sondern es sogar verschlechtern. Ich hab hier auch schon viel mit dem Wikiteam diskutiert, nach und nach schleift sich aber der Stil des Wikis und Teams ein, um nicht reverted zu werden und weil man den Sinn dahinter sucht und findet. Ich hab es oben eigentlich recht gut begründet, was mich daran stört. Du musst dich aber mit den einzelnen Punkten oben gar nicht weiter ein zweites Mal befassen: Ich fragte ja bereits march nach "der Wikimeinung" als auch dritter Meinung als Artikelautor und dann sehen wir weiter. Er kümmert sich vor allem darum, dass die Strukturen Wiki-konform sind. Uns braucht es da nicht, wir sollten uns mal um den inhalt kümmern, wo er uns braucht und ich dich auch ❗ Ich dachte nur, ein paar Tipps kann ich geben und intransparente Kürzungen ohne "[...]" und Anpassung der Zeilennummern ausmerzen. Ich finde schlicht, da gehörte im Falle von Firefox auch das ganze .desktop-File vom Firefox rein, einfach um im Wiki ein Gesamtbild zu dokumentieren und keine Fragen zum Kontext offenzulassen. Ein Script würde auch nicht gekürzt, ich würde es hier aus dem Bauch heraus auch lieber ganz sehen. Auf KEINEN Fall aber kaputtgehackt. Wenn was weggelassen wird, muss das kenntlich gemacht werden: Sowohl in der Box mit z.B.
ABC
[...]
XYZ
als auch ggf. im Text berücksichtigend. Das war übrigens ein Notfall-Kompromissvorschlag, den ich für Dillo trotzdem für eine Verschlimmbesserung halte, die ich da für völlig fehl am Platze halt. Bei Firefox könnte man eher darüber nachdenken und das so ausmachen. Bis sich also march gemeldet hat, können wir noch einen Haufen andrer Links einbauen. Ich schreib derweil meinen Bericht zum Phone weiter. Lass dich nicht aufhalten. Da ich auch nicht weiterweiß, hab ich ja die Sache an march weitergeleitet - vorher ergibt sich hier kein neuer Sachverhalt. So lang müssen wir uns dazu noch gedulden. ☺ Die Dillo-Installation kannst du natürlich als Codeblock reinmachen bzw. da es nur ein Beispiel ist, sollten wir Dillo vielleicht nur verlinken. Die Installation muss dann nicht nochmal hier aufgeführt werden und bläht den Artikel auf in der Zeilenanzahl. Des Weiteren wird das dann zu einem Howto und sowas wird hier im Wiki so gut wie nie zugelassen, außer als Howto selbst, mit entsprechend verschärften Regeln für den Onlinestatus des Howtos. Inhalt vor Struktur - nix umstrukturieren, sondern Inhalt auffüllen. Nix ohne Rückfrage kürzen/ rauswerfen. Ganz einfach eigentlich. 😉 Um den Rest kümmer ich mich gern in Zusammenarbeit mit march. Je nachdem, wie wir uns dann einigen. Wir stecken da einfach schon länger in den mühsigen Detaildiskussionen drin, aber vielleicht hat march auch deine Meinung und vielleicht werd ich auch da ein Gegenargument einbringen - bis irgendwann entschieden wird. Vorher keine Edit-Wars bitte, da hast du recht. ☺ Grüße, Benno
|
whazzup
Anmeldungsdatum: 20. April 2015
Beiträge: 550
|
For real? Du meinst allen Ernstes die beiden derzeitigen Hauptauthoren dieser Seite koennen sich ohne Moderator in keinem einzigen der Punkte einigen? Inklusive zB der Frage welches dieser beiden Scripts leichter lesbar ist? #!/bin/bash
export DISPLAY=:1
Xmir $DISPLAY &
sleep 0.5
dillo & #!/bin/bash
DISP=$1
Xmir $DISP --desktop_file_hint=/home/phablet/.local/share/applications/dillo.desktop &
sleep 0.5
DISPLAY=$DISP dillo &
# DISPLAY=$DISP x11vnc # evtl. Optionen wie -localhost -usepw -display :0 Wow! Versteh mich nicht falsch. Ich sage nicht dass es von immenser Tragweite ist welches der beiden Skripts auf der Seite steht. Was ich beachtenswert finde ist wenn wir uns ueber sowas nicht ohne Mod einigen koennen .... juhu.
|
Benno-007
(Themenstarter)
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Wo hab ich grad das Script angesprochen? Nirgends. Aber den Punkt hab ich auch nicht verstanden: export DISPLAY=:1 ist keineswegs kürzer als DISP=$1 - nur mal so. Und Kommentare weglassen - ist zwar kürzer, aber dann halt unkommentiert. Und warum der desktop-hint drinbleiben soll, hab ich ja nun auch an mehreren Stellen im Forum bereits erklärt, aber gerne nochmal: Es hat irgendeinen Sinn, auch wenn wir den noch nicht genau rausgefunden haben. Spekulationen gab es dazu bereits auch. Man kann es auskommentieren und einkommentieren, wie man will - sollte es aber zur Verfügung stellen. Und - nochmal - nah am Original bleiben. Denn da ist der Support am besten. Ansonsten sind wir bald wie Ubuntu zu Debian: Müssen alles zurechtpatchen. Der Wartungsaufwand wird zu hoch, wenn x Varianten in unsrer Community rumgeistern: Die aus dem Web und die hier abweichenden im Wiki. Find ich jedenfalls. Davon ab, ich hab keine Zeit, alle Varianten zu testen. Das Wiki hier ist sehr streng. Es ist kein Wiki, es ist im Grunde eine Debatte darüber, wie man ein Buch (bzw. eben grad kein Buch, aber eben professioneller) schreibt. Nimm doch Ratschläge an, auch wenn ich nicht im Wikiteam bin. Oder wenigstens die, die dann von march schon noch kommen werden. Ich will dich letztlich davor bewahren, Arbeit in Sachen zu stecken, die sowieso reverted würden. Und intransparente Kürzungen wie desktop-hint werde zumindest ich nicht für gut heißen. Sowohl aus technischer als auch aus dokumentarischer Sicht. Mit den Wiki-Maßstäben auf Transparenz ebenfalls. Transparent heißt nicht, alles wegzulassen, was man nicht versteht. Wenn es eine Funktion hat, muss es bleiben. Aber bis march da ist, halt ich mich hier auch raus - wir verschwenden unsere Zeit mit der Debatte. Und ja, wir brauchen dazu natürlich dritte Meinungen und Wikimods. Was meinst du, wie oft ich schon Artikel gelöscht hab oder kurz davor war, weil das Wikiteam einfach saumäßig hohe Qualitätsansprüche hat: unzufriedenheit-mit-dem-wiki-team. Das ist harte, trockene Arbeit - das gehört dazu. Grüße, Benno Edit: Inhaltlich zu den Links: Benötigte wie auf Dillo (zur Installation und Beschreibung) im internen Wiki sind im Fließtext gut, aber falls sie nicht direkt benötigt werden und eher eine Art weiterführende Informationsquelle sind, sollen unten in die Link-Liste. So kann man das vielleicht bisschen differenzieren, warum Dillo im Text ist, aber der Videolink ganz unten.
|