Skins für Programm?

[Targion]

In Delphi gab es die SXSkin-Komponenten. Vielleicht könnte man die für Lazarus portieren. (z.B. auf GTK aufsetzen)

[pluto]

OH ! ich glaube wir sind hier wieder an meinem Lieblings Thema angekommen: Skinbare GUI'S für Lazarus..... FPGUI *G*

Wir ihr sehen könnt, vermissen viele diese Möglichkeit bei Lazarus. Eine Skinbare GUI zu haben. Nicht alle haben die Möglichkeit unter Windows GTK2 zu nutzen. Warum auch immer. Also währen Native Komponenten nicht schlecht. Ich glaube das die Windows API von Haus aus Skinnen kann oder ?
Also sollten es unter Windows Relativ leicht sein das aussehen der Komponenten an zu passen. Unter Linux jedoch dürfte das nicht so leicht sein. Da es ja mind. so viele GUI'S gibt wie Sand am Meer.

Also währe es logischerweise am besten eine eigene zu schreiben. Der Aufwand ist zwar sehr hoch. Meine bisherigen versuche sind auch nicht grade Positiv verlaufen in dieser Richtung. Allerdings eine gewisse Ausnahme ist meine GUI für meine 2D Engine. Die werde ich jedoch zu gegebener zeit komplett neu erstellen. Weil es dort noch einige Probleme gibt die einen neu Anfang rechtfertigen würden.

Somit würde die GUI auf Canvas basieren. Was mir voll kommen ausreichen würde.

Was ich gerne mal machen würde, weiß aber nicht wie ich anfangen müsste:
Ich suche mir eine GUI aus dem Internet die mir gefällt. und stelle sie dann in Lazarus zu Verfügung. Es gibt recht schöne GUI'S wenn ihr mal ausschau haltet. Ich denke das müsste auch gehen.

Aber eine eigene GUI finde ich verlockender. Wir sollten mal gemeinsam eine entrechende GUI's Klassen Struktur erstellen.
Also mein Vorschlag währe folgender:
Es gibt eine Bases Klasse. Die ist direkt von Canvas abgeleitet. Oder wir erstellen uns ein eigens Canvas dafür. Was mir lieber währe.
Dann gibt es einige weitere Bases Klassen:
Eine die, für das Scroll Verhalten, eine andere für Buttons und soweiter. Die Komponenten werden in Gruppen gefasst und pro Gruppe gibt es eine Klasse wenn es sich anbietet: Beispiele:
TPLBUTTONS
- TPLButton
- TPLChekButton
- TPLRadiobutton

TPLListen
- ListBox
- ListView
- ComboBox(*)
- TreeView
- MainMenu
- PopupMenu

TPLInput
- Edit
- Memo
- Editor
- SoruceEdit
.....

das währe meine Vorgehensweise. Bei meiner GUI für die 2D Engine habe ich außerdem noch ein Komponenten Manger erstellt. Der weiß welche Komponente den Focus hat, und verteilt die Events entsprechend.

Es gibt aber noch weitere zahlreiche Probleme in diesem Zusammenhang:
- Scrollen
Ich möchte gerne ein allgemeines Scrollwindow haben. Dann könnte das eigentliche Problem auf die Komponenten verteilt werden.
So ähnlich macht das ja auch TCustomControl.

- Reinhenfolge beim erstellen
Alle Komponenten dürfen nicht sichtbar sein am Anfang. Es muss eine liste geben wo drin steht welche Komponente zu letzt sichtbar wurde. So habe ich das Klick Problem bei meiner GUI für meine 2D Engine gelöst.

- GUI-Editor
Wir sollten uns aufjedenfall überlegen, ob und wie wir ein GUI-Editor erstellen. Wenn sollten wir ihn gleich am Anfang hinzufügen z.b. nach dem es 10 einfache Komponenten gibt.

- Datenspeicherung
Wie speichern die Komponenten ihre Einstellungen in einer Datei ?
Ich finde bei meinem Paint2 Projekt habe ich das relativ gut gelöst, dort hat sich eine allgemeine Bases Klasse um dieses Problem gekümmert. Es hat einfach alle Daten "Eingesammelt" und weiter gereicht an den TFileFormatManger. Der wiederum entschied wie die Daten gespeichert werden. Zur Auswahl standen glaube ich zwei Formate.

- Bei einzelnen Komponenten
Die Komponenten würde ich dann so einteilen das die einfachsten zu erst kommen und sich der Schwierigkeitsgrad gerad erhöht

[Christian]

Nich labern, machen.

[pluto]

Nich labern, machen.

Dann mach. Ich mache mir ständig Gedanken über sowas. Wie ich eine gute Grundlage erstellen kann. Genau das ist das Problem: Die Grundlage. Sie muss stimmen. Aber du hast natürlich recht: Die Idee sollte umgesetzt sein/werden.

[marcov]

OH ! ich glaube wir sind hier wieder an meinem Lieblings Thema angekommen: Skinbare GUI'S für Lazarus..... FPGUI *G*

Wir ihr sehen könnt, vermissen viele diese Möglichkeit bei Lazarus. Eine Skinbare GUI zu haben. Nicht alle haben die Möglichkeit unter Windows GTK2 zu nutzen. Warum auch immer. Also währen Native Komponenten nicht schlecht. Ich glaube das die Windows API von Haus aus Skinnen kann oder ?

Ja und nein, erst nur mit XP.

Also sollten es unter Windows Relativ leicht sein das aussehen der Komponenten an zu passen.

Nur soweit wie das Windows Api das zusteht. Un so ist est auch mit GTK2 und QT. Man kann nur die Möglichkeiten nutzen die es da gibt.

Unter Linux jedoch dürfte das nicht so leicht sein. Da es ja mind. so viele GUI'S gibt wie Sand am Meer.

Halb von denen gibt es auch fuer Windows (zb in Cygwin gibt es windowmaker etc, wxwidgets, gtk und QT gibts fuer Windows auch). Aber typisch wird nur Windows API unterstutzt.

Gleich so löst mann das auch fuer Linux. GTK2+QT ist 95%, und das ist genügend.

Also währe es logischerweise am besten eine eigene zu schreiben.

Mann loest ein paar Probleme damit (owner drawn), aber es gibt auch ein paar neue Probleme. Zb, den Applikation aussehen ändert sich nicht wann das OS theme sich ändert.
Natuerlich wirt dann direkt behaupten das die Applikation das bemerken kann, und adaptiert. Aber das ist sehr schwer, und hört nie auf.

Es gibt schon solch einen versuch. fpgui, und auch MSEGUI ist glaub ich meistens ownerdrawn.

[pluto]

Nur soweit wie das Windows Api das zusteht. Un so ist est auch mit GTK2 und QT. Man kann nur die Möglichkeiten nutzen die es da gibt.

Ja ! Das meine ich ja: Nicht jede API verfügt über vergleichbare Möglichkeiten. Das ist ja das Dilemma. Demzufolge kann man Lazarus nicht nachsagen das es keine Skinbaren Komponenten hat, sondern das es einfach nicht möglich ist, bei der vielzahl von Toolkits die dann auch noch sich unterscheiden.

Daher finde ich die Idee mit fpGUi gar nicht mal so schlecht. Eine Native GUI zu erstellen. Die über eine Skin Funktion verfügt. Mein Ziel ist es dort mit zu machen und den Soruce-Code zu erweitern. Ich weiß allerdings noch nicht genau ob er noch weiter entwickelt wird von anderen.

Halb von denen gibt es auch fuer Windows (zb in Cygwin gibt es windowmaker etc, wxwidgets, gtk und QT gibts fuer Windows auch). Aber typisch wird nur Windows API unterstutzt.

Gleich so löst mann das auch fuer Linux. GTK2+QT ist 95%, und das ist genügend

Ja ! Die QT GUI soll sehr gut sein. Der QT-Desiner hat mir einen überblick geben über die verfügbaren Komponenten. Würde es eine ausreichende Möglichkeit geben QT- Komponenten in Lazarus zu nutzen würde ich es machen. Evlt. neue hinzufügen. Aber damit müsste ich mich ersteinmal befassen.
Ich glaube von den QT-Komponenten sind doch nur die Komponenten übernommen wurden die auch von den anderen Toolkis kommen oder ?

Mann loest ein paar Probleme damit (owner drawn), aber es gibt auch ein paar neue Probleme. Zb, den Applikation aussehen ändert sich nicht wann das OS theme sich ändert.

naja, man könnte das Problem lösen in dem verschiedene Style anbietet. z.b. ein System Style, der sich Automatisch anpasst.

Natuerlich wirt dann direkt behaupten das die Applikation das bemerken kann, und adaptiert. Aber das ist sehr schwer, und hört nie auf.

Ja ! Das habe ich gemerkt. Wie viele Probleme auf einen zu kommen. Hier noch mal ein großes Lob an Lazarus und FPC das es sowas gibt. Das ist in meinen Augen eine Meisterleistung.

Es gibt schon solch einen versuch. fpgui, und auch MSEGUI ist glaub ich meistens ownerdrawn.

Was meinst du mit onwdrawn ?
Den Soruce-Code von FPGUi habe ich schon angeschaut. in einigen fällen konnte er mir sogar weiter helfen. Ich bin schon lange am überlegen ob und wie ich FPGUI am besten helfen kann. einige Aufgaben müsste ich übernehmen können. Weiß du evlt. mehr oder kennst du jemanden der mehr über FPGUI weiß ?
das meiste dazu finde ich leider nur in englisch. Das kann ich nicht so gut.... Allerdings habe ich noch eine kleine "Scheu" davor mich in FPGUI einzuarbeiten. Weil ich auf der einen seite weiß: eine eigene GUI währe für mich besser, aber auf der anderen seite weiß ich: Logischer währe es ein bestehendes Projekt mit meiner Energie zu helfen. Das beste ist auch noch: Theoretisch dürfte das sogar für mich überhaupt kein Problem sein von meiner Erfahrung her. Es fehlt halt noch der "Anstoß" wenn du weiß was ich mein.

Ich hätte glaube ich vier Möglichkeiten:
01 - Ich erweitere FPGUI und spreche mich mit den FPGUI Entwicklern ob, wenn es die noch gibt
02 - Ich kopiere FPGUI und mache daraus ein weiteres Projekt. Ich würde sagen: Der Kern ist bzw. kommt von FPGUI der rest ist meine eigene Entwicklung oder so ähnlich
03 - Ich schreibe eine komplett eigene GUI, auf der Grundlage von TBitMap und Canvas.
04 - Ich schreibe eine eigene GUI, auf grundlage von TCustomControl, aber das würde mir nicht so gefallen. Weil ich dann nicht mehr freie hand habe....

Zu was würdet ihr mir raten ?Ich nehme an zu "01"

[creed steiger]

Gleich so löst mann das auch fuer Linux. GTK2+QT ist 95%, und das ist genügend.

Bei Gnome/GTK2 vielleicht.
Qt ist aber nicht KDE.Da müssten erst Bindings her um sich an die Themes anpassen zu können.
(Von KDE eigenen Dialogen garnicht zu reden.)

[Christian]

Dont feed the trolls

[KOBOLD Messring GmbH]

Das hab ich noch nicht ganz verstanden:

Bei Gnome/GTK2 vielleicht.
Qt ist aber nicht KDE.Da müssten erst Bindings her um sich an die Themes anpassen zu können.

Wenn ich einfach unter Linux/KDE ein Lazarus-Programm mit GKT2 erstelle, werden sämtliche Theme-Einstellungen übernommen, ich finde die eigenen Lazarus/GKT2-Apps kann man gar nicht von den KDE-eigenen unterscheiden, die höchstwahrscheinlich mit C++ geschrieben wurden, AUSSER die Datei- und Verzeichnis-Dialoge, die sind bei den Lazaraus/GKT2-Apps 100% GTK2-Style.
¿Wo kommen denn die KDE-Dialoge her?
¿gibt's da Bindings, Pascal-Wrapper-Units oder sowas?
¿gibt's überhaupt 'ne Chance an z.B. die Datei-öffnen/speichern-Dialogfenster von KDE ranzukommen und diese in eigenen Lazarus-Pascal-Apps zu verwenden?

[mse]

Es gibt schon solch einen versuch. fpgui, und auch MSEGUI ist glaub ich meistens ownerdrawn.

MSEgui benützt nur gdi32 auf win32 und xlib auf Linux. Skinning beruht in MSEgui hauptsächlich auf tframe und tface. twidget (entspricht in etwa TWinControl) ist die Basis Komponente aller visuellen Elemente. twidget hat eine frame und eine face Eigenschaft, alle Fähigkeiten von tframe und tface stehen also allen twidget Abkömmlingen zur Verfügung. Falls frame oder face nicht benötigt werden, ist die Eigenschaft lediglich ein NIL pointer und braucht keine weitere Resourcen.
tframe kümmert sich um den Rahmen und die Einteilung (client area) des widget. Als Rahmen können etweder schnelle 3D Linien oder langsamere aus pixmaps konstruierte Bilder verwendet werden. tcaptionframe hat die Eigenschaft caption welche zur Beschriftung von widgets verwendet werden kann. Auch scrollbars und Ähnliches wird von tframe Abkömmlingen gezeichnet.
tface kümmert sich um die client area. Dabei können ein Farbverlauf und eine pixmap überlagert werden. Durch die Kombination von tframe und tface sind fast beliebige Darstellungen möglich.

MSEgui skin

skin.png (17.12 KiB) 2202 mal betrachtet

tframe und tface haben die Eigenschaft template womit die Einstellungen "ferngesteuert" werden können. Applikationsweite Einstellungen werden durch tskincontroller vorgenommen.

Martin

[marcov]

Es gibt schon solch einen versuch. fpgui, und auch MSEGUI ist glaub ich meistens ownerdrawn.

Was meinst du mit onwdrawn ?

ownerdraw= Das alle Widgets vom Hand gezeichnet werden, und nicht von externe Bibliotheken (winapi/qt/gtk2) verwaltet werden. Man alloziert ein Flach vom API, und zeichnet darin alles selber. (edit, buttons, scrollbars usw)

Dagegen steht sogenannte "Native" Widgets, wo mann die standard auf System existierende Widgets verwendet.

Die VCL ist meistens ein Nativer Widget library. Lazarus LCL schiebt den entscheidung ab auf den verwendete Widgetset, aber die meisten sind nativ. (nur fpgui nicht)

Ein guter Vorbild von ownerdraw Bibliotheken ist Java Swing. Das sind immer dasselbe aus, und hat ueberall ein "alien" look and feel.,

Den Soruce-Code von FPGUi habe ich schon angeschaut. in einigen fällen konnte er mir sogar weiter helfen. Ich bin schon lange am überlegen ob und wie ich FPGUI am besten helfen kann.

Zuerst muss du dich fragen warum du das machen willst.

einige Aufgaben müsste ich übernehmen können. Weiß du evlt. mehr oder kennst du jemanden der mehr über FPGUI weiß ?
[/quite]

Graham Graeme auf der FPC und Lazarus list.

das meiste dazu finde ich leider nur in englisch. Das kann ich nicht so gut....

Das werde schwierig.

Allerdings habe ich noch eine kleine "Scheu" davor mich in FPGUI einzuarbeiten. Weil ich auf der einen seite weiß: eine eigene GUI währe für mich besser, aber auf der anderen seite weiß ich: Logischer währe es ein bestehendes Projekt mit meiner Energie zu helfen. Das beste ist auch noch: Theoretisch dürfte das sogar für mich überhaupt kein Problem sein von meiner Erfahrung her. Es fehlt halt noch der "Anstoß" wenn du weiß was ich mein.

Ich hätte glaube ich vier Möglichkeiten:
01 - Ich erweitere FPGUI und spreche mich mit den FPGUI Entwicklern ob, wenn es die noch gibt
02 - Ich kopiere FPGUI und mache daraus ein weiteres Projekt. Ich würde sagen: Der Kern ist bzw. kommt von FPGUI der rest ist meine eigene Entwicklung oder so ähnlich
03 - Ich schreibe eine komplett eigene GUI, auf der Grundlage von TBitMap und Canvas.
04 - Ich schreibe eine eigene GUI, auf grundlage von TCustomControl, aber das würde mir nicht so gefallen. Weil ich dann nicht mehr freie hand habe....

Zu was würdet ihr mir raten ?Ich nehme an zu "01"

05 Nutze einfach Lazarus, und vergiss das es etwas wie ownerdraw und fpgui gibt, und investiere den Zeit nutzlich.

Ich mag ownerdraw Systemen nicht besonders(fühlen sich "alien" an, und verhalten sich auch so ) , außer für bestimmte embedded Projekte. Aber dort mag ich mehr dedizierte Loesungen, nicht ein comp

[mse]

Weiß du evlt. mehr oder kennst du jemanden der mehr über FPGUI weiß ?

Graeme Geldenhuys.
[url]NNTP://opensoft.homeip.net/fpgui.support[/url]
[url]NNTP://opensoft.homeip.net/fpgui.development[/url]

[pluto]

Zuerst muss du dich fragen warum du das machen willst.

Wenn du dich auf meine Aussage meinst mit FPGUI: Weil ich das Thema
- interessant finde
- Ich habe schon einige Versuche hinter mir. Somit könnte oder würde ich "arbeit" sparen
.....

05 Nutze einfach Lazarus, und vergiss das es etwas wie ownerdraw und fpgui gibt, und investiere den Zeit nutzlich.

Das währe auch eine Möglichkeit. Diesen weg gehe ich gerade bei meine PLEdit Komponente.

[monta]

¿Wo kommen denn die KDE-Dialoge her?
¿gibt's da Bindings, Pascal-Wrapper-Units oder sowas?
¿gibt's überhaupt 'ne Chance an z.B. die Datei-öffnen/speichern-Dialogfenster von KDE ranzukommen und diese in eigenen Lazarus-Pascal-Apps zu verwenden?

Ich vermute mal, du benutzt eine Distro, wo das GTK2-Theme standardmäßig an das KDE-Theme angepasst ist. Folglich sehen die Komponenten auch weitgehend identisch aus und man kann es nicht unterscheiden. Prinzipiell übernimmt ein GTK2-Programm aber keine KDE/QT Einstellungen sondern die systembedingten GTK2-Konfigurationen, was man natürlich angleichen kann.
An die KDE-Dialoge kommst du folglich auch nicht so einfach ran, es ist und bleibt halt GTK2

Aber du kannst natürlich dein Programm mit QT erstellen...dann hast natürlich auch QT-Dialoge. Die entsprechende Lib dazu gibt es samt Anleitung im Wiki und dann sollte es gehen.

[theo]

¿Wo kommen denn die KDE-Dialoge her?
¿gibt's da Bindings, Pascal-Wrapper-Units oder sowas?
¿gibt's überhaupt 'ne Chance an z.B. die Datei-öffnen/speichern-Dialogfenster von KDE ranzukommen und diese in eigenen Lazarus-Pascal-Apps zu verwenden?

Kurz gesagt: Nein. Die lange Antwort erspare ich uns.