Die Frage ist weiter unten (in dem Qt für Mac-Artikel) beantwortet :)

Gruss,

Ralf

In der Doku zu Qt3 nachlesen. Qt 3 bietet ein Plugin-system und die styles selbst sind auch plugins. Das kannst du beliebig fortsetzen, z.B. eigene Widgets als plugins kreiren. Empfehlen kann ich zu dem ganzen, sich mal den Vortrag von Matthias Ettrich anzuschauen (siehe dot.kde.org, mit RealPlayer).

Gruss,

Ralf

Die windows-version der qt-lib wird nur als Visual-C++-6-Variante weitergegeben (im Moment noch). Deshalb brauchst du VC++ um damit unter windows zu entwickeln. Wer VC++ nicht hat, kann unter KDE damit sicher ganz genauso bequem mit KDevelop entwickeln.

Hi,
Ich weiss(?)!
Mir geht es eher darum, meine qt-Programme mal unter Windows zu kompilieren. aber ich will dafür nicht extra VC6 kaufen müssen!

Gruss

@charon_77: du sollst ja auch kein VC++ kaufen. Du sollst wenn du schon programmiest, was nützliches tun, damit dein Leben einen Sinn hat. Mach ein KDE-Programm oder programmier direkt an KDE mit. VC++ hat doch keinen Sinn für einen GPL-Programmierer, der noch ein bischen was auf sich hält :))

Gruss,

Ralf

PS: wollte mir nicht mal einer eine Webform schreiben für meine Seite, wo man per digitaler Unterschrift für 36 Monate bei KDE unterschreiben kann ??

@Ralph
Wenn die Trolls die Non-Commercial-Edition auch als Version für den Borland BCC32 oder den GNU GCC herausbringen, stellt sich dieses Problem mit einem kommerziellen Compiler ja gar mehr. (Haaallloooo Trolltech ;-))

@charon_77
Du musst dir ja nicht unbedingt die Professional-Version vom Visual C++ kaufen. Es reicht wenn es überhaupt der VC6 ist.
Wenn du in meinem Artikel auf Verweis Nummer fünf drückst, kannst du die Standard Edition von Visual C++ 6.0 für EUR 143,16
bestellen. Für QT Programme unter Windows ist diese Version vollkommen ausreichend und bringt auch noch eine an KDevelop angelehnte -- gell Ralph -- Entwicklungsumgebung mit. Ich bevorzuge aber trotzdem den VIM.

@Ralf
Ich programmiere an einem Beleg für Techn. Mech. (Nebenfach). Mir würde es nur gefallen, wenn das Programm auch unter Windows laufen könnte, damit ich meinen Profs nicht immer erklären muss, warum ich an dem einzigen Linuxrechner des Instituts mein Programm vorführen muss!
PS: Ich verwende KDevelop durchaus und sehr gern! Leider lässt mir mein Studium nebenbei kaum Zeit, sonst würde ich mich gern an KDE beteiligen, da ich von dem Projekt beeindruckt und begeistert bin. Vor allem gefällt mir das Komponentenkonzept sehr gut.

@Thomas
Na, dann werde ich mir das mit windows nochmal überlegen! Mal sehen...

Gruss

QT ist eine Bibliothekensammlung, die Du vorzugsweise unter C++ einsetzen kannst. Theoretisch sind auch Wrapper für andere Projekte möglich...

Kylix baut auf QT auf

...und Kylix ist Mist. Was aber nicht heisst das die QT Mist ist. Denn diese ist sogar ausgesprochen gut und lässt alle MFC-Freunde neidisch werden

> ...und Kylix ist Mist. <

Also bei soeinem Text hier gibt es nur 2 möglichkeiten wie der entstehen konnte:

1) Du bist nicht oft hier und kannst es deswegen nicht besser wissen
2) Du willst mich provizieren

In beiden fällen hast du mein Mitleid da du keine Ahnung zu haben scheinst. Lass mich raten: Du hast es noch nie gestartet? Du hast noch nie eine Anwendung erstellt die sowohl unter Windows wie auch unter Linux lief und dafür hast du nur 5 Minuten gebraucht? Oder kennst du nur die Open/Personal Edition und hast noch nie die Enterprise VErsion gesehen?

Wie auch immer, meit mitleid sei dir sicher

Stimmt, Pascal ist die Zukunft; hast recht das is wirklich toll.......

> Du hast noch nie eine Anwendung
> erstellt die sowohl unter Windows
> wie auch unter Linux lief und dafür
> hast du nur 5 Minuten gebraucht?

Nein!! Bitte nicht! nicht noch mehr von diesen 'ach wie toll! schau mal eine MessageBox(":::"); und das hat nur 5min gedauert....
Sorry; aber _dieses_ Argument kann ich nicht einfach so stehen lassen; OK, wer Kylix mag soll damit seine Anwendungen zusammenklicken, aber _bitte_ nicht in 5min.;

#include
for (int i=0;i<IchHabsVerstanden;i++)
if(i <= K&R && NextQuery());
cout << "SCNR" << endl;

"Pascal ist die Zukunft"....und Microsoft hat das beste OS und Deutschland hat keine Arbeitslosen mehr und nächste Woche ist Weihnachten LOL

Ihr scheint noch ziemlich jung zu sein? Naja wir wollen ja nicht Euer Weltbild zerstören.

ui, hab` dir tags vergessen ;)

...und Pascal is die Zukunft...

> Ihr scheint noch ziemlich jung zu
> sein?

nee, ich glaub' eher unerfahren....

>Nein!! Bitte nicht! nicht noch mehr von diesen 'ach wie toll! schau mal eine MessageBox(":::"); und das hat nur 5min gedauert....<

Was redest du für eine scheise?
Ich habe das auf das Portieren bezogen! Mit keinem anderen System kann man inzwischen so schnell Anwendungen schreiben die sowohl unter Windows wie auch unter Linux laufen wie mit Kylix+Delphi. Und diese Anwendungen sind, einen richtigen programmierer vorrausgesetzt, schneller fertig als mit jedem anderen System (dank einer sehr guten Klassenbibliothek [VCL/CLX] und einer hervorragenden IDE)!

>Sorry; aber _dieses_ Argument kann ich nicht einfach so stehen lassen;<

Du hast mir nicht wiedersprochen, das geht nur mit Argumenten.

>OK, wer Kylix mag soll damit seine Anwendungen zusammenklicken, aber _bitte_ nicht in 5min.;<

Verfolgungswahn? WO stand etwas von zusammenklicken? Zumal deine abwertende Darstellung eben dieses Zeigt das du da nicht viel erfahrung haben kannst. Den durch eine unterstützende IDE kann ein Programmierer viel Zeit sparen an teilen wo einfach nichts anderen nötig ist. Das Borland recht hat zeigen die überall auftauchenden IDE Designer marke Qt Designer und Glade. Was die machen ist gut, aber bei Borland Böse. KLar doch.

>Ihr scheint noch ziemlich jung zu sein? Naja wir wollen ja nicht Euer Weltbild zerstören.<

Das Pascal die zukunft gehört ist unsinn, das stimmt. Aber deine Antwort zeugt von unwissen. Pascal ist mit Delphi immer aktuell gewesen und die Projekte Kylix und FreePascal haben es nocheinmal deutlich wichtiger gemacht im Markt. Pascal war schon lange nicht mehr so aktuell wie heute.

>nee, ich glaub' eher unerfahren....<

Oh man, sich selbst als gott zu fühlen muss toll sein oder?

Schade nur das ich mindestens 10 Delphi Programmierer kenne welche die meisten hier locker in die tasche stecken.
Eine kleine Auswahl scheibt auch ein Full Price Spiel (wie viele von euch können das behauptet???)
www.digitalprojects.com/way-x

Sorry, aber ich HASSE solches besser wisser gelabere. Ich habe es schon zu oft gehört. Und ich mag da einfach nicht stillhalten. Und wer mich kennt weiss das ich da auch nicht still halte. Also: wenn ihr hierdrauf antworten wollt, bedenkt das ich mit sicherheit den längeren Atem habe :)

gar nicht

Objektorientierung

C++ ist eine Erweiterung von C oder so

QT ist ein C++-Framework - also eine Klassenbibliothek. Klassen gibt es nicht in C, obwohl man sie mit hilfe einer struktur nachbilden könnte - aber das ist ein anderes Thema.

Hey Oliver,
der erste Schritt ist schonmal getan! Wenn du weder mit C noch mit
C++ gearbeitet hast, fängst du ruhig erstmal mit C an und zwirbelst
dir, wenn du die Grundlagen verstanden hast, die Erweiterungen in
C++ rein. C++-Basics sind erforderlich, wenn du Programme mit Qt
schreiben willst. Und es stimmt - einen wirklich leichten Einstieg
(z. B. anhand der Tutorials) hast du, indem du Anwendungen für KDE (vorzugsweise mit KDevelop ;-)
schreibst.

Daniel

Die Meinungen, wie man am besten C++ lernt, gehen auseinander.

Wenn man bereits C++ kann oder über den Umweg über C zu C++ kommt, ist es auf förderlich, sich Lektüre zum Thema "Objekt Orientierung" zu Gemüte zu führen. Diese sind oft Sprachenunabhängig, aber sehr gut, um die Idee hinter OO zu verstehen.

Gruß,

</daniel>

@DCM, Daniel:

Warum ich der Meinung bin direkt mit C++ anzufangen anstatt sich mit C aufzuhalten, ist ganz einfach. C ist eine funktionale, prozedurorientierte Sprache, C++ zwar syntaktisch nur eine Erweiterung, aber technisch und philosophisch betrachtet eine Objektorientierte Sprache. Das sind zwei ganz verschiedene paar Schuhe. Wer C++ programmieren kann, kann eigentlich auch C programmieren, deshalb halte ich den Umweg über C für reine Zeitverschwendung. Vor allem, wenn man sich einfach mal an KDevelop ransetzt und die Qt Tutorials mal ausprobiert. Mal ehrlich, wer sich nen Videorecorder kauft, liest sich doch auch nicht die Bedienungsanleitung durch, nur wenn gar nix mehr geht :)

Anonymous: guck mal auf http://kandalf.homeip.net, da findest du die Infos zu KDevelop und den Qt tutorials. Fang einfach mal an und melde dich einfach bei mir oder im IRC auf irc.kde.org im Channel #kde wenn's Probleme gibt.
(Das gilt für alle anderen interessierten natürlich genauso und natürlich seid ihr alle herzlich eingeladen mit eurem neuen Wissen zum KDE-Projekt beizutragen)

Gruss,

Ralf

Und Ralf, schon deinen großen Konqui zu hause stehen? :)

Mal sehen ob es Ralf mal schaft die Worte C++ und KDevelop NICHT in einem Beitrag zusammen zu nutzen ;)

@LH: Nee, für den Konqui fehlt doch das Geld Aber die Wette würdest du wahrscheinlich jede Woche verlieren :))

Gruss,

Ralf

Unten steht weder was von C++ noch von KDevelop, also der Kommentar zählt nich. Hier der schon :))

Hehe, wir können ja einen "Ralf needs Konqui" Spenden aufruf machen

Ob nun zuerst C und dann C++ (oder umgekehrt) ist sicherlich eine Sache der Didaktik. Da C eine Untermenge von C++ ist macht es schon Sinn zuerst mit C anzufangen. Nach einem kurzem Ausflug in die objektorientierte Sichtweise ist C++ dann kein Problem mehr. Immerhin heisst die Devise Flexibilität! Wer C kann versteht auch die meisten anderen prozedurorientierten Sprachen. Und wer das objektorientierte Modell versteht, kommt dann auch mit C++, Java, Ruby usw. gut zurecht - weil sich die Konzepte doch ähneln.

@Arni: darum geht's nicht. Wenn ich C++ lernen will, fange ich mit C++ an, nicht mit C. Und aus meiner ganz beschränkten Sicht als Programmierer muss ich sagen, das Prozedurale Sprachen zu lernen dich hinterher von der Denkweise voll behindert. Ich hab mir auch ein C Buch gekauft und damit angefangen, heute wünschte ich mir, ich hätt's nicht getan sondern gleich mit
C++ angefangen und an KDevelop programmiert ;)

Übrigens ist KDevelop mein erstes Projekt direkt nach den Qt Tutorials und dem Editor-Example von Richard Moore geworden. Also, wer sagt das das äußerst schwierig sein soll ? Ausserdem, das was ich an der Uni über Modula2 gelernt habe als auch das was ich dort über C++ gelernt habe, konnte man eh in die Tonne hier einfügen. Weil einem die wahre Bedeutung von stack und heap sowie von Virtuellen Funktionen und Ableitungen und Klassen kommen dir eh erst wenn du mal mit Qt programmierst. Dann weisst du wie sowas auszusehen hat und auf den ersten Blick begreifst du, warum das gut ist und warum du deine Freizeit nicht mit anderen Dingen totschlagen sollst :))

Gruss,

Ralf

An DCM, Arni:

IMHO ist es kontraproduktiv, für C++ zunaechst mit C zu beginnen. Die reine Syntax hat man sich ohnehin schnell angeeignet, als C-Anfaenger wird man jedoch mit Dingen belastet, die unter C++ ueberfluessig sind (u.a. auch dank STL). Steigt man dann auf C++ um, wird man vermutlich mehr Muehe haben, sich die sein C-Verhalten wieder abzugewoehnen, als dass es Vorteile bringt.

Man kann eben unter C++ auch C programmieren... das scheint sogar unter C++ -Anfaengern verbreitet zu sein. Scheint an falscher (schlechter) Einstiegs-Literatur zu liegen(?)

Umgekehrt duerfte sich aber auch ein C++ -Entwickler mit reiner C-Programmierung zunaechst nicht ganz leicht tun.

Ist sicherlich alles Geschmackssache und beruht auf eigene Erfahrungen. Ich habe selbst vor mehr als 10 Jahren mit C angefangen und ein paar Jahre später mit C++. Für mich war das perfekt so. Ich profitiere heute aus den damit gemachten Erfahrungen. Letztlich muss das aber jeder für sich entscheiden.

IMHO gab es in einer der letzen Ct's einen Artikel über Qt und MFC.

Soweit ich mich erinnere, kann man in Qt den Dateinamen des zu ladenden Bildes gleich in Konstuktor angeben. Also "new QImage("bild.xpm")" oder so.

mfg
Gunnar

Hi!

http://doc.trolltech.com
oder $QTDIR/doc/html ist, was du suchst. Dort finden sich alle Qt Klassen mit Kurzbeschreibung, kompletter Referenz und Dokumentationen und meist auch Beispielen.

Komplexeren Konzepten, bei denen mehere Klassen involviert sind (z.B. Styles oder DOM) gibt es immer Extra Kapitel, die das Zusammenspiel der Klassen anhand von Beispielen erklären.

Du möchstest dir eventuell die Doku zu QPixmap und QImage ansehen.

Gruß,

</daniel>

Einen Toolkitvergleich zwischen Qt und Gtk gibt es hier:

http://klotski.berlios.de/kde/cmp-toolkits.html

Kein Angst. Ein zweiter Teil ist bereits in Arbeit und nach dem was ich hier an Kommentaren gelesen habe, wird es auch sicher noch einen dritten und vierten Teil geben.
Eventuell schiebe ich zwischen Teil1 und Teil2 noch einen Teil1.5 ein der dann das gleiche macht wie Teil1 nur eben nicht mit der QT- sondern der KDE-Lib. Nur um zu zeigen wie auch dies mit einem *.pro File möglich ist und um die kleinen Unterschiede im Quellcode von QT zu KDE aufzuzeigen. Was meinen die Leser, ist so ein QT/KDE Quellcodevergleich anhand des Listing 1: main.cpp / Listing2: QMainWindow.pro sinnvoll (einmalige Aktion) oder soll ich mich eher auf den eigentlichen QT Workshop konzentrieren ?

@Thomas: Ich würde da (in Anlehnung an meine docs auf http://kandalf.homeip.net ) bringen, wie Pakete mit automake und autoconf gemacht werden. tmake ist für denjenigen, der dein Programm nachher bei sich compilieren will, immer noch nicht das was er sich wünscht. Er will tar zxvf .tar.gz, ./configure; make; su -c"make install" machen, mehr nicht. Daher ist man als Programmierer dann mit tmake etwas aufgeschmissen und rpm's kannst du auch nur bringen für eine spezielle Distri genauso wie die Makefiles von tmake, wenn du sie in einem Tarball mitlieferst, ja auch nur für dein System gültig sind. Das ist der Knackpunkt an tmake, was Linux angeht. Für Windows ist das sicher die richtig(ere) Wahl, ideal ist daher eine Kombination von beidem. Da autoconf/automake aber nicht gerade trivial ist, sollte man darauf hinweisen, das kapptemplate aus dem kdesdk bzw. KDevelop dir ein Qt bzw. KDE Programm generieren können, das du einfach paketieren kannst, das automake/autoconf hat und damit sehr portable ist und das du rpm's machen kannst ohne von specfiles irgendeine Ahnung zu haben. Für die windows-variante kann man sich ja noch das .pro file selber schreiben und tmake verwenden. Ich würd das jedenfalls so aufziehen, und wenn ich auf apps.kde.com jemals ein KDE-Programm mit .pro files auffinden werde, weiss ich wem ich als erstes ne mail schreibe das das nicht das ist, wo man mit KDE unter Linux/UNIX hin wollte, nämlich für den Endanwender ein einfach zu compilierendes Paket über den Standardweg configure, make, make install. :)

Das sei nur als Anregung gedacht, wie gesagt halte ich tmake an sich nicht für eine schlechte Sache, um zu üben oder um unter Windows zu compilieren. Aber da wir hier auf Pro-Linux sind, sollte doch eher auf das Standard-Vorgehen unter Linux hingewiesen werden und tmake für die Windows-Variante erklärt werden.
Schreib mir mal ne mail dazu, wir könnten das ja zusammen machen bzw. könnte ich dir die tips zu den Artikeln geben wenn du sie schreibst.

Gruss,

Ralf
Ralf

Dazu muß man nichts "basteln". Benutze doch "winzip" oder "filzip". Die können so etwas. Wenn Du mir Deine Emailadresse gibst kann ich Dir das Programm auch zumailen.

Solche Tools gibt es doch schon. Ich glaube sogar der WindowsCommander kann Dateien aufsplitten. Das zusammenfügen unter linux z.b. mit cat datei.part1 datei.part2 > datei ist auch kein Problem (komfortabler gehts natürlich mit einem kleinen script)

NOT_UNDERSTAND

Der Unterschied ist das du einmal das Objekt auf dem Heap und einmal auf dem Stack anlegst. Im 1. Teil ist app ein Bezeichner, im 2.Teil ein Zeiger (d.h bei Funktionsaufrufen an app einmal
app.exec(); beim anderen mal (Zeiger) app->exec();)

Gruss,

Ralf

Zu der Deklaration "QApplication app = new QApplication(argc, argv)" sagt GCC 3.0 "conversion from `QApplication*' to non-scalar type `QApplication' requested"

Richtig wäre natürlich "QApplication *app = new QApplication(argc, argv)", denn "new" liefert grundsätzlich einen Pointer zurück. In Funktionen ist meist die Version "QApplication app(argc,argv)" sinnvoller, weil man sich da nicht darum kümmern muß, dass das Objekt wieder entfernt wird, wenn die Funktion beendet wird.

Der nächste Teil ist bereits in Arbeit...

nmake wird AFAIK immer mit installiert. Schau mal unter folgendem Pfad nach (wenn du in C:\Programme installiert hast): C:\Programme\DevStudio\VC\bin