staging.inyokaproject.org

Wir lassen das mit dem Editor einfach weg. Oder schreiben Hexeditor dazu, damit geht es bestimmt. Oder wir nehmen den

dd if=descent_logo.pf2 bs=1 count=30 skip=20

rein 😀

Das mit dem submenu habe ich nochmal überarbeitet.

Das mit dem Radius verstehe ich immer noch nicht:

• Der Bezug zu width/height ist mir nicht klar

• Meines Erachtens ist es eh nicht ganz richtig

Im Screenshot sind drei circular_progress zu sehen. Das linke und rechte sind aus den selben Bildern gebaut:

1. Das center_bitmap ist 61x61 Pixel groß

2. Das tick_image ist 16x16 Pixel groß

Die linke Anzeige hat eine breite von 120 Pixel (ca. doppelte center_bitmap-Breite), das Rechte ein breite von 61 Pixel (=center_bitmap-Breite).

Nach der Radiusberechnung ist für die linke Zeitanzeige

Radius = (width_der_Komponente/2 – width_des_ZeigerImages/2) – 2 [Pixel]
r = (120/2 - 16/2) -2
r = 50

Und nu? Was soll ich mit dem Wert? Was bringt Dir, TausB, diese Berechnung? Und wenn man den Wert für die breite/höhe verwenden soll, so ist das eine Zirkuläre Berechnung, da der Wert von der breite/höhe des Elementes abhängt.

Ich finde man sollte das mit dem Radius weglassen. Das verwirrt mehr als das es Erleuchtung bringt. Besser wäre ein Satz wie:

Die Angabe für die Breite und Höhe bestimmen den Abstand des Zeigerelementes zum center_bitmap.

fertig. Es ist nämlich durchaus auch möglich, das Zeigerelement innerhalb des center_bitmaps zu positionieren, siehe das circular_progress-Element in der Mitte, wo der Rote Zeiger innerhalb des center_bitmaps rotiert 😉

kaputtnik schrieb:

Wir lassen das mit dem Editor einfach weg.

O.k.

Das mit dem submenu habe ich nochmal überarbeitet.

Liest sich nun gut.

Das mit dem Radius verstehe ich immer noch nicht:

• Der Bezug zu width/height ist mir nicht klar

"heigt" spielt keine Rolle.

• Meines Erachtens ist es eh nicht ganz richtig

Tut mir leid, Deine Vermutung stimmt nicht!

Anbei mein dritter und letzter Versuch DEINEN Knoten zu lösen. Da ich mit der Formel kein Problem habe und sie mir die richtigen Resultate bringt, ist Dein Problem für mich nicht nachvollziehbar. ☹ Aber es ist Dein Artikel und ich möchte keine Doktorarbeit daraus machen und da nur einer das letzte Wort haben kann: Tue was Du für richtig hältst. 😉

Zum Nachvollziehen sind die Images angehängt.

• alle Center-Images haben die Größe 160x160

  • Ringe haben eine Breite von 10 Pixeln

• Zeiger hat die Größe 10x10

• Fall a) Komponentengröße 120x120

• Fall b) Komponentengröße 160x160

• Fall c) Komponentengröße 200x200

• alle Komponenten werden an der gleichen "top"-Position angezeigt

# kreisförmige progress bar a).
+ circular_progress {
    id = "__timeout__"
    left = 20
    top = 100%-220
    width = 120
    height = 120
    num_ticks = 30
    start_angle = 0
    # ticks werden abgebaut:
    ticks_disappear = false
    center_bitmap = "Kompo_120.png"
    tick_bitmap = "Zeiger.png"
}

# kreisförmige progress bar b).
+ circular_progress {
    id = "__timeout__"
    left = 260
    top = 100%-220
    width = 160
    height = 160
    num_ticks = 30
    start_angle = 0
    # ticks werden abgebaut:
    ticks_disappear = false
    center_bitmap = "Kompo_160.png"
    tick_bitmap = "Zeiger.png"
}

# kreisförmige progress bar c).
+ circular_progress {
    id = "__timeout__"
    left = 500
    top = 100%-220
    width = 200
    height = 200
    num_ticks = 30
    start_angle = 0
    # ticks werden abgebaut:
    ticks_disappear = false
    center_bitmap = "Kompo_200.png"
    tick_bitmap = "Zeiger.png"
}

Definition:
Image := I; Komponente := K; Zeiger := Z

Was sieht man?

Was bringt Dir, TausB, diese Berechnung?

Mir bringt es die Lage des Zeigerelementes zu bestimmen. 😉
Vereinfacht läßt sich sagen, daß das Zeigerelement an der Innenseite [bis auf 2 Pixel] der Komponente_(width) angezeigt wird (unabhängig von der Größe des CenterImage!).

Es ist nämlich durchaus auch möglich, das Zeigerelement innerhalb des center_bitmaps zu positionieren,

Dem habe ich nie widersprochen.

TausB

Mein „Knoten“ dabei ist einfach: Ich weiß nicht was ich mit dem errechneten Wert anfangen soll. Ich kann ihn nirgendwo bei „width“ eintragen oder sonst wie verwenden. Das ist mein Problem. Den einzige Sinn sehe ich darin, den Radius (Abstand zur Mitte) in einem Grafikprogramm zu überprüfen.

Setz mal den Zeiger auf den 6. Ring (Radius = 53 Pixel), bei einer Komponenten/Bildbreite von 160 Pixel. Im angehängten Screenshot habe ich ein Bild von Dir verwendet, der Text im center_bitmap stimmt also für diesen Screenshot nicht.

Aber es ist Dein Artikel und ich möchte keine Doktorarbeit daraus machen und da nur einer das letzte Wort haben kann: Tue was Du für richtig hältst.

Ne, es ist Dein Abschnitt 😛

kaputtnik schrieb:

Mein „Knoten“ dabei ist einfach: Ich weiß nicht was ich mit dem errechneten Wert anfangen soll. Ich kann ihn nirgendwo bei „width“ eintragen oder sonst wie verwenden.

Korrekt!

Das ist mein Problem. Den einzige Sinn sehe ich darin, den Radius (Abstand zur Mitte) in einem Grafikprogramm zu überprüfen.

Für meine visuelle Vorstellung ist es wichtig zu wissen, in welchem Abstand das Zeigerelement um den Ursprung kreist. Über die notwendige Genauigkeit läßt sich streiten. Der Kernaussagen sind, daß ...

• ... der Radius eine Funktion der Breite der Komponente und nicht des CenterImage ist!

• ... der Zeiger innenseitig an der "runden" Außenkante der Komponente (und nicht des CenterImage) kreist.

• ... richtig ist: Der Radius wird nirgendwo eingegeben.

Setz mal den Zeiger auf den 6. Ring (Radius = 53 Pixel), bei einer Komponenten/Bildbreite von 160 Pixel. Im angehängten Screenshot habe ich ein Bild von Dir verwendet, der Text im center_bitmap stimmt also für diesen Screenshot nicht.

Jetzt habe ich einen Hänger, poste doch bitte den entsprechenden Eintrag aus Deiner "theme.txt". Grundsätzlich kann das Verhältnis von Image- und Komponentengröße nur 3 Fallunterscheidungen aufweisen. Diese 3 Fälle sind in meinem obigen Post abgearbeitet...

Nur ein Verdacht: Evtl. gibt es (auch hier) einen Unterschied zwischen GRUB 2,00 und GRUB 1,99. Für

• text = "@KEYMAP_SHORT@"

• text = "@KEYMAP_LONG@"

kann ich das bereits vorab bestätigen. Mehr dazu später.

Wie ein Screenshot mit "meinen" Originalbildern und "theme.txt"-Einträgen bei Dir aus - genauso, oder anders?

Aber es ist Dein Artikel und ich möchte keine Doktorarbeit daraus machen und da nur einer das letzte Wort haben kann: Tue was Du für richtig hältst.

Ne, es ist Dein Abschnitt 😛

Na super - jetzt sind wir einen Riesenschritt weiter ... 😉

TausB

TausB schrieb:

kaputtnik schrieb:

Mein „Knoten“ dabei ist einfach: Ich weiß nicht was ich mit dem errechneten Wert anfangen soll. Ich kann ihn nirgendwo bei „width“ eintragen oder sonst wie verwenden.

Korrekt!

Dann ist es für den Artikel meiner Meinung nach nicht relevant.

Der Kernaussagen sind, daß ...

• ... der Radius eine Funktion der Breite der Komponente und nicht des CenterImage ist!

Dann sollte man das einfach so schreiben ☺

• ... der Zeiger innenseitig an der "runden" Außenkante der Komponente (und nicht des CenterImage) kreist.

Dann sollte man das einfach so schreiben ☺ Den Abstand zur "runden"Außenkante kann man mit dem tick_bitmap einstellen. s.u.

• ... richtig ist: Der Radius wird nirgendwo eingegeben.

Dann sollte man das so schreiben ☺

Jetzt habe ich einen Hänger,

hehe...das dachte ich mir 😉

poste doch bitte den entsprechenden Eintrag aus Deiner "theme.txt".

Das wird nicht viel bringen. Guck Dir lieber den Zeiger im Anhang an.

Na super - jetzt sind wir einen Riesenschritt weiter ... 😉

Mir ist nur daran gelegen nichts unnötiges/verwirrendes im Artikel zu schreiben und das wir uns einig werden. Ich denke mir halt: Wenn ich das nicht checke, dann haben andere auch Probleme damit. Aber vllt bin ich ja auch der einzige 😬

Da transparente Bereiche auch zum Image gehören, bleiben inhaltlich meine Aussage - und die Formel - korrekt. Werde trotzdem versuchen den Absatz wunschgemäß umzuschreiben.
EDIT done. /EDIT

Aber vllt bin ich ja auch der einzige 😬

Das könnte in diesem Fall schon sein... 😀

TausB

Anderes Thema 😉 :
Sollte GRUB 2/Thema nicht umbenannt werden, um Verwechselungen zu vermeiden, z.B. in "Design" oder "Aussehen"? Die Ansätze sind gänzlich unterschiedlich. Der hier beschriebene Ansatz wird im GRUB-Handbuch unter "Theme" (Thema) beschrieben, d.h. paßt hier die Bezeichnung meines Erachtens deutlich besser. Der andere Ansatz wird dort unter "Simple configuration" geführt und wird primär über /etc/default/grub gesteuert.

TausB

Lassen wir den Absatz jetzt so... ich bin nicht zufrieden, aber was solls, ich weiß ja wie es geht 😊

TausB schrieb:

Anderes Thema 😉 :
Sollte GRUB 2/Thema nicht umbenannt werden, um Verwechselungen zu vermeiden, z.B. in "Design" oder "Aussehen"?

Ja, da sollte „man“ (respektive ubuntuusers/Wikiteam, NewUbunti und syscon-hh und wir) uns was überlegen. Auch für diesen Artikel hier könnte man einen anderen Namen wählen. Mir fiel im ersten Moment nichts besseres ein...

Aber die Diskussion sollte man führen, wenn unser Artikel mal fertig ist ☺

Ich komme im Moment leider recht selten dazu mich einzubringen (außer meckern, was immer leichter ist, als selbst schreiben 😉 ).

kaputtnik schrieb:

Lassen wir den Absatz jetzt so... ich bin nicht zufrieden, aber was solls, ich weiß ja wie es geht 😊

Glücklich bin ich damit auch nicht - also fühle Dich eingeladen einen Alternativvorschlag zu verfassen. 😉

TausB schrieb:

Anderes Thema 😉 :
Sollte GRUB 2/Thema nicht umbenannt werden, um Verwechselungen zu vermeiden, z.B. in "Design" oder "Aussehen"?

Ja, da sollte „man“ (respektive ubuntuusers/Wikiteam, NewUbunti und syscon-hh und wir) uns was überlegen. Auch für diesen Artikel hier könnte man einen anderen Namen wählen. Mir fiel im ersten Moment nichts besseres ein...

Mein Vorschlag ist:

• /GRUB_2/Themen - für unseren Artikel 😀

Aber die Diskussion sollte man führen, wenn unser Artikel mal fertig ist ☺

Was fehlt außer "Styled Boxes" noch?

TausB

TausB schrieb:

kaputtnik schrieb:

Lassen wir den Absatz jetzt so... ich bin nicht zufrieden, aber was solls, ich weiß ja wie es geht 😊

Glücklich bin ich damit auch nicht - also fühle Dich eingeladen einen Alternativvorschlag zu verfassen. 😉

Hm... warst Du vorher glücklicher? Wenn ich ein circular_progress baue,

1. möchte ich das ganze center_bitmap verwenden → Hinweise zur Beschneidung sind nicht nötig

2. möchte ich wissen, wie das tick_bitmap einzubauen ist → Die width-Angabe regelt die Gesamtgröße: Breite von center_bitmap + ( 2x Breite von tick_bitmap) + evtll. abstand = width. Diese Berechnung passt natürlich nur, wenn das center_bitmap so groß ist, das der eigentliche Inhalt dargestellt wird, also keine großen transparenten Ränder hat. Gleiche gilt für das tick_bitmap.

Mein Vorschlag ist:

• /GRUB_2/Themen - für unseren Artikel 😀

Ja, so ähnlich hatte ich auch schon gedacht. „Im Prinzip“ (meiner Meinung nach) sollte die Empfehlung sein, auch eine grafisch einfache Konfiguration des Grubmenüs (zB nur das Einstellen eines Hintergrundbildes) über unseren Artikel anstatt über Grub 2/Thema zu machen. Damit hätte man eine Einheitliche Grundlage und muss nicht mit diesem Skript oder mit den moreblue-orbit_blue.png oder den export= Variablen hantieren. Man ändert dann ja nur maximal zwei Dinge in /etc/default/grub, was IMHO wesentlich zur Übersicht beiträgt.

Aber die Diskussion sollte man führen, wenn unser Artikel mal fertig ist ☺

Was fehlt außer "Styled Boxes" noch?

Der Abschnitt boot_menu und mein Teil über vbox (was mit der Verschachtelung von Elementen einhergeht) zB.. Ebenso fehlen noch unsere fertigen Beispielthemen als Anhang. Du wolltest doch auch noch ein schöneres Bild für den circular_progress machen 😉 (Artikelanhänge wie Bilder oder sonstige Dateien kannst Du über den Reiter "Mehr → Dateianhänge verwalten" anfügen/ändern ☺ )

Hi kaputtnik und TausB,

da sich die Backlinks in Grenzen halten, ist es kein Problem den aktuellen Themenartikel umzubenennen. Das Problem bei solchen Umbenennungen ist nur, dass Verlinkungen aus dem Forum dann nicht mehr passen. Klasse Arbeit bisher und ich freue mich immer über die Bilder, die ihr hier als Anhang zeigt ☺ .

Ich überfliege eure Diskussion nur, also wenn irgendetwas vom Wikiteam aus zu machen ist, bitte gut kennzeichnen 😉 .

Gruss Lasall

kaputtnik schrieb:

TausB schrieb:

kaputtnik schrieb:

Lassen wir den Absatz jetzt so... ich bin nicht zufrieden, aber was solls, ich weiß ja wie es geht 😊

Glücklich bin ich damit auch nicht - also fühle Dich eingeladen einen Alternativvorschlag zu verfassen. 😉

Hm... warst Du vorher glücklicher?

Nein ...

Wenn ich ein circular_progress baue,

1. möchte ich das ganze center_bitmap verwenden → Hinweise zur Beschneidung sind nicht nötig

Dem könnte ich noch etwas abgewinnen.

1. möchte ich wissen, wie das tick_bitmap einzubauen ist → Die width-Angabe regelt die Gesamtgröße: Breite von center_bitmap + ( 2x Breite von tick_bitmap) + evtll. abstand = width.

Diese Formel halte ich schlicht für irreführend, um nicht zu sagen falsch...
Allmählich verstehe ich Deinen Ansatz ...
Du "baust auf" - ich "baue/passe hinein" (nutze gegebenen Platz) - das ist der Unterschied in der Denke. *klick*

Daher sind wir bisher auch unglücklich über die Formulierung des anderen gewesen! 😀

Diese Berechnung passt natürlich nur, wenn das center_bitmap so groß ist, das der eigentliche Inhalt dargestellt wird, also keine großen transparenten Ränder hat. Gleiche gilt für das tick_bitmap.

Auf deutsch: Du bevorzugst "Deine" Formel mit der Angabe von Prämissen?!

Mein Vorschlag ist:

• /GRUB_2/Themen - für unseren Artikel 😀

Ja, so ähnlich hatte ich auch schon gedacht.

Fein.

„Im Prinzip“ (meiner Meinung nach) sollte die Empfehlung sein, auch eine grafisch einfache Konfiguration des Grubmenüs (zB nur das Einstellen eines Hintergrundbildes) über unseren Artikel anstatt über Grub 2/Thema zu machen. Damit hätte man eine Einheitliche Grundlage und muss nicht mit diesem Skript oder mit den moreblue-orbit_blue.png oder den export= Variablen hantieren. Man ändert dann ja nur maximal zwei Dinge in /etc/default/grub, was IMHO wesentlich zur Übersicht beiträgt.

Die Idee finde ich gut. Wird unser Artikel nicht zu lang? Der Riesenvorteil wäre, daß die Links "Lasall-Problem" weiterhin funktionieren würden und der Leser Appetit auf mehr bekommt. 😉

Aber die Diskussion sollte man führen, wenn unser Artikel mal fertig ist ☺

Was gemäß Deines vorherigen Vorschlags unmöglich ist... 😎

Was fehlt außer "Styled Boxes" noch?

Der Abschnitt boot_menu und mein Teil über vbox (was mit der Verschachtelung von Elementen einhergeht) zB.. Ebenso fehlen noch unsere fertigen Beispielthemen als Anhang. Du wolltest doch auch noch ein schöneres Bild für den circular_progress machen 😉 (Artikelanhänge wie Bilder oder sonstige Dateien kannst Du über den Reiter "Mehr → Dateianhänge verwalten" anfügen/ändern ☺ )

Vorschlag:

Zum Thema Screenshot oder ganze Themendatei/-verzeichnis:

• Wie sieht es mit der Verwendung von Ubuntudistri- und ubuntuusers.de-Icons,Symbolen und Hintergründen aus - dürfen die "einfach so" verwendet werden (GPL?)?

• Falls die "theme.txt" einen Header benötigt, machst Du das bitte?

TausB

//EDIT:
Tabelle aktualisiert

Ich glaube es war gestern Abend etwas spät...

TausB schrieb:

kaputtnik schrieb:

2. möchte ich wissen, wie das tick_bitmap einzubauen ist → Die width-Angabe regelt die Gesamtgröße: Breite von center_bitmap + ( 2x Breite von tick_bitmap) + evtll. abstand = width.

Diese Formel halte ich schlicht für irreführend, um nicht zu sagen falsch...

Ja, sie ist „etwas“ falsch...

Wie wäre es, wenn wir so etwas wie im Anhang im Artikel einbauen? Das gleiche dann noch einmal mit dem Bild von hier (Natürlich ohne die Schrift und nur einem Zeiger). Damit dürften die Zusammenhänge dann klar sein. Was hälst Du davon?

Auf deutsch: Du bevorzugst "Deine" Formel mit der Angabe von Prämissen?!

Nein, weil sie ist ja auch nur annähernd „richtig“. Ich denke, das man den Zusammanhang am besten mit solchen Bildern wie oben beschreiben kann. Man kann ja auch eines machen, wo Deine Radius-Formel drin ist. Für Leute die so denken wie Du 😉

„Im Prinzip“ (meiner Meinung nach) sollte die Empfehlung sein, auch eine grafisch einfache Konfiguration des Grubmenüs (zB nur das Einstellen eines Hintergrundbildes) über unseren Artikel anstatt über Grub 2/Thema zu machen. Damit hätte man eine Einheitliche Grundlage und muss nicht mit diesem Skript oder mit den moreblue-orbit_blue.png oder den export= Variablen hantieren. Man ändert dann ja nur maximal zwei Dinge in /etc/default/grub, was IMHO wesentlich zur Übersicht beiträgt.

Die Idee finde ich gut. Wird unser Artikel nicht zu lang?

Ich meinte den bisherigen Artikel komplett durch unseren zu ersetzen. Aber das finde ich jetzt nicht mehr so eine gute Idee... Denn wenn jemand nur ein anderes Hintergrundbild haben möchte, muss er eine komplette Themendatei (mind. Hintergrundbild + boot_menu-Abschnitt) erstellen. Oder man bietet eine solche vorgefertigt an.

Die zwei Artikel zu vermischen halte ich für keine gute Idee.

Der Riesenvorteil wäre, daß die Links "Lasall-Problem" weiterhin funktionieren würden

Ich glaube nicht, das es so viele Links aus dem Forum auf den Themen-Artikel gibt ☺

Vorschlag:

ToDo:
Thema	Wer?
Terminal	TausB
boot_menu	kaputtnik
Styled Boxes	TausB
vbox	kaputtnik
Integration alter Themenartikel	kaputtnik
Bild "circular progress"	TausB
optischer Feinschliff und Syntax	kaputtnik]

Ja, Prima.

Zum Thema Screenshot oder ganze Themendatei/-verzeichnis:

• Wie sieht es mit der Verwendung von Ubuntudistri- und ubuntuusers.de-Icons,Symbolen und Hintergründen aus - dürfen die "einfach so" verwendet werden (GPL?)?

Ja, so viel ich weiß schon.

• Falls die "theme.txt" einen Header benötigt, machst Du das bitte?

Mit „header“ meinst Du ein paar Kommentare am Anfang der Datei?

kaputtnik schrieb:

Wie wäre es, wenn wir so etwas wie im Anhang im Artikel einbauen? Das gleiche dann noch einmal mit dem Bild von hier (Natürlich ohne die Schrift und nur einem Zeiger). Damit dürften die Zusammenhänge dann klar sein. Was hälst Du davon?

Sehr gute Idee! - Darum kümmere ich mich.

Auf deutsch: Du bevorzugst "Deine" Formel mit der Angabe von Prämissen?!

Nein, weil sie ist ja auch nur annähernd „richtig“. Ich denke, das man den Zusammanhang am besten mit solchen Bildern wie oben beschreiben kann.

Zustimmung.

Man kann ja auch eines machen, wo Deine Radius-Formel drin ist. Für Leute die so denken wie Du 😉

Höre ich da eine Anspielung raus? 😀

„Im Prinzip“ (meiner Meinung nach) sollte die Empfehlung sein, auch eine grafisch einfache Konfiguration des Grubmenüs (zB nur das Einstellen eines Hintergrundbildes) über unseren Artikel anstatt über Grub 2/Thema zu machen....

Die zwei Artikel zu vermischen halte ich für keine gute Idee.

Hmmm - ich habe mir eine deutlich gekürzte Variante des Original-Artikel vorgestellt, die unserem voransteht.

• Einfache grafische Konfiguration (altes "Geraffel")

• GRUB-Themen-Gestaltung mit vielfältigen Möglichkeiten

Immerhin ist beides stark verwandt und gehört damit irgendwie zusammen ...

Der Riesenvorteil wäre, daß die Links "Lasall-Problem" weiterhin funktionieren würden

Ich glaube nicht, das es so viele Links aus dem Forum auf den Themen-Artikel gibt ☺

So hatte es Lasall ja auch eingeschätzt.

Zum Thema Screenshot oder ganze Themendatei/-verzeichnis:

• Wie sieht es mit der Verwendung von Ubuntudistri- und ubuntuusers.de-Icons,Symbolen und Hintergründen aus - dürfen die "einfach so" verwendet werden (GPL?)?

Ja, so viel ich weiß schon.

Gut.

• Falls die "theme.txt" einen Header benötigt, machst Du das bitte?

Mit „header“ meinst Du ein paar Kommentare am Anfang der Datei?

Das war auf den obigen Absatz bezogen. Herkunft der Bilder, das Weitergabe möglich ist etc.

Kannst Du mit meinem Absatz "Styled Boxes" leben?

TausB

TausB schrieb:

Sehr gute Idee! - Darum kümmere ich mich.

👍

Man kann ja auch eines machen, wo Deine Radius-Formel drin ist. Für Leute die so denken wie Du 😉

Höre ich da eine Anspielung raus? 😀

Nein, das sollte nur andeuten, das es eben verschiedene Denkweisen gibt ☺

Hmmm - ich habe mir eine deutlich gekürzte Variante des Original-Artikel vorgestellt, die unserem voransteht.

Jetzt, nachdem ich mich mit dem Thema so weit auseinandergesetzt habe, finde ich Grub 2/Thema ziemlich durcheinander. Das liegt sicherlich daran, das er getestet ab Lucid ist und deswegen viele Sonderfälle (je nach Ubuntuversion) behandelt. Ob man das soweit verkürzen kann, das man es in unseren Artikel einbauen könnte, wage ich zu bezweifeln. Aber wir können das Wikiteam ja bitten, Grub 2/Thema erst einmal in die Baustelle zu schieben und versuchen ihn zu straffen. Wenn, dann aber erst wenn wir hier fertig sind.

Immerhin ist beides stark verwandt und gehört damit irgendwie zusammen ...

Das ist richtig.

• Falls die "theme.txt" einen Header benötigt, machst Du das bitte?

Mit „header“ meinst Du ein paar Kommentare am Anfang der Datei?

Das war auf den obigen Absatz bezogen. Herkunft der Bilder, das Weitergabe möglich ist etc.

Achso. Die Bilder hier im Portal sind so weit ich weiß fast alle aus dem Tango-Projekt → heißt: Wir müssen den Namen angeben.

@Wikiteam: Könntet Ihr bitte klären welche Rechte bei den anderen Bildern zu beachten sind →

• Portal-Header (geschwungenes Hintergrundbild oben)

• Ubuntuuserslogo (mit und ohne Schrift)

Wir sollten für die Themen, die wir hier zur Verfügung stellen, je eine Datei copyright und readme hinzufügen. Alles zusammen (Bilder, Themendatei und zuvor genannte Dateien) dann als tar.gz packen.

Kannst Du mit meinem Absatz "Styled Boxes" leben?

👍 Nur im Bild würde ich keine schwarzen Bereiche nehmen, sondern tatsächlich benutzte Bilder. Also für die Ecken so was rundes, für Senk- und Waagerecht einfach gerade Teile. Und im Abschnitt progress-bar-Grafische-Balkenanzeige fehlt dann noch die nötige Angabe ( "bar_style" und "highlight_style" ?).