Am 22.02.2011 um 19:56 schrieb Berni _:
Mich plagt: die Unterschiede zw. Dialogen und Fenster (und Widgets) zu verstehen, mal so grundsätzlich. Obwohl das schau ich mir jetzt grad nochmal an. Zu wissen ob es gscheit ist ein Projekt mit UI anzufangen, oder besser alles ausschreiben. Was hat es mit dem moc auf sich? Das sind für mich ja alles noch Fachbegriffe! ;)
Ich arbeit an meiner ersten Cocoa App, mit MacRuby, und als Webdev der alles selber schreibt hab ich mich auch umstellen müssen mit diesem Interface Builder und so. Aber: Es lässt sich alles lernen, und wird schnell verständlich.
Ist QT ein weiser Schritt? Das gehört ja zu Nokia.
Es ist Open Source mit einer großen Firma dahinter. Besser als Open Source ohne Geld von Papa's Firma.
Wenn du mal im Lab wärst Georg, dann könnte ich dir zeigen was ich bis jetzt gemacht habe. Zeitvorgaben für mein Projekt habe ich, muss aber nicht die Woche sein.
bin ich auch, vielleicht hab ich ja als Mit-Anfänger auch schon Wissen das dir helfen kann. ciao, tom -- Thomas R. "TomK32" Koll just a geek trying to change the world http://ananasblau.com || http://photostre.am || http://photolog.at
Ist QT ein weiser Schritt? Das gehört ja zu Nokia. Es ist Open Source mit einer großen Firma dahinter. Besser als Open Source ohne Geld von Papa's Firma. Und es ist auch schon seit Jahren unmöglich, dass Trolltech/Nokia ihren Ball nehmen und vom Spielplatz abhauen könnten: <http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php>
Qt wird ja jetzt nochmal richtig interessant: <http://heise.de/-1194461> Ich würde mich auch gerne am Freitagabend dazuhängen für die ersten Schritte mit <http://code.google.com/p/perlqt4/>.
Am 22.02.2011 21:18, schrieb Berni _:
Ich suche (noch immer) das Sheet wo ALLE Klassen drauf sind mit Hierachy und so...
Hm, mit Hierarchy jetzt auf die schnelle auch nicht gefunden, nur f�r Qt3 ... Die Liste aus der Doc kennst ja sicher: http://doc.qt.nokia.com/4.6/classes.html Prinzipiell gilt: Von QObject is AFAIK alles abgeleitet, alle GUI-Elemente von von QWidget. F�r jede Klasse steht eh in der Doc drinnen von was sie ableitet und was von ihr ableitet, da kann man sich recht bequem durchklicken.
Am 22.02.2011 19:56, schrieb Berni _:
Mich plagt: die Unterschiede zw. Dialogen und Fenster (und Widgets) zu
In QT sind alle GUI-Element von QWidget abgeleitet, d.h. jedes Fenster und jeder Dialog, aber auch Kn�pfe, Lables, und alles andere sind prinzipiell mal auch QWidgets. Ein QDialog bietet im Gegensatz zu anderen Fensterarten die M�glichkeit, dass die Funktion, welche man zum Anzeigen aufruft, so lange blockt, bis man den Dialog wegklickt. Ist sinnvoll wenn man z.B. irgend eine Ja/Nein-Abfrage machen will, weil man einfach nur auf das Return von QDialog.exec() warten muss, und nicht einen EventHandler schreiben. Das Hauptfenster einer Applikation sollte normalerweise ein QMainWindow sein. F�r alle anderen Fenster, die nicht QMainWindow sind und auch nicht w�hrend der Anzeige blocken sollen, kann man direkt QWidget verwenden.
Zu wissen ob es gscheit ist ein Projekt mit UI anzufangen, oder besser alles ausschreiben. Was hat es mit dem moc auf sich?
Was Du hier mit "UI" meinst versteh ich jetzt nicht ganz. Komplizierte Fenster sollte man nat�rlich mit dem Designer machen, und dann aus den .ui Files die notwendigen Header erzeugen. Zum �ben w�r's aber schon sinnvoll wenn Du mal ein paar einfache Fenster direkt schreibst, damit Du sp�ter das Einbinden vom automatisch generierten Header aus dem .ui-File besser verstehst. Der moc (Meta-Object Compiler) erzeugt zus�tzliche cpp-Files, die f�r das Funktionieren von "Signals und Slots" notwendig sind. Signals und Slots sind eine sehr praktische M�glichkeit wie man Funktionen aufrufen und miteinander verbinden kann, die allerdings von der Sprache C++ nicht direkt unterst�tzt wird. Der moc muss daher die Source-Files parsen und zus�tzlichen Code erzeugen, damit das funktioniert.
Ist QT ein weiser Schritt? Das geh�rt ja zu Nokia.
Das ist nat�rlich immer eine Philosophie-Frage. Ich pers�nlich finde QT so ziemlich das beste universelle Frameworks �berhaupt, man kann richtig viel damit machen, es ist clever designed und l�uft auf verschiedenen Plattformen. Lizenz ist LGPL, d.h. es handelt sich um echte freie Software. Da "st�rt" auch Nokia nicht, f�r den Fall das die mal bl�d werden wird es sicher von der Community weiter gepflegt.
Wenn du mal im Lab w�rst Georg, dann k�nnte ich dir zeigen was ich bis jetzt gemacht habe. Zeitvorgaben f�r mein Projekt habe ich, muss aber nicht die Woche sein.
Bin voraussichtlich am Freitag da, nach Clifford's Kurs k�mma mal schauen. Sonst m�ss ma was ausmachen, vorzugsweise Wochenende .... Hoffe, das hilft bissl, Gr��e! Georg
Hi, (nitpick: bei Qt ist das "t" klein; QT = Quicktime) On Tue, Feb 22, 2011 at 08:47:28PM +0100, Georg Lippitsch wrote:
Am 22.02.2011 19:56, schrieb Berni _:
Mich plagt: die Unterschiede zw. Dialogen und Fenster (und Widgets) zu
In QT sind alle GUI-Element von QWidget abgeleitet, d.h. jedes Fenster und jeder Dialog, aber auch Kn�pfe, Lables, und alles andere sind prinzipiell mal auch QWidgets. Ein QDialog bietet im Gegensatz zu anderen Fensterarten die M�glichkeit, dass die Funktion, welche man zum Anzeigen aufruft, so lange blockt, bis man den Dialog wegklickt. Ist sinnvoll wenn man z.B. irgend eine Ja/Nein-Abfrage machen will, weil man einfach nur auf das Return von QDialog.exec() warten muss, und nicht einen EventHandler schreiben.
Das Hauptfenster einer Applikation sollte normalerweise ein QMainWindow sein. F�r alle anderen Fenster, die nicht QMainWindow sind und auch nicht w�hrend der Anzeige blocken sollen, kann man direkt QWidget verwenden.
Es gibt da auch noch QML/Qt Quick. Damit kann man in einer JavaScript-�hnlichen, deklarativen Sprache die UI definieren. Ist f�r Touch-UIs interessant (aber nicht nur). Eine QML-View "l�dt" man in ein QDeclarativeView (und die ist von QWidget abgeleitet). QML gibt's ab Qt 4.7. Man kann dann viele UI-Sachen direkt in JavaScript l�sen, wenn man mag (und meistens mag man). Und wenn die Zielplattform OpenGL (ES) kann, l�sst sich das (im Gegensatz zu QWidget-basierten UIs) auch gleich mal per Zweizeiler hardwarebeschleunigen; sogar GL-Shader lassen sich zuk�nftig einbauen, wenn man lustig ist[1]. Kommunikation zwischen C++ Backend und QML UI erfolgt dann �ber Properties, Signals und Slots, und das Trennen von UI und Backend-Code funktioniert mit diesem Ansatz sehr sch�n (man wird bissl dazu gezwungen).
Ist QT ein weiser Schritt? Das geh�rt ja zu Nokia.
Das ist nat�rlich immer eine Philosophie-Frage. Ich pers�nlich finde QT so ziemlich das beste universelle Frameworks �berhaupt, man kann richtig viel damit machen, es ist clever designed und l�uft auf verschiedenen Plattformen. Lizenz ist LGPL, d.h. es handelt sich um echte freie Software. Da "st�rt" auch Nokia nicht, f�r den Fall das die mal bl�d werden wird es sicher von der Community weiter gepflegt.
Qt gibt's unter 3 Lizenzen, das geht ungef�hr so (IANAL): * Kommerzielle Lizenz (grob gesagt: du musst �nderungen an Qt nicht teilen, und darfst statisch linken, ohne selbst (L)GPL sein zu m�ssen) * LGPL (du darfst deine closed source Anwendung dynamisch gegen Qt linken, musst �nderungen an Qt selbst aber unter die LGPL stellen) * GPL (nur wenn dein Programm auch unter die GPL f�llt) Meistens trifft aber eh die LGPL zu, au�er du willst dein closed source Programm statisch gegen Qt linken (zB wenn du auf Windows abzielst, und nur "eine kleine exe" ausliefern willst anstatt exe + die gro�en Qt DLLs).
Wenn du mal im Lab w�rst Georg, dann k�nnte ich dir zeigen was ich bis jetzt gemacht habe. Zeitvorgaben f�r mein Projekt habe ich, muss aber nicht die Woche sein.
Bin voraussichtlich am Freitag da, nach Clifford's Kurs k�mma mal schauen. Sonst m�ss ma was ausmachen, vorzugsweise Wochenende ....
Wenn QML/Qt Quick in Frage kommt, kann ich dir da auch gerne was zeigen. lg thp [1] http://youtu.be/VMz5Z_vdDSA
Am 22.02.2011 23:08, schrieb Thomas Perl:
Es gibt da auch noch QML/Qt Quick.
Stimmt, damit hab ich mich bisher leider noch kaum besch�ftigt (hab Qt gelernt lange bevor's das gab). Ist das auch f�r einfache GUIs mit einem Fenster und ein paar Textfeldern schon eine Erleichterung, oder erst wenn man eben Touch-Screens mit jeder menge blinkendem Zeugs machen will? Bei der Gelegenheit m�cht ich allerdings auch mal drauf hinweisen, dass Qt keinesfalls (wie manche vielleicht glauben) nur eine GUI-Bibliothek ist, sondern eben ein universelles Framework. Es gibt beispielsweise ein ausgezeichnetes Netzwerk-Modul, das gleich auch jede menge Layer 7 Protokolle unterst�tzt. Man kann z.B. mit ein paar Zeilen eine HTTPS-Verbindung aufbauen. In QtCore gibt's jede Menge Klassen f�r alle wichtigen Datenstrukturen (verschiedene Arten von Listen und assoziativen Listen), die sich dann wieder �ber verschiedene Iteratoren (STL- oder Java-Style) verwenden lassen. Dann nat�rlich Threads und Thread-Synchronisation, FileIO, Strings parsen, kurz so ziemlich alles was man halt eigentlich in jedem Programm braucht. Kann also auch sehr n�tzlich sein, wenn man Anwendungen ohne GUI schreibt.
Hi Georg, On Wed, Feb 23, 2011 at 01:01:50AM +0100, Georg Lippitsch wrote:
Am 22.02.2011 23:08, schrieb Thomas Perl:
Es gibt da auch noch QML/Qt Quick.
Stimmt, damit hab ich mich bisher leider noch kaum besch�ftigt (hab Qt gelernt lange bevor's das gab). Ist das auch f�r einfache GUIs mit einem Fenster und ein paar Textfeldern schon eine Erleichterung, oder erst wenn man eben Touch-Screens mit jeder menge blinkendem Zeugs machen will?
Kommt drauf an. So klassische "Forms" hat mit QWidgets im Designer wahrscheinlich schneller zusammengeklickt, aber wenn man ein ansprechendes UI haben will, ist QML schon besser. Probiers doch mal aus ;) Ist nicht ausschlie�lich f�r Touch-UIs, sondern auch f�r Maus- und Keyboard-UIs interessant. lg thp
Am 24.02.2011 00:26, schrieb Thomas Perl:
Kommt drauf an. So klassische "Forms" hat mit QWidgets im Designer wahrscheinlich schneller zusammengeklickt, aber wenn man ein ansprechendes UI haben will, ist QML schon besser. Probiers doch mal aus
Ja, sollt ich mir wirklich mal anschauen. Falls Du im Lab bist und wem was zeigst, w�rd ich mich gern dranh�ngen! Gru�, Georg
Hallo! On Thu, Feb 24, 2011 at 10:31:35AM +0100, Georg Lippitsch wrote:
Am 24.02.2011 00:26, schrieb Thomas Perl:
Kommt drauf an. So klassische "Forms" hat mit QWidgets im Designer wahrscheinlich schneller zusammengeklickt, aber wenn man ein ansprechendes UI haben will, ist QML schon besser. Probiers doch mal aus
Ja, sollt ich mir wirklich mal anschauen. Falls Du im Lab bist und wem was zeigst, w�rd ich mich gern dranh�ngen!
Ich bin gerne bereit einen kleinen QML Workshop (hands-on) zu halten. Jede(r), die/der da gerne dabei w�re, bekundet ihr/sein Interesse per E-Mail direkt an mich mit Wochen(end-)tagspr�ferenzen, und ich mach' dann einen Doodle-Poll draus. lg thp
Hallo, ich halte morgen ein Referat über P2P und Torrent. Kann sich bitte jemand den Text durchlesen und mir Verbesserungsvorschläge zukommen lassen(vor allem ob Inhaltliche Fehler bestehen). Peer-to-peer Hello, today I report about the network technology peer-to-peer(P2P) and the Internet protocol .torrent. "Peer-to-peer short P2P is a network technology which was developed on 1971 for the Usenet-Network. Before P2P we used normal servers which are the central system. Every computer get the file from there. The problems are if this one server gets problems the whole file isnt reach able. So smart heads started developing a new technology. They made a very simple plan to use the unused resources of every client which also has the file and share it to others. So, every client is also a host from that moment on he gets parts of the file. With this simple idea and technique we were able to speed up the very slowly download rate form then in a very cheap and efficient way. The infrastructure of a peer to peer network is pretty simple. One Seeder has the information first of all. A leecher comes and want to get the file, he get the information shared of the seeder. If the leecher get enough informations he can start also with seeding from the informations he is arriving form the first seeder. In the computer vocational we also say he loopthrough the informations. The next leecher makes the same and so we get a complex network between many clients and server. This is a very simple and cheap way because u are using your upload in less of the time u surf the web. Now to torrent. Torrent is a internet protocol which is based on P2P. The name torrent is english and means “Sturzbach” . The protocol was developed by the programmer Bram Cohen in 2001 in the age of 26 years. It is mostly used for illegal data because but it is getting more and more to a conventional technology. The base is also really pretty simple. You download the .torrent file from a Torrent Tracker(aufspürer). The file has all informations saved who is the seeder and where you get the files from. Also in the torrent-file is the checksum saved, which stopps the problem of bad-seeder which seed an other file and could bring you a virus on the computer. For downloading the informations you need a Torrent-Client like µTorrent or Transmission. Also you need the torrent-file from a tracker like thepiratebay. A main problem is that it is very simple to maintain popularly files, because there enough seeder. But after a while much seeder will stop seeding and the file is getting busy. To prevent this you need super-seeder which will seed the file with a NAS which is 24/7 connected and seeding to internet. Also you can use webseeder which have saved the file on a server. Wrap-up: Peer to peer: Peer-to-peer is a decentralized network technology The acronym of peer to peer is P2P Seeders have the whole information and share it to the Leechers Leechers are getting the information from seeders and share the gotten infromations to other leechers Seeders and leechers together are the peers The more Seeders and less Leechers the transfer rate is getting higher and higher If there is no Seeder and few Leechers you cant get the whole information P2P is used for sharing files, in chat protocols aka Skype and for big computer clusters(used for the LHC as example). Torrent: - is just used for file sharing is fully based on P2P the informations are decentralized saved on many computers the files are redundant saved Limewire, Vuze, uTorrent and co. are using this protocol the further development are using magnet-URLs instead of torrents files" Greets und danke
Internet protocol .torrent. .torrent ist eine Dateiendung. BitTorrent-Peers benutzen einen kleinen Zoo an Protokollen. Der Name ist BitTorrent, nicht einfach Torrent.
gets problems has problems
share it to others with others
A leecher […] want to […] he get wants to, gets
shared of shared by
the leecher get gets
informations Fehler kommt mehrmals vor. information
he is arriving receiving
In the computer vocational we also say he loopthrough the informations. streichen
makes the same does the same
u are using […] u surf the web we Bleibe bei den Pronomen, die du schon benutzt hast.
Now to torrent. streichen
Torrent is a internet protocol BitTorrent is a collection of Internet protocols
in the age of at the age of
illegal data Sowas gibt's nicht. unauthorised copying
because but it is getting more and more to a conventional technology It is becoming increasingly a common-place means for data exchange.
Tracker(aufspürer) Ne, das kommt von "to keep track". Du kannst Aufseher/Verwalter sagen.
who is the seeder and where you get the files from erstzen mit: the Internet addresses of seeders
Also in the torrent-file is the checksum saved Also, the .torrent file is checksummed
problem of bad-seeder of malicious seeders
an other file a different file
bring you a virus plant malicious software
Also you need the torrent-file from a tracker like thepiratebay. Das ist nicht korrekt, der Hash reicht aus, siehe Magnet-URIs.
popularly popular
there enough seeder there are enough seeders
much seeder many seeders
the file is getting busy is becoming rare
super-seeder which will seed the file with a NAS which is 24/7 connected Das Wort bedeutet etwas anderes. NAS ist auch Unsinn. Das ganze ersetzen mit: seeders who are always connected
webseeder which have saved the file on a server Web seeders who provide parts of the file via HTTP, which is the Web's chief protocol.
The more […] the transfer rate is getting higher and higher The more […], the higher is the transfer rate
aka for example
redundant redundantly
Außerdem möchte ich feststellen, dass "get" dein Lieblingsverb ist. Zähle mal nach, wie oft du es verwendet hast. Ein bisschen Variation wäre nicht schlecht, das verbessert dein Ausdrücksvermögen.
Vielen Dank. Werde es einfließen lassen :).
Heute.25.2. 16:00 U6 Alser Straße>Demo gegen Abschiebung von Yazid,der seit Donnerstag in Haft und im Hungerstreik ist!Bleiberecht für alle!Bitte weiterleiten!!
On 2011-02-24 11:46:48 +0100, Phileas Lebada wrote:
Hallo, ich halte morgen ein Referat über P2P und Torrent. Kann sich bitte jemand den Text durchlesen und mir Verbesserungsvorschläge zukommen lassen(vor allem ob Inhaltliche Fehler bestehen).
Peer-to-peer
Hello, today I report about the network technology peer-to-peer(P2P) and the Internet protocol .torrent.
"Peer-to-peer short P2P is a network technology which was developed on 1971 for the Usenet-Network.
Das geht sich zeitlich nicht aus. Usenet ist erst 1979/80 entstanden. Die Parallelen zwischen Usenet und P2P-Filesharing scheinen mir außerdem begrenzt zu sein. hp -- _ | Peter J. Holzer | Web 2.0 könnte man also auch übersetzen als |_|_) | Sysadmin WSR | "Netz der kleinen Geister". | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Oliver Cromm in desd
pronounciation reminder: Qt ... Cutie KDE ... Kiddie lg, mih PS. LaTeX ... layman's tex ... 'Lay Tech' :) 2011/2/22 Thomas Perl <thp@thpinfo.com>:
Hi,
(nitpick: bei Qt ist das "t" klein; QT = Quicktime)
On Tue, Feb 22, 2011 at 08:47:28PM +0100, Georg Lippitsch wrote:
Am 22.02.2011 19:56, schrieb Berni _:
Mich plagt: die Unterschiede zw. Dialogen und Fenster (und Widgets) zu
In QT sind alle GUI-Element von QWidget abgeleitet, d.h. jedes Fenster und jeder Dialog, aber auch Knöpfe, Lables, und alles andere sind prinzipiell mal auch QWidgets. Ein QDialog bietet im Gegensatz zu anderen Fensterarten die Möglichkeit, dass die Funktion, welche man zum Anzeigen aufruft, so lange blockt, bis man den Dialog wegklickt. Ist sinnvoll wenn man z.B. irgend eine Ja/Nein-Abfrage machen will, weil man einfach nur auf das Return von QDialog.exec() warten muss, und nicht einen EventHandler schreiben.
Das Hauptfenster einer Applikation sollte normalerweise ein QMainWindow sein. Für alle anderen Fenster, die nicht QMainWindow sind und auch nicht während der Anzeige blocken sollen, kann man direkt QWidget verwenden.
Es gibt da auch noch QML/Qt Quick. Damit kann man in einer JavaScript-ähnlichen, deklarativen Sprache die UI definieren. Ist für Touch-UIs interessant (aber nicht nur). Eine QML-View "lädt" man in ein QDeclarativeView (und die ist von QWidget abgeleitet). QML gibt's ab Qt 4.7. Man kann dann viele UI-Sachen direkt in JavaScript lösen, wenn man mag (und meistens mag man). Und wenn die Zielplattform OpenGL (ES) kann, lässt sich das (im Gegensatz zu QWidget-basierten UIs) auch gleich mal per Zweizeiler hardwarebeschleunigen; sogar GL-Shader lassen sich zukünftig einbauen, wenn man lustig ist[1].
Kommunikation zwischen C++ Backend und QML UI erfolgt dann über Properties, Signals und Slots, und das Trennen von UI und Backend-Code funktioniert mit diesem Ansatz sehr schön (man wird bissl dazu gezwungen).
Ist QT ein weiser Schritt? Das gehört ja zu Nokia.
Das ist natürlich immer eine Philosophie-Frage. Ich persönlich finde QT so ziemlich das beste universelle Frameworks überhaupt, man kann richtig viel damit machen, es ist clever designed und läuft auf verschiedenen Plattformen. Lizenz ist LGPL, d.h. es handelt sich um echte freie Software. Da "stört" auch Nokia nicht, für den Fall das die mal blöd werden wird es sicher von der Community weiter gepflegt.
Qt gibt's unter 3 Lizenzen, das geht ungefähr so (IANAL):
* Kommerzielle Lizenz (grob gesagt: du musst Änderungen an Qt nicht teilen, und darfst statisch linken, ohne selbst (L)GPL sein zu müssen) * LGPL (du darfst deine closed source Anwendung dynamisch gegen Qt linken, musst Änderungen an Qt selbst aber unter die LGPL stellen) * GPL (nur wenn dein Programm auch unter die GPL fällt)
Meistens trifft aber eh die LGPL zu, außer du willst dein closed source Programm statisch gegen Qt linken (zB wenn du auf Windows abzielst, und nur "eine kleine exe" ausliefern willst anstatt exe + die großen Qt DLLs).
Wenn du mal im Lab wärst Georg, dann könnte ich dir zeigen was ich bis jetzt gemacht habe. Zeitvorgaben für mein Projekt habe ich, muss aber nicht die Woche sein.
Bin voraussichtlich am Freitag da, nach Clifford's Kurs kömma mal schauen. Sonst müss ma was ausmachen, vorzugsweise Wochenende ....
Wenn QML/Qt Quick in Frage kommt, kann ich dir da auch gerne was zeigen.
lg thp
[1] http://youtu.be/VMz5Z_vdDSA
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at http://lists.metalab.at/mailman/listinfo/metalab
Teilnehmer (8)
-
Anonymous User -
Georg Lippitsch -
Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 -
Michael Hauser -
Peter J. Holzer -
Phileas Lebada -
Thomas Perl -
Thomas R. Koll