Login
Newsletter
Werbung

Thema: Qt-Implementation von Perl/Tk vorgestellt

31 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von gtkmm am Mo, 19. Dezember 2005 um 13:05 #
interessant wirds doch erst bei einer Perl/Tk-over-Qt-over-GTK+-Implementation
[
| Versenden | Drucken ]
  • 0
    Von ;-) am Mo, 19. Dezember 2005 um 15:50 #
    Und kann man dann wieder zurück zu QT kommen?
    Nein ist es möglich qt over gtk zu erlangen?
    [
    | Versenden | Drucken ]
    • 0
      Von wer am Mo, 19. Dezember 2005 um 16:09 #
      Ich erinnere mich, daß es ein "gtk+ on Qt" gibt. Aber von einem "QT on GTK" wüßte ich nicht.
      [
      | Versenden | Drucken ]
    0
    Von Name tut nichts zur Sache am Mo, 19. Dezember 2005 um 17:54 #
    Hualp!

    Da nehme ich doch lieber gleich Perl:Gtk oder Perl:Gnome her, dann stimmt zumindest die Optik.

    [
    | Versenden | Drucken ]
    • 0
      Von ;-) am Mo, 19. Dezember 2005 um 18:35 #
      Was hat dies mit Optik zu tun?
      Das ist immer noch Informatik!

      Und die Widgets von GTK sind nach meinem Geschmack nicht so bunt wie die von QT (KDE)

      ;-)

      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Mo, 19. Dezember 2005 um 19:00 #
        > 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.

        [
        | Versenden | Drucken ]
        0
        Von panzi am Di, 20. Dezember 2005 um 01:12 #
        Na, Pearl ist doch ein Optiker! ;)
        [
        | Versenden | Drucken ]
        0
        Von Name tut nichts zur Sache am Di, 20. Dezember 2005 um 09:45 #
        Ganz einfach - den Code, der entsteht, wenn Du GUIs in Perl baust, willst Du nicht wirklich sehen!
        [
        | Versenden | Drucken ]
        0
        Von TBO am Di, 20. Dezember 2005 um 10:17 #
        > 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.

        [
        | Versenden | Drucken ]
0
Von alterMann am Mo, 19. Dezember 2005 um 13:46 #
Hallo Leute,

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

[
| Versenden | Drucken ]
  • 0
    Von em am Mo, 19. Dezember 2005 um 13:55 #
    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.

    http://search.cpan.org/src/GGARAND/PerlQt-3.008/doc/en/index.html

    [
    | Versenden | Drucken ]
    0
    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") ?

    [
    | Versenden | Drucken ]
    • 0
      Von cm am Mo, 19. Dezember 2005 um 15:00 #
      > 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") ?

      Ja, wirf mal einen Blick auf diese Übersicht: http://developer.kde.org/language-bindings/

      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Mo, 19. Dezember 2005 um 15:10 #
        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.

        [
        | Versenden | Drucken ]
        • 0
          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.

          [
          | Versenden | Drucken ]
          0
          Von em am Mo, 19. Dezember 2005 um 17:11 #
          > Auf der Webseite sieht man dann übrigens auch, dass das Projekt nicht gerade lebendig ist.
          Naja, er ist aber auch fertig geworden damit.
          [
          | Versenden | Drucken ]
    0
    Von Chaoswind am Mo, 19. Dezember 2005 um 14:13 #
    > Also in Perl stecken Aufrufe, die die Tk Bibliotheken ansprechen.
    > 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.

    [
    | Versenden | Drucken ]
0
Von Chaoswind am Mo, 19. Dezember 2005 um 14:09 #
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 :)
[
| Versenden | Drucken ]
  • 0
    Von G. W. am Mo, 19. Dezember 2005 um 15:05 #
    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.
    [
    | Versenden | Drucken ]
    • 0
      Von Anonymus am Mo, 19. Dezember 2005 um 15:50 #
      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.
      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Mo, 19. Dezember 2005 um 16:01 #
        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.
        [
        | Versenden | Drucken ]
0
Von em am Mo, 19. Dezember 2005 um 18:40 #
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?
[
| Versenden | Drucken ]
  • 0
    Von G. W. am Mo, 19. Dezember 2005 um 19:16 #
    > 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.

    [
    | Versenden | Drucken ]
    • 0
      Von em am Mo, 19. Dezember 2005 um 20:22 #
      > 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.

      [
      | Versenden | Drucken ]
mehr ehm
0
Von tom am Mo, 19. Dezember 2005 um 19:09 #
"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.

[
| Versenden | Drucken ]
  • 0
    Von XXX am Mo, 19. Dezember 2005 um 23:52 #
    http://de.wikipedia.org/wiki/Skriptsprache
    [
    | Versenden | Drucken ]
    • 0
      Von thomas001 am Di, 20. Dezember 2005 um 00:40 #
      lisp ist also ne scriptsprache? o_O
      [
      | Versenden | Drucken ]
      0
      Von tom am So, 1. Januar 2006 um 23:29 #
      Der Wikipedia-Artikel ist in großen Zügen falsch.

      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.

      Vielen Dank für Ihre Aufmerksamkeit ;)

      [
      | Versenden | Drucken ]
0
Von Bernie am Di, 20. Dezember 2005 um 12:29 #
Wenn es jetzt noch einen Port fuer TclTk gaebe, waere das super!
[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung