3. Improved Console für Unix Systeme

Improved Console für Unix Systeme

  • 3

    Möp!

    Ich hab hier eine Art Improved Console für Unix Systeme geschrieben. Downloadlink: http://www.2shared.com/file/HZeWhGMb/console.html

    Implementierte Funktionen:
    - Setzen der Textfarbe durch foreground() und lightforeground()
    - Setzen der Hintergrundfarbe durch background() und lightbackground()

    - Fette Schrift mit style::bold (Deaktivieren über style::nobold)
    - Unterstrichene Schrift mit style::underline (Deaktivieren über style::nounderline)
    - Blinkende Schrift mit style::blink (Deaktivieren über style::noblink)
    - Invertierte Farben über style::inverse (Deaktivieren über style::noinverse)

    - Leeren des Bildschirms über clear
    - Zurücksetzen des Stils über reset

    - Setzten des Titels der Konsole über title()

    Diese ganzen Funktionen lassen sich wie Stream-Manipulatoren verwenden. Funktionen die mit der Geometrie des Fensters zusammenhängen (verschieben, resizen, ...) habe ich bewusst weggelassen, da ich sie für unnötig erachte. Ihr dürft mich aber gerne eines besseren belehren.

    Getestet unter Mac OS X 10.6.8 Snow Leopard mit GCC 4.6, sollte aber auch unter den meisten anderen Unix Systemen laufen.

    Auch wenns nichts besonders großes ist, wäre etwas Feedback dazu recht nett 🙂

    Edit: Achja, ein kleines Designproblem hat das ganze, und hier ersuche ich gleich um Hilfe. Und zwar bleiben diese Design-Änderungen nach beenden des Programms erhalten. Ich suche eine Möglichkeit, am Ende des Programms automatisch ein reset zu machen. Gibts da irgendwas einfaches, ohne einen eigenen streambuffer o.ä.?

    0
  • V

    314159265358979 schrieb:

    - Setzen der Textfarbe durch foreground() und lightforeground()

    Wäre nicht nur forground() besser und doppelt so viele Farbwerte?

    0
  • P

    314159265358979 schrieb:

    Ich suche eine Möglichkeit, am Ende des Programms automatisch ein reset zu machen. Gibts da irgendwas einfaches, ohne einen eigenen streambuffer o.ä.?

    Du könntest entweder global, static in einer der Klassen oder als static in den Funktionen Variablen anlegen, die den Anfangszustand speichern und bei Zerstörung wiederherstellen. Quasi RAII auf Programmebene.

    Ist vielleicht nicht für alle Belange sicher genug aber das einfachste was mir grade einfällt 🙂

    0
  • E

    Edit: Achja, ein kleines Designproblem hat das ganze, und hier ersuche ich gleich um Hilfe. Und zwar bleiben diese Design-Änderungen nach beenden des Programms erhalten. Ich suche eine Möglichkeit, am Ende des Programms automatisch ein reset zu machen. Gibts da irgendwas einfaches, ohne einen eigenen streambuffer o.ä.?

    Du könntest doch die Grundfunktionalität in ein Singleton packen (das können die Streammanipulatoren ja auch nutzen) und im Ctor den Status abspeichern + im Dtor wiederherstellen.

    0
  • 3

    Ergibt sich da nicht ein Problem mit der Lebenszeit von cout? Ich bin mir da nicht sicher, darum frag ich lieber nochmal nach.

    0
  • 3

    volkard schrieb:

    314159265358979 schrieb:

    - Setzen der Textfarbe durch foreground() und lightforeground()

    Wäre nicht nur forground() besser und doppelt so viele Farbwerte?

    Habe ich überlegt und wollte ich auch ursprünglich so machen. Vielleicht bau ichs doch noch um.

    0
  • S

    Ich dachte immer für Unix-Systeme gäbe es da schon ncurses, ist das nicht so einfach benutzbar?

    MfG SideWinder

    0
  • 3

    Ich kenne ncurses nicht, aber soweit ich mir das ergoogelt habe, ist das eine C-Bibliothek, das finde ich nicht so schön wie Manipulatoren 🙂

    0
  • C

    314159265358979 schrieb:

    Diese ganzen Funktionen lassen sich wie Stream-Manipulatoren verwenden. Funktionen die mit der Geometrie des Fensters zusammenhängen (verschieben, resizen, ...) habe ich bewusst weggelassen, da ich sie für unnötig erachte. Ihr dürft mich aber gerne eines besseren belehren.

    Ich hab' mir den Code nicht angesehen, aber hoffentlich hast du daran gedacht, was passiert, wenn man deine Manipulatoren auf etwas anderes als cout loslässt. Was die Aufräumarbeiten angeht, wäre eventuell ios_base::register_callback() ein Lösungsansatz.

    0
  • 3

    Meine Manipulatoren geben ganz normale Zeichen an den Streams aus, man kann die Texte also auch persistent speichern und wiederverwenden 😉

    0
  • 3

    Also ein bisschen Feedback wäre schon ganz nett 🤡
    Habt ihr nicht schon immer von einer Bunten Unix-Konsole geträumt? 😃

    0
  • Mod

    314159265358979 schrieb:

    Habt ihr nicht schon immer von einer Bunten Unix-Konsole geträumt? 😃

    Das gibt nur komische Zeichen, wenn ich die Ausgabe irgendwohin pipe 🙂 .

    0
  • 3

    Sind ja im Prinzip nur "komische Zeichen". Auf der Konsole sollte es allerdings bunt sein.

    0
  • H

    also bei mir funktioniert das gut, allerdings musste ich die Datei ändern, bei mir gabs einen Comilerfehler: "'style' is already declared in this scope" oder so.
    Ich habs mit GCC 4.2 kompiliert, liegt wohl daran.

    auf jeden Fall könntest du doch eine Klasse daraus machen, deren Destruktor reset "aufruft". Man könnte ein Objekt dieser Klasse als "alternatives" cout verwenden, z.b.:

    int main()
{
    // angenommen, die Klasse hieße Print
    Print MyOut;
    MyOut << foreground(blue) << "Hallo Welt!\n";
    return 0;
}

    ich hab jedenfalls mal sowas ähnliches als Wrapper um NCurses gemacht.

    0
  • Mod

    314159265358979 schrieb:

    Sind ja im Prinzip nur "komische Zeichen". Auf der Konsole sollte es allerdings bunt sein.

    Nee, ich meine, dass wenn ich ein Programm schreibe, dass auf die Standardausgabe ausgibt, dann erwarte ich auch, dass diese Ausgabe auch von Nicht-Konsolen vernünftig verarbeitet werden kann. Wenn ich will, dass mein Programm nur Konsole kann (etwa eine tolle Benutzeroberfläche hat), dann nehme ich auch eine richtige Konsolenbibliothek und kein aufgebohrtes cout. Da hab ich dann auch Farbe.
    Wobei mir ein C++-Wrapper um die (meistens sehr C-igen) Konsolenbibliotheken durchaus sehr recht wäre, falls ich mal so etwas schreiben möchte (Das ist derzeit jedoch nicht absehbar, dass ich so etwas jemals tun werde).

    Ja, im Prinzip heißt das, dass ich den Sinn hinter deinem Projekt nicht einsehe. Wenn schon improved Console, dann hätte ich gleich auf einer Konsolenbibliothek aufgesetzt. Das kann man natürlich auch gerne alles selber machen (die Form die du derzeit hast ist auch ok), aber deine Bibliothek braucht noch dringend ein paar Grundfunktionen einer Konsolenbibliothek, wie Cursorpositionierung und Feedback über die Fenstergröße. Denn wenn schon bunt, dann auch gleich eine "richtige" Oberfläche.

    0
  • I

    Ich programmiere selten unter Unix, jedoch kann man doch irgendwie erkennen, ob stdout auf die Konsole oder in eine Pipe geht. Schließlich macht ls mit --color=tty genau das Gewünschte. Insofern wäre es für die Bibliothek sinnvoll, wenn das entweder automatisch erkannt werden würde, woraufhin alle Funktionen keinen Effekt haben, oder es eine Möglichkeit zur Erkennung und zur manuellen globalen Deaktivierung der Formatierung gibt.

    0
  • R

    Alptraeume 🙂
    Besonders wenn man unter Linux ne Konsole aufm anderen (Nicht Linux) System mit ncurses aufmacht ^^

    Ciao 🙂

    0
  • 3

    Ich verstehe euer Problem nicht. Wenn ihr die Farben nicht in der Datei oder wo auch immer haben wollt, dann haut sie da einfach nicht rein.

    Wenn man Nachrichten in einer Datei samt Farben speichern will, ist sowas nützlich. Und wenn ihr die Farben nicht wollt, dann lasst es eben bleiben.

    0
  • ?

    ipsec schrieb:

    Ich programmiere selten unter Unix, jedoch kann man doch irgendwie erkennen, ob stdout auf die Konsole oder in eine Pipe geht.

    #include <unistd.h>

if(isatty(STDOUT_FILENO)) { /* STDOUT_FILENO == 1 */
  ...
}
    0
  • 3

    Naja, ich hab das ganze ohne nur zum Spaß gemacht. Wenns keiner brauchen kann, dann halt nicht.

    0
Anmelden zum Antworten