4. Algierlib: GUI Bibliothek

Algierlib: GUI Bibliothek

  • A

    phlox81 schrieb:

    Wäre es dann nicht geschickter wenn der View einen typedef handle hätte?

    view::handle x;

    👍 Bin ich bisher blind gewesen! Da ich sowas schon in der Lib gemacht habe. Zwar nicht mit Typedefs für Smartpointer, aber Typedefs für tr1::function habe ich als public in die Klassen geschrieben. Das ist definitiv besser als ein Namespace!

    Also ich sag mal, das sind bisher die Kandidaten, die ich pers. bevorzugen würde:

    `view_h

    viewh

    view::handle`

    0
  • A

    Blue-Tiger schrieb:

    Mich persoenlich stoert das gesamte "_h", weil ich vermutlich in 99.999% der Faelle kein Interesse daran habe, dass ich grad mit 'nem Handle hantiere. Und soweit ich das gesehen hab, verwendet die Lib die meiste Zeit sowieso das Handle und nicht den eigentlichen Typ. Sprich, ich wuerde das view in sowas wie view_t umbenennen und den view_h zum view machen. Letztendlich verwendet der Benutzer naemlich sowieso dieses Handle.

    Hem, also deine Analyse ist soweit richtig. Als Anwender wird man die Klassennamen nur beim Erzeugen benutzen. Danach wird man entweder direkt tr1::shared_ptr<view> oder das kürzere Typedef benutzen. Aber auch den Handlenamen selbst schreibt man eigentlich nie wieder, außer man will Funktions-Paramter definieren. Hält sich also in Grenzen für den Anwender, wann er z.B. view_h schreibt. Denn typischerweise initialisiert man GUI-Objekte in einem Rutsch und haut die in den Container... und sieht sie selten wieder. Weil man nämlich mit den Models weiter arbeitet. ⚠

    Die API selbst erwartet immer den Smartpointer respektive Typedefed Handle.

    Dein Vorschlag würde also so aussehen:

    button btn(new actionbutton_t(L"OK"));

    Bleibt aber noch die (abstrakte) Basisklasse, die würde button_t heißen müssen, wegen dem Namenskonflikt. Obwohl die abstrakte Basis unvollständig ist, finde ich _t widersprüchlich. Dann wohl eher base_button ?

    Das würde aber dann nicht auf Oran-Klassen zutreffen, da diese von der ganzen Handle-Geschichte nicht betroffen sind. Diese Klassen auch auf _t enden lassen zu müssen, würde eine Begründung nötig machen. Ohne _t wäre das irgendwie nicht konsistent... Oder man sagt, das sollte Oran nicht betreffen, da Oran eh nicht von Algier abhängt.

    Blue-Tiger schrieb:

    Aber ich vermute wenn ich wirklich mal mit der Lib arbeiten wuerde (dafuer brauch ich aber den Linux-Port 😉 ), koennt ich mich auch ans _h gewoehnen. Namespaces faend ich aber auch keine schlechte Loesung (und machen fuer mich durchaus Sinn, da muss ich Walli widersprechen). Nur seh ich's schon kommen, dass ich dann irgendwann im Code

    using namespace algier; using namespace algier::handles

    stehen haette und der Compiler sich wieder nicht auskennt, was ich denn nun mein, wenn ich button schreib.

    Ja, Namespace kommt definitiv nicht in Frage. Da finde ich die Member-Lösung von oben besser.

    Blue-Tiger schrieb:

    Verschreckst du damit nicht eher sowohl Gnome als auch KDE-User? Wenn ich mein gtk-Theme aender, ziehen Qt-Apps mittlerweile automatisch nach, weil gerade bei den zwei grossen (gtk/Qt) halbwegs Interopabilitaet besteht. Im Idealfall merk ich nichtmal mehr, welche Lib der App zugrund liegt. K. A. ob das auch fuer OpenMotif gegeben ist. Bei wxWidgets stoerts auch niemand, dass sie gtk wrappen statt Qt.

    OpenMotif hat seinen eigenen Look & Feel, der eher neutral wirkt. Der passt sich nicht an Gtk oder Qt an. Ist in KDE und Gnome natürlich "fremd". Aber OpenMotif ist sehr kompakt und unterliegt einer stabilen API und stabilen Implementierung. Vorallem ist es Standard von dern OpenGroup! Das sollte man einfach mit einbeziehen. Für den Pflegeaufwand in Algierlib ideal.
    Hier sind Screenshots von Anwendungen die ältere OpenMotif-Versionen nutzen:

    http://www.gnu.org/software/ddd/
    http://www.nedit.org/screenshots.php

    Neuere OM-Versionen sollen laut Release-News schon Anti Aliasing Fonts haben.

    Gtk kenne ich nur als User. Und das kommt mir monströs vor. Ich meine nicht von der Festplattenbelegung (das ist heute auf PCs egal), sondern was ich als Algierlib-Implementierer an abhängigen Libs beachten müsste. Ich versuche da realistisch zu sein.

    Ich weiß nicht wieviel Entwickler hinter wxWidgets stecken, aber wx ist von der Community her ein ganz anderes Kaliber. Und doch werden die sicherlich Pflegedefizite haben? Ein gutes Beispiel ist FLTK: ein bekanntes, angesehenes und verbreitetes Toolkit. Aber die 2er Version wurde eingestampft, weil einfach keine Entwickler da sind. Die 1.3er Version erhält nur Bugfixes. Und es ist erst jetzt ein Table-Widgets beigesteuert worden. 😮

    Deshalb wollte ich erstmal einen OpenMotif-Port als Prototyp ausprobieren (also nicht Feature-complete). Man könnte auch einen Prototyp auf Gtk-basis probieren. Ich habe noch nichts in Stein gemeisselt.

    Blue-Tiger schrieb:

    Das Beispiel find ich gut, macht klar warum das so ist. Macht echt Sinn! 👍 Aber: mir widerstrebt es, meine Applikationslogik von einer Fremden Lib (Oran) abhaengig zu machen. Grad bei so Sachen wie Datenstrukturen: was, wenn ich das ganze spaeter mal mit Swig interfacen will, oder ausserdem noch Library X einstetzen will um statistische Auswertungen zu machen oder..... da hab ich dann mit einem schlichten int oder bool sicher weniger Probleme/Umstaende als mit einem oran::binary . Ich wuerds schoen finden, wenn Oran Wrapper fuer die Grunddatentypen anbieten wuerde (die dann eine Referenz speichern o. AE.), damit ich meine eigentliche Applikationslogik frei von oran halten koennte.

    Ja, kann ich verstehen. Deshalb wäre es noch schlimmer, View-Klassen zu nutzen. Oran selbst hat nämlich nur die Abhängigkeit zur C++-Standard Lib, sonst nichts weiter! Das als wichtiger Hinweis.

    Wenn du noch weiter gehen willst, kannst du natürlich noch eine Trennung vornehmen, und dir Adapter bauen bzw. man könnte das in Oranlib natürlich zus. anbieten. Aber gehen wir von dem aktuellen Stand aus.

    // Deine Anwendungslogik Lib, ohne Oran-Abhängigkeit
struct level
{
    bool sonne;
};

    Jetzt müsstest du natürlich trotzdem die View verbinden. Dazu baust du dir einen Adapter, den die Views verstehen:

    // Dein Adapter Projekt, in einer eigenen Lib mit Oran-Abhängigkeit

class bool_adapter : public oran::binary_model // nicht oran::binary!!!
{
    bool &b_; // Reference!
public:
    bool_adapter(bool &b) : b_(b)
    {}
    bool status() const
    {
         return b_;
    } 
};

    binary_model ist eine abstrakte Klasse in Oran, die nicht implementiert ist. binary ist die Default-Implentierung. Mit der binary_model kann sich aber jeder das passende bauen, was er braucht... meistens wohl Adapter-Klassen.

    class level_adapter
{
    level &level_;
public:
    bool_adapter sonne_;

    level_adapter(level &l) : level_(l), sonne_(l.sonne)
    {}
};

    Das wäre so der ad-hoc Vorschlag, als Dummycode. Kann sein das der Buggy wäre. 😉
    Evtl. gibts da auch schlauere Lösungen.

    0
  • B

    Genau an so Adapter fuer die Grunddatentypen hatte ich gedacht! 🙂 Die sollten in Oran bereits vorhanden sein 🙂 Dann kann ich den Logikteil oran-frei halten und trotzdem ein Model im GUI-Layer der Applikation erstellen (oder wo immer ich sie sonst fuer sinnvoll halte), mit dem ich meine GUI-Teile fuettere.

    Ad OpenMotif: ich weiss wie OpenMotif-Apps aussehen/sich anfuehlen und das ist der Killergrund, warum ich den DDD kaum verwende obwohl er ein weltklasse Debugger ist. Aber sein Handling, Look and Feel ist einfach derart "fremd" (und furchtbar altbacken) dass ich mich nicht damit anfreunden mag.
    OpenMotif unterstuetzt AFAIK nichtmal die Freedesktop-Standards, da hilfts dann auch nicht wenn es von der Open Group kommt. Es hat schon einen Grund warum so gut wie kein modernes Programm auf OpenMotif setzt. Ich wuerd den Prototypen trotz evlt. hoeherem Initialaufwand in GTK(mm)/Qt schreiben, denn wenn du irgendwann ernsthaft Linux unterstuetzen willst (und dort eine Userbase gewinnen) kommst du nicht drum rum auf einen der 2 Grossen zu setzen.

    0
  • A

    Announcement: Version 0.5.0 released

    Es hat lange gedauert bis mal wieder ein neues Release raus kam. Zu lange! Ich will das in Zukunft anders handhaben und in kürzeren Zeiträumen veröffentlichen, die dann aber weniger Änderungen haben können. Hauptsächlich habe ich so lange gebraucht, weil ich immer und immer wieder was geändert habe, sowohl am API-Design als auch an der Implementierung. Nie zufrieden. 😞

    Habe versucht TDD-basiert zu entwickeln. Es ist mir bei den Mouse-Listener-Tests auch sehr gut gelungen. 🙂 Habe den Dreh ganz gut raus. Ich muß aber viele alte fehlende Unittests nachziehen.

    GDI+ hat mir unter MinGW Sorgen bereitet. Dann habe ich nochmal die 2D-Grafik-API umgestellt, und zwar Status-basiert. Leider noch ohne Double Buffer.

    Wer 3D-Grafik machen will, kann einfach einen OpenGL-View erzeugen. Ein Beispiel, das ein Dreieck mittels Slider rotieren kann, sieht man an diesem Sourcecode, das Ergebnis als Screenshot.

    Die Handles habe ich jetzt von xyz_h auf xyz_ptr geändert. Ich habe mich einfach nach der Konvention von shared_ptr und weak_ptr gerichtet.

    Was steht an? Bisher gibt es nur einfache sinnlose Testprogramme. Ich will ein paar kleine Demoprogramme mit Source raus bringen, um praktische Beispiele zu zeigen. Die man auch zum Lernen nutzen kann.

    An die Linux-Fraktion: Sorry, noch nichts in der Richtung gemacht. Arbeiten am X11-Port werde ich Ende September starten. Das wird schneller gehen als die Win32-Version, weil ich keine Arbeit in das API-Design, Doku usw. stecken muß.

    Feedback willkommen! 🙂

    0
  • V

    Surfe grade deine Seite http://www.kharchi.eu/algierlib/ an
    Microsoft Security Essentials
    Sagt mit das der Trojan::JS/Redirector und Exploit:Win32/CVE-2010-1885.A da beherbergt ist.
    .....AppData\Local\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5\N6ELFRG1\algierlib[1].htm->(SCRIPT0001)

    Überprüf mal bitte ob sich da was eingeschlichen hat.

    0
  • A

    Ich weiß, habe selber MSE zu Hause. Aber ich weiß ums Verrecken nicht was der da anmotzt. Wenn ich es im IE aufrufe, meckert er nicht. Wenn ich es im Opera aufrufe, meckert er.

    Hier auf Arbeit haben wir McAfee, und der meckert gar nichts an, wenn ich es im Firefox aufrufe.

    Hier der komplette Source der Weiterleitungsseite:

    <head>
<meta http-equiv="refresh" content="1; URL=html/index.html">
<a href="html/index.html">Go to Algierlib reference documentation</a>
</head>

    Wenn jemand weiß, woran es liegt und eine Alternative zu meinem HTML kennt, kann mir das gerne mitteilen. 🙂

    EDIT: ist ja gar nicht die Weiterleitungsseite. Geht ja direkt auf die Doxygen-Seite. Weiß nicht was da Doxygen so generiert. Werde ich mal zu Hause nochmal versuchen raus zu finden.

    0
  • A

    Komisch. Die index.html-Datei auf dem Webserver war verändert... hatte viel Mist am Ende der Datei stehen, ca. 44 KByte. Das originale auf meiner Platte war viel kleiner (5 KB). 🙄

    0
  • F

    Hey,
    erst mal Respekt für diese Bibliothek 👍
    Ist bisher finde ich sehr gut gelungen. Ich bin mich im Moment am einarbeiten, und muss echt sagen, sehr gut zu verstehen 🙂
    Find sie vor allem sehr gut da es ein sehr modernes C++ ist und ich sowieso erst mal C++ richtig beherrschen will, aber viele GUI-Frameworks unterstützen da einen nicht, sondern hindern einen eher dran. Aber immer nur Konsole is auch n bisschen langweilig, da ich oft nicht weiß wie ich da was umsetzen soll. Und genau in dem Punkt passt deine Lib echt super rein, man lernt trotzdem sehr gut mit C++ umzugehen, ohne irgendwelchen zusätzlichen Murks der nicht mehr so viel mit echtem C++ zu tun hat.

    Respekt 😉

    Ich hoffe du arbeitest auch fleißig dran weiter 😋

    Lg freeG

    0
  • A

    Danke für die gute Kritik! 🙂

    An der Lib arbeite ich auf jeden Fall weiter, da ich damit selber ein paar kleine Anwendungen und Tools programmiere. Es geht aber nicht so schnell voran weil ich das alles in meiner Freizeit mache (neben meinem Beruf). Man kann aber immer spätestens alle 6 Monate mit einem Release rechnen.

    Es ist gut, wenn du auch die Lib ausprobierst oder benutzt, dann kann man mehr Fehler finden und die Lib für mehr User gerecht gestalten.

    Auch schön das du es verständlich findest. Das Handbuch war mir sehr wichtig, da die meisten OSS-Projekte an dem Punkt scheitern. Leider ist mein Englisch nicht so gut, sonst würde ich das Handbuch ausführlicher und besser schreiben können. Ein Engländer wird sich wahrscheinlich die Hände über den Kopf schlagen. 😉 Aber ich habe noch vor, ein ausführlicheres deutsches Handbuch zu schreiben.

    Wenn Du also Fragen hast oder Fehler findest, dann scheue dich nicht mir das mitzuteilen. Entweder hier in diesem Thread oder in der offiziellen user-Mailingliste (kannst auch dort auf deutsch schreiben).

    0
  • G

    Hallo,

    ich habe bisher für GUI Projekte immer Qt verwendet, wollte mir jetzt aber auch mal andere Frameworks anschauen, da ich mit Qt nicht komplett zufrieden bin (MOC, eigene "Standardbibliothek", etc.).
    Algierlib scheint da genau das richtige zu sein: Schön schlank und modern.

    Mir ist allerdings unklar, wie ich eigene Modelle einbinden kann. Ich möchte eigentlich so etwas wie algier::listbox , allerdings möchte ich natürlich meine Daten nicht alle zuerst in eine oran::stringlist kopieren, da ich sie dann ja zweimal im Speicher hätte.

    Ich vermute, ich muss dafür irgendwie mit algier::list<Model> arbeiten, aber ich weiß ehrlich gesagt nicht wie. 🙂
    Könntest du mir da irgendwie weiterhelfen (sprich: Welches Interface braucht Model genau, welche Funktionen von algier::view muss ich selbst implementieren, etc.)?

    Gruß,
    Guybrush

    0
  • A

    Hallo Guybrush™! Au waija! Schande über mich! Deine Anforderung ist (noch) gar nicht möglich. 😞 Aber das kann ich schnell ändern. 🙂 Ich werde die stringlist-Klasse nochmal abstrahieren und diese am Wochenende noch in das SVN-Repository schreiben.
    Dann kannst du die abstrakte Klasse für den Bau eines Model-Adapters nutzen und es entstehen dadurch keine Kopien deiner Daten. Ich würde dir dann auch ein Beispiel-Code liefern.
    Aber dein Gedanke mit dem Model war auf jeden Fall schon richtig.

    Sehr gut das Du nachgefragt hast. 👍 Nur so kann ich auch die Library an die Bedürfnisse der breiteren Masse anpassen.

    0
  • A

    Guybrush™ schrieb:

    Könntest du mir da irgendwie weiterhelfen (sprich: Welches Interface braucht Model genau, welche Funktionen von algier::view muss ich selbst implementieren, etc.)?

    Du könntest natürlich auch die View-Klasse ändern. In der Datei list.cpp suchst du nach "Fill list content". Dort wird durch das Model iteriert.
    Die View-Klasse direkt zu manipulieren ist natürlich dirty. 😃 Man müsste für die Zukunft vielleicht die Model-Zugriffe auslagern, damit man andere Model-Interfaces nutzen kann... Da könnten evtl. Policy-Klassen helfen.

    Zur Zeit steht so ein hoch flexibles Design noch nicht an. Die Prioritäten liegen im Projekt noch woanders. Aber es ist ein Gedanke den man verfolgen sollte. 🙂

    0
  • G

    Schön, dass ich helfen konnte. 🙂
    Dann warte ich mal bis zum Wochenende - bin schon gespannt.

    Du könntest natürlich auch die View-Klasse ändern. In der Datei list.cpp suchst du nach "Fill list content". Dort wird durch das Model iteriert. Die View-Klasse direkt zu manipulieren ist natürlich dirty. 😃

    Ah, tatsächlich. Vielleicht mache ich es testweise mal so.

    Gruß,
    Guybrush

    0
  • G

    Hallo,

    hattest du Zeit daran zu arbeiten? Ich habe testweise mal die list.cpp an meine Bedürfnisse angepasst und es funktioniert, aber das ließe sich natürlich wunderbar abstrahieren.

    Gruß,
    Guybrush

    0
  • A

    Sorry, wird heute knapp. Aber ich habe es nicht vergessen! 😃

    0
  • M

    Hat die AlgierLIB ein Table/Grid/Matrix Widget?

    So dass man eine Tabelle mit 3 Spalten und "beliebig" vielen Zeilen anzeigen lassen kann.

    Von der Doku. und Code habe ich nichts dies bezüglich gefunden, aber ich frag lieber mal nach.

    Grüße
    Martin

    0
  • N

    Nun bin ich gerade auf diese Ankündigung gestossen... Finde ich sehr schade, zumal die AlgierLib mit nativen Widgets, modernem C++ und ihrer Schlankheit wirklich Potential hat.

    Darf ich fragen, ob es eher design-/codetechnische Gründe sind, oder du nicht mehr genügend Zeit bzw. Interesse am Projekt hast? Im ersten Fall müsste man ja nicht gleich das ganze Projekt auf ewig einfrieren. Wäre jedenfalls cool, falls du eines Tages wieder daran weiterarbeiten würdest, aber ich kann auch verstehen, falls du genug davon hast. Und wenig Feedback ist natürlich auch etwas frustrierend, vielleicht müsstest du das Projekt an diversen Orten vorstellen. Zum Beispiel im wxWidgets-Forum 😃

    0
  • A

    Danke für die Nachfrage, Nexus! 🙂

    Ja, ich habe das Projekt gestoppt, weil ich die Implementierung vergeigt habe. 😞 Mit dem API-Design selbst bin ich jedoch im großen und ganzen zufrieden (auch wenn es natürlich immer was zu meckern gibt).

    Konkret habe ich das Win32-Message-Handling falsch gemacht, so das ich beim implementieren der Scrollbars bei deren Events an einer ziemlich komplizierten Situation gekommen bin, um die Events zuordnen zu können.

    Ehm, was mir dann aber auch schon vorher den Nerv geraubt hatte (aber nicht zum Stopp führte), war das Pimpl-Idiom, das ich durchgängig nutzte. Dieses hat auch sehr viel Codierarbeit verschlungen. Ich würde das heute überdenken oder besser vorher ein Script schreiben, das mir die immer wiederkehrende Arbeit abnimmt.

    Was auch sehr anstrengend war, ist die englische Dokumentation. Ich möchte behaupten, das ich im Vergleich zu anderen Libs von Anfang an die Doku recht gut gepflegt habe. Aber die Doku zu schreiben und pflegen ist wirklich viel Arbeit.

    Naja, von einem geplanten Linux-Port will ich gar nicht anfangen. 😃

    Feedback gab es leider wenig. Es gab aber doch schon ein gewisses Interesse. Ich vermute mal, es hat noch der Break-even-Point gefehlt, damit nenneswertes Feedback und Unterstützung kommt.

    Ich habe aber noch nicht endgültig aufgegeben. Es geistert immer noch in meinem Kopf herum, ein GUI-Lib-Projekt raus zu bringen, das die Bedürfnisse recht vieler C++ler erfüllt. Und worauf ich zu Anfang achten muss, weiß ich jetzt. 🙂 Auch das ich vielleicht aktiver nach Unterstützern suchen muss, da es doch recht viel Arbeit ist, wenn man es publik machen will. Aber jetzt ist erstmal Projekt-Stopp. 😉

    0
  • N

    Okay, danke für die Erläuterung!

    Zum Pimpl habe ich mir mal einen Smart-Pointer geschrieben, der das Impl-Objekt automatisch kopiert. So muss man wenigstens nicht jedes Mal gleich die Grossen Drei überladen, wenn die Klasse kopierbar sein soll. Aber ich nehme mal an, der nervige Teil der Arbeit waren die doppelten Funktionen und ständigen Weiterleitungen...

    0
Anmelden zum Antworten