staging.inyokaproject.org

TausB schrieb:

kaputtnik schrieb:

Bei Deinen Scrollbars ist der linke und rechte Rahmen der Scrollbar im _c Teil integriert. Sowohl beim scrollbar_frame als auch beim scrollbar_thumb. Zudem beinhalten alle frame und thumb-Bilder den Rahmen des menu_e Bildes. Der Rahmen wird also mehrfach überzeichnet/überlagert, was nach meinem Verständnis nicht richtig wäre.

Das habe ich nur wegen der Optik gemacht, damit die Scrollbar mittig im "_e-Rahmen" liegt. Standard ist: Linke Seite vom "_e-Rahmen"

Das ist nach meinen Tests so nicht ganz richtig... Wenn Du mit _e-Rahmen den von menu_pixmap_style meinst.

Eine Überlagerung ist auf keinen Fall nötig / Voraussetzung.

Das ist mir klar.

(Natürlich hätte GRUB intelligenter programmiert werden können, um auch die Verwendung aller Teile fehlerfrei zu ermöglichen... 😉 )

Es wäre nett, wenn Du das mit GRUB v2 auch mal testen könntest.

Mache ich doch die ganze Zeit. 😀

Achso, hier hattest Du „ohne Test“ geschrieben.

Evtll ist das dort schon behoben?

Nein.

Gut ☺

Dann soll ich mich sicherlich auch an dem boot_menu Abschnitt versuchen?

Nicht deswegen, aber trotzdem sinnvoll. Ein guter Test, ob Du jetzt alles verstanden hast... 😀

Ich glaube schon das ich das verstanden habe. Nur verhält sich die „Wirklichkeit“ etwas anders 😉

Aber egal, ich schreibe den menu_boot-Abschnitt ☺ Das mit der Scrolleiste kriege ich auch hin 😉

canvas - erledit. Habe versucht mich kurz zu fassen.

Danke. Wenn es Dich nicht stört, ändere ich „virtueller Bildschirm“ in „Leinwand“, oder „Fenster“ oder so ähnlich.

angepaßt: Styled-Box

Die Hinweisbox ist gut.

//EDIT:
Vorschlag Menu Icons:

Bestimmt den Abstand zwischen einem Boot-Menü-Eintrag und dem Boot-Menü Icon. Werden keine Boot_Menü Icons (Standardbreite = 32 Pixel) benutzt, kann mit einer negativen Einstellung dieser Eigenschaft der Abstand zwischen dem linken Bild (Kennung: _w) und dem Text mit einer reduziert eingestellt werden.

Jo, viel besser 👍 Bitte künftig direkt im Artikel einbauen.

//EDIT2:
Vorschlag Styled-Box:

Die Tabelle würde ich so lassen wie jetzt im Artikel steht. Die zusätzliche Spalte bringt keinen wirklichen Mehrwert und verwirrt meines Erachtens.

Wie bekomme ich die unterste Zelle linksbündig?

Entferne den Doppelpunkt

<-4 :> *) `terminal­-box: ` (globale Angabe) und `menu_pixmap_style = ` (boot_menu) verwenden alle Angaben.

TausB schrieb:

TausB schrieb:

EDIT3: (Übernehme aber gerne die Illustration.)

Anbei zwei Illustrationen. Hat wirklich Arbeit gemacht... - hoffentlich gefallen sie Dir und Du kannst sie verwenden.

Super, danke. Dieses ist etwas verwirrend, aber das andere ist perfekt 👍

kaputtnik schrieb:

Das habe ich nur wegen der Optik gemacht, damit die Scrollbar mittig im "_e-Rahmen" liegt. Standard ist: Linke Seite vom "_e-Rahmen"

Das ist nach meinen Tests so nicht ganz richtig... Wenn Du mit _e-Rahmen den von menu_pixmap_style meinst.

Doch, meinte ich. Welche abweichenden Erkenntnisse hast Du?

Dann soll ich mich sicherlich auch an dem boot_menu Abschnitt versuchen?

Nicht deswegen, aber trotzdem sinnvoll. Ein guter Test, ob Du jetzt alles verstanden hast... 😀

Ich glaube schon das ich das verstanden habe. Nur verhält sich die „Wirklichkeit“ etwas anders 😉

Nur wenn man immer alle Teile verwenden will... 😉

Aber egal, ich schreibe den menu_boot-Abschnitt ☺ Das mit der Scrolleiste kriege ich auch hin 😉

Du schaffst das!

canvas - erledit. Habe versucht mich kurz zu fassen.

Danke. Wenn es Dich nicht stört, ändere ich „virtueller Bildschirm“ in „Leinwand“, oder „Fenster“ oder so ähnlich.

Leinwand!

Vorschlag Menu Icons:

Bestimmt den Abstand zwischen einem Boot-Menü-Eintrag und dem Boot-Menü Icon. Werden keine Boot_Menü Icons (Standardbreite = 32 Pixel) benutzt, kann mit einer negativen Einstellung dieser Eigenschaft der Abstand zwischen dem linken Bild (Kennung: _w) und dem Text mit einer reduziert eingestellt werden.

Jo, viel besser 👍 Bitte künftig direkt im Artikel einbauen.

Habe aber Skrupel Deine Version einfach zu verbessern. Nicht immer liegt Dir meine Sichtweise.

Vorschlag Styled-Box:

Die Tabelle würde ich so lassen wie jetzt im Artikel steht. Die zusätzliche Spalte bringt keinen wirklichen Mehrwert und verwirrt meines Erachtens.

Überzeugt hat es mich so auch noch nicht, allerdings erschien mir der Gedanke nicht schlecht, die Verwendung auf bestimmte Elemente konkret einzuschränken, da es sonst zu unerwarteten optischen Fehlern kommt. Das kennst Du ja ... 😉

Anbei zwei Illustrationen. Hat wirklich Arbeit gemacht... - hoffentlich gefallen sie Dir und Du kannst sie verwenden.

Super, danke. Dieses ist etwas verwirrend,

Zugegeben ja, aber alles in eine Illustration erschien mir die schlechtere Variante zu sein. Kannst Du trotzdem damit leben?

aber das andere ist perfekt 👍

Prima.

TausB

TausB schrieb:

Doch, meinte ich. Welche abweichenden Erkenntnisse hast Du?

Sorry, hatte nicht richtig gelesen 😳 Stimmt schon.

Dann soll ich mich sicherlich auch an dem boot_menu Abschnitt versuchen?

Nicht deswegen, aber trotzdem sinnvoll. Ein guter Test, ob Du jetzt alles verstanden hast... 😀

Ich glaube schon das ich das verstanden habe. Nur verhält sich die „Wirklichkeit“ etwas anders 😉

Nur wenn man immer alle Teile verwenden will... 😉

Nein, das sehe ich anders. Oder sagen wir: Bei scrollbar_frame ist mir ein Unterschied aufgefallen. Gibt es Deiner Erfahrung nach weitere Elemente, wo keine _komplette styled_Box Definition (mit allen Teilen) möglich ist? Es geht mir um die Möglichkeit, nicht darum, ob eine komplette styled_box Definition (mit allen Teilen) auch Sinnvoll ist. Bei der Scrollbar ist die Verwendung aller Teile nach meinem Wissen nicht möglich.

Der Hintergrund meiner Hartnäckigkeit in dieser Frage ist:

1. Steckt ein Fehler im Programmcode (Bug)?

2. Wenn man alle styled_box-Teile verwenden kann, ergeben sich weitere Gestaltungsmöglichkeiten

canvas - erledit. Habe versucht mich kurz zu fassen.

Danke. Wenn es Dich nicht stört, ändere ich „virtueller Bildschirm“ in „Leinwand“, oder „Fenster“ oder so ähnlich.

Leinwand!

Ja, Canvas wird normalerweise mit Leinwand übersetzt.

Jo, viel besser 👍 Bitte künftig direkt im Artikel einbauen.

Habe aber Skrupel Deine Version einfach zu verbessern. Nicht immer liegt Dir meine Sichtweise.

Dein Text ist aber eindeutig besser ☺

Überzeugt hat es mich so auch noch nicht, allerdings erschien mir der Gedanke nicht schlecht, die Verwendung auf bestimmte Elemente konkret einzuschränken, da es sonst zu unerwarteten optischen Fehlern kommt. Das kennst Du ja ... 😉

Siehe meine Frage von oben.

Anbei zwei Illustrationen. Hat wirklich Arbeit gemacht... - hoffentlich gefallen sie Dir und Du kannst sie verwenden.

Super, danke. Dieses ist etwas verwirrend,

Zugegeben ja, aber alles in eine Illustration erschien mir die schlechtere Variante zu sein. Kannst Du trotzdem damit leben?

Natürlich kann ich damit leben 😉 Ich fange demnächst mal an zu schreiben und versuche die Bilder einzubauen.

Irgendwann muss ich ja auch noch mein ubuntuusers-Thema fertig machen...

kaputtnik schrieb:

Nur wenn man immer alle Teile verwenden will... 😉

Nein, das sehe ich anders. Oder sagen wir: Bei scrollbar_frame ist mir ein Unterschied aufgefallen. Gibt es Deiner Erfahrung nach weitere Elemente, wo keine _komplette styled_Box Definition (mit allen Teilen) möglich ist?

Ja, grafische progress bar.

Es geht mir um die Möglichkeit, nicht darum, ob eine komplette styled_box Definition (mit allen Teilen) auch Sinnvoll ist. Bei der Scrollbar ist die Verwendung aller Teile nach meinem Wissen nicht möglich.

Korrekt.

Der Hintergrund meiner Hartnäckigkeit in dieser Frage ist:

1. Steckt ein Fehler im Programmcode (Bug)?

Ja sehe ich so.

1. Wenn man alle styled_box-Teile verwenden kann, ergeben sich weitere Gestaltungsmöglichkeiten

Im Fall der scrollbar kann ich KEINE erkennen, nenne mir bitte nur ein Beispiel, welches nicht durch die 3 Elemente darstellbar ist. Alles, was nichts umschließt, braucht nur 3 Elemente.

Jo, viel besser 👍 Bitte künftig direkt im Artikel einbauen.

Habe aber Skrupel Deine Version einfach zu verbessern. Nicht immer liegt Dir meine Sichtweise.

Dein Text ist aber eindeutig besser ☺

Ich will mich nicht um das Ändern "drücken", sondern nur davor es ohne "Freigabe" zu machen.

Überzeugt hat es mich so auch noch nicht, allerdings erschien mir der Gedanke nicht schlecht, die Verwendung auf bestimmte Elemente konkret einzuschränken, da es sonst zu unerwarteten optischen Fehlern kommt. Das kennst Du ja ... 😉

Siehe meine Frage von oben.

Ist damit noch nicht vom Tisch ... 😉

Anbei zwei Illustrationen. Hat wirklich Arbeit gemacht... - hoffentlich gefallen sie Dir und Du kannst sie verwenden.

Super, danke. Dieses ist etwas verwirrend,

Zugegeben ja, aber alles in eine Illustration erschien mir die schlechtere Variante zu sein. Kannst Du trotzdem damit leben?

Natürlich kann ich damit leben 😉 Ich fange demnächst mal an zu schreiben und versuche die Bilder einzubauen.

Bin schon gespannt drauf!

Irgendwann muss ich ja auch noch mein ubuntuusers-Thema fertig machen...

Damit kann man eine Menge Zeit verplempern ... 😀

TausB

PS: Bin etwas überrascht, daß es noch kein Feedback von "den anderen" gibt.

TausB schrieb:

kaputtnik schrieb:

Nur wenn man immer alle Teile verwenden will... 😉

Nein, das sehe ich anders. Oder sagen wir: Bei scrollbar_frame ist mir ein Unterschied aufgefallen. Gibt es Deiner Erfahrung nach weitere Elemente, wo keine _komplette styled_Box Definition (mit allen Teilen) möglich ist?

Ja, grafische progress bar.

Ok...

1. Wenn man alle styled_box-Teile verwenden kann, ergeben sich weitere Gestaltungsmöglichkeiten

Im Fall der scrollbar kann ich KEINE erkennen, nenne mir bitte nur ein Beispiel, welches nicht durch die 3 Elemente darstellbar ist. Alles, was nichts umschließt, braucht nur 3 Elemente.

ok...

PS: Bin etwas überrascht, daß es noch kein Feedback von "den anderen" gibt.

Nur die Ruhe. Es gibt auch noch das reale Leben, welches immer Vorrang vor uu.de hat.

• Styled_box nach unten geschoben.

• Allgemeine Angaben in den Abschnitt Konfiguration gesetzt

• Deinen Text eingebaut.

• Text von Vorbereitung geändert

Wie siehst Du das mit dem Abschnitt Ein normales Bootmenü? Soll er raus oder macht das als kleine Einführung Sinn? Sollte man ein anderes Bild nehmen? So ganz sicher bin ich mir mit dem Abschnitt nicht.

kaputtnik schrieb:

PS: Bin etwas überrascht, daß es noch kein Feedback von "den anderen" gibt.

Nur die Ruhe. Es gibt auch noch das reale Leben, welches immer Vorrang vor uu.de hat.

Das ist richtig und gut so (habe mich leider selber nicht dran gehalten...). 😉

Wie siehst Du das mit dem Abschnitt Ein normales Bootmenü? Soll er raus oder macht das als kleine Einführung Sinn? Sollte man ein anderes Bild nehmen? So ganz sicher bin ich mir mit dem Abschnitt nicht.

Bild und Abschnitt gefallen mir. Um die Mächtigkeit der Themen aufzuzeigen, ist ggf. ein zweites "schönes" mit den gleichen Elementen sinnvoll? So würde man auf einen Blick sehen, was alles möglich ist.

• ich werde noch die fehlende Grauformatierung in den Tabellen machen. - done

• Was muß zu konvertierten Schriften (Lizenz) noch im README geschrieben werden?

  • Nach Klärung würde ich das "Glas-Thema" als einfaches Beispiel einstellen (Bild, Download)

• Die Elemente der "Styled Box" beschäftigen mich noch ... - Wie darf ich in dem Zusammenhang Dein "ok..." deuten? Als nachdenkliche und ungläubige Zustimmung? Als skeptische Zweifel? 😉

TausB

Neuer Versuch / Vorschlag:

//EDIT:
gerade bemerkt; daß

• color = "#red"

in label dürfte falsch sein. Bei Farbnamen wird kein '#' vorweg verwendet.

• ... (Kennung: _w) ...

wird in boot-menu verwendet, ist aber erst weiter unten beschrieben.

=⇒ beides korrigiert/angepaßt.

TausB schrieb:

kaputtnik schrieb:

PS: Bin etwas überrascht, daß es noch kein Feedback von "den anderen" gibt.

Nur die Ruhe. Es gibt auch noch das reale Leben, welches immer Vorrang vor uu.de hat.

Das ist richtig und gut so (habe mich leider selber nicht dran gehalten...). 😉

Ohoh... da wird doch nicht jemand süchtig? 😉

Wie siehst Du das mit dem Abschnitt Ein normales Bootmenü? Soll er raus oder macht das als kleine Einführung Sinn? Sollte man ein anderes Bild nehmen? So ganz sicher bin ich mir mit dem Abschnitt nicht.

Bild und Abschnitt gefallen mir. Um die Mächtigkeit der Themen aufzuzeigen, ist ggf. ein zweites "schönes" mit den gleichen Elementen sinnvoll? So würde man auf einen Blick sehen, was alles möglich ist.

Hm.. so ein Artikel ist immer eine Abwägung zwischen guter Information und Überladung. Man kann ja immer nur von sich selber aus gehen. Mir würde der bisherige Stand reichen, da wir ja am Anfang des Artikels die Beispiele (mit Downloadmöglichkeit) haben. Ein Vergelich ist also schon jetzt möglich.

• ich werde noch die fehlende Grauformatierung in den Tabellen machen. - done

Danke ☺

• Die Elemente der "Styled Box" beschäftigen mich noch ... - Wie darf ich in dem Zusammenhang Dein "ok..." deuten? Als nachdenkliche und ungläubige Zustimmung? Als skeptische Zweifel? 😉

😀 Als einfache Zustimmung. Wenn Du sagst es ist so, dann glaube ich es Dir ☺

Zu der Tabelle:
Ich wäre eher dafür, Besonderheiten in den entsprechenden Abschnitten aufzuführen. Das hat den Vorteil, das bei einer Änderung in der Anwendung nur der entsprechende Abschnitt geändert werden muss. Wenn man alle Eventualitäten im Abschnitt styled_box unterbringen will, besteht die Gefahr das man vor lauter wenn hier dann so, und wenn dort dann anders den Text nicht mehr versteht. Also Konkret: Im Abschnitt boot_menu → scrollbar schreibt man dann halt, das man nur _n, _c, und _s -Teile verwenden sollte.

Danke für die anderen Änderungen 👍

• Mein Thema Aktualisiert.

• Bei label eine Tabellenüberschrift entfernt.

Demnächst mache ich mich dann an den Abschnitt boot_menu.

kaputtnik schrieb:

Zu der Tabelle:
Ich wäre eher dafür, Besonderheiten in den entsprechenden Abschnitten aufzuführen. Das hat den Vorteil, das bei einer Änderung in der Anwendung nur der entsprechende Abschnitt geändert werden muss. Wenn man alle Eventualitäten im Abschnitt styled_box unterbringen will, besteht die Gefahr das man vor lauter wenn hier dann so, und wenn dort dann anders den Text nicht mehr versteht. Also Konkret: Im Abschnitt boot_menu → scrollbar schreibt man dann halt, das man nur _n, _c, und _s -Teile verwenden sollte.

Ist vermutlich die beste Lösung.

Demnächst mache ich mich dann an den Abschnitt boot_menu.

Bin schon gespannt ... 😉

Hier war noch etwas offen:

• Was muß zu konvertierten Schriften (Lizenz) noch im README geschrieben werden?

  • Nach Klärung würde ich das "Glas-Thema" als einfaches Beispiel einstellen (Bild, Download)

TausB

TausB schrieb:

• Was muß zu konvertierten Schriften (Lizenz) noch im README geschrieben werden?

  • Nach Klärung würde ich das "Glas-Thema" als einfaches Beispiel einstellen (Bild, Download)

Da musst Du wohl in der Lizenz zur verwendeten Schrift nachgucken. Ansonsten → Schriftarten. Ich gehe davon aus, das alle Schriften die zur Standardinstallation oder über die Paketverwaltung installiert werden können, „freie“ Schriftarten sind. Sonst müsste man ja bei jedem öffentlichen Brief oder bei Plakaten so was wie "Diese Dokument enthält die Schrift xy von blablup" stehen.

kaputtnik schrieb:

TausB schrieb:

• Was muß zu konvertierten Schriften (Lizenz) noch im README geschrieben werden?

  • Nach Klärung würde ich das "Glas-Thema" als einfaches Beispiel einstellen (Bild, Download)

Da musst Du wohl in der Lizenz zur verwendeten Schrift nachgucken. Ansonsten → Schriftarten. Ich gehe davon aus, das alle Schriften die zur Standardinstallation oder über die Paketverwaltung installiert werden können, „freie“ Schriftarten sind. Sonst müsste man ja bei jedem öffentlichen Brief oder bei Plakaten so was wie "Diese Dokument enthält die Schrift xy von blablup" stehen.

Ich deute Deine Antwort bei Verwendung der von Ubuntu mitgelieferten Schriften so:

• Diese sind "frei".

• Durch Konvertierung ändert sich die "freie Lizenz" nicht bzw. wird dadurch nicht beeinträchtigt.

=⇒ Sie können daher "gefahrlos" unkommentiert mit ausgeliefert werden?!

Danke, Gruß
TausB

//EDIT:

• Glas-Thema eingestellt.

• kleine Fehlerchen korrigiert.

• "Im Abschnitt boot_menu → scrollbar schreibt man dann halt, das man nur _n, _c, und _s -Teile verwenden sollte." –> done.

Hmm - ich glaube mein Teil ist jetzt fertig?! 😛

Hinweis:

item_padding = 5 Linker und rechter Abstand zwischen Menüeinträgen und Rahmen.

Und oben und unten! Das Padding umschließt die Summer aller Menüeinträge, ist quase ein innerer Rahmen im Menürahmen (siehe auch mein Bild im Post dazu).

TausB schrieb:

=⇒ Sie können daher "gefahrlos" unkommentiert mit ausgeliefert werden?!

Ich nehme es an.

//EDIT:

• Glas-Thema eingestellt.

• kleine Fehlerchen korrigiert.

• "Im Abschnitt boot_menu → scrollbar schreibt man dann halt, das man nur _n, _c, und _s -Teile verwenden sollte." –> done.

Danke ☺

Hmm - ich glaube mein Teil ist jetzt fertig?! 😛

Ich hatte extra den 30.12.2012 als Fertigstellungstermin angegeben. Also nicht hetzen 😉

• boot_menu angefangen. Ich versuche das ganze etwas zu gruppieren.

• Von daher habe ich den Abschnitt Boot_menü-Icons nach unten geschoben. Damit bleibt der Abschnitt Komponenten auf die Komponenten bezogen.

• Ein normales Grubmenü habe ich nach oben geschoben. Denke das passt als Einführung besser weiter oben.

• Container in den Abschnitt Komponenten verschoben → Irgendwie sind das ja auch Komponenten.

Ich hoffe, das Du damit klar kommst ☺ Muss mal schauen, wo ich Deine

Ah, Du hast den Artikel abonniert. Ändere das bitte gleich im Artikel.

@ Wikiteam: Folgende Anhänge können gelöscht werden:

• Baustelle/Grub 2/Thema/Per Datei/circular progress.png

• Baustelle/Grub 2/Thema/Per Datei/styled box.png

Ich habe versucht den Artikel in der jetzigen Form Syntaxkonform zu machen. Insbesondere im Abschnitt Boot-menü-icons war ich mir bei der --class-Formatierung nicht sicher. Wäre nett wenn mal einer drüber schauen könnte ☺

Hi kaputtnik,

gelöscht.

Beim Überfliegen sieht die Syntax schon perfekt aus. Mit deiner Erfahrung gehörst du ja selbst zu denjenigen, denen die Wikisyntax am besten geläufig ist. --class würde ich in Mono setzen, da dies ein Teil in der Konfigurationsdatei ist.

Gruss Lasall