Wird Zeit, dass endlich mehr OS Software in C++ geschrieben wird. Klar geht das alles auch in C, aber vernünftige Objektorientierung, sowie Destruktoren und Exceptions sind für große, komplexe Projekte schon ein Segen. Das macht nicht nur den Einstieg leichter sondern auch die Wartung.
Insgesamt begrüsse ich den Umstieg auf Qt. Nicht weil Qt unbedingt besser ist als GTK, sondern weil es den Einsatz von C++ fördert.
C++ ist die kaputteste Dreckssprache nach PHP. Der Behemoth der ekelhaften Syntaktischen Verbrechen und des schlechten Sprachdesigns. C war schon kaputt, C++ macht es nur noch schlimmer. Für den Einstieg:
Welche Idiotie. Der Hauptunterschied zwischen C++ und C ist, dass C++ (möglicherweise nicht ganz optimale) Lösungen für Probleme liefert, die C komplett auf den Programmierer abwälzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jan 2011 um 17:20.
Praxis: C/C++ ist die wichtigste compilierte Sprache PHP ist die wichtigste Scriptsprache im Web Qt ist ein gut strukturiertes Framework in C++ Man muss nicht alle Features einer Sprache exzessiv nutzen Siehe: Qt
C++ ist die kaputteste Dreckssprache nach PHP. Der Behemoth der ekelhaften Syntaktischen Verbrechen und des schlechten Sprachdesigns. C war schon kaputt, C++ macht es nur noch schlimmer. Für den Einstieg:
Defective C++ FQA Fefe's C++ Talk C++ Quotes Torvalds
c++ is a pile of crap.
Klar steht C++ im Vergleich zu vielen anderen objektorientierten Sprachen schlecht da. Es ist auch leicht die Fehler einer Programmiersprache herauszuheben und darauf einzubashen aber nicht zu zeigen wie man es in C eleganter lösen kann. Viele der Beispiele aus deinen Links wie z.B. ...
foo->bar(3)
... können einfach durch entsprechende Namenskonventionen gelöst werden. Klar, wenn "foo" und "bar" als Namen verwendet, dann ist das ne unleserliche Katastrophe.
Auch die Vorteile weitgehend zu ignorieren ist kein besonders guter Stil. Nehmen wir z.B. Exceptions. Die sind in C++ nicht besonders schön gelöst (keine Exceptions in Destruktoren und in Konstruktoren sollten sie vermieden werden). Wenn man sich allerdings dieser Einschränkungen bewusst ist, kann man wesentlich saubereren Code schreiben, als wenn man alle möglichen Fehlerwerte mit if-Konstrukten abfangen muss. Sorry, aber wenn nach einem Funktionsaufruf erstmal 10 if-Abfragen kommen, dann ist das einfach unleserlich. Daher kann man zwar auf C++ einbashen, das heisst aber nicht, dass es in C sauberer/eleganter gehen würde.
Je größer ein Projekt wird, desto wichtiger werden einfach Features wie Destruktoren und Exceptions.
Auch die Vorteile weitgehend zu ignorieren ist kein besonders guter Stil. Nehmen wir z.B. Exceptions. Die sind in C++ nicht besonders schön gelöst (keine Exceptions in Destruktoren und in Konstruktoren sollten sie vermieden werden).
Es ist richtig, dass man in einem Destruktor keine Exception werfen sollte, aber bei Konstruktoren ist das Unsinn. Exceptions sind die _einzige_ vernünftige Möglichkeit, einen Fehler in einem Konstruktor zu melden. Die einzige Alternative ist, in dem Objekt ein "Zombie-Flag" zu setzen, falls im Konstruktor etwas schief geht, und dann bei jeder Methode erstmal zu prüfen, ob man ein Zombie-Objekt vorliegen hat - das ist Gift für die Wartbarkeit.
Es ist richtig, dass man in einem Destruktor keine Exception werfen sollte, aber bei Konstruktoren ist das Unsinn. Exceptions sind die _einzige_ vernünftige Möglichkeit, einen Fehler in einem Konstruktor zu melden. Die einzige Alternative ist, in dem Objekt ein "Zombie-Flag" zu setzen, falls im Konstruktor etwas schief geht, und dann bei jeder Methode erstmal zu prüfen, ob man ein Zombie-Objekt vorliegen hat - das ist Gift für die Wartbarkeit.
Da gebe ich dir völlig recht. Ich habe mich nur in meinem Beitrag an die offizielle Ansi C++ Empfehlung gehalten. Die empfiehlt eben, dass man in Konstruktoren keine Exceptions wirft, weil man sie bei globalen statischen Variablen nicht abfangen kann (viele Compiler bieten aber eine solche Optionen). Wollte hier keine weiteren unnötigen Diskussionen herbeiführen. So wie diese hier :-)
Globale Variablen sollte man nach Möglichkeit sowieso vermeiden. Erst recht, wenn diese nichttriviale Konstruktoren aufweisen. Das Problem ist jedenfalls mitnichten C++-spezifisch.
Globale Variablen sollte man nach Möglichkeit sowieso vermeiden. Erst recht, wenn diese nichttriviale Konstruktoren aufweisen. Das Problem ist jedenfalls mitnichten C++-spezifisch.
Genau diese Art der sinnlosen Diskussion wollte ich vermeiden - nur eben in die andere Richtung. Ich weiss gar nicht warum du da jetzt drauf rumreitest, ich hab dir doch schon recht gegeben.
Du sollst eben nicht all deinen Code im Konstruktor parken. Der Konstruktor ist wie ein erweitertes malloc das es auch gleichzeitig erlaubt dafür zu sorgen, dass das erstellte Objekt in einem entsprechenden Anfangszustand ist.
Als C entdeckt wurde gab es noch keine Inseln sondern man musste sich das Land selbst aus dem Meer erheben lassen, Wasser abfliessen lassen und Himmel drumrum bauen.
Anwendungsfrickler haben unter Gnome die Wahl zwischen verschiedenen Sprachen. Ein C-Programmierer und wer direkt am Deskttop selbst arbeitet, greif meist auf GObject zurück:
Der Weg von C -> C++ "Vom Regen in die Traufe" trifft es nicht ganz. Mit C++ kann ich mich eher anfreunden als mit halbseidenen C-Lösungen, die objektorientiert geschrieben sind, aber vieles halt durch Konvetionen erzwungen worden ist. Da ist doch C++ angenehmer.
Ohne Garbagecollector sollte eigentlich heute gar nichts mehr laufen. Die Geschwindigkeitsvorteile, die sich einige Leute von Sprachen wie C/C++ versprechen, sind doch kaum haltbar, wenn die Fehleranzahl stark ansteigt.
Das ist als mit "Unity" gemeint. Der Linux-Desktop wird unter der Ägide von Mark und Canonical endlich vereint. Canonical pickt sich das Beste aus beiden Projekten raus. KDE, das von KDE-Libs abhängige Monstrum, das seit Version 4 an Qualität leidet (und das nach Jahren), Plasma over-engineered und instabil. Gnome auf der anderen Seite, unkoorporativ Canonical gegenüber und eigenbrödlerisch und konservativ. Jetzt bringt Canonical endlich mal Schwung her. Jetzt werden die KDE-Programme von KDE-libs bereinigt und mit Dconf ausgestattet, wogegen sich KDE so lange gesträubt hat. Und die Gnome-Programme werden mit Qt erweitert.
Wenn Du Dich auch nur einmal mit einem neueren KDE4 beschäftigt hättest, dann wüsstest Du, dass nicht Plasma das Problem ist. Zwischen Plasma in KDE 4.5 und KDE 4.0 liegen Welten.
Was Gnome anbelangt: Canonical ist (bzw. erscheint) unkooperativ, nicht Gnome. Im übrigen versucht OpenSuse, jetzt einige Gnome-Änderungen von Ubuntu zu übernehmen, einzuarbeiten und bei Upstream durchzusetzen, was ja eigentlich Canonicals Job gewesen wäre.
Canonical selbst möchte anscheinend in Zukunft zumindest "oberflächlich" Gnome als sichtbaren Desktop (Gnome2, Gnome3 mit oder ohne Gnome-Shell) völlig verschwinden lassen.
Aber: Wenn Unity einigermaßen funktioniert, steht der "aktiven" Übernahme u.a. durch OpenSuse nichts im Wege. Warum auch? Freie Software boykottiert man nicht.
Wenn Du Dich auch nur einmal mit einem neueren KDE4 beschäftigt hättest, dann wüsstest Du, dass nicht Plasma das Problem ist. Zwischen Plasma in KDE 4.5 und KDE 4.0 liegen Welten.
Dann ist es halt KWin.
Was Gnome anbelangt: Canonical ist (bzw. erscheint) unkooperativ, nicht Gnome. Im übrigen versucht OpenSuse, jetzt einige Gnome-Änderungen von Ubuntu zu übernehmen, einzuarbeiten und bei Upstream durchzusetzen, was ja eigentlich Canonicals Job gewesen wäre.
Canonical muss nicht OpenSuse den Hintern abwischen und ist zu gar nichts verpflichtet.
Frei nach dem Motto: Feuer frei, egal auf was. Das, was getroffen wird, wird es schon verdient haben.
"Canonical muss nicht OpenSuse den Hintern abwischen und ist zu gar nichts verpflichtet."
Da hast Du etwas missverstanden, eigentlich ist es genau umgekehrt: http://news.opensuse.org/2011/01/08/opensuse-weekly-news-issue-157-is-out/ Siehe hier "Atayana in OBS" und "Ubuntu patches going to GNOME".
Ich bin ja am Wochenende alle KWin Crashers des letzten halben Jahres durchgegangen und das sah mir überhaupt nicht danach aus, dass wir ein Stabilitätsproblem hätten. Insgesamt gab es nur drei häufig auftretende Crashers, wovon einer bereits lange behoben ist und zwei in den Treibern sind, davon einer sowohl in Mesa behoben als auch von uns in 4.6 umgangen ist. Der dritte scheint wohl mit dem in 4.7 neuen OpenGL 2 Backend umgehbar zu sein.
Aber es ist natürlich denkbar, dass bei dir KWin komplett instabil ist und du nur noch nicht dazugekommen bist, uns die Crasher zu melden
| Aber es ist natürlich denkbar, dass bei dir KWin komplett instabil ist und du nur noch nicht dazugekommen bist, uns die Crasher zu melden |
der war nicht schlecht. Ich kann auch keine Abstürze hier unter openSUSE feststellen, wobei ich KDE4 auch nur zum Testen benutze. Die neue Version ist ja nun wirklich schnell geworden, nur der Start von KDE4 dauert länger als der komplette Systemstart. Warum eigentlich? Unter irgendeinem Meilenstein (11.3 M6?) war das mal nicht der Fall. In der finalen 11.3/KDE4 geht das nun wieder fürchterlich langsam vonstatten. Also benutze ich weiterhin die 11.3/KDE3, unter anderem auch weil KDE4 immer noch nicht die Antriebe meiner externen USB-Platten abschalten kann. Für die 11.3/KDE3 stellt das auch weiterhin kein Problem dar (über Miniprogramm Speichermedien). Aber ich gebe die Hoffnung nicht auf. Irgendwann bekommt ihr das schon noch geregelt. Ansonsten macht ihr schon klasse Arbeit. Man sieht schon das sich was tut.
Von openSUSE11.3kde4usb am Mi, 19. Januar 2011 um 03:59 #
"unter anderem auch weil KDE4 immer noch nicht die Antriebe meiner externen USB-Platten abschalten kann"
Mit einem externen USB-Festplattenproblem kann ich auch dienen. Ich habe unter openSUSE 11.3 mit KDE4 das merkwürdige Problem, dass eine gerade gemountete USB-Festplatte nach ca. 11 Sekunden wieder automatisch unmountet wird, obwohl ich das nicht veranlasst habe. Unter /var/log/messages steht dann, ich (der "user") hätte die Festplatte unmountet. Unter Gnome2 und KDE3 passiert das auf dem genau gleichen System nicht: Die externe USB-Festplatte bleibt gemountet. Ich habe keinen blassen Schimmer, wo hier der Fehler liegt.
Energieoptionen? Hatte vor kurzen das Problem mit nfs-shares von meinem Desktop. Kpowernowd hats nicht interressiert das die von meinem Laptop gemaountet waren
Von da-real-lala am Di, 18. Januar 2011 um 15:47 #
Wenn man KDE 4 in Kubuntu nutzt, dann ist es klar, dass man solch eine Meinung hat. Fuer mich laeuft KDE 4.4 zur Zeit sehr gut auf Debian Squeeze (und das hat immernoch HAL), welches immer noch nicht offiziell stabil ist. KDE 3 wird immenoch unterstuetzt. openSUSE's KDE ist auch nicht von schlechten Eltern -- vorausgesetzt man laesst halt die Finger vom andauernden Updaten aus Factory. Arch's KDE ist auch meisst sehr gut -- mit Kubuntu hatte ich nur Probleme.
Ausserdem: Plasma, genau wie KDE schon immer, hat halt einen anderen Ansatz als Gnome, Xfce, LXDE -- und zwar dem Benutzer alles moegliche zu bieten. Die Entscheidung KDE vor der 4.3 als stabil zu bezeichnen war ein Fehler finde ich, deshalb sind dann alle losgerannt um den Benutzern das Bling Bling zu bieten -- viele haben ihre Entscheidung ueber KDE auf Grund von Update fanatischen Distri wie Kubuntu getroffen. Dass KDE auch nicht jedermanns Geschmack ist, war ja auch klar. Debian hat da Update-technisch eine gute Entscheidung getroffen und openSUSE hatte zumindest etwas gewartet bis es KDE 4 offiziell gemacht hat und hat dann noch KDE3 untestuetzt.
Persoenlich finde ich das Mischen von Qt nicht schlimm solange es eben nicht KDE Libs reinzieht -- denn das macht den Unity Desktop dann langsamer beim Start -- was ja KDE Benutzern egal ist, Gnome und Ubuntu Nutzern aber ein Dorn im Auge ist (denn die moegen eben leichte UIs a la Mac). Aber da es ja nur fuer graphische Gimmicks benutzt wird, sollte es kein Problem sein.
Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum? Es gibt Gnome-Liebhaber, es gibt KDE-Liebhaber, es gibt Window-Manager-Fans... und es wird nun bald Unity- und Unity-2D-Fans geben. Nur einen Einheitsdesktop wird es nicht geben, weil jeder Versuch nur auf n+1 Desktops hinaus läuft... Dass Ubuntu allerdings dafür mit Unity das Risiko einzugehen scheint, die Debian-Stabilität über Bord gehen zu lassen, finde ich bemerkenswert.
> Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum? Das Problem ist, dass nicht nur die Desktops unterschiedlich sind, sondern auch die ganzen grundlegenden Bibliotheken (GUI-Toolkits und ähnliches), obwohl es dafür keinen vernünftigen Grund gibt. Entsprechend schlecht ist die Integration eines Qt-Programms auf einem Gnome-Desktop und umgekehrt, und es ist grandios, dass Canonical daran mal etwas ändert.
Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum?
Das Problem sind nicht die Desktops, sondern die Toolkits. Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit. Zum Photos nachbearbeiten nehme ich Digikam und gimp. Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw. Das bringt nur Nachteile für die User und Vorteile sehe ich eigentlich überhaupt keine. Und nur KDE/Qt oder gtk Programme zu verwenden, funktioniert auch nicht, weil die besten Programme halt oft nur für KDE/Qt oder gtk gibt.
Für kommerzielle Software ist die Vielfalt an Desktops unter Linux auch ein Hemmschuh, weil sich der Support einfach nicht lohnt. Mag ja Leute geben, die grundsätzlich keine kommerzielle Software verwenden, aber ich wäre schon froh, wenn es Photoshop und Corel Painter für Linux geben würde.
Letztendlich ist der Desktop eher unwichtig, was wirklich wichtig ist, ist Software. Ich würde lieber einen Desktop benutzen, der mir nicht so liegt, als auf gute Software und konsistente Bedienung zu verzichten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jan 2011 um 17:00.
"Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit."
Das mache ich genauso. Trotz mittlerweile bescheidener Hardware nutze ich querbeet das, was ich tatsächlich an Software benötige. Ich habe früher sogar Epiphany-Gecko unter KDE benutzt.
"Mag ja Leute geben, die grundsätzlich keine kommerzielle Software verwenden, aber ich wäre schon froh, wenn es Photoshop und Corel Painter für Linux geben würde."
Ich kann die Hersteller nur ermuntern, genau das zu tun. Adobe denkt ja mittlerweile darüber nach, Corel hat diesen Schritt schon lange hinter sich (u.a. mit Corel Linux (dem späteren Xandros Linux), Word Perfect für Linux sowie Corel Draw und Photopaint 9 für Linux), so dass aus der Corelecke hier wohl kein neuer Versuch unternommen werden wird.
> Word Perfect für Linux sowie Corel Draw und Photopaint 9 für Linux), so dass aus der Corelecke hier wohl kein neuer Versuch unternommen werden wird.
Word Perfect war damals schon so gut wie tot, auch unter Windows. Corel Draw gab es niemals für Linux und Corel Photopaint war kein echter Port, sondern eine per Wine portierte Windows-Anwendung. Das Programm hatte massive Darstellungsprobleme und war in meinen Augen nur ein halbherziger Versuch auf den damaligen Linux-Hype aufzuspringen. Hätte es Corel wirklich ernst mit der Linux-Unterstützung gemeint, wären sie am Ball geblieben.
Aber CorelDraw 9 gab es als käuflich erwerbbares Produkt für Linux: http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2001/04/Grafik-Suite-Corel-DRAW-9
In diesem Sinne war es nicht halbherzig. Dass Corel mit Linux nicht am Ball blieb, hat andere Gründe. Sie gerieten in "Schwierigkeiten" und wurden etwas später unter massiver Mithilfe von Microsoft gerettet: http://www.linuxplanet.com/linuxplanet/opinions/2409/1/
Danach gab Corel seine Linuxsparte nach und nach auf. Der angegebene Artikel nimmt das praktisch schon vorweg: http://www.linuxplanet.com/linuxplanet/opinions/2409/2/
>> Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw
Das zumindest ist unter Windows nicht anders. (Beispiel: Explorer > Nero > WinAmp). Aber wer Linux nicht unterstützen will findet immer einen Grund (ich meine jetzt Firmen, nicht dich).
Das stimmt, nur hat Windows halt > 90% Marktanteil und Linux auf dem Deskop weniger als 2-3 % Marktanteil. Wenn unter Linux Programme genauso inkonsistent zu benutzen sind, wie unter Windows, warum sollten dann Leute von Windows zu Linux wechseln? Und die meisten Windows-Programme haben wenigstens einheitliche Datei-Dialoge.
Ich benutze meinen Computer, um im Internet zu surfen, emails zu schreiben, meine Photos nachzubearbeiten, ab und zu einen Brief zu schreiben und zum Programmieren. Für keine dieser Tätigkeiten spielt es eine große Rolle, welchen Desktop ich verwende. Letztendlich könnte ich die Programme auch aus WMaker oder einem anderen einfachen Window-Manager starten. Aber die inkonsistente Bedienung und das inkonsistente Aussehen der Programme stört mich schon, auch wenn ich natürlich trotzdem damit arbeiten kann.
Apple hat es doch vorgemacht wie man auf dem Desktop Erfolg haben kann. Wie weit wäre MacOS X auf dem Desktop heute verbreitet, wenn die Software inkonsistent zu bedienen wäre und inkonsistent aussieht? Wieviel Erfolg hätte MacOS X auf dem Desktop, wenn jedes zweite Programm ein anderes Toolkit verwendet?
Mir ist natürlich klar, daß viele in ihrerer Freizeit an den Desktops / Programmen arbeiten. Da steht natürlich der eigene Spaß im Vordergrund und es ist eher zweitrangig ob die Arbeit Linux auf dem Desktop langfrisitig weiterbringt oder nicht. Und das ist auch völlig o.k. Ein Hobby ist eben ein Hobby und das muß für andere keinen Sinn machen. Aber welchen Vorteil die ganze Desktop-Zersplitterung aus User-Sicht haben kann, leuchtet mir wirklich nicht ein und ein richtig gutes Argument, welche Vorteile das für den User haben soll, habe ich auch noch nie gehört.
Das stimmt, nur hat Windows halt > 90% Marktanteil und Linux auf dem Deskop weniger als 2-3 % Marktanteil. Wenn unter Linux Programme genauso inkonsistent zu benutzen sind, wie unter Windows, warum sollten dann Leute von Windows zu Linux wechseln?
Ich habe noch niemand gesehen der wegen der Konsistenz von Windows zu GNU/Linux gewechselt ist. Computer-Nutzer, über alle Systeme hinweg, sind gewohnt das Programme unterschiedlich aussehen, nehmen das gar nicht mehr war und deswegen ist es auch kein Argument für/gegen einen Wechsel. Eine nette Anekdote am Rand: Ich habe mal einem typischen "windows-dau" Firefox als alternative installiert, er hat aber weiter fröhlich den IE verwendet. Nicht weil er besser war, weil er ihn gewohnt war, etc. Einfach, weil für ihn das IE Symbol das Synonym für "Internet" war. Ich habe dann mal heimlich den IE starter gelöscht und dem Firefox mit dem IE Logo versehen. Ergebnis: Seit dem Zeitpunkt an hat er den Firefox verwendet und nicht mal gemerkt, dass er einen anderen Browser startet.
Fazit: Wir als GNU/Linux User sind hier schon sehr verwöhnt in dem, dass wir mit ein paar kleinen Einschränkungen einen (relativ) konsistenten Desktop einrichten können. Die große Masse interessiert das Thema aber gar nicht. Damit will ich nicht gegen die Bemühungen für mehr Konsistenz argumentieren. Ich möchte nur darum bitten diese richtig einzuordnen und mit Blick auf den "Otto-Normal-User" nicht über zu bewerten.
Apple hat es doch vorgemacht wie man auf dem Desktop Erfolg haben kann. Wie weit wäre MacOS X auf dem Desktop heute verbreitet, wenn die Software inkonsistent zu bedienen wäre und inkonsistent aussieht? Wieviel Erfolg hätte MacOS X auf dem Desktop, wenn jedes zweite Programm ein anderes Toolkit verwendet?
Sorry, aber Appel und Desktop Erfolg? Also ich glaube das man da genauso wenig von Erfolg sprechen kann wie bei GNU/Linux. Apple hat einen Zielgruppe, diese kauft Apple aber nicht weil es so schön konsistent ist (was sich übrigens auch schnell ändert wenn man nicht nur speziell für Apple geschriebene Software verwendet) sondern weil Apple es geschafft hat sich als (Oberklasse) Marke zu etablieren. Es gibt eine Gruppe von Leute die denken in Kategorien wie "Hans Wurst hat ein nur Notebook, ich ein iBook", "Hans Wurst hat nur ein MP3-Player, ich ein iPod", "Hans Wurst hat nur ein Smartphone, ich ein iPhone". Apple zieht seine Kunden aus einem aufgebauten Image des "besonderen" und aus nichts anderem.
Im Mutterland des Apfels ja. Dort sind die Preise auch nicht so überzogen wie bei uns.
Ich bin nur mal gespannt was mit Apple passiert, wenn Steve Jobs die Firma nicht weiter leiten kann. Das moderne Apple (Seit 1997) ist Steve Jobs. Vor Jobs vor Apple so gut wie pleite und nahezu tot. Erst nachdem er wieder die Leitung übernahm, ging es mit Apple wieder aufwärts. Ohne Jobs wird Apple wieder nur ein Unternehmen unter vielen werden.
Das Problem sind nicht die Desktops, sondern die Toolkits. Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit. Zum Photos nachbearbeiten nehme ich Digikam und gimp. Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw.
Das Problem sind auch nicht die Toolkits, sondern die unterschiedliche Vorstellungen und Anforderungen von Anwendern und Entwicklern. Wenn alle die gleiche Vorstellung von einem File-Dialog hätten, dann wären alle gleich, egal ob das Programm in Gtk, Qt, fltk, Cocoa, Window-Forms,.. geschrieben ist. Da es aber verschiedene Vorstellungen und Anforderungen gibt, gibt es unterschiedliche Entwürfe und das würde sich auch nicht ändern wenn alle das gleiche Toolkit verwenden würden. Der Qt File Dialog ist z.B. auch nicht der gleiche wie der KDE File Dialog.
Für kommerzielle Software ist die Vielfalt an Desktops unter Linux auch ein Hemmschuh, weil sich der Support einfach nicht lohnt.
Der Support hat damit gar nichts zu tun. Support wird für das Programm geleistet und nicht für das eingesetzte Betriebssystem, Windowmanager, etc. Und das Programm verhält sich überall gleich.
Der Qt File Dialog ist z.B. auch nicht der gleiche wie der KDE File Dialog.
Unter KDE schon. Sofern die Entwickler einer Applikation nicht explizit die Qt eigenen Dialoge benutzen, werden die der jeweiligen Plattform verwendet. D.h. unter Windows der Windows Dateidialog, unter KDE der KDE Dateidialog, usw.
Die Qt Demo Applikation "qtdemo" (z.B. unter Debian im Paket qt4-demos) hat unter Punkt "Standard Dialogs" dazu ein Demoprogramm, dass diese Integration bzw. deren explizites Abschalten vorzeigt.
Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme
...so geht es mir auch. Aber der Erfolg und die Qualität von GNU/Linux basiert nun mal auf der Dezentralität und der Option für sich die beste Kombination zu verwenden. Und was definitiv nicht geht ist, diese Auswahl an freier Software haben zu wollen und gleichzeitig einen Einheitsdesktop zu verlangen, denn der müsste als standardisierende Vorgabe oktroyiert werden.
"Wir wählen die Freiheit!" (Ernst Reuter, 9. September 1948)
Als normaler Anwender, ohne Ahnung von Toolkits, QT, GTK usw. klingt das Vorhaben eher positiv. Mich stört es z.B. nicht, wenn ich unter Ubuntu meine VirtualBox starte, deren Oberfläche wohl QT benutzt (oder wie man das nennt). Auch die HPLIPs sehen doch ganz ordentlich aus unter Ubuntu, auch die haben was mit QT zu tun.
Naja, das Beste wäre doch einfach, wenn alle Programme aus allen "Lagern" friedlich nebeneinander funktionieren würden und optisch eine Einheit darstellen.
Wie ist das eigentlich unter Windows gelöst, da sehen ja auch viele Programme unterschiedlich aus, manche benötigen VisualBasic, andere DOT.Net, ist das wie bei Linux und QT und GTK? Wenn ja, wieso gibt es da keinen solchen "Glaubenskrieg" (den ich als ziemlich kindisch halte )
> Wenn ja, wieso gibt es da keinen solchen "Glaubenskrieg" > (den ich als ziemlich kindisch halte)
Da kann ich Dir recht geben.
Ein Toolkit, oder SDK (Software Development Kit) besteht aus Bibliotheken und Werkzeugen zur Entwicklung. Die Bibliotheken nehmen dem Programmierer die Arbeit ab, etwas auf den Bildschirm zu bringen. Diese Bibliotheken zeichnen also z.B. Fenster, Buttons, Menus ... usw.
Davon gibt es nun mehrere konkurrierende Produkte (Qt, GTK, wxWidgets , ...)
Das ist nicht nur unter Linux so, sondern auch unter Windows und Mac.
Unter Windows gab und gibt es MFC (Microsoft Foundation Classes), Borland Lösungen wie Delphi, Visual Basic, Java und auch Qt und GTK
Man merkt den Unterschied häufig an unterschiedlichen Dateidialogen.
Das besondere an den Toolkits, die unter Linux gebräuchlich sind ist, dass man Programme, die man damit erstellt hat auch ohne größere Probleme auch für Windows und Mac anbieten kann. Man braucht da nur 1 Quelltext.
Im Gegesatz dazu laufen die MS Produkte NUR unter Windows.
Ich frage mal hier in die Runde, weil sich mit dem Thema vielleicht jemand hier auskennt:
Ich würde gerne einige Applikation in Common Lisp schreiben und vielleicht auch ein QT-Interface bereitstellen. Ich frage mich, wie man in einer anderen Sprache Qt-Bindings schreiben sollte.
Es gibt dazu schon einige Bindings, zum Beispiel CommonQt die nutzen wohl Smoke, um die Bindings zu realisieren. Aber angenommen eine C++-Bibliothek bietet so etwas nicht an, wie soll man dafür Bindings schreiben? Insbesondere bei QT ist es ja auch so (ich habe noch nie mit QT gearbeitet), dass es wohl kein korrektes C++ ist, sondern Erweiterungen wie das Slot-Konzept mitbringt.
Gibt es, außer erst ein komplettes C-Binding zu schreiben, einen generischen Weg um Bindings für C++-Bibliothen zu schreiben, bzw. gar generieren zu lassen?
Verwende den Generator http://swig.org/ um die Sprachanbindung zu generieren.
CLISP ist auch dabei. Man muss swig mit den Headern füttern und es generiert Dir das Sprachbinding. Wie vollständig das Binding wird, wenn Du das auf Qt loslässt, weiss ich allerdings nicht.
Ich würde gerne einige Applikation in Common Lisp schreiben und vielleicht auch ein QT-Interface bereitstellen. Ich frage mich, wie man in einer anderen Sprache Qt-Bindings schreiben sollte.
Du könntest Clojure und QtJambi nehmen. Ist wahrscheinlich nicht das, was du suchst, aber interessant wäre es allemal;-)
Clojure ist ein sehr interessantes Projekt, aber leider kein Common Lisp. Andere Lisp-Dialekte sind auch sehr schön, aber ehrlich gesagt finde ich das „Original” einfach besser. Es gibt aber auch eine Common Lisp Implementation für die JVM, das ist ABCL. Aber wenn ich das benutze würde wäre ich komplette auf ABCL und JVM festgelegt. Es ist dennoch sicherlich eine Option.
Diese Aussage bezieht sich nur auf die aktuelle Version von Unity. Diese wurde nur auf kleine Bildschirme angepasst. Die neue Version unter Ubuntu 11.04 wird ganz normal funktionieren, d.h. Anwendungen werden nicht automatisch maximiert.
Überall sieht man diese hochgezüchteten Desktops, aber niemand arbeitet damit. Am Ende gewinnt das funktionale.
- Foto von Hund, Kind oder Frau wird als Desktophintergrund genommen - Fenster erhalten keinen Schmuckrand, sondern ein schlichten blauen, mit abgerundeten Ecken - die Schalter für Vollbild, Schließen, Minimieren eines Fensters sind groß und eindeutig genug, dass man sie fehlerfrei anklicken kann.
Genau das kenne ich eigentlich von Windows her. Die ganzen Tweaks nerven da. Dann macht man es halt wieder wie du oben erwähnt hast. Aber Linux-Desktops habe ich schon extrem leckere gesehen (inklusive mein eigener ). Gnome kann da richtig toll ausschauen, KDE4 kann da richtig toll ausschauen. Das macht eigentlich nur noch Spass.
mittlerweile ist nicht mehr Mutter sondern Compiz der Window-Manager von Unity. Bei der Bekanntgabe, dass Unity und nicht die Gnome-Shell ab 11.04 als Standard zum Einsatz kommt wurde dies von Cannonical umgestellt. Als Grund wurden Performance-Probleme mit Mutter die Cannonical aufgrund mangelndem Know-how nicht lösen konnte genannt.
Habe es gestern mal installiert und muss sagen: Sauber! Es fehlen zwar definitiv noch einige Dinge, aber im Großen und Ganzen kann daraus wirklich was werden. Ich nutze es jetzt schon den ganzen Tag und habe nicht vor, das so schnell zu ändern :).
...habe UNITY auch ausprobiert: es steckt gewiss ein Mordsstück imposante Programmierarbeit drin. Aber: Unity löst auch die meisten Probleme, die ich ohne Unity gar nicht hatte!!!
Wird Zeit, dass endlich mehr OS Software in C++ geschrieben wird. Klar geht das alles auch in C, aber vernünftige Objektorientierung, sowie Destruktoren und Exceptions sind für große, komplexe Projekte schon ein Segen. Das macht nicht nur den Einstieg leichter sondern auch die Wartung.
Insgesamt begrüsse ich den Umstieg auf Qt. Nicht weil Qt unbedingt besser ist als GTK, sondern weil es den Einsatz von C++ fördert.
C++ ist die kaputteste Dreckssprache nach PHP. Der Behemoth der ekelhaften Syntaktischen Verbrechen und des schlechten Sprachdesigns. C war schon kaputt, C++ macht es nur noch schlimmer. Für den Einstieg:
Defective C++ FQA
Fefe's C++ Talk
C++ Quotes
Torvalds
c++ is a pile of crap.
Mein Lieblingsquote: "C++ is to C as Lung Cancer is to Lung."
Welche Idiotie. Der Hauptunterschied zwischen C++ und C ist, dass C++ (möglicherweise nicht ganz optimale) Lösungen für Probleme liefert, die C komplett auf den Programmierer abwälzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jan 2011 um 17:20.Mein Lieblingsquote: "C++ is to C as Lung Cancer is to Lung."
Ich finde auch, daß es elegantere Sprachen als C++ gibt, aber bei dem Zitat frage ich mich schon, ob das etwas über C++ oder über dich aussagt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jan 2011 um 16:50.> C++ ist die kaputteste Dreckssprache nach PHP.
Praxis:
C/C++ ist die wichtigste compilierte Sprache
PHP ist die wichtigste Scriptsprache im Web
Qt ist ein gut strukturiertes Framework in C++
Man muss nicht alle Features einer Sprache exzessiv nutzen Siehe: Qt
Klar steht C++ im Vergleich zu vielen anderen objektorientierten Sprachen schlecht da. Es ist auch leicht die Fehler einer Programmiersprache herauszuheben und darauf einzubashen aber nicht zu zeigen wie man es in C eleganter lösen kann. Viele der Beispiele aus deinen Links wie z.B. ...
foo->bar(3)
... können einfach durch entsprechende Namenskonventionen gelöst werden. Klar, wenn "foo" und "bar" als Namen verwendet, dann ist das ne unleserliche Katastrophe.
Auch die Vorteile weitgehend zu ignorieren ist kein besonders guter Stil. Nehmen wir z.B. Exceptions. Die sind in C++ nicht besonders schön gelöst (keine Exceptions in Destruktoren und in Konstruktoren sollten sie vermieden werden). Wenn man sich allerdings dieser Einschränkungen bewusst ist, kann man wesentlich saubereren Code schreiben, als wenn man alle möglichen Fehlerwerte mit if-Konstrukten abfangen muss. Sorry, aber wenn nach einem Funktionsaufruf erstmal 10 if-Abfragen kommen, dann ist das einfach unleserlich. Daher kann man zwar auf C++ einbashen, das heisst aber nicht, dass es in C sauberer/eleganter gehen würde.
Je größer ein Projekt wird, desto wichtiger werden einfach Features wie Destruktoren und Exceptions.
Da gebe ich dir völlig recht. Ich habe mich nur in meinem Beitrag an die offizielle Ansi C++ Empfehlung gehalten. Die empfiehlt eben, dass man in Konstruktoren keine Exceptions wirft, weil man sie bei globalen statischen Variablen nicht abfangen kann (viele Compiler bieten aber eine solche Optionen). Wollte hier keine weiteren unnötigen Diskussionen herbeiführen. So wie diese hier :-)
Globale Variablen sollte man nach Möglichkeit sowieso vermeiden. Erst recht, wenn diese nichttriviale Konstruktoren aufweisen. Das Problem ist jedenfalls mitnichten C++-spezifisch.
Genau diese Art der sinnlosen Diskussion wollte ich vermeiden - nur eben in die andere Richtung. Ich weiss gar nicht warum du da jetzt drauf rumreitest, ich hab dir doch schon recht gegeben.
Du sollst eben nicht all deinen Code im Konstruktor parken. Der Konstruktor ist wie ein erweitertes malloc das es auch gleichzeitig erlaubt dafür zu sorgen, dass das erstellte Objekt in einem entsprechenden Anfangszustand ist.
ich dachte immer c wäre eine insel ?
Als C entdeckt wurde gab es noch keine Inseln sondern man musste sich das Land selbst aus dem Meer erheben lassen, Wasser abfliessen lassen und Himmel drumrum bauen.
Kling verdächtig nach Populus
Anwendungsfrickler haben unter Gnome die Wahl zwischen verschiedenen Sprachen. Ein C-Programmierer und wer direkt am Deskttop selbst arbeitet, greif meist auf GObject zurück:
http://de.wikipedia.org/wiki/GObject
Anwendungsentwickler haben auch unter KDE die Wahl zwischen verschiedenen Sprachen.
Der Weg von C -> C++ "Vom Regen in die Traufe" trifft es nicht ganz. Mit C++ kann ich mich eher anfreunden als mit halbseidenen C-Lösungen, die objektorientiert geschrieben sind, aber vieles halt durch Konvetionen erzwungen worden ist. Da ist doch C++ angenehmer.
Ohne Garbagecollector sollte eigentlich heute gar nichts mehr laufen. Die Geschwindigkeitsvorteile, die sich einige Leute von Sprachen wie C/C++ versprechen, sind doch kaum haltbar, wenn die Fehleranzahl stark ansteigt.
Das ist als mit "Unity" gemeint. Der Linux-Desktop wird unter der Ägide von Mark und Canonical endlich vereint. Canonical pickt sich das Beste aus beiden Projekten raus. KDE, das von KDE-Libs abhängige Monstrum, das seit Version 4 an Qualität leidet (und das nach Jahren), Plasma over-engineered und instabil. Gnome auf der anderen Seite, unkoorporativ Canonical gegenüber und eigenbrödlerisch und konservativ. Jetzt bringt Canonical endlich mal Schwung her. Jetzt werden die KDE-Programme von KDE-libs bereinigt und mit Dconf ausgestattet, wogegen sich KDE so lange gesträubt hat. Und die Gnome-Programme werden mit Qt erweitert.
[...]das seit Version 4 an Qualität leidet (und das nach Jahren), Plasma over-engineered und instabil.[...]
Hast du in letzter Zeit KDE SC genutzt (Nein, ich meine nicht in Kubuntu)?
[...]Gnome auf der anderen Seite, unkoorporativ Canonical gegenüber[...]
Warum sollten GNOME-Entwickler Canonicals Arbeit übernehmen (ohne Gegenleistung)?
Ich bin gespannt, ob sich genügend KDE-Entwickler vor den Ubuntu-Karren spannen lassen.
Wenn Du Dich auch nur einmal mit einem neueren KDE4 beschäftigt hättest, dann wüsstest Du, dass nicht Plasma das Problem ist. Zwischen Plasma in KDE 4.5 und KDE 4.0 liegen Welten.
Was Gnome anbelangt: Canonical ist (bzw. erscheint) unkooperativ, nicht Gnome. Im übrigen versucht OpenSuse, jetzt einige Gnome-Änderungen von Ubuntu zu übernehmen, einzuarbeiten und bei Upstream durchzusetzen, was ja eigentlich Canonicals Job gewesen wäre.
Canonical selbst möchte anscheinend in Zukunft zumindest "oberflächlich" Gnome als sichtbaren Desktop (Gnome2, Gnome3 mit oder ohne Gnome-Shell) völlig verschwinden lassen.
Aber: Wenn Unity einigermaßen funktioniert, steht der "aktiven" Übernahme u.a. durch OpenSuse nichts im Wege.
Warum auch? Freie Software boykottiert man nicht.
Dann ist es halt KWin.
Canonical muss nicht OpenSuse den Hintern abwischen und ist zu gar nichts verpflichtet.
"Dann ist es halt KWin."
Frei nach dem Motto: Feuer frei, egal auf was. Das, was getroffen wird, wird es schon verdient haben.
"Canonical muss nicht OpenSuse den Hintern abwischen und ist zu gar nichts verpflichtet."
Da hast Du etwas missverstanden, eigentlich ist es genau umgekehrt:
http://news.opensuse.org/2011/01/08/opensuse-weekly-news-issue-157-is-out/
Siehe hier "Atayana in OBS" und "Ubuntu patches going to GNOME".
Aber es ist natürlich denkbar, dass bei dir KWin komplett instabil ist und du nur noch nicht dazugekommen bist, uns die Crasher zu melden
| Aber es ist natürlich denkbar, dass bei dir KWin komplett instabil ist und du nur noch nicht dazugekommen bist, uns die Crasher zu melden |
der war nicht schlecht. Ich kann auch keine Abstürze hier unter openSUSE feststellen, wobei ich KDE4 auch nur zum Testen benutze. Die neue Version ist ja nun wirklich schnell geworden, nur der Start von KDE4 dauert länger als der komplette Systemstart. Warum eigentlich? Unter irgendeinem Meilenstein (11.3 M6?) war das mal nicht der Fall. In der finalen 11.3/KDE4 geht das nun wieder fürchterlich langsam vonstatten.
Also benutze ich weiterhin die 11.3/KDE3, unter anderem auch weil KDE4 immer noch nicht die Antriebe meiner externen USB-Platten abschalten kann. Für die 11.3/KDE3 stellt das auch weiterhin kein Problem dar (über Miniprogramm Speichermedien). Aber ich gebe die Hoffnung nicht auf. Irgendwann bekommt ihr das schon noch geregelt.
Ansonsten macht ihr schon klasse Arbeit. Man sieht schon das sich was tut.
"unter anderem auch weil KDE4 immer noch nicht die Antriebe meiner externen USB-Platten abschalten kann"
Mit einem externen USB-Festplattenproblem kann ich auch dienen.
Ich habe unter openSUSE 11.3 mit KDE4 das merkwürdige Problem, dass eine gerade gemountete USB-Festplatte nach ca. 11 Sekunden wieder automatisch unmountet wird, obwohl ich das nicht veranlasst habe. Unter /var/log/messages steht dann, ich (der "user") hätte die Festplatte unmountet. Unter Gnome2 und KDE3 passiert das auf dem genau gleichen System nicht: Die externe USB-Festplatte bleibt gemountet.
Ich habe keinen blassen Schimmer, wo hier der Fehler liegt.
Energieoptionen?
Hatte vor kurzen das Problem mit nfs-shares von meinem Desktop.
Kpowernowd hats nicht interressiert das die von meinem Laptop gemaountet waren
Lg Mig
Hier musste ich echt lachen, danke!
Wenn man KDE 4 in Kubuntu nutzt, dann ist es klar, dass man solch eine Meinung hat. Fuer mich laeuft KDE 4.4 zur Zeit sehr gut auf Debian Squeeze (und das hat immernoch HAL), welches immer noch nicht offiziell stabil ist. KDE 3 wird immenoch unterstuetzt. openSUSE's KDE ist auch nicht von schlechten Eltern -- vorausgesetzt man laesst halt die Finger vom andauernden Updaten aus Factory. Arch's KDE ist auch meisst sehr gut -- mit Kubuntu hatte ich nur Probleme.
Ausserdem: Plasma, genau wie KDE schon immer, hat halt einen anderen Ansatz als Gnome, Xfce, LXDE -- und zwar dem Benutzer alles moegliche zu bieten. Die Entscheidung KDE vor der 4.3 als stabil zu bezeichnen war ein Fehler finde ich, deshalb sind dann alle losgerannt um den Benutzern das Bling Bling zu bieten -- viele haben ihre Entscheidung ueber KDE auf Grund von Update fanatischen Distri wie Kubuntu getroffen. Dass KDE auch nicht jedermanns Geschmack ist, war ja auch klar. Debian hat da Update-technisch eine gute Entscheidung getroffen und openSUSE hatte zumindest etwas gewartet bis es KDE 4 offiziell gemacht hat und hat dann noch KDE3 untestuetzt.
Persoenlich finde ich das Mischen von Qt nicht schlimm solange es eben nicht KDE Libs reinzieht -- denn das macht den Unity Desktop dann langsamer beim Start -- was ja KDE Benutzern egal ist, Gnome und Ubuntu Nutzern aber ein Dorn im Auge ist (denn die moegen eben leichte UIs a la Mac). Aber da es ja nur fuer graphische Gimmicks benutzt wird, sollte es kein Problem sein.
Von GTK abzulassen und sich QT zuzuwenden ist immer ein Schritt in die richtige Richtung.
Ja, denn Qt ist ein fantastisches Toolkit. Sehr sauber designet.
Und hat Zukunft.
Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum? Es gibt Gnome-Liebhaber, es gibt KDE-Liebhaber, es gibt Window-Manager-Fans... und es wird nun bald Unity- und Unity-2D-Fans geben. Nur einen Einheitsdesktop wird es nicht geben, weil jeder Versuch nur auf n+1 Desktops hinaus läuft...
Dass Ubuntu allerdings dafür mit Unity das Risiko einzugehen scheint, die Debian-Stabilität über Bord gehen zu lassen, finde ich bemerkenswert.
Xfce-Fans, KDE3-Fans, KDE4-Fans, Gnome2-Panel-Fans, Gnome3-Shell-Fans, Unity-3D-Compiz-Fans, Unity-2D-Qt-Fans, LXDE-Fans, Enlightenment-Fans, ...
Ubuntu und "Debian-Stabilität"? Du meinst die vielen verpatchten Pakete aus unstable?
*gähn*
> Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum?
Das Problem ist, dass nicht nur die Desktops unterschiedlich sind, sondern auch die ganzen grundlegenden Bibliotheken (GUI-Toolkits und ähnliches), obwohl es dafür keinen vernünftigen Grund gibt. Entsprechend schlecht ist die Integration eines Qt-Programms auf einem Gnome-Desktop und umgekehrt, und es ist grandios, dass Canonical daran mal etwas ändert.
Debian Stabilität - Ist die jemals bei Ubuntu angekommen?
Stabilität ist in den Sourcen fundiert, nicht in den Binaries - und dazu tragen beide Projekte bei.
Was ich beim besten Willen nicht verstehe, ist dieses offenbar nicht tot zu kriegende Verlangen nach einem "Einheitsdesktop" unter Linux. Warum?
Das Problem sind nicht die Desktops, sondern die Toolkits. Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit. Zum Photos nachbearbeiten nehme ich Digikam und gimp. Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw. Das bringt nur Nachteile für die User und Vorteile sehe ich eigentlich überhaupt keine. Und nur KDE/Qt oder gtk Programme zu verwenden, funktioniert auch nicht, weil die besten Programme halt oft nur für KDE/Qt oder gtk gibt.
Für kommerzielle Software ist die Vielfalt an Desktops unter Linux auch ein Hemmschuh, weil sich der Support einfach nicht lohnt. Mag ja Leute geben, die grundsätzlich keine kommerzielle Software verwenden, aber ich wäre schon froh, wenn es Photoshop und Corel Painter für Linux geben würde.
Letztendlich ist der Desktop eher unwichtig, was wirklich wichtig ist, ist Software. Ich würde lieber einen Desktop benutzen, der mir nicht so liegt, als auf gute Software und konsistente Bedienung zu verzichten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Jan 2011 um 17:00.Volle Zustimmung, sehr guter Beitrag.
"Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit."
Das mache ich genauso.
Trotz mittlerweile bescheidener Hardware nutze ich querbeet das, was ich tatsächlich an Software benötige. Ich habe früher sogar Epiphany-Gecko unter KDE benutzt.
"Mag ja Leute geben, die grundsätzlich keine kommerzielle Software verwenden, aber ich wäre schon froh, wenn es Photoshop und Corel Painter für Linux geben würde."
Ich kann die Hersteller nur ermuntern, genau das zu tun. Adobe denkt ja mittlerweile darüber nach, Corel hat diesen Schritt schon lange hinter sich (u.a. mit Corel Linux (dem späteren Xandros Linux), Word Perfect für Linux sowie Corel Draw und Photopaint 9 für Linux), so dass aus der Corelecke hier wohl kein neuer Versuch unternommen werden wird.
> Word Perfect für Linux sowie Corel Draw und Photopaint 9 für Linux), so dass aus der Corelecke hier wohl kein neuer Versuch unternommen werden wird.
Word Perfect war damals schon so gut wie tot, auch unter Windows. Corel Draw gab es niemals für Linux und Corel Photopaint war kein echter Port, sondern eine per Wine portierte Windows-Anwendung. Das Programm hatte massive Darstellungsprobleme und war in meinen Augen nur ein halbherziger Versuch auf den damaligen Linux-Hype aufzuspringen. Hätte es Corel wirklich ernst mit der Linux-Unterstützung gemeint, wären sie am Ball geblieben.
Das mit Wine stimmt.
Aber CorelDraw 9 gab es als käuflich erwerbbares Produkt für Linux:
http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2001/04/Grafik-Suite-Corel-DRAW-9
In diesem Sinne war es nicht halbherzig. Dass Corel mit Linux nicht am Ball blieb, hat andere Gründe. Sie gerieten in "Schwierigkeiten" und wurden etwas später unter massiver Mithilfe von Microsoft gerettet:
http://www.linuxplanet.com/linuxplanet/opinions/2409/1/
Danach gab Corel seine Linuxsparte nach und nach auf.
Der angegebene Artikel nimmt das praktisch schon vorweg:
http://www.linuxplanet.com/linuxplanet/opinions/2409/2/
> Aber CorelDraw 9 gab es als käuflich erwerbbares Produkt für Linux.
Sorry, mein Fehler. Das wusste ich nicht. Ich kannte nur Photopaint (Gab es damals kostenlos, z.B. als Beilage von Zeitschriften).
Meine vollste Zustimmung. Und sehr freundlich formuliert
>> Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw
Das zumindest ist unter Windows nicht anders. (Beispiel: Explorer > Nero > WinAmp). Aber wer Linux nicht unterstützen will findet immer einen Grund (ich meine jetzt Firmen, nicht dich).
Ansonsnten hast du natürlich recht.
Das zumindest ist unter Windows nicht anders.
Das stimmt, nur hat Windows halt > 90% Marktanteil und Linux auf dem Deskop weniger als 2-3 % Marktanteil. Wenn unter Linux Programme genauso inkonsistent zu benutzen sind, wie unter Windows, warum sollten dann Leute von Windows zu Linux wechseln? Und die meisten Windows-Programme haben wenigstens einheitliche Datei-Dialoge.
Ich benutze meinen Computer, um im Internet zu surfen, emails zu schreiben, meine Photos nachzubearbeiten, ab und zu einen Brief zu schreiben und zum Programmieren. Für keine dieser Tätigkeiten spielt es eine große Rolle, welchen Desktop ich verwende. Letztendlich könnte ich die Programme auch aus WMaker oder einem anderen einfachen Window-Manager starten. Aber die inkonsistente Bedienung und das inkonsistente Aussehen der Programme stört mich schon, auch wenn ich natürlich trotzdem damit arbeiten kann.
Apple hat es doch vorgemacht wie man auf dem Desktop Erfolg haben kann. Wie weit wäre MacOS X auf dem Desktop heute verbreitet, wenn die Software inkonsistent zu bedienen wäre und inkonsistent aussieht? Wieviel Erfolg hätte MacOS X auf dem Desktop, wenn jedes zweite Programm ein anderes Toolkit verwendet?
Mir ist natürlich klar, daß viele in ihrerer Freizeit an den Desktops / Programmen arbeiten. Da steht natürlich der eigene Spaß im Vordergrund und es ist eher zweitrangig ob die Arbeit Linux auf dem Desktop langfrisitig weiterbringt oder nicht. Und das ist auch völlig o.k. Ein Hobby ist eben ein Hobby und das muß für andere keinen Sinn machen. Aber welchen Vorteil die ganze Desktop-Zersplitterung aus User-Sicht haben kann, leuchtet mir wirklich nicht ein und ein richtig gutes Argument, welche Vorteile das für den User haben soll, habe ich auch noch nie gehört.
Das stimmt, nur hat Windows halt > 90% Marktanteil und Linux auf dem Deskop weniger als 2-3 % Marktanteil. Wenn unter Linux Programme genauso inkonsistent zu benutzen sind, wie unter Windows, warum sollten dann Leute von Windows zu Linux wechseln?
Ich habe noch niemand gesehen der wegen der Konsistenz von Windows zu GNU/Linux gewechselt ist. Computer-Nutzer, über alle Systeme hinweg, sind gewohnt das Programme unterschiedlich aussehen, nehmen das gar nicht mehr war und deswegen ist es auch kein Argument für/gegen einen Wechsel. Eine nette Anekdote am Rand: Ich habe mal einem typischen "windows-dau" Firefox als alternative installiert, er hat aber weiter fröhlich den IE verwendet. Nicht weil er besser war, weil er ihn gewohnt war, etc. Einfach, weil für ihn das IE Symbol das Synonym für "Internet" war. Ich habe dann mal heimlich den IE starter gelöscht und dem Firefox mit dem IE Logo versehen. Ergebnis: Seit dem Zeitpunkt an hat er den Firefox verwendet und nicht mal gemerkt, dass er einen anderen Browser startet.
Fazit: Wir als GNU/Linux User sind hier schon sehr verwöhnt in dem, dass wir mit ein paar kleinen Einschränkungen einen (relativ) konsistenten Desktop einrichten können. Die große Masse interessiert das Thema aber gar nicht. Damit will ich nicht gegen die Bemühungen für mehr Konsistenz argumentieren. Ich möchte nur darum bitten diese richtig einzuordnen und mit Blick auf den "Otto-Normal-User" nicht über zu bewerten.
Apple hat es doch vorgemacht wie man auf dem Desktop Erfolg haben kann. Wie weit wäre MacOS X auf dem Desktop heute verbreitet, wenn die Software inkonsistent zu bedienen wäre und inkonsistent aussieht? Wieviel Erfolg hätte MacOS X auf dem Desktop, wenn jedes zweite Programm ein anderes Toolkit verwendet?
Sorry, aber Appel und Desktop Erfolg? Also ich glaube das man da genauso wenig von Erfolg sprechen kann wie bei GNU/Linux. Apple hat einen Zielgruppe, diese kauft Apple aber nicht weil es so schön konsistent ist (was sich übrigens auch schnell ändert wenn man nicht nur speziell für Apple geschriebene Software verwendet) sondern weil Apple es geschafft hat sich als (Oberklasse) Marke zu etablieren. Es gibt eine Gruppe von Leute die denken in Kategorien wie "Hans Wurst hat ein nur Notebook, ich ein iBook", "Hans Wurst hat nur ein MP3-Player, ich ein iPod", "Hans Wurst hat nur ein Smartphone, ich ein iPhone". Apple zieht seine Kunden aus einem aufgebauten Image des "besonderen" und aus nichts anderem.
> Sorry, aber Appel und Desktop Erfolg?
Im Mutterland des Apfels ja. Dort sind die Preise auch nicht so überzogen wie bei uns.
Ich bin nur mal gespannt was mit Apple passiert, wenn Steve Jobs die Firma nicht weiter leiten kann. Das moderne Apple (Seit 1997) ist Steve Jobs. Vor Jobs vor Apple so gut wie pleite und nahezu tot. Erst nachdem er wieder die Leitung übernahm, ging es mit Apple wieder aufwärts. Ohne Jobs wird Apple wieder nur ein Unternehmen unter vielen werden.
Das Problem sind nicht die Desktops, sondern die Toolkits. Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme unabhängig vom Toolkit. Zum Photos nachbearbeiten nehme ich Digikam und gimp. Die beiden Programme sind völlig inkonsistent zu bedienen, haben verschiedene File-Dialoge, verschiedenes Look & Feel (zum Teil kann man das mit Themes verbessern) usw.
Das Problem sind auch nicht die Toolkits, sondern die unterschiedliche Vorstellungen und Anforderungen von Anwendern und Entwicklern. Wenn alle die gleiche Vorstellung von einem File-Dialog hätten, dann wären alle gleich, egal ob das Programm in Gtk, Qt, fltk, Cocoa, Window-Forms,.. geschrieben ist. Da es aber verschiedene Vorstellungen und Anforderungen gibt, gibt es unterschiedliche Entwürfe und das würde sich auch nicht ändern wenn alle das gleiche Toolkit verwenden würden. Der Qt File Dialog ist z.B. auch nicht der gleiche wie der KDE File Dialog.
Für kommerzielle Software ist die Vielfalt an Desktops unter Linux auch ein Hemmschuh, weil sich der Support einfach nicht lohnt.
Der Support hat damit gar nichts zu tun. Support wird für das Programm geleistet und nicht für das eingesetzte Betriebssystem, Windowmanager, etc. Und das Programm verhält sich überall gleich.
Unter KDE schon.
Sofern die Entwickler einer Applikation nicht explizit die Qt eigenen Dialoge benutzen, werden die der jeweiligen Plattform verwendet.
D.h. unter Windows der Windows Dateidialog, unter KDE der KDE Dateidialog, usw.
Die Qt Demo Applikation "qtdemo" (z.B. unter Debian im Paket qt4-demos) hat unter Punkt "Standard Dialogs" dazu ein Demoprogramm, dass diese Integration bzw. deren explizites Abschalten vorzeigt.
Ich will mit meinem Rechner einfach arbeiten und nehme die für mich besten Programme
...so geht es mir auch. Aber der Erfolg und die Qualität von GNU/Linux basiert nun mal auf der Dezentralität und der Option für sich die beste Kombination zu verwenden. Und was definitiv nicht geht ist, diese Auswahl an freier Software haben zu wollen und gleichzeitig einen Einheitsdesktop zu verlangen, denn der müsste als standardisierende Vorgabe oktroyiert werden.
"Wir wählen die Freiheit!" (Ernst Reuter, 9. September 1948)
Als normaler Anwender, ohne Ahnung von Toolkits, QT, GTK usw. klingt das Vorhaben eher positiv. Mich stört es z.B. nicht, wenn ich unter Ubuntu meine VirtualBox starte, deren Oberfläche wohl QT benutzt (oder wie man das nennt). Auch die HPLIPs sehen doch ganz ordentlich aus unter Ubuntu, auch die haben was mit QT zu tun.
Naja, das Beste wäre doch einfach, wenn alle Programme aus allen "Lagern" friedlich nebeneinander funktionieren würden und optisch eine Einheit darstellen.
Wie ist das eigentlich unter Windows gelöst, da sehen ja auch viele Programme unterschiedlich aus, manche benötigen VisualBasic, andere DOT.Net, ist das wie bei Linux und QT und GTK? Wenn ja, wieso gibt es da keinen solchen "Glaubenskrieg" (den ich als ziemlich kindisch halte
)
Danke für die Antworten schonmal...!
> Wenn ja, wieso gibt es da keinen solchen "Glaubenskrieg"
> (den ich als ziemlich kindisch halte)
Da kann ich Dir recht geben.
Ein Toolkit, oder SDK (Software Development Kit) besteht aus Bibliotheken und Werkzeugen zur Entwicklung. Die Bibliotheken nehmen dem Programmierer die Arbeit ab, etwas auf den Bildschirm zu bringen. Diese Bibliotheken zeichnen also z.B. Fenster, Buttons, Menus ... usw.
Davon gibt es nun mehrere konkurrierende Produkte (Qt, GTK, wxWidgets
, ...)
Das ist nicht nur unter Linux so, sondern auch unter Windows und Mac.
Unter Windows gab und gibt es MFC (Microsoft Foundation Classes), Borland Lösungen wie Delphi, Visual Basic, Java
und auch Qt und GTK
Man merkt den Unterschied häufig an unterschiedlichen Dateidialogen.
Das besondere an den Toolkits, die unter Linux gebräuchlich sind ist,
dass man Programme, die man damit erstellt hat auch ohne größere Probleme auch für Windows und Mac anbieten kann. Man braucht da nur 1 Quelltext.
Im Gegesatz dazu laufen die MS Produkte NUR unter Windows.
Ich frage mal hier in die Runde, weil sich mit dem Thema vielleicht jemand hier auskennt:
Ich würde gerne einige Applikation in Common Lisp schreiben und vielleicht auch ein QT-Interface bereitstellen. Ich frage mich, wie man in einer anderen Sprache Qt-Bindings schreiben sollte.
Es gibt dazu schon einige Bindings, zum Beispiel CommonQt die nutzen wohl Smoke, um die Bindings zu realisieren. Aber angenommen eine C++-Bibliothek bietet so etwas nicht an, wie soll man dafür Bindings schreiben? Insbesondere bei QT ist es ja auch so (ich habe noch nie mit QT gearbeitet), dass es wohl kein korrektes C++ ist, sondern Erweiterungen wie das Slot-Konzept mitbringt.
Gibt es, außer erst ein komplettes C-Binding zu schreiben, einen generischen Weg um Bindings für C++-Bibliothen zu schreiben, bzw. gar generieren zu lassen?
Verwende den Generator
http://swig.org/
um die Sprachanbindung zu generieren.
CLISP ist auch dabei.
Man muss swig mit den Headern füttern und es generiert Dir das Sprachbinding.
Wie vollständig das Binding wird, wenn Du das auf Qt loslässt, weiss ich allerdings nicht.
Danke. Ich hätte nicht erwartet, dass es so ein Projekt gibt.
Das wird kaum funktionieren, da Qt mit moc eine Spracherweiterung ist. Und ich glaube nicht, dass swig diese kennt.
da könntest du natürlich recht haben.
für pyqt haben die anscheinend einen eigenen generator gebaut,
http://www.riverbankcomputing.co.uk/software/sip/intro
Ich würde gerne einige Applikation in Common Lisp schreiben und vielleicht auch ein QT-Interface bereitstellen. Ich frage mich, wie man in einer anderen Sprache Qt-Bindings schreiben sollte.
Du könntest Clojure und QtJambi nehmen. Ist wahrscheinlich nicht das, was du suchst, aber interessant wäre es allemal;-)
Danke für den Tipp.
Clojure ist ein sehr interessantes Projekt, aber leider kein Common Lisp. Andere Lisp-Dialekte sind auch sehr schön, aber ehrlich gesagt finde ich das „Original” einfach besser. Es gibt aber auch eine Common Lisp Implementation für die JVM, das ist ABCL. Aber wenn ich das benutze würde wäre ich komplette auf ABCL und JVM festgelegt. Es ist dennoch sicherlich eine Option.
>Programme starten in der Regel mit maximiertem Fenster.
Wer will das auf einem normalen Bildschirm?
? wer redet denn von "Normalem Bildschirm"?
Diese Aussage bezieht sich nur auf die aktuelle Version von Unity. Diese wurde nur auf kleine Bildschirme angepasst. Die neue Version unter Ubuntu 11.04 wird ganz normal funktionieren, d.h. Anwendungen werden nicht automatisch maximiert.
Überall sieht man diese hochgezüchteten Desktops, aber niemand arbeitet damit.
Am Ende gewinnt das funktionale.
- Foto von Hund, Kind oder Frau wird als Desktophintergrund genommen
- Fenster erhalten keinen Schmuckrand, sondern ein schlichten blauen, mit abgerundeten Ecken
- die Schalter für Vollbild, Schließen, Minimieren eines Fensters sind groß und eindeutig genug, dass man sie fehlerfrei anklicken kann.
Genau das kenne ich eigentlich von Windows her. Die ganzen Tweaks nerven da. Dann macht man es halt wieder wie du oben erwähnt hast. Aber Linux-Desktops habe ich schon extrem leckere gesehen (inklusive mein eigener
). Gnome kann da richtig toll ausschauen, KDE4 kann da richtig toll ausschauen. Das macht eigentlich nur noch Spass.
mittlerweile ist nicht mehr Mutter sondern Compiz der Window-Manager von Unity. Bei der Bekanntgabe, dass Unity und nicht die Gnome-Shell ab 11.04 als Standard zum Einsatz kommt wurde dies von Cannonical umgestellt. Als Grund wurden Performance-Probleme mit Mutter die Cannonical aufgrund mangelndem Know-how nicht lösen konnte genannt.
Habe es gestern mal installiert und muss sagen: Sauber!
Es fehlen zwar definitiv noch einige Dinge, aber im Großen und Ganzen kann daraus wirklich was werden. Ich nutze es jetzt schon den ganzen Tag und habe nicht vor, das so schnell zu ändern :).
...habe UNITY auch ausprobiert: es steckt gewiss ein Mordsstück imposante Programmierarbeit drin. Aber: Unity löst auch die meisten Probleme, die ich ohne Unity gar nicht hatte!!!