Das deutsche Python-Forum

lunar hat geschrieben: Unter Windows können Tkinter-Programme den XP-Stil nicht übernehmen, sprich selbst wenn das Luna-Theme aktiviert ist, sehen die Buttons nicht so aus.

Achso, die Buttons?
Ich hatte an das Fenster gedacht.
Ja, die Buttons sehen einfach Eckig aus.
Als nicht abgerundet etc.
Aber mir gefällt es so und achte auch nicht so sehr darauf.

Kann man das bei den anderen auch so einstellen, dass es eine selbst ausgewählte Form annimmt, egal unter welchem Betriebs-System es läuft?

Erwin hat geschrieben:Kann man das bei den anderen auch so einstellen, dass es eine selbst ausgewählte Form annimmt, egal unter welchem Betriebs-System es läuft?

Naja, ich habe noch nicht viel mit wxPython gemacht. (Hab auch erst Tkinter genommen) Aber generell kannst Du ein Widget, gleich ob Fenster, Button etc. so anzeigen lassen, wie Du willst. Ob "native-Look" oder auch nicht. Bei wxPython kann man sich die Widgets sogar selbst zeichnen. Also ganz unabhängig sein eigenes Ding machen. Ich empfehle ja nkoehrings Projekt immer gern weiter: Er hat die Vista-Navigation-Leiste nachgebaut.

Leonidas hat geschrieben:

sma hat geschrieben:Bei Qt 4 unterliegt AFAIK der GPL oder erfordert eine gesonderte kommerzielle Lizenz.

Stimmt nicht mehr, siehe dieser Thread, den es hier letztens gab.

Nope, wer es kommerziell nutzen möchte muss richtig löhnen. Und zwar für QT und PyQT!

noise hat geschrieben:

Leonidas hat geschrieben:

sma hat geschrieben:Bei Qt 4 unterliegt AFAIK der GPL oder erfordert eine gesonderte kommerzielle Lizenz.

Stimmt nicht mehr, siehe dieser Thread, den es hier letztens gab.

Nope, wer es kommerziell nutzen möchte muss richtig löhnen. Und zwar für QT und PyQT!

Wer proprietäre Software entwickelt hat nichts anderes verdient. Und für kommerzielle Opensource Software fallen afaik keine Kosten an.

veers hat geschrieben:

noise hat geschrieben:

Leonidas hat geschrieben:

sma hat geschrieben:Bei Qt 4 unterliegt AFAIK der GPL oder erfordert eine gesonderte kommerzielle Lizenz.

Stimmt nicht mehr, siehe dieser Thread, den es hier letztens gab.

Nope, wer es kommerziell nutzen möchte muss richtig löhnen. Und zwar für QT und PyQT!

Wer proprietäre Software entwickelt hat nichts anderes verdient. Und für kommerzielle Opensource Software fallen afaik keine Kosten an.

Wenn du für den Support Geld verdienst, klar. Wenn du für das distributieren Geld nimmst, klar. Und der source offen ist. Das habe ich auch nicht bestritten.
http://trolltech.com/company/model

noise hat geschrieben:

Leonidas hat geschrieben:

sma hat geschrieben:Bei Qt 4 unterliegt AFAIK der GPL oder erfordert eine gesonderte kommerzielle Lizenz.

Stimmt nicht mehr, siehe dieser Thread, den es hier letztens gab.

Nope, wer es kommerziell nutzen möchte muss richtig löhnen. Und zwar für QT und PyQT!

Habe ich etwas anderes behauptet? Ich habe nur gemeint, dass der Code nicht mehr nur unter GPL stehen darf - es reicht wenn er freie Software ist.

Hi Leonidas,
ne sorry war mein Fehler. Hab dich falsch verstanden.

Hi!

veers hat geschrieben:Wer proprietäre Software entwickelt hat nichts anderes verdient. Und für kommerzielle Opensource Software fallen afaik keine Kosten an.

So lese ich http://trolltech.no/downloads/index auch:
"""Which Downloads Are Right for You?
Using a Dual Licensing Business Model, Trolltech provides its Qt and Qtopia products under commercial licenses for proprietary development and under the GPL and similar Open Source licenses for free and open source development."""

Allerdings stört mich hierbei, dass das Wort "Commercial" verwendet wird. Schließlich kann man auch kommerzielle Freie Software (vgl. http://www.gnu.de/documents/gpl-3.0.de.html) schreiben.

Gruß

Gnushi

Naja "under the GPL and similar Open Source licenses for free and open source development." muss man ein wenig genauer betrachten. veers hat insofern schon recht, dass du deine OpenSource software "Verkaufen" - bzw. für den Support und das verteilen auf Medien - darfst, solange du den source offen legst. Das schließt ja die GPL nicht aus.

Oder sehe ich das vielleicht jetzt total verkehrt?

noise hat geschrieben:Oder sehe ich das vielleicht jetzt total verkehrt?

Ne hab noch mal in die GPL gerade geschaut. Passt schon so wie ich das geschrieben habe. Es ist dabei so das die Kommerzielle Nutzung hierbei ausdrücklich erlaubt ist.

Hatte ich nicht mehr so auf den Plan, da ich mit der GPL nicht viel am Hut habe und mehr der MIT/BSD Typ bin

BTW: Sorry für den doppel post.

"commercial licenses for proprietary development"

Außerdem geht es nicht um kommerzielle Entwicklung, sondern die Lizenz ist kommerziell wenn du proprietäres entwickelst.

Ich hab jetzt nicht alle Beiträge gelesen, möchte aber meinen Senf noch unterrühren.

Meine Meinungen:

Tkinter:
Vorteil: Ist bei (fast) jedem Python dabei
Nachteil: Hässlich (meiner Meinung nach) und verhältnismäßig wenige Möglichkeiten

GTK:
Umständlich zu programmieren und anscheinend ein ziemliches Frickelwerk aus C mit dem Versuch das nachträglich in Objekte zu packen. Mehr Funktionalität als Tkinter, aber immer noch viel Handarbeit nötig

Qt4:
Umfangreiches Framework und gerade mit den Python Bindings recht gut zu programmieren. Neben den GUI Klassen gibt es auch noch weitere Klassen für XML, SQL, Netzwerk und einiges andere.


Ich habe auch eine Weile überlegt und mich letztlich dafür entschieden Qt4 zu verwenden. Ich verwende zwar selbst Gnome als Desktop, aber das hindert mich ja nicht daran Qt4 Anwendungen zu starten. Die zusätzlichen Klassen sind bei Python eigentlich überflüssig, bei C++ aber schon sinnvoll. Ich werde bei mir wenn möglich die Qt4 Klassen verwenden um später die Möglichkeit zu haben das Ganze auch nach C++ portieren zu können falls es nötig ist.

Ich habe mir sogar kürzlich ein Buch gekauft das ich empfehlen kann. Ist zwar in englisch, aber gut geschrieben. Normalerweise bin ich kein Fan von englischer Literatur, aber damit kommt ich gut zurecht

Rapid GUI Programming with Python and Qt
The Definitive Guide to PyQt Programming
Buch - Autor(en): Mark Summerfield
Verlag: Prentice Hall International

burli hat geschrieben:GTK:
Umständlich zu programmieren und anscheinend ein ziemliches Frickelwerk aus C mit dem Versuch das nachträglich in Objekte zu packen. Mehr Funktionalität als Tkinter, aber immer noch viel Handarbeit nötig

Das stimmt schlichtweg nicht. Es ist nicht schwerer oder leichter zu programmieren als andere GUI-Libs (teils komplizierter, teils einfacher, hängt von der Aufgabe ab) und das ziemliche Frickelwerk was du meinst ist eben Objektorientiertes C - kann dir aber unter Python vollständig egal sein, denn dort hält es sich ganz normal an das Objektmodell von Python. Zudem hast du noch mit gnome-python(-extras, -desktop) recht viele zusätzliche Widgets die dir Zeit sparen.

GTK ist sicher nicht der Weisheit letzter Schluss, aber das was du behauptest ist unter Python FUD.

burli hat geschrieben:Ich habe auch eine Weile überlegt und mich letztlich dafür entschieden Qt4 zu verwenden.

Zu dieser Wahl kann ich dir nur gratulieren

Ich verwende zwar selbst Gnome als Desktop

Zu dieser eher weniger

Die zusätzlichen Klassen sind bei Python eigentlich überflüssig.

Letztens gab es hier das Problem, einen Prozess unter Anzeige eines Qt4-Fortschrittdialogs nicht-blockierend aufzurufen: http://www.python-forum.de/topic-13448.html?highlight=

Daran kann man erkennen, dass man die Qt4-Klassen auch verwenden sollte, weil sie optimal mit den GUI-Widgets interagieren.

Ich werde bei mir wenn möglich die Qt4 Klassen verwenden um später die Möglichkeit zu haben das Ganze auch nach C++ portieren zu können falls es nötig ist.

Aus welchen Grund sollte man das tun?

Leonidas hat geschrieben: GTK ist sicher nicht der Weisheit letzter Schluss, aber das was du behauptest ist unter Python FUD.

Unter Python vielleicht. Aber ich hab mir schon ein paar Sachen angeschaut und bei denen haben sich mir die Nackenhaare aufgestellt

lunar hat geschrieben: Zu dieser eher weniger

Ich war lange Zeit der Meinung KDE sei die bessere Wahl. Mittlerweile bin ich es aber leid. Mit jedem KDE Desktop, egal ob Suse, Debian oder Kubuntu, hatte ich die gleichen Probleme. Programme starten erst beim 2. oder 3. Versucht, jeden Tag mehrfach den Crashmanager gesehen (das passiert sogar manchmal unter Gnome wenn ich mal ein KDE Programm starte). Außerdem ist mir KDE zu bunt und sieht zu sehr nach dem Versuch aus Windows nachzubilden.

Alle anderen Desktops sind mir zu spartanisch. Gnome ist sicher nicht der Weisheit letzter Schluss, aber für mich die geeignete Mischung.

Trotzdem bevorzuge ich Qt4 für meine eigenen Projekte weil die etwas weiter über die üblichen kleinen Tools mit 1-2 Fenstern hinausgehen. Da hat Qt einfach die meisten Möglichkeiten und ist nach meinem Empfinden auch robuster

burli hat geschrieben:

Leonidas hat geschrieben: GTK ist sicher nicht der Weisheit letzter Schluss, aber das was du behauptest ist unter Python FUD.

Unter Python vielleicht. Aber ich hab mir schon ein paar Sachen angeschaut und bei denen haben sich mir die Nackenhaare aufgestellt

Für was für eine Sprache wird denn hier ein Toolkit gesucht? Ich gebe zu, einige Widgets sind unnötig kompliziert (wobei man manchmal auch denn Sinn dahinter erkennen kann und es nicht einmal so blöd ist), aber das ist bei wxPython ganz genau so (und es crasht seltener).

burli hat geschrieben:Außerdem ist mir KDE zu bunt und sieht zu sehr nach dem Versuch aus Windows nachzubilden.

Als ob man das nicht konfigurieren könnte


Lege mal deine idiotische Umsteiger-Arroganz ab, und betrachte die Dinge rational: Erstens ist die Windows-UI an sich nicht schlecht, und zweitens kann man KDE in punkto Aussehen wesentlich genauer anpassen als Gnome.

Deine persönlichen Präferenzen stehen natürlich nicht zur Debatte, ebenso wie die Tatsache, dass KDE bei dir offenbar fehlerhaft ist, aber dieses Nicht-Argument hättest du dir echt sparen können.

@Leonidas
Das ist ja alles gut und schön, aber du wirst wohl kaum bestreiten, dass GLib krude ist. Und darauf baut der PyGtk-Code letzten Endes wieder auf. Unabhängig davon, wie sich nun die PyGtk API tatsächlich "anfühlt", ist und bleibt die darunter liegende Bibliothek in Interface und Implementierung abenteuerlich

@rest
sorry für offtopic

lunar hat geschrieben:@Leonidas
Das ist ja alles gut und schön, aber du wirst wohl kaum bestreiten, dass GLib krude ist. Und darauf baut der PyGtk-Code letzten Endes wieder auf. Unabhängig davon, wie sich nun die PyGtk API tatsächlich "anfühlt", ist und bleibt die darunter liegende Bibliothek in Interface und Implementierung abenteuerlich

Mag ja sein (und ich habe weder Zeit, noch Lust mir das anzusehen, abenteuerlichen Code sehe ich oft genug *g*), aber solange der mich nicht anspringt, ist das nicht gar so schlimm. Zum Ausgleich: die Python Stdlib. Umfassend, aber total unkonsistent und teilweise ebenso abenteuerlich. mitsuhiko kramt alle 2 Tage in #python.de ein neues Modul aus, bei dem man die Implementation nicht kennen will.

Leonidas hat geschrieben:Mag ja sein (und ich habe weder Zeit, noch Lust mir das anzusehen, abenteuerlichen Code sehe ich oft genug *g*), aber solange der mich nicht anspringt, ist das nicht gar so schlimm. Zum Ausgleich: die Python Stdlib. Umfassend, aber total unkonsistent und teilweise ebenso abenteuerlich. mitsuhiko kramt alle 2 Tage in #python.de ein neues Modul aus, bei dem man die Implementation nicht kennen will.

Auch wieder war

lunar hat geschrieben: Als ob man das nicht konfigurieren könnte

Das weiß ich auch

lunar hat geschrieben: Deine persönlichen Präferenzen stehen natürlich nicht zur Debatte, ebenso wie die Tatsache, dass KDE bei dir offenbar fehlerhaft ist

Bei 3 unterschiedlichen Distributionen? Auf verschiedenen Rechnern? Und ich bin nicht der einzige mit diesen Problemen.

Aber genug OT.

Die Wahl welches Toolkit man letztendlich verwendet hängt hauptsächlich von der geplanten Anwendung und von den persönlichen Vorlieben ab. Für kleiner Tools kann man jedes der Tookits verwenden, aber bei komplexen Anwendungen (mit vielen Dialogen, Docked Windows usw) würde ich Qt vorziehen (was nicht bedeuten soll das es mit wxw oder GTK nicht auch gehen würde)