Erfahrungen und Meinungen zu Python GUI-Toolkits gewünscht

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

PmanX hat geschrieben:Gibt es einige Widgets, die man in pyGTK vermißt?
Die nötigsten Widgets sind natürlich da - wenn dir ein bestimmtes spezifisches Widget fehlst, kannst du es selbst schreiben. Dazu gibt es Anleitungen, ist also etwas mehr Arbeit aber keine Unmöglichkeit.

Ja, wxPython hat definitiv mehr Widgets, aber die PyGTK-Demo muss ja nicht alle Widgets von PyGTK demonstrieren, also ist sie als Zählgrundlage ungeeignet.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Groucho
User
Beiträge: 9
Registriert: Donnerstag 15. Februar 2007, 14:44

@Gerold:

Wenn ich frühere Beiträge im Forum ansehe, dann hast Du ursprünglich mit pyGTK begonnen und bist dann auf wxPython umgestiegen.

Kannst Du etwas dazu schreiben, welche Gründe oder Erfahrungen Dich zu dem Umstieg bewogen haben?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

PmanX hat geschrieben:Gibt es einige Widgets, die man in pyGTK vermißt?
Hi PmanX!

- Eine einfach zu verwendende ListBox
- Eine InputBox
- Ein besser FileDialog (öffnen, speichern, ...)
- Ein Tabellen-Widget (wie bei Excel)

Mehr fällt mir jetzt nicht ein. Wie geschrieben, setze ich pyGTK ja nicht mehr ein.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

Ohauerha.. Bevor das ausartet...:

Meiner Meinung nach, können die wenigsten doch wirklich seriös sagen, ob nun X besser ist als Y... Man entscheidet sich in der Regel irgendwann für eines der beiden und hatte damals Gründe dafür, aber aktive Projekte entwickeln sich oft so schnell weiter, dass man dann gar nicht mehr sagen kann, ob die Gründe mittlerweile nicht obsolet sind.... Wer macht sich denn die Mühe nachher noch in regelmäßigen Zeitabständen seine Entscheidung neu in Hinblick auf die aktuelle Situation auf den Prüfstand zu stellen?

Das ist wahrlich nicht nur bei den GUI-Frameworks so...
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

oliver1974 hat geschrieben:Ohauerha.. Bevor das ausartet...:

Meiner Meinung nach, können die wenigsten doch wirklich seriös sagen, ob nun X besser ist als Y...
...
Dieses Thema dient mir als Entscheidungshilfe, auch wenn ich schon eine kleine Bevorzugung habe.
Allumfassend wird nicht entschieden. Pros/Kontras gegeneinander abwägen und einen Entscheidung
treffen die möglichst lange vorteilhaft ist.
Man will kein Narr von Hause aus sein ;)
Zuletzt geändert von PmanX am Donnerstag 15. März 2007, 17:28, insgesamt 1-mal geändert.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Hi Gerold.

Ok, da gebe ich dir Recht. wxPython in Action ist wohl die Referenz (Hab nur gutes darüber gehört). Leider ist das komplett in Englisch und da mein Englisch nicht besonders gut ist, habe ich mir das dann auch nicht gekauft -- Durch englische Literatur kann ich mich auch im Web durchquälen und muss dafür nicht auch noch viel Geld ausgeben. Naja, bisher kam ich auch so an meine Informationen durch google, hier im erstklassigen Forum, durch die wxPython Demo und mit 80% ausprobieren.

Zur Demo von wxPython kann ich auch nur sagen das es erstklassig ist.
gerold hat geschrieben:
sape hat geschrieben:wx.AcceleratorTable
Die Verwendung der ``wx.AcceleratorTable`` ist ein Fall, wo man nicht um die Verwendung von IDs herum kommt.
Schade, hätte ja sein können das du dazu auch ein Tipp hast. Den ich finde deine Möglichkeit mit dem wegfallen von IDs bei wxMenu nämlich Super und kannte das bisher nicht, da in der wxPython Demo auch IDs dafür benutzt benutzt werden.
gerold hat geschrieben:
sape hat geschrieben:Ich finde nicht, das man sich dann eine eigene Schreibkonvention anlegen sollte **nur** damit man nicht ausersehen eine Methode überschreibt.
Da bin ich deiner Meinung. Ich sage nur, dass ich mich beim Programmieren an PEP-8 halte. Dieser bleibe ich treu und werde nicht wegen einem anderen Styleguide, der mich persönlich total abschreckt, groß von PEP-8 abweichen. Der wxPython-Styleguide sollte eigentlich in die wxPython-Dev-Rubrik verschoben werden und nicht direkt von der Startseite aus zugänglich sein. Dieser wxPython-Styleguide macht mehr kaputt als gut. Dieser Stuileguide ist zu sehr an die Schreibweise der C++-Methoden angelehnt und zu weit von Python entfernt.
Ok, von dieser Sicht aus betrachtet ist das ein sehr gutes Argument und werde ich mir daher auch nochmal durch den Kopf gehen lassen. Den glaube mir, ich habe sehr lange darüber nachgedacht nach welche Styleguide ich meine GUIs programmiere. Den von euch kamen damals **das für** mit PEP-8 und ich denke die Argumente sollte man dann auch konsequent weiterführen und für andere Sachen keine Ausnahme machen. Aber wie gesagt, ich werde darüber noch mal nachdenken.
gerold hat geschrieben:
sape hat geschrieben:
gerold hat geschrieben:Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen.
Nein macht es nicht!
Niemand wird mich davon abhalten. Ich programmiere jetzt seit 21 Jahren und habe meinen Stil immer wieder angepasst, um besseren, durchschaubareren und wartbareren Code zu produzieren. -- Nach meiner Erfahrung, gibt es absolut keinen Grund für mich, einen Event-Handler besonders zu kennzeichnen. Es genügt, wenn als zweiter Parameter ``event`` erwartet wird. Im Gegenteil! Bei vielen Programmen, hat man nur mehr Schreibarbeit und absolut keinen Zusatznutzen. Was bringt es mir zehn Event-Handler zu schreiben, die nichts anderes tun, als eine einzige Methode aufzurufen. Da schreibe ich diese einzelne Methode doch lieber so um, dass diese als Event-Handler verwendet werden kann, als dass ich zig Methoden erzeuge, deren einziger Zweck eine Weiterleitung zur richtigen Methode ist! Wenn es auch nur ansatzweise mehr Durchschaubarkeit des Codes bringen würde, dann würde ich es machen, aber nachdem ich beide Schreibweisen ausprobiert und abgewägt habe, bleibe ich bei meiner Aussage, dass besonders benannte Event-Handler (z.B. OnCloseWidget1 oder OnClickButton2) keinen zusätzlichen Vorteil bringen.
Ok, da gebe ich dir teils Recht. Aber was machst du bei "richtigen" Eventmethoden die auch auf den Parameter ``event`` zurückgreifen und dort kein ``None`` erwarten sondern z.B. ein angeklicktes item von ``wx.ListCtrl``? Solch eine Methode ist dann nur in Verbindung mit einem vom Programm generierten Event benutzbar oder wenn man selber ein Event explizit generiert und es der Methode übergibt. Wegen diesem nicht sofort ersichtlichen Zustand, habe ich es mir angewöhnt meine Eventmethoden auch besonder zu kennzeichnen (Und ich benutze halt die "Auszeichnung" auf die sich alle geeinigt haben.). Und wenn eben eine Funktionalität unabhängig von einem Event genutzt werden kann, schreibe ich eine Methode dafür. Falls ich diese Methode halt auch im Event benötige, kommt es halt in eine ``On``-Event Methode rein. Damit komme ich am besten klar und finde es für mich übersichtlicher.
gerold hat geschrieben:
sape hat geschrieben:Wenn ich eine Methode habe die auch so benutzt werden kann und von einem Event, dann schreibe ich die Methode z.B. ``FillBooklist``. So wenn nun ein Event auch dafür zuständig sein soll, da schreibe ich eine Eventmethode die ``FillBooklist`` aufruft.
Es hindert dich ja niemand daran. ;-)
Nein :)
gerold hat geschrieben:
sape hat geschrieben:Um eine Analogie herbeizuführen: Keiner Benutzt "Private"-Methoden (_ und __ am Anfang) oder? Genauso verhält es sich auch mit einer Eventmethode...
Den verstehe ich nicht.
Naja, sagen wir es mal so: Die meisten fassen ja Methoden/etc die mit einem unterstrich oder zwei unterstrichen beginne nicht an, weil es suggerieren soll das es privat ist und nur für interner relevant ist. Bei Eventmethoden verhält es sich "ähnlich" (Ok, die Analogie hinkt ein wenig).

Die Konvention sagt, das man eine Eventmethode nur explizit aufrufen sollte, wenn man dem Event-Parameter auch ein Event übergibt:
Beispiel:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os

os.path
import wx
wx.SetDefaultPyEncoding("utf-8")


class WidgetFoobar(wx.Panel):
    def __init__(self, parent):
        wx.Panel.__init__(self, parent)
        
        self.textCtrl = wx.TextCtrl(self, -1, "", size=(300, -1))
        self.Bind(wx.EVT_TEXT, self.OnTextCtrlEdit, self.textCtrl)
        
        vbox = wx.BoxSizer(wx.VERTICAL)
        vbox.Add(self.textCtrl, 0, wx.EXPAND|wx.ALL, 5)
        self.SetSizer(vbox)
    
    def OnTextCtrlEdit(self, event):
        return self.textCtrl.GetValue()
        

class MainFrame(wx.Frame):
    def __init__(self, parent=None, id=-1, title = "MyApp"):
        wx.Frame.__init__(self, parent, id, title)
        self.Centre()
        self.panel = wx.Panel(self)
        self.widgetFoobar = WidgetFoobar(self.panel)
        self.widgetFoobar.Bind(wx.EVT_TEXT, self.OnTextCtrlEdit)
        
    def OnTextCtrlEdit(self, event):
        # Ist OK, da ich die Eventmethode mit einem Event aufrufe.
        # In dem Fall leite ich das Event nur um.
        value =  self.widgetFoobar.OnTextCtrlEdit(event)
        print value
        # Sonstiges mit dem aufgefangen wert machen...
    
def main():
    app = wx.PySimpleApp()
    mf =  MainFrame()
    mf.Show()
    app.MainLoop()

if __name__ == "__main__":
    main()
Nun z.B. eine Eventmethode zu schreiben die man auch so ohne Event aufrufen kann, z.B. mit None, ist eigentlich unkonventionell und es wird auch abgeraten solche "Eigeartigen" Methoden zu schreiben, da sie das "Bild" inkonsistent machen (Den jeder assoziert mit dem "On" das es sich um eine Eventmethode handelt und wird ziemlich verwirt sein wenn sich das anders verhält als der Konvention entsprechend.)
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

gerold hat geschrieben: Mit "schneller" meine ich, dass wxPython-Programme unter Windows spürbar schneller laufen als pyGTK-Programme. Das gilt aber nur für Windows. Da bei Linux bei wxPython-Programmen eine zusätzliche Abstraktionsschickt zwischen GTK und dem geschriebenen Programm liegt, kann ein wxPython-Programm unter Linux nicht schneller sein als ein pyGTK-Programm. Es ist wahrscheinlich langsamer, aber das kann ich nur ahnen, denn merken tu ich nichts davon.
Und das ist bei Windows anders? Auch bei Windows ist eine Abstraktionsschicht dazwischen. wxWidget wrappt eigentlich die GUI-API des jeweiligen OS und stellt somit die Abstraktionsschicht dar.

http://de.wikipedia.org/wiki/Wxwidgets
wxWidgets abstrahiert plattformnative Funktionalitäten, wie z.B. die IPC-Klassen, oder implementiert fehlende Komponenten, wie z.B. die Baumkomponente (engl. treecontrols). Einige Funktionen wie z.B. wxMetafile oder OLE werden notgedrungen für die Plattform einzeln in wxWidgets implementiert. Für bessere Portabilität verzichtet wxWidgets auf Ausnahmen (exceptions) oder Templates. Die API umfasst über 450 Klassen mit über 5000 Funktionen. Wichtigste Funktionalitäten decken folgende Bereiche ab:
wxWidgets ist also lediglich ein "Wrapper".

Das wxPython Applikationen unter GTK "langsamer" laufen liegt mit daran das, GNOME auch spürbar(?) langsamer ist als z.B. Windows (Das ging ja aus der Diskussion bei meiner Umfrag heraus, ob ich Ubuntu, Kubuntu, etc nehmen soll.).

Das nun aber GTK-Programme auf Windows langsamer laufen als auf Linux, liegt nur daran das zwischen den GTK und Windows ein Wrapper ist, der bei Linux weg fällt. Wenn man dan pyGTK nutzt hat man es da mit zwei wrappern zu tun. Einmal den GTK und dann den Wrapper von Python auf GTK(pyGTK). Ist dann logisch das pyGTK nochmal langsame ist auf Windows. Aber ob das ganze sehr spürbar langsam ist bezweifele ich;) [1]


[1]Ich hoffe das ich nun kein scheiß erzähle mit dem GTK @ Windows. Hab das so gehört :)
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Leonidas hat geschrieben:
sape hat geschrieben:-- Passt sich dem nativen Look des Betriebssystemes an. Kann pyGTK nicht (Und ist auch nich deren Konzept). Eine in pyGTK geschriebene Anwendung sieht auf Linux genauso aus wie auf Windows. Den Look kann man aber durch Themes beeinflussen.
Das ist doch Quatsch. PyGTK kann über die Wimp-Engine ebenso den Nativen Windows-Look haben wie jedes andere Programm. Und ja, sie kommt auch wunderbar mit Themes aus, wie die die von Windows XP genutzt werden.
Ja und in wie fern widerspricht das meiner Aussage? Klar können GTK Programme @ Windows den Loock von Windows mit den entsprechenden theme annehmen. Das man den Look über Themes ändern kann habe ich ja geschrieben und jeder der GTK kennt weiß auch das es ein Windows Theme gibt. Daher weiß ich nicht wo meine aussage quatsch sein sol, weil es passt sich ja nicht dem nativen OS Look an, sondern wird über die themes bestimmt, wo es zufällig eines gibt das wie Windows aussieht.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

oliver1974 hat geschrieben:Ohauerha.. Bevor das ausartet...:

Meiner Meinung nach, können die wenigsten doch wirklich seriös sagen, ob nun X besser ist als Y... Man entscheidet sich in der Regel irgendwann für eines der beiden und hatte damals Gründe dafür, aber aktive Projekte entwickeln sich oft so schnell weiter, dass man dann gar nicht mehr sagen kann, ob die Gründe mittlerweile nicht obsolet sind.... Wer macht sich denn die Mühe nachher noch in regelmäßigen Zeitabständen seine Entscheidung neu in Hinblick auf die aktuelle Situation auf den Prüfstand zu stellen?

Das ist wahrlich nicht nur bei den GUI-Frameworks so...
Full Ack. Das ist beisher die Objektivste aussag in diesem Thread. Den Ich und gewiss auch die anderen hier haben bestimmt schon seit langen nicht zur "Konkurrenz" geschaut um zu sehen was sich geändert hat.

Ich denke deiner Aussage kann man nichts mehr hinzufügen und daher würde ich einfach sagen: Teste es selbst und macht euch eure eigenes Bild ,bevor es hier zur Flammware wie mit den Web-Frameworks-Threads ausartet!
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

sape hat geschrieben:...
Ich denke deiner Aussage kann man nichts mehr hinzufügen und daher würde ich einfach sagen: Teste es selbst und macht euch eure eigenes Bild ,bevor es hier zur Flammware wie mit den Web-Frameworks-Threads ausartet!
Auseinandersetzungen müssen nicht degenerieren :!:
Warum soll jeder das Rad neu erfinden? Der Vorteil einer Community ist der Erfahrungsaustausch.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

sape hat geschrieben:Aber was machst du bei "richtigen" Eventmethoden die auch auf den Parameter ``event`` zurückgreifen und dort kein ``None`` erwarten sondern z.B. ein angeklicktes item von ``wx.ListCtrl``?
[...]
Wegen diesem nicht sofort ersichtlichen Zustand, habe ich es mir angewöhnt meine Eventmethoden auch besonder zu kennzeichnen
[...]
Damit komme ich am besten klar und finde es für mich übersichtlicher.
Hi sape!

Für mich ist das kein Problem! Diese Methoden heißen dann z.B. so:

Code: Alles auswählen

on_mylistctl_click(self, event)
und bekommen keinen Standardwert für ``event`` übergeben. :P

Dass du lieber zu 100% mit besonders benannten Event-Handlern arbeitest, das ist dein gutes Recht und das sollte dir niemand nehmen. Ich arbeite halt nicht zu 100% mit besonders benannten Event-Handlern, sondern nur dann, wenn ich ein besonderes Event-Objekt als Argument erwarte und damit arbeiten muss. Beides hat seine Vorteile. Bei dir ist es die Kontinuität und bei mir ist es der gesparte Schreibaufwand.

lg
Gerold
:-)
Zuletzt geändert von gerold am Donnerstag 15. März 2007, 17:50, insgesamt 2-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

PmanX hat geschrieben:Auseinandersetzungen müssen nicht degenerieren :!:
Ist wünschenswert.
PmanX hat geschrieben: Warum soll jeder das Rad neu erfinden? Der Vorteil einer Community ist der Erfahrungsaustausch.
Ack.
Benutzeravatar
mq
User
Beiträge: 124
Registriert: Samstag 1. Januar 2005, 19:14

Leonidas hat geschrieben:Das ist doch Quatsch. PyGTK kann über die Wimp-Engine ebenso den Nativen Windows-Look haben wie jedes andere Programm. Und ja, sie kommt auch wunderbar mit Themes aus, wie die die von Windows XP genutzt werden.
Es wundert mich wie lange das PyGTK noch vorgeworfen wird.
Weisst du zufaelligerweise, wie das auf OS X aussieht?
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

lumax hat geschrieben:
Leonidas hat geschrieben:Das ist doch Quatsch. PyGTK kann über die Wimp-Engine ebenso den Nativen Windows-Look haben wie jedes andere Programm. Und ja, sie kommt auch wunderbar mit Themes aus, wie die die von Windows XP genutzt werden.
Es wundert mich wie lange das PyGTK noch vorgeworfen wird.
Weisst du zufaelligerweise, wie das auf OS X aussieht?
Dafür gibt es auch ein Theme. http://art.gnome.org/themes/gtk2/1329

Keine Ahnung ob es aber alles abdeckt. Habe kein Mac.

€: http://art.gnome.org/themes/gtk2/?page= ... order=DESC
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

oliver1974 hat geschrieben:Ohauerha.. Bevor das ausartet...:
[...]
aktive Projekte entwickeln sich oft so schnell weiter, dass man dann gar nicht mehr sagen kann, ob die Gründe mittlerweile nicht obsolet sind...
Hi oliver1974!

Zum ersten Punkt:
Solange jeder akzeptiert, dass andere anderer Meinung sein können und man nur mit gut gemeinten Worten versucht, die anderen von der eigenen Meinung zu überzeugen, wird eine Diskussion nicht ausarten. Eine Diskussion artet dann aus, wenn man nicht akzeptiert, dass andere anderer Meinung sein können und dass andere auch eventuell recht haben könnten.

Zum zweiten Punkt:
Die Hauptgründe für meinen Wechsel zu wxPython waren: mehr Komfort für den Programmierer und bessere Geschwindigkeit unter Windows. Bei beiden Gründen ist wxPython pyGTK immer noch weit voraus. (Wobei "mehr Komfort" so von mir gefühlt wird. Das kann ich jetzt nicht beweisen.)

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
mq
User
Beiträge: 124
Registriert: Samstag 1. Januar 2005, 19:14

sape hat geschrieben:
lumax hat geschrieben:
Leonidas hat geschrieben:Das ist doch Quatsch. PyGTK kann über die Wimp-Engine ebenso den Nativen Windows-Look haben wie jedes andere Programm. Und ja, sie kommt auch wunderbar mit Themes aus, wie die die von Windows XP genutzt werden.
Es wundert mich wie lange das PyGTK noch vorgeworfen wird.
Weisst du zufaelligerweise, wie das auf OS X aussieht?
Dafür gibt es auch ein Theme. http://art.gnome.org/themes/gtk2/1329

Keine Ahnung ob es aber alles abdeckt. Habe kein Mac.

€: http://art.gnome.org/themes/gtk2/?page= ... order=DESC
Ich will kein Theme, dass so aussieht wie Aqua (oder es versucht, wirklich so auszusehen, hat noch keins geschafft). Ich will wissen, ob es 'ne Engine gibt, mit der der Kram unter OS X ueber die nativen Widgets rendert (wie das laut Leonidas bei Windows/Wimp der Fall ist).
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

lumax, dann habe ich euch beide vollkommen falsch verstanden. Ich dachte die Themes wäre damit gemeint gewesen. :?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sape hat geschrieben:Ja und in wie fern widerspricht das meiner Aussage? Klar können GTK Programme @ Windows den Loock von Windows mit den entsprechenden theme annehmen. Das man den Look über Themes ändern kann habe ich ja geschrieben und jeder der GTK kennt weiß auch das es ein Windows Theme gibt. Daher weiß ich nicht wo meine aussage quatsch sein sol, weil es passt sich ja nicht dem nativen OS Look an, sondern wird über die themes bestimmt, wo es zufällig eines gibt das wie Windows aussieht.
Stimmt eben nicht. Die Wimp-Engine rendert die Widgets über die Nativen Widgets und diese haben den Stil der auch von anderen "nativen" Programmen benutzt wird.
Das was du beschreibst sind Themes. Wimpose war so ein Theme, welches Windows nachbaute aber Wimp ist wesentlich mehr. Themes git es natürlich weiterhin, die kannst du in GTK ebenso nutzen.

Es gibt sogar eine Engine die GTK mit Qt-Widgets laufen lässt. Damit sehen GTK-Programme aus wie native KDE/Qt-Programme.
Von diesen Engines profitieren natürlich sowohl PyGTK als auch wxGTK.
sape hat geschrieben:Das nun aber GTK-Programme auf Windows langsamer laufen als auf Linux, liegt nur daran das zwischen den GTK und Windows ein Wrapper ist, der bei Linux weg fällt. Wenn man dan pyGTK nutzt hat man es da mit zwei wrappern zu tun. Einmal den GTK und dann den Wrapper von Python auf GTK(pyGTK). Ist dann logisch das pyGTK nochmal langsame ist auf Windows. Aber ob das ganze sehr spürbar langsam ist bezweifele ich;) [1]
In Windows gibt es auch diverse Mittelschichten. Zum Beispiel sind die MFC so eine Zwischenschicht. Aber einen Performanceunterschied merkt man in der Regel nicht.

Was GTK angeht - sonderlich schnell ist es nicht, das ist wahr (aber wxGTK ist andererseits warscheinlich auch nicht schneller - das Problem liegt wohl in GTK selbst und nicht dessen Wrappern). Vielleicht wird das mit Cairo besser
sape hat geschrieben:Dafür gibt es auch ein Theme. http://art.gnome.org/themes/gtk2/1329
Was lumax meinte ist eine Aqua-Engine. Soweit ich weiß gibt es keine, GTK+ sieht unter Mac OS X wohl so aus. Jedoch ist es technisch durchaus möglich dass in Zukunft so eine Engine geschrieben wird. Jedoch scheint im Moment dass Interesse an "GTK+ on Mac" zu gering zu sein, dass da jemand sich die Arbeit gemacht hätte. Der Mac-Support von GTK+ soll überhaupt eher schwach sein (von Mac-X11 mal abgesehen, natürlich). Getestet habe ich es nicht weil ich auch keinen Mac habe.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Hi Leonidas.

Danke dir für die Ausführliche Information. Das alles wusste ich bisher noch garnicht.

lg
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

PmanX hat geschrieben:Auseinandersetzungen müssen nicht degenerieren :!:
Warum soll jeder das Rad neu erfinden? Der Vorteil einer Community ist der Erfahrungsaustausch.
Keiner hat was gegen Erfahrungsaustausch.

Es lässt sich aber oft folgendes Muster in Foren beobachten:

Anhänger von X gegen Y, wobei X und Y GUI-Frameworks, Web-Application-Frameworks, Programmiersprachen und sonstwas sein können.. sucht euch was aus.

Wenn man wirklich tief bohrt, merkt man schnell, dass in der Regel der Befürworter von X auch nur über X wirklich Bescheid weiß.. damit arbeitet er schon länger, ist auch oft über neue Entwicklungen informiert.

Y dagegen hat er sich damals angeschaut, aber für X aus für ihn guten Gründen entschieden.

Y wird danach bestenfalls nur noch sporadisch beobachtet, wenn überhaupt.

Die korrekte Vorgehensweise wäre bei einer Diskussion ja dann eigenlich zu sagen: "Meine Gründe für X waren damals die folgende... Bei Y fehlte mir (bla) und (bla) war auch nicht so gut.. andere Punkte waren dagegen nicht schlecht.".

Wenn jetzt ein vernünftiger Befürworter von Y kommt wäre ja ein ordentlicher Ton sowas in der Art: "Hallo, dein Grund (bla) ist mittlerweile gar nicht mehr aktuell, da hat sich einiges getan! Und das Feature (blubb) ist dir vielleicht damals gar nicht aufgefallen, oder :-) "

Aber nein, allzuoft geht's gleich ins Eingemachte.. bevor die beiden schlichtweg zugeben, dass man auf dem Gebiet der "Gegenseite" kein Experte (mehr) ist, und lieber voneinander lernen, artet die Diskussion dann allzuoft aus.

Ich sag liebe ehrlich: "Ich mag an X folgende Dinge... Aber vielleicht gibt es ja irgendwo ein Z, was mein neuer Liebling werden könnte, aber ich einfach noch nicht kenne?"

Also: Ich mag zur Zeit wxPython. Und ich mag Python.
Aber wer weiß, vielleicht verliebe ich mich unter anderen Voraussetzungen nochmals in pyGTK? Oder Ruby? Wer weiß, wer weiß....
Antworten