Tolle Taktik, immer gleich alle als Troll zu bezeichnen, die etwas Unerwünschtes sagen. Bloß ist es halt leider nicht richtig.
Deshalb: Selber testen! Dieses winzige Programm hier runterladen:
http://kchmviewer.sourceforge.net/
Einmal mit und einmal ohne kdelibs kompilieren, siehe ./configure --help, wie das geht, und dann selber testen.
Aber nein, anstatt ganz ruhig und angemessen auf Kritik zu reagieren, wird natürlich wieder der "RABÄÄH! Der hat was gegen KDE gesagt"-Diskussionsstil gefahren. Ganz toll.
Hast völlig recht. Bezeichne einfach alle, die etwas auszusetzen haben, als Troll, so wird OpenSource bestimmt ein Riesenerfolg!
Keine OpenSource-Lösung für ein konkretes Problem? Kein Problem, wenn es keine OpenSource-Lösung gibt, ist das Problem kein Problem und wer etwas anderes sagt, ist ein Troll
So wird es mit dem Erfolg von OpenSource richtig aufwärts gehen!
> Bezeichne einfach alle, die etwas auszusetzen haben, als Troll, so wird OpenSource bestimmt ein > Riesenerfolg! Ich glaube der Einfluss von Newskommentaren auf das vorrankommen von Freier und OpenSource Software ist so gut wie null.
Wenn du mit mir diskutieren willst, mußt du deinen Namen ändern. Du bist in meinem internen Speicher schon längst als Troll gekennzeichnet und ich nehme deine Kommentare daher schon längst nicht mehr ernst.
Das eine KDE-Anwendung langsamer als eine Qt-Anwendung ist, liegt sicherlich auch in dem beschränkteren Funktionsumfang begründet und sollte auch daran bemessen werden.
Unter "Funktionsumfang" verstehe ich durchaus auch Dinge wie "Integration in die bestehende Desktopumgebung".
Kommt auch drauf an, ob Qt lediglich für die GUI oder auch für darunter liegende Funktionen verwendet wird.
>lade irgendein app runter und compilier es mit/ohne gnome support... mit wird es lahm sein.
Wobei man schon sagen muß, dass KDE apps im Gegensatz zu Qt apps mehr "extras" drin haben als das bei GNOME der Fall ist.
Ansonsten stimme ich dir zu, bis auf dieses Kommentar:
>Und das KDE gnome wegrennt ist ja altbekannt...
dass halte ich genauso für polemik wie wenn ich das Gegenteil behaupten würde. Imho gibt es Szenarien wo Qt/KDE etwas schneller wirkt und umgekehrt, insgesammt denke ich das heute bei aktueller Hardware nichtmehr wirklich ein Unterschied existiert über den es lohnen würde zu streiten.
mensch, G-Punkt/W-Punkt, du bist uns noch ein paar antworten schuldig. im thread http://www.pro-linux.de/news/2005/8323.html (subject: Botschaft gut, Darstellung leider gar nicht) hast du dich ja sang-und klanglos aus der affäre gezogen, nachdem dir aufgegangen ist, was für einen himmelschreienden unsinn du dort behauptet hast:
> Die Äußerung "Mit freier Software ist dies natürlich kein Problem" ist reine OpenSource-Trollerei
nun also her mit den argumenten, du bist ja sonst auch nicht so maulfaul.
Die Startup und Compilezeiten von Qt4.0 sind besser als Qt3, die Laufzeiten sind leider sehr viel langsamer - langsamer sogar als das Gespann Qt3/KDE. Für die Portierung von Anwendungen die auf schnelles Neuzeichnen angewiesen sind, ist daher Warten - mindestens auf das mit Qt4.1 (Ende 05) angekündigte Redesign der Paint Engine - angesagt.
Nebenbei: TrollTech hat seit ca. einem Monat keine BugFixes mehr in Qt4.0.0 einfliessen lassen (und das waren/sind wirklich viele). Es empfiehlt sich daher so früh wie möglich auf die 4.0.1 Snapshots umzusteigen.
Trolltech listet auf http://www.trolltech.com/products/qt/known-issues.html einige Performance-Engpässe auf. Die sollen aber alle innerhalb von 4.0.x gelöst werden, da mußt du nicht auf Qt 4.1 für warten.
jop, Qt is einfach genial.. Sollte ich mal was anständiges programmieren, werd ich dafür auch Qt nehmen. Naja, und KDE.. vielleicht wirds ja mal wieder schneller und stabiler. Momentan bin ich allerdings unzufrieden und nutze ion3. Mal was gänzlich anderes
Kann mir ein QT/KDE-Entwickler sagen, was sich hinter der MVCC-Neuerung versteckt? Bin kein C++ler, aber MVC sollte sich doch in jedem OO-Setting umsetzen lassen, ist ja zudem ein "alter" Hut.
Was unterscheidet denn nun QT4 genau von dem was bisher mit QT3 möglich war?
Einfach den Link im Artikel anklicken und lesen, hier extra für Dich nochmal: http://doc.trolltech.com/4.0/qt4-intro.html - Vielzahl an Änderungen und Neuerungen.
den artikel habe ich gelesen, Sie auch? dann wird der geniegten LeserIn auf aufgefallen sein, dass sich dieser primär um ein "Was ist MVC" kümmert und nur ein wenigen Zeilen das "What's Changed Since Qt 3" behandelt...
Ausser dem Satz: "The table and item view classes in Qt 3 implemented widgets that both stored data and presented it to the user. These classes were designed to be easy-to-use and consistent, but were sometimes difficult to customize and extend." ist nicht wirklich etwas zu erfahren, daher nochmal meine Bitte an EntwicklerInnen den primären Unterschied herauszarbeiten...
Ist etwas geschönt dafür, daß Du, wenn Du Tabellen/Bäume in Qt3 darstellen willst, Aufwand betreiben mußt, um eine vollständige Kopie der Daten zu vermeiden. Bei Tabellen mit 100000*20 Zellen ist glaube ich klar, warum das wichtig ist.
Das hat mit Model/View insoweit zu tun, daß die View in Qt4 über eine abstrakte Schnittstelle auf die Daten zugreift, anstatt sie wie in Qt3 über Item Klassen hereingereicht bekommen zu haben.
Ich habe mit Qt noch nicht programmiert aber bei der GUI- Entwicklung sind sie einen eigenen Weg gefahren, nämlich die sogenannte Slot-Technik. Wie die genau funktioniert, weiß ich wiederum nicht aber bei klassischen GUI-Toolkits (z.B. Javas Swing) wird das MVC-Modell benutzt, wobei bei Swing View (Anzeige) und Controller (I/O) der Einfachheit halber vereint sind (genannt: Delegate).
Was bringt's?
Trennung von Datenhaltung (z.B. Tabelle) und Anzeige, so dass man Daten ohne Weiteres in verschiedenen GUI-Elementen darstellen kann. Wenn das Modell jetzt eine Änderung erfährt (z.B. ein Datensatz wurde hinzugefügt oder geändert), benach- richtigt das Modell die Delegates und diese aktualisieren ihre Darstellung der Daten.
Ein weiteres Stichwort hierfür ist noch: Observer-Pattern (bzw. Beobachter Entwurfsmuster)
Bedeutet das dann, daß in KDE4 jeder, der Programme auf der Basis von Qt3.x geschrieben hat erstmal wieder portieren muß? Möchte nicht wissen wieviele Anwendungen dann wieder hinten rüber fallen und aufgegeben werden. Wäre sicher schade. Oder wie steht es um die Abwärtskompatibilität von KDE4?
Ich warte am meisten auf die "Console Version" von Qt; bis jetzt war man immer daran gebunden zumindest einen virtuellen XServer im Hintergrund laufen zu haben, wenn man nicht QtE nutzen wollte, das ändert sich nun. Mal schauen, wann die ersten in Qt geschriebenen Server heraus kommen.
Danke Trolltech für dieses Produkt! p.S.: Jemand Lust einen minit-clone auf Qt-console Basis mit zu erarbeiten, mein Laptop könnte etwas schneller booten ^^
bis jetzt war man immer daran gebunden zumindest einen virtuellen XServer im Hintergrund laufen zu haben
Das ist so absolut falsch. Man konnte auch bisher schon non-GUI Applikationen machen (Hinweis: dritter Parameter des QApplication Konstruktors), der Unterschied ist, daß man nur mehr gegen Nicht-GUI Teile linken muß
Es ist eine Cross Plattform Bibliothek und keine GUI Bibliothek mehr.
Ich finde die sollten sich lieber auf die GUI beschränken denn da gibt es noch genug zu tun. Na ja wenigstens kann ich jetzt toplevel modale fenster erzeugen, wir kommen der Portierbarkeit von MacOSX Anwendungen schon näher.
Aber es wird auch immer mehr zum Hack, ein cleanup kommt hoffentlich mit 5.0
> Aber es wird auch immer mehr zum Hack, ein cleanup kommt hoffentlich mit 5.0 Ich würde mir wünschen das wieder mehr Std-C++ benutzt würde. Ich verstehe nicht wieso es QString, QList, etc. geben muss wenn der Standard so etwas schon hat. Vielleicht gab es zu Beginn von Qt noch keine STL aber mittlerweile dürfte das kein Argument mehr sein Vor allem wenn es sowieso um ein Port zu 4.0 geht, da hätte man doch sowas dann auch "verbessern" können.
Kenn mich mit Qt net so genau aus, aber ich denk der QString kann auch UTF-8 und viele andere encodings und ist von dem her dem std::string überlegen. Also std::string würde einen Rückschritt bedeuten, aber QList hat anscheined keinen wesentlichen Vorteil. So wie ich das aufgefasst hab, kann man ja auch std::list verwenden, wenn man will.
Der std::string also prinzipiell ein std::basic_string ist ein gegenstück zu QCString, Wenn man andere stringtypen in std-c++ will kann man entweder auf den wstring ausweichen, wobei dieser ein std::basic_string ist und wchar_t definiert ist als das "weiteste" was das system an character typen unetrstützt. Damit wäre dieser eher ein Gegenstück zum QString. Wem das nicht reicht, der kann in stdc++ seine eigene Stringklasse machen indem er std::basic_string als basis nimmt. Der std::basic_string ist dem QString dahingehend überlegen das er von der art des Character Typs unabhängig ist. Dazu kommt noch das jeder Hersteller von Betriebsystemen die STL an sein System anpasst. In der Regel ist std::basic_string wie der QString copy-on-write. Er muss es aber nicht sein, da das in einer multi-threaded Umgebung auch Nachteile haben kann. Letztlich kostet der std::basic_string kein Geld, der QString schon für den ich entweder ungefähr 5000 Dollar pro Entwickler (kommerzielle Lizenz) oder mit meinem Code bezahle(QPL/GPL).
Und anscheinend kann das forum nicht template klassen von html tags unterscheiden, also entschuldigt das in meinem letzten kommentar alle spitzen klammern fehlen...
Inwiefern ist Qt inkompatibel zur STL? Du kannst in Qt-Applikationen wunderbar die STL-Klassen verwenden. Gar kein Problem. Wenn dir QString, QList, QVector und Konsorten nicht gefallen, nimmst du einfach die STL-Varianten. Wo ist das Problem?
Das ist keine Trollerei, sondern einfach das QStrings nicht mit c++ streams funktionieren und man nicht die ganze zeit strings umwandeln will. Außerdem gehen die STL container z.B. nicht mit dem QVariant (prinzipiell eine union aus vielen Qt typen) der ja intensiv im property - system von Qt genutzt wird.
sondern einfach das QStrings nicht mit c++ streams funktionieren
Wenn du zum Beispiel immer ein fixes Encoding in den Strings hast, kannst du einfach einen Operator definieren, der das entsprechende Encoding benutzt um einen char* zu erhalten. (Zum Beispiel QString::local8Bit())
Ich habe gerade das C++ Äquivalent versucht, also einen std::string<wchar_t> auf cout ausgeben und das wurde nicht kompiliert. Scheint also dort auch nicht so einfach zu sein einen UTF-16 String auszugeben.
Außerdem gehen die STL container z.B. nicht mit dem QVariant
Hmm, das wäre mir neu. Hab gerade einen std::vector mit QVariants gefüllt und wieder ausgelesen.
/** Puts the next word of the a std::istream into a QString. * */ std::istream &operator>> ( std::istream &is, QString &_s ) { std::string s; is >> s; _s = QString::fromUtf8( s.c_str() );
Ich habe mir schon gedacht das ich so einen Anfängerscheiss als Antwort bekomme.
1) Eine unnötige kopie. 2) QString::fromUtf8() ist eher schlecht, wegen der surrogate chars im 8 bit bereich von Unicode 3) Wenn Qt den C++ ISO standard berücksichtigen würde wäre der oben gezeigte Quatsch völlig überflüssig.
Das entscheidende ist das die Technik des statische ungebundene polymorphismus in Qt völlig ungenutzt ist was aber einer der Vorteile von C++ ist.
Das problem ist das es schlecht ist immer ständig alles umkopieren zu müssen und Qt intern natürlich seine schlechten, selbstgebrauten container nutzt und nicht die des C++ ISO standards. Im übrigen ist es das geschickte Zusammenspiel aus Iteratoren und Algorithmen mit Streams und Containern das die STL besser und moderner macht als der betagte Programmierstil von Qt.
Hallo, Vielleicht etwas OT, aber gibt es ein Buch (oder druckbares PDF) das einem die Programmierung von KDE 3.x näher bringt. Die HTML-Developer-Seiten auf KDE.org zu lesen finde ich als altmodischer Mensch etwas anstrengend. Bisher habe ich nur zu KDE 2.0 (M&T) etwas gefunden. (kann engl. oder Deustch sein. Igendwas im Stile von Programming with Qt. Danke!
Na, da bin ich ja mal gespannt! KDE ist momentan leider nicht so der Renner in Sachen Stabilität. Nachdem mir dutzendmal Quanta und der Konqueror und manchmal der Kicker abgesemmelt ist, habe ich dann wieder Win gestartet und machs mit Dreamweaver... Muss zwar net an QT liegen, weiss ich nicht, könnte aber.
Momentan kann zumindest ich mit KDE nicht arbeiten und wenns an QT liegen sollte, hoffe ich dann mal das es schnell ne Portierung/Anpassung von KDE auf die QT4 gibt.
Welches KDE und Welche Distrie hast du denn? Hin und wieder verändern die Distributionen was an KDE und Linux, es kann also sein, dass KDE dadurch instabil wird. Oder wenn du ein selbstkompiliertes KDE drüberstülpst kann das (weils nicht verändert wurde) nicht richtig mit dem Rest vom System.
Also ich kann das ebenfalls nicht nachvollziehen, ich hatte mal eine Quanta Version drauf, die wirklich instabil war, das lag aber nicht an kde sondern Quanta.
Ansonsten hab ich keine Anwendung in KDE seit mindestens nem halben Jahr abstürzwen sehen. Aber meiner Meinung nach liegts an den Distris, ich hatte frühers mal RedHat oder Mandrake und die hatten im Vergleich immer mehr Fehler in KDE als Gentoo, kommt einfach durch die Patcherei und das teilweise die Bibliotheken, des Paketerstellers nicht mit denen übereinstimmen, die man auf seiner Kiste hat.
Aus meiner Sicht kann ich nur sagen, wenn KDE instabil ist, dann ist Windows ein Glashaus.
Ich liebe es.
Allo
Deshalb: Selber testen! Dieses winzige Programm hier runterladen:
http://kchmviewer.sourceforge.net/
Einmal mit und einmal ohne kdelibs kompilieren, siehe ./configure --help, wie das geht, und dann selber testen.
Aber nein, anstatt ganz ruhig und angemessen auf Kritik zu reagieren, wird natürlich wieder der "RABÄÄH! Der hat was gegen KDE gesagt"-Diskussionsstil gefahren. Ganz toll.
Keine OpenSource-Lösung für ein konkretes Problem? Kein Problem, wenn es keine OpenSource-Lösung gibt, ist das Problem kein Problem und wer etwas anderes sagt, ist ein Troll
So wird es mit dem Erfolg von OpenSource richtig aufwärts gehen!
> Riesenerfolg!
Ich glaube der Einfluss von Newskommentaren auf das vorrankommen von Freier und OpenSource Software ist so gut wie null.
Das eine KDE-Anwendung langsamer als eine Qt-Anwendung ist, liegt
sicherlich auch in dem beschränkteren Funktionsumfang begründet
und sollte auch daran bemessen werden.
Unter "Funktionsumfang" verstehe ich durchaus auch Dinge wie
"Integration in die bestehende Desktopumgebung".
Kommt auch drauf an, ob Qt lediglich für die GUI oder auch für
darunter liegende Funktionen verwendet wird.
Gruß
L00NIX
Was ist also das besondere an deiner Aussage?
Und das KDE gnome wegrennt ist ja altbekannt...
Wobei man schon sagen muß, dass KDE apps im Gegensatz zu Qt apps mehr "extras" drin haben als das bei GNOME der Fall ist.
Ansonsten stimme ich dir zu, bis auf dieses Kommentar:
>Und das KDE gnome wegrennt ist ja altbekannt...
dass halte ich genauso für polemik wie wenn ich das Gegenteil behaupten würde. Imho gibt es Szenarien wo Qt/KDE etwas schneller wirkt und umgekehrt, insgesammt denke ich das heute bei aktueller Hardware nichtmehr wirklich ein Unterschied existiert über den es lohnen würde zu streiten.
http://www.pro-linux.de/news/2005/8323.html (subject: Botschaft gut, Darstellung leider gar nicht) hast du
dich ja sang-und klanglos aus der affäre gezogen, nachdem dir aufgegangen ist, was für einen himmelschreienden unsinn du dort behauptet hast:
> Die Äußerung "Mit freier Software ist dies natürlich kein Problem" ist reine OpenSource-Trollerei
nun also her mit den argumenten, du bist ja sonst auch nicht so maulfaul.
Auto ohne Anhänger
Auto mit Anhänger
Wenn du kdelibs mit einkompilierst hast du auch Funktionalität davon drin, ergo langsamer.
Seid ihr wirklich so dumm oder wisst ihr es nicht besser?
Nebenbei: TrollTech hat seit ca. einem Monat keine BugFixes mehr in Qt4.0.0 einfliessen lassen (und das waren/sind wirklich viele). Es empfiehlt sich daher so früh wie möglich auf die 4.0.1 Snapshots umzusteigen.
Uwe
Naja, und KDE.. vielleicht wirds ja mal wieder schneller und stabiler. Momentan bin ich allerdings unzufrieden und nutze ion3. Mal was gänzlich anderes
das wird was
Bin kein C++ler, aber MVC sollte sich doch in jedem OO-Setting umsetzen lassen, ist ja zudem ein "alter" Hut.
Was unterscheidet denn nun QT4 genau von dem was bisher mit QT3 möglich war?
Danke!
grüße aus Pisa
den artikel habe ich gelesen, Sie auch? dann wird der geniegten LeserIn auf aufgefallen sein, dass sich dieser primär um ein "Was ist MVC" kümmert und nur ein wenigen Zeilen das "What's Changed Since Qt 3" behandelt...
Ausser dem Satz:
"The table and item view classes in Qt 3 implemented widgets that both stored data and presented it to the user. These classes were designed to be easy-to-use and consistent, but were sometimes difficult to customize and extend." ist nicht wirklich etwas zu erfahren, daher nochmal meine Bitte an EntwicklerInnen den primären Unterschied herauszarbeiten...
Danke!
PS: Jemals einen PISA-Report gelesen?
Das hat mit Model/View insoweit zu tun, daß die View in Qt4 über eine abstrakte Schnittstelle auf die Daten zugreift, anstatt sie wie in Qt3 über Item Klassen hereingereicht bekommen zu haben.
Uwe
Ich habe mit Qt noch nicht programmiert aber bei der GUI-
aber bei klassischen GUI-Toolkits
Entwicklung sind sie einen eigenen Weg gefahren, nämlich
die sogenannte Slot-Technik. Wie die genau funktioniert,
weiß ich wiederum nicht
(z.B. Javas Swing) wird das MVC-Modell benutzt, wobei bei
Swing View (Anzeige) und Controller (I/O) der Einfachheit
halber vereint sind (genannt: Delegate).
Was bringt's?
Trennung von Datenhaltung (z.B. Tabelle) und Anzeige, so dass
man Daten ohne Weiteres in verschiedenen GUI-Elementen
darstellen kann. Wenn das Modell jetzt eine Änderung erfährt
(z.B. ein Datensatz wurde hinzugefügt oder geändert), benach-
richtigt das Modell die Delegates und diese aktualisieren ihre
Darstellung der Daten.
Ein weiteres Stichwort hierfür ist noch:
Observer-Pattern (bzw. Beobachter Entwurfsmuster)
Gruß
L00NIX
.
.
Da ist also eigentlich kein Unterschied zwischen einer Qt3/Qt3, Qt3/Qt4 und Qt4/Qt4 Kombination von zwei Applikationen.
Danke Trolltech für dieses Produkt!
p.S.: Jemand Lust einen minit-clone auf Qt-console Basis mit zu erarbeiten, mein Laptop könnte etwas schneller booten ^^
Das ist so absolut falsch.
Man konnte auch bisher schon non-GUI Applikationen machen (Hinweis: dritter Parameter des QApplication Konstruktors), der Unterschied ist, daß man nur mehr gegen Nicht-GUI Teile linken muß
Ich finde die sollten sich lieber auf die GUI beschränken denn da gibt es noch genug zu tun. Na ja wenigstens kann ich jetzt toplevel modale fenster erzeugen, wir kommen der Portierbarkeit von MacOSX Anwendungen schon näher.
Aber es wird auch immer mehr zum Hack, ein cleanup kommt hoffentlich mit 5.0
Ich würde mir wünschen das wieder mehr Std-C++ benutzt würde. Ich verstehe nicht wieso es QString, QList, etc. geben muss wenn der Standard so etwas schon hat. Vielleicht gab es zu Beginn von Qt noch keine STL aber mittlerweile dürfte das kein Argument mehr sein
Das Problem mit der STL ist, daß sie nicht überall gleich (gut) implementiert ist.
Also besser man hat Klassen auf deren Vorhandensein und Verhalten man sich verlassen kann.
Wem das nicht reicht, der kann in stdc++ seine eigene Stringklasse machen indem er std::basic_string als basis nimmt. Der std::basic_string ist dem QString dahingehend überlegen das er von der art des Character Typs unabhängig ist.
Dazu kommt noch das jeder Hersteller von Betriebsystemen die STL an sein System anpasst. In der Regel ist std::basic_string wie der QString copy-on-write. Er muss es aber nicht sein, da das in einer multi-threaded Umgebung auch Nachteile haben kann.
Letztlich kostet der std::basic_string kein Geld, der QString schon für den ich entweder ungefähr 5000 Dollar pro Entwickler (kommerzielle Lizenz) oder mit meinem Code bezahle(QPL/GPL).
Sehr richtig!
Der hohe Preis (kein LGPL) und die Inkompatibilität zur STL sind echte KO-Kriterien für Qt.
Wenn du zum Beispiel immer ein fixes Encoding in den Strings hast, kannst du einfach einen Operator definieren, der das entsprechende Encoding benutzt um einen char* zu erhalten.
(Zum Beispiel QString::local8Bit())
Ich habe gerade das C++ Äquivalent versucht, also einen std::string<wchar_t> auf cout ausgeben und das wurde nicht kompiliert.
Scheint also dort auch nicht so einfach zu sein einen UTF-16 String auszugeben.
Außerdem gehen die STL container z.B. nicht mit dem QVariant
Hmm, das wäre mir neu.
Hab gerade einen std::vector mit QVariants gefüllt und wieder ausgelesen.
Das ist im QProperty context ja auch totaler Quatsch. Einen std::vector in einen QVariant zu packen wäre interessant.
Doch, du musst natürlich den std::wcout nehmen. Und wenn du schon dabei bist nimm gleich einen std::wstring.
/** Puts the next word of the a std::istream into a QString.
*
*/
std::istream &operator>> ( std::istream &is, QString &_s )
{
std::string s;
is >> s;
_s = QString::fromUtf8( s.c_str() );
return is;
}
Funktioniert einwandfrei.
1) Eine unnötige kopie.
2) QString::fromUtf8() ist eher schlecht, wegen der surrogate chars im 8 bit bereich von Unicode
3) Wenn Qt den C++ ISO standard berücksichtigen würde wäre der oben gezeigte Quatsch völlig überflüssig.
Das entscheidende ist das die Technik des statische ungebundene polymorphismus in Qt völlig ungenutzt ist was aber einer der Vorteile von C++ ist.
Im übrigen ist es das geschickte Zusammenspiel aus Iteratoren und Algorithmen mit Streams und Containern das die STL besser und moderner macht als der betagte Programmierstil von Qt.
Vielleicht etwas OT, aber gibt es ein Buch (oder druckbares PDF) das einem die Programmierung von KDE 3.x näher bringt. Die HTML-Developer-Seiten auf KDE.org zu lesen finde ich als altmodischer Mensch etwas anstrengend.
Bisher habe ich nur zu KDE 2.0 (M&T) etwas gefunden. (kann engl. oder Deustch sein. Igendwas im Stile von Programming with Qt.
Danke!
Es gibt ein Buch was den Einstieg in die KDE 3.x Programmierung mit KDevelop leichter machen sollte.
Es nennt sich: KDE Programmierung mit KDevelop 3.x
Dein Buch habe ich schon;) Es geht mir weniger um KDeevelop als um eine Dokuentation der eigentlichen KDE-Programmierung.
LG
Stephan
Naja, ein ausführliches Buch gibt es leider nicht.
Aber so schwierig ist es auch nicht die KDE Programmierung zu verstehen. Es dauert aber ohne Buch sehr lange sich einzuarbeiten.
Es gibt da noch das Qt - Buch und KDE basiert ja, auch in der Programmierung, stark auf Qt. Vielleicht hilft das schon weiter.
Es kann wirklich sehr viel von Qt auf KDE übertragen werden. Was genau willst Du wissen? Vielleicht kann ich Dir weiterhelfen.
KDE ist momentan leider nicht so der Renner in Sachen Stabilität. Nachdem mir dutzendmal Quanta und der Konqueror und manchmal der Kicker abgesemmelt ist, habe ich dann wieder Win gestartet und machs mit Dreamweaver...
Muss zwar net an QT liegen, weiss ich nicht, könnte aber.
Momentan kann zumindest ich mit KDE nicht arbeiten und wenns an QT liegen sollte, hoffe ich dann mal das es schnell ne Portierung/Anpassung von KDE auf die QT4 gibt.
Schusterjunge bleib bei deinen Leisten, und red' nicht über Sachen die du nicht verstehst.
Hin und wieder verändern die Distributionen was an KDE und Linux, es kann also sein, dass KDE dadurch instabil wird. Oder wenn du ein selbstkompiliertes KDE drüberstülpst kann das (weils nicht verändert wurde) nicht richtig mit dem Rest vom System.
Das kann ich hier SuSE9.3/KDE3.4.1 absolut nicht nachvollziehen. Läuft sehr stabil. SuSE "Yast RPM Plugin" für den Konqui mal ausgenommen.
Ansonsten hab ich keine Anwendung in KDE seit mindestens nem halben Jahr abstürzwen sehen. Aber meiner Meinung nach liegts an den Distris, ich hatte frühers mal RedHat oder Mandrake und die hatten im Vergleich immer mehr Fehler in KDE als Gentoo, kommt einfach durch die Patcherei und das teilweise die Bibliotheken, des Paketerstellers nicht mit denen übereinstimmen, die man auf seiner Kiste hat.
Aus meiner Sicht kann ich nur sagen, wenn KDE instabil ist, dann ist Windows ein Glashaus.