> Und die Widgets von GTK sind nach meinem Geschmack > nicht so bunt wie die von QT (KDE)
Du meinst sicherlich nicht die Widgets an sich, sondern die Art und Weise, wie die Widgets von denjenigen Themes, die Du bisher benutzt hast, gezeichnet werden. Beide genannten Toolkits unterstützen nämlich Themes, die beliebig bunt sein können.
> Was hat dies mit Optik zu tun? > Das ist immer noch Informatik!
Gute UIs haben sehr wohl auch mit Optik zu tun. Allerdings ist es dabei ziemlich egal ob man Qt oder Gtk verwendet, mit dem geeigneten Theme sehen beide ziemlich gleich aus.
Kann mir hier einer sagen, wie man sowas wie dieses Perl/Tk over Qt implementiert? Also in Perl stecken Aufrufe, die die Tk Bibliotheken ansprechen. In den Tk Bibliotheken stecken Aufrufe, die X11 ansprechen. Und jetzt ist die Neuigkeit, dass die Tk Bibliotheken nicht X11 direkt sondern Qt ansprechen!? Richtig?
Aber war es nicht schon immer so, dass wenn ich ein Gtk oder Tk oder sonstwas Programm in KDE starte, ich auch ein KDE Fenster bekomme? Was ist dann das besondere an dieser Entwicklung?
Ich werde immer verwirrter. Ich hoffe jemand kann mir das erklären?
Klingt eher danach daß das nur ein Wrapper ist. Mit den TK-Funktionen wird halt kein TK erzeugt sondern Qt. Sozusagen Qt-Programmierung mit TK Methoden.
Davon mal abgesehen lohnt sich auf jeden Fall ein Blick direkt nach Qt, man kann damit auch in Perl sehr elegant programmieren.
Von QT/Perl-Laie am Mo, 19. Dezember 2005 um 14:02 #
> Also in Perl stecken Aufrufe, die die Tk Bibliotheken ansprechen. Nein, in diesem Fall wird eine Bibliothek angesprochen, die eben nicht eine TK-Bibliothek ist, sondern nur genauso angesprochen werden kann.
> In den Tk Bibliotheken stecken Aufrufe, die X11 ansprechen. Nein, ich glaube, hier hast Du die Schichten verwechselt, X11 liegt unter QT und nicht darüber. Wenn es andersherum wäre, müsste man ja x11 für jedes Embedded-System verwenden, das wäre recht unangenehm was Speicherverbracuh etc angeht.
> Was ist dann das besondere an dieser Entwicklung? Das besondere ist die konsistente Schnittstelle. Man kann mit einem use entweder QT oder tk mit derselben Schnittstelle verwenden, je nach Wahl.
Gibt es eigentlich schon eine native Perl-Schnittstelle für QT (ich glaube sowas nennt man "Perl Binding für QT" oder "QT Binding für Perl") ?
Warum verlinkst Du nicht gleich die eigentliche Projektseite?
http://perlqt.sourceforge.net/
PerlQt ist kein KDE-Projekt. (Qt != KDE)
Auf der Webseite sieht man dann übrigens auch, dass das Projekt nicht gerade lebendig ist.
Außerdem ist das was anderes, diese Sache hier ist nicht weniger nativ (es handelt sich nicht um eine Emulation) und außerdem müsste man bestehende Perl/Tk-Skripte für PerlQt umkrempeln.
Das hier ist einfach eine Nachbildung der Perl/Tk-API mit Qt als Backend, genau wie WINE eine Nachbildung einer gewissen API für POSIX ist.
Von Perl/QT-Laie am Mo, 19. Dezember 2005 um 15:26 #
> Außerdem ist das was anderes, diese Sache hier ist nicht weniger nativ (es handelt sich > nicht um eine Emulation) und außerdem müsste man bestehende Perl/Tk-Skripte für PerlQt > umkrempeln.
Vielleicht ist "nativ" ja der falsche Ausdruck. Aber wenn ich eine TK->QT-Bridge anbiete (so kann man das IMHO auch nennen) dann kann ich naturgemäß nicht alle Features von QT nutzen. Wenn ich ein "natives" binding benutze, kann ich immer alle Features nutzen.
Python hat ja schon in der Standard-Lib eine Tk-Implementierung. Da waere es doch sehr praktisch wenn man da dann gleich auswaehlen kann ob das ganze nicht Qt oder sogar GTK+ zur darstellung nutzt. Dann noch ein kleiner Switch bei der initialisierung der die laufende DE abfragt und man hat eine perfekte Integration
Sowas (oder zumindestens sowas ähnliches) gibt es schon und nennt sich wxWidgets, inklusive Python-Bindings. Bevor man wieder was neues anfängt, wäre es sicherlich effizienter, wxQt zu realisieren (gesprochen wurde darüber auf Mailinglisten, umgesetzt wurde es nie), dann hätte man nämlich auf einen Schlag dasselbe Ergebnis sowohl für Python als auch für C++ und neben GTK und Qt auch noch für eine ganze Reihe weiterer Frameworks.
Leider ist WxWidgets alles andere als angenehm zu programmieren. Ich habe mir zwar nur ein paar Beispiele angesehen, aber was ich gesehen habe, hat mich so verschreckt, dass ich gleich bei gtk (mit einem oop-wrapper ala gtkmm/pygtk/etc.) bleibe.
Das ist halt der Preis, wenn man ein Framework benutzt, das sich auf die größtmögliche Schnittmenge aller möglichen und unmöglichen Plattformen, Compiler, Toolkits usw. beschränkt. Soll aber durch Aufgabe einiger Ports angeblich demnächst besser werden.
Nun haben die das Ding unter einer BSD-artigen Lizenz. Ist das denn so einfach? Was ist wenn ich ein kommerzielles Programm schreiben will, dann muß doch sicherlich eine Qt Lizenz gekauft werden. Muß dann der Entwickler des kommerziellen perl-Programms dieses pq neu kompilieren und gegen sein gekauftes Qt linken, um dann damit das kommerzielle Programm zu entwickeln? Oder wie ist das gedacht?
> Nun haben die das Ding unter einer BSD-artigen Lizenz. > Ist das denn so einfach?
Klar ist es einfach, bloß ist es in der Praxis leider relativ witzlos, weil die Lizenz der darunterliegenden Bibliothek die aller darauf aufbauenden Dinge plattmacht, und zwar unabhängig davon, ob man die GPL-Option oder die kommerzielle Option auswählt.
Die Software hätte genauso gut auch unter dieselbe Lizenz wie Qt gestellt werden können, der Effekt wäre genau derselbe. Dass es anders gemacht wurde, liegt wahrscheinlich daran, dass die Autoren nicht mehr bei Trolltech angestellt sind.
> Was ist wenn ich ein kommerzielles Programm schreiben will, > dann muß doch sicherlich eine Qt Lizenz gekauft werden.
Ja, man kann aber einfach auch "bescheißen", indem man sein Produkt für Perl/Tk ausliefert und ein Installationsskript beilegt, das einfach sämtliche use-Anweisungen während der Installation auf dem Rechner des Benutzers ändert.
"Bescheißen" bedeutet in diesem Zusammenhang übrigens lediglich "die Freiheit 0 in einer Art und Weise nutzen, über die weder die FSF noch Trolltech oder MySQL jemals sprechen werden und die aber trotzdem völlig legal ist."
> Muß dann der Entwickler des kommerziellen perl-Programms > dieses pq neu kompilieren und gegen sein gekauftes Qt linken, > um dann damit das kommerzielle Programm zu entwickeln?
So hätte Trolltech das wohl gerne, so ist es allerdings dank der "Freiheit 0" nicht: Pq gegen GPL-Qt kompilieren, zusammen mit dem Quellcode sowohl von Qt als auch von Pq unter der GPL mitliefern und dann obigen "Beschiss" ausführen, fertig. Das hier ist nämlich ein klassischer Fall für die "Plugin-Klausel" der GPL, unter die Pq ja automatisch fällt, wenn es gegen GPL-Qt gebaut wird.
Ich gehe allerdings davon aus, dass das in der Praxis nicht vorkommen wird, weil viele Leute ihre Rechte nicht umfassend kennen und in diesem Fall interessanterweise auch von niemandem aufgeklärt werden. Es gibt sehr viele Unternehmen, die Qt und MySQL ausschließlich intern benutzen und eigentlich gar keine kommerziellen Lizenzen bräuchten, aber trotzdem welche kaufen.
> Ich gehe allerdings davon aus, dass das in der Praxis nicht vorkommen wird, weil viele Leute ihre Rechte nicht umfassend kennen und in > diesem Fall interessanterweise auch von niemandem aufgeklärt werden. Es gibt sehr viele Unternehmen, die Qt und MySQL ausschließlich > intern benutzen und eigentlich gar keine kommerziellen Lizenzen bräuchten, aber trotzdem welche kaufen.
Sollen sie doch. Ist mir lieber als wenn Trolltech pleite geht. Es geht doch darum daß Entickler und User ihre Rechte abgesteckt bekommen und nicht daß der und der soundsoviel zu bezahlen hat. Es interessiert genau garkeinen wenn in einer großen Firma nun ein paar tausend Euro mehr oder weniger für so eine Entwicklerlizenz bezahlt wird. Wichtig für uns ist ob und wie der Opensource-Entwickler das Zeug nutzen kann.
"Diese nutzt das in Tcl, einer anderen Skriptsprache, implementierte Toolkit Tk"
1) Tk ist in C implementiert. 2) Der Begriff "Skriptsprache" ist mittlerweile etwas veraltet. "Dynamische Sprache" trifft es eher. (Wieso ist "Skriptsprache" veraltet? -- weil heutzutage viele sog. "Skriptsprachen" nicht mehr interpretiert werden ("intepretiert" im Sinne von GWBASIC damals), sondern erst zu irgendeiner Zwischen-Form kompiliert werden (Bytecode, ASTs, etc.). Erst die Zwischen-Formen werden dann ausgeführt; der Sourcecode ist auf der Ebene aber gar nicht mehr vorhanden.
Auch C-Programme können "interpretiert" werden, ist C deswegen eine Skriptsprache?
Laut des Wikipedia-Artikels müssen bei Skriptsprachen Variablen oft nicht deklariert werden. Macht das "kompilierte Sprachen", die ebenfalls auf den Deklarationszwang verzichten, zu Skriptsprachen?
Nicht eine *Sprache* wird "intepretiert" oder "kompiliert" -- es kommt auf die Implementation an.
C kann zu nativen Objektcode kompiliert werden *oder* intepretiert werden.
Was it mit VMs? Was ist mit VMs mit Ahead-of-Time- (AOT) oder Just-in-Time-Kompilierung (JIT)? etc.
"Scripting language" is considered harmful!
Werden C-Programme, wenn sie in einem Emulator ausgeführt werden, interpretiert?
Einfach nur zu sagen "alles, was nicht zu nativem Objektcode kompiliert wird", wird interpretiert, ist veraltet. Der Begriff "Skriptsprache" sollte nicht mehr benutzt werden.
Beispiele:
Perl (eine "Skriptsprache") wird zu einem Abstract Syntax Tree (AST) kompiliert, welcher dann ausgeführt wird.
PHP wird sogar zu Bytecode kompiliert.
Python ebenfalls.
Zu *lisp* gibt es viele viele Implementationen; einige kompilieren zu nativem Code, andere nicht.
Und, laut den anderswo hier geposteten Vorträgen über die nächste Version von Perl, Perl 6, werden bei Perl 6 mehrere Möglichkeiten angeboten: direktes Ausführen in Haskell, Kompilation zu PIR (Parrot Intermediate Representation) und damit auch zu nativem Code, Kompilation zu JavaScript, etc.
Nein ist es möglich qt over gtk zu erlangen?
Da nehme ich doch lieber gleich Perl:Gtk oder Perl:Gnome her, dann stimmt zumindest die Optik.
Das ist immer noch Informatik!
Und die Widgets von GTK sind nach meinem Geschmack nicht so bunt wie die von QT (KDE)
;-)
> nicht so bunt wie die von QT (KDE)
Du meinst sicherlich nicht die Widgets an sich, sondern die Art und Weise, wie die Widgets von denjenigen Themes, die Du bisher benutzt hast, gezeichnet werden. Beide genannten Toolkits unterstützen nämlich Themes, die beliebig bunt sein können.
> Das ist immer noch Informatik!
Gute UIs haben sehr wohl auch mit Optik zu tun.
Allerdings ist es dabei ziemlich egal ob man Qt oder Gtk verwendet, mit dem geeigneten Theme sehen beide ziemlich gleich aus.
Kann mir hier einer sagen, wie man sowas wie dieses Perl/Tk over Qt implementiert?
Also in Perl stecken Aufrufe, die die Tk Bibliotheken ansprechen.
In den Tk Bibliotheken stecken Aufrufe, die X11 ansprechen.
Und jetzt ist die Neuigkeit, dass die Tk Bibliotheken nicht X11 direkt sondern Qt
ansprechen!? Richtig?
Aber war es nicht schon immer so, dass wenn ich ein Gtk oder Tk oder sonstwas Programm
in KDE starte, ich auch ein KDE Fenster bekomme?
Was ist dann das besondere an dieser Entwicklung?
Ich werde immer verwirrter. Ich hoffe jemand kann mir das erklären?
alter Mann
Davon mal abgesehen lohnt sich auf jeden Fall ein Blick direkt nach Qt, man kann damit auch in Perl sehr elegant programmieren.
http://search.cpan.org/src/GGARAND/PerlQt-3.008/doc/en/index.html
Nein, in diesem Fall wird eine Bibliothek angesprochen, die eben nicht eine TK-Bibliothek ist, sondern nur genauso angesprochen werden kann.
> In den Tk Bibliotheken stecken Aufrufe, die X11 ansprechen.
Nein, ich glaube, hier hast Du die Schichten verwechselt, X11 liegt unter QT und nicht darüber. Wenn es andersherum wäre, müsste man ja x11 für jedes Embedded-System verwenden, das wäre recht unangenehm was Speicherverbracuh etc angeht.
> Was ist dann das besondere an dieser Entwicklung?
Das besondere ist die konsistente Schnittstelle. Man kann mit einem use entweder QT oder tk mit derselben Schnittstelle verwenden, je nach Wahl.
Gibt es eigentlich schon eine native Perl-Schnittstelle für QT (ich glaube sowas nennt man "Perl Binding für QT" oder "QT Binding für Perl") ?
> (ich glaube sowas nennt man "Perl Binding für QT" oder "QT Binding für Perl") ?
Ja, wirf mal einen Blick auf diese Übersicht: http://developer.kde.org/language-bindings/
http://perlqt.sourceforge.net/
PerlQt ist kein KDE-Projekt. (Qt != KDE)
Auf der Webseite sieht man dann übrigens auch, dass das Projekt nicht gerade lebendig ist.
Außerdem ist das was anderes, diese Sache hier ist nicht weniger nativ (es handelt sich nicht um eine Emulation) und außerdem müsste man bestehende Perl/Tk-Skripte für PerlQt umkrempeln.
Das hier ist einfach eine Nachbildung der Perl/Tk-API mit Qt als Backend, genau wie WINE eine Nachbildung einer gewissen API für POSIX ist.
> nicht um eine Emulation) und außerdem müsste man bestehende Perl/Tk-Skripte für PerlQt
> umkrempeln.
Vielleicht ist "nativ" ja der falsche Ausdruck. Aber wenn ich eine TK->QT-Bridge anbiete (so kann man das IMHO auch nennen) dann kann ich naturgemäß nicht alle Features von QT nutzen. Wenn ich ein "natives" binding benutze, kann ich immer alle Features nutzen.
Naja, er ist aber auch fertig geworden damit.
> In den Tk Bibliotheken stecken Aufrufe, die X11 ansprechen.
Du hast da deine normale Schnittstelle die irgendwo dann Funktionen aufruft. Ob das jetzt Tk, Qt oder GTK+ ist, kann dir als Programmierer egal sein.
> Aber war es nicht schon immer so, dass wenn ich ein Gtk oder Tk
> oder sonstwas Programm in KDE starte, ich auch ein KDE Fenster bekomme?
Nein, der Fensterrahmen und seine Eigenschaften kommen vom Windowmanager,
der Inhalt des Fensters ist dagegen Variabel.
> Ist das denn so einfach?
Klar ist es einfach, bloß ist es in der Praxis leider relativ witzlos, weil die Lizenz der darunterliegenden Bibliothek die aller darauf aufbauenden Dinge plattmacht, und zwar unabhängig davon, ob man die GPL-Option oder die kommerzielle Option auswählt.
Die Software hätte genauso gut auch unter dieselbe Lizenz wie Qt gestellt werden können, der Effekt wäre genau derselbe. Dass es anders gemacht wurde, liegt wahrscheinlich daran, dass die Autoren nicht mehr bei Trolltech angestellt sind.
> Was ist wenn ich ein kommerzielles Programm schreiben will,
> dann muß doch sicherlich eine Qt Lizenz gekauft werden.
Ja, man kann aber einfach auch "bescheißen", indem man sein Produkt für Perl/Tk ausliefert und ein Installationsskript beilegt, das einfach sämtliche use-Anweisungen während der Installation auf dem Rechner des Benutzers ändert.
"Bescheißen" bedeutet in diesem Zusammenhang übrigens lediglich "die Freiheit 0 in einer Art und Weise nutzen, über die weder die FSF noch Trolltech oder MySQL jemals sprechen werden und die aber trotzdem völlig legal ist."
> Muß dann der Entwickler des kommerziellen perl-Programms
> dieses pq neu kompilieren und gegen sein gekauftes Qt linken,
> um dann damit das kommerzielle Programm zu entwickeln?
So hätte Trolltech das wohl gerne, so ist es allerdings dank der "Freiheit 0" nicht: Pq gegen GPL-Qt kompilieren, zusammen mit dem Quellcode sowohl von Qt als auch von Pq unter der GPL mitliefern und dann obigen "Beschiss" ausführen, fertig. Das hier ist nämlich ein klassischer Fall für die "Plugin-Klausel" der GPL, unter die Pq ja automatisch fällt, wenn es gegen GPL-Qt gebaut wird.
Ich gehe allerdings davon aus, dass das in der Praxis nicht vorkommen wird, weil viele Leute ihre Rechte nicht umfassend kennen und in diesem Fall interessanterweise auch von niemandem aufgeklärt werden. Es gibt sehr viele Unternehmen, die Qt und MySQL ausschließlich intern benutzen und eigentlich gar keine kommerziellen Lizenzen bräuchten, aber trotzdem welche kaufen.
> diesem Fall interessanterweise auch von niemandem aufgeklärt werden. Es gibt sehr viele Unternehmen, die Qt und MySQL ausschließlich
> intern benutzen und eigentlich gar keine kommerziellen Lizenzen bräuchten, aber trotzdem welche kaufen.
Sollen sie doch. Ist mir lieber als wenn Trolltech pleite geht. Es geht doch darum daß Entickler und User ihre Rechte abgesteckt bekommen und nicht daß der und der soundsoviel zu bezahlen hat. Es interessiert genau garkeinen wenn in einer großen Firma nun ein paar tausend Euro mehr oder weniger für so eine Entwicklerlizenz bezahlt wird. Wichtig für uns ist ob und wie der Opensource-Entwickler das Zeug nutzen kann.
1) Tk ist in C implementiert.
2) Der Begriff "Skriptsprache" ist mittlerweile etwas veraltet. "Dynamische Sprache" trifft es eher. (Wieso ist "Skriptsprache" veraltet? -- weil heutzutage viele sog. "Skriptsprachen" nicht mehr interpretiert werden ("intepretiert" im Sinne von GWBASIC damals), sondern erst zu irgendeiner Zwischen-Form kompiliert werden (Bytecode, ASTs, etc.). Erst die Zwischen-Formen werden dann ausgeführt; der Sourcecode ist auf der Ebene aber gar nicht mehr vorhanden.
Auch C-Programme können "interpretiert" werden, ist C deswegen eine Skriptsprache?
Laut des Wikipedia-Artikels müssen bei Skriptsprachen Variablen oft nicht deklariert werden. Macht das "kompilierte Sprachen", die ebenfalls auf den Deklarationszwang verzichten, zu Skriptsprachen?
Nicht eine *Sprache* wird "intepretiert" oder "kompiliert" -- es kommt auf die Implementation an.
C kann zu nativen Objektcode kompiliert werden *oder* intepretiert werden.
Was it mit VMs? Was ist mit VMs mit Ahead-of-Time- (AOT) oder Just-in-Time-Kompilierung (JIT)? etc.
"Scripting language" is considered harmful!
Werden C-Programme, wenn sie in einem Emulator ausgeführt werden, interpretiert?
Einfach nur zu sagen "alles, was nicht zu nativem Objektcode kompiliert wird", wird interpretiert, ist veraltet. Der Begriff "Skriptsprache" sollte nicht mehr benutzt werden.
Beispiele:
Vielen Dank für Ihre Aufmerksamkeit