[C++] GCL - Die flexible GUI Bibliothek

    • Release
    • Open Source

    Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von Gonger96.

      [C++] GCL - Die flexible GUI Bibliothek



      Beschreibung:
      GCL ist eine GUI Bibliothek für Windows, die ihre Controls mit einem Renderer zeichnet. Dadurch wird in Sachen Design natürlich fast alles möglich. Transparenz, Transformationen und pixelgenaue Kollision werden demnach auch von allen Controls unterstützt. Das Defaulftdesign ist relativ schlicht und funktionsmäßig gehalten, aber Ownerdrawing wird natürlich unterstützt. Controls müssen auch nicht rechteckig sein, jede Form ist möglich.

      Ich hab mich dazu entschieden dieses Monstrum selbst zu implementieren, weil sämtliche vorhandenen GUI-Libs mich von der Architektur her absolut nicht ansprachen. Grade was Events/Callbacks anging, nehmen die jede Flexibilität weg. Habe Ende 2012 mit GCL begonnen (mit teils sehr langen Pausen) und nun endlich Version 1.0.0 fertig. Vielen Dank an @Trade, der bei den Tutorials und der Doku hilft. Er steht auch für Support zur Verfügung. Noch ein großes Dankeschön an @nafets, der freundlicherweise ein komplettes Logo-Set für GCL machte und @Nikx der sich um die Website (gcl-ui.com) gekümmert hat :)

      Screenshot(s):
      Spoiler anzeigen


      Die Restlichen sind im Anhang zu sehen.

      Verwendete Programmiersprache(n) und IDE(s):
      C++ mit Visual Studio 2013 Commiunity, Visual Studio 2012 Professional und Visual studio 2010 Professional

      Systemanforderungen:
      Keine. Zum Entwickeln ist allerdings ein Compiler mit mind. C++ 11 Standard erforderlich. Z.B. VS 2013+

      Systemveränderungen:
      Keine.

      Download(s):
      Download für die Demo inklusive Source der Demo hier (30,5MB).
      Die Source der Library gibts nochmal auf Github.
      Einen besseren Überblick zu GCL und etliche Tutorials gibt es auf der Website.

      Lizenz/Weitergabe:
      OpenSource, Lizenz ist auf Github zu finden.
      Bilder

      • snap1.png

        18,67 kB, 858×558, 466 mal angesehen

      • snap2.png

        16,62 kB, 858×558, 516 mal angesehen

      • snap4.png

        38,44 kB, 840×542, 394 mal angesehen

      • snap5.png

        15,99 kB, 858×558, 396 mal angesehen

      • transform.png

        28,44 kB, 991×584, 444 mal angesehen

      Also bin nach wie vor begeistert davon und hoffe, dass ich Zukunft dann etwas Zeit finde und mitarbeiten kann. Leider hat es ja zeitlich nicht ganz geklappt.
      Auf jeden Fall stolze Leistung, sowas auf die Beine gestellt zu haben. Ist ja auch sehr komplexes Zeug drin und das nativ. :)

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Trade“ ()

      @Bluespide Funfact: Keine Ahnung. :D Selbst Gonger weiß es nicht mehr.
      @thefiloe Könnte man theoretisch ausweiten, wäre aber nach den ganz vielen zukünftigen Sachen wohl am Ende eine Aufgabe. ;)

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

      @Solaris , @thefiloe Danke^^ Ich wollte die Library gerne erstmal ausweiten, die Doku vervollständigen und ggf. noch einen Designer entwickeln. Danach werd ich GCL auf ein paar Plattformen ausweiten, was ja letztlich nicht extrem viel Arbeit ist. API wird hauptsächlich in window.h und zum DragDrop verwendet, ansonsten müsste ich nur einen neuen Renderer implementieren.

      Hi @Gonger96!

      Hab mir grad die Demo runtergeladen. Erst mal: Ganz dickes Lob! Super schön gemacht ;D

      Hab da aber noch eine Frage: Bei mir dauert des (trotz SSD) ewig lange, bis das Fenster aufgeht. Also sowohl die GCLDemo.exe aus GCL-Demo-1.0.0\GCL-Demo 1.0.0\bin\Direct2D als auch die aus GCL-Demo-1.0.0\GCL-Demo 1.0.0\bin\GDIplus.
      Also zumindest bei ersten mal starten. Liegt des am rendern?

      Lg Radinator
      In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

      Ja. Das ist normal und auch bei mir auf meiner Raketenkiste so. :P
      Kommt natürlich drauf an. Direct2D als Renderer müsste im Endeffekt noch etwas schneller sein als GDI+, aber dauert auch kurz.

      Grüße
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

      Jo, beim ersten Laden werden alle Ressourcen initialisiert, das ganze Layout wird gesetzt und es sind auch noch ein paar Schleifen drin um buttons zu generieren (für die Layoutseite) und Testdaten für List und Combobox.

      Btw: Welche Plattformen wären denn unbedingt nötig?

      Gonger96 schrieb:

      Welche Plattformen wären denn unbedingt nötig?

      Wie meinste des?
      In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

      Linux fände ich noch sinnvoll - bei Mac OS X halte ich das nicht für nötig, da man dort mMn ein UI mit nativem Aussehen erstellen sollte.

      Kleiner Nachtrag: Warum verlieren die Scrollbar und die TrackBar den Fokus, wenn ich beim Ziehen die Maus aus ihrem Feld herausziehe? Das macht die beiden für mich fast nicht nutzbar, da ich ständig neu ansetzen muss. Außerdem fühlen sich Doppelklicks komisch an. Außerem wäre es sinnvoll, bei der gecheckten Version des MenuItems mit Icon beim Hover der Box um das Icon herum eine andere Farbe zu geben. Sonst sieht man ja nicht, dass es gecheckt ist.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „nafets“ ()

      nafets schrieb:

      Warum verlieren die Scrollbar und die TrackBar den Fokus, wenn ich beim Ziehen die Maus aus ihrem Feld herausziehe?

      Nicht nur beim außerhalb-des-Fenster-bewegens, sondern auch wenn ich außerhalb des Controls komme.
      Ging mir also genau so ;D

      Lg Radinator
      In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

      nafets schrieb:

      Warum verlieren die Scrollbar und die TrackBar den Fokus, wenn ich beim Ziehen die Maus aus ihrem Feld herausziehe?

      Wird geändert, Danke. Inwiefern fühlen Doppelklicks sich komisch an? Kann da eigentlich nicht viel dran machen, ist ja letztendlich nur eine Windowmessage.

      Hi @Gonger96: Was ich eingentlich schon die ganze Zeit mal fragen wollte:
      In einer PN hast du mir ja geschrieben, dass dein GCL-Projekt weniger als Setze-IncludePath-auf sondern mehr ein füge-Dateien(Header/Sourcen)-zu-Projekt-hinzu zu verstehen ist.
      Warum servierst du aber dann immer noch die einzelnen Files in seperaten Ordnern, aus denen sich der Progger die Dateien erst in sein Projekt kopieren muss?
      Wäre es nich sinnvoller
      1.) das ganze als DLL zu vertreiben und den Quellcode offen zu lassen oder
      2.) einfach im Projekt selber die Ordner zu behalten und die #include <...>erei relativ zu gestalten und einen "IncludeAll-Header" zu erstellen, der alle wichtigen Sachen inkludiert. So dass sich der Progger nur den einen inkludieren muss, bzw einfach den Pfad zu GCL als zusätzlichen Include-Path hinzufügt.

      Lg Radinator
      In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

      Gonger96 schrieb:

      Wozu das Programm unnötig aufblähen?

      Was heißt hier unnötig aufblähen? Ich frag ja nur, warum die einzelnen Dateien in seperaten Orndern drinnen sind und nicht alles in einem bzw warum die Dateien nicht relativ unter einander ver-inkludiert sind.

      Lg Radinator
      In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

      Gonger96 schrieb:

      C++ ist nicht für Dlls ausgelegt, dass wirst du nicht als Dll kompilieren können. Ich habs extra semantisch sortiert damit sich der Nutzer das raussuchen kann, was er braucht. Wozu das Programm unnötig aufblähen?
      Das ist nicht wahr. Es wäre fatal, wenn C++ als eine höhere Programmiersprache so eine Grundkompetenz nicht mit sich bringt. Wenn du dein Projekt nicht als dynamische Bibliothek (.so, .dll, wie auch immer) kompilieren kannst, wäre es vielleicht Ratsam, den Code nochmal zu überarbeiten :P (merke: ich bin mir nicht sicher, inwiefern C++/CLI sich darauf auswirkt).
      Generell ist es auch eine gute Idee, dem Endnutzer die Wahl zwischen dynamisch und statisch eingebunden zu lassen, da dieser meist am besten weiß, welche der beiden Varianten für ihn die beste ist; beide bringen Vor- und Nachteile mit sich.

      Radinator schrieb:

      Was heißt hier unnötig aufblähen? Ich frag ja nur, warum die einzelnen Dateien in seperaten Orndern drinnen sind und nicht alles in einem bzw warum die Dateien nicht relativ unter einander ver-inkludiert sind.

      Die gewählte Struktur macht schon Sinn. Man sollte (vor allem) Bibliotheken in einzelne Pakete oder Module einteilen, die jeweils einen eigenen Zuständigkeitsbereich haben. Hier ist das vielleicht nicht unbedingt nötig, allerdings wird das in größeren und weiträumigeren (bzgl. Funktionalität) Projekten essentiell. Was genau du mit deinem letzten Satz ausdrücken willst verstehe ich nicht, allerdings ist es für gewöhnlich eine bessere Idee, Header absolut einzubinden und vor allem die Abhängigkeiten untereinander möglichst gering zu halten, da mehr (nicht zwingend notwendig) eingebundene Header wahrscheinlich auch die Kompilierzeit erhöhen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „martinustreveri“ ()