Wäre ja durchaus mal sinnvoll, wenn die GTK Laute sich um bessere Integration in KDE bemühen würden. Es gibt Sinn für zwei Desktopumgebungen oder mehr, aber GTK unter KDE muss in KDE sich besser integrieren. Besonders im Konfigurationsbereich und bei den Farbschemata ist die Inkompatibilität schon ein sichtbares Ding. Unter der Haube noch viel schlimmer. Das führt dann dazu, dass Programmierer lieber eine separate QT-Applikation bauen, um nicht ein Alien zu werden. Als ob das GUI Entwicklungssystem mit der Desktopumgebung verheiratet wäre. Warum soll eine GTK Applikation unter KDE nicht nach KDE integrieren, unter Windows nach Win, unter Mac OS X nach Mac OS X und unter Gnome nach Gnome? Warum muss eine GTK Application krampfhaft anders aussehen als eine QT Application?
ok das kann man auch umdrehen. Wieso integriert sich Qt nicht in einen GTK-basierten Desktop?
Wenn man möchte, dass es optisch passend aussieht gibt es ja einige Themes und Engines, die versuchen dass z.B. GTK wie Qt aussieht.
Aber ich bezweifle, dass die Entwickler eines Toolkits unbedingt daran interessiert sind, dass sich ihr Toolkit in Anwendungen eines anderen integriert. Sicherlich wäre es nicht schlecht, aber es wird nicht das Hauptziel sein. Und selbst dann stellt sich eben die Frage, welches Toolkit sich in welches integrieren sollte.
Gerade im Bereich Konfiguration wird ja derzeit bei KDE sowieso recht laut über radikale Ansätze nachgedacht, Registry und dergleichen. Da wäre es gut, wenn nicht jeder sein eigenes Süppchen kocht, sondern zusammen gearbeitet wird.
Welches sich in welches intergriert ist letztenendes Wumpe. Es geht nicht um die Integration in ein anderes Toolkit, sondern die Integration in eine Desktopumgebung.
Von hkey_classes_suck am Mo, 15. August 2005 um 00:19 #
Wofür denn eine Registry, wenn man ein schönes Verzeichnis mit Konfigurationsdateien hat? Klar, ich kenne gconf, das ist noch nicht so schlimm, weil alle Daten in einem für Menschen lesbaren XML-Format gespeichert werden (anders als bei einem Betriebssystem aus Redmond). Aber dennoch ist es mir lieber, wenn jedes Programm seine eigenen Konfigurationsdateien mitbringt, die man bei Bedarf einfach löschen kann. Das ist übersichtlicher, als erst in einer Unmenge von Verzweigungen herum suchen zu müssen. Ich sehe in einer Registry im Prinzip keinen Vorteil. Gerüchten zurfolge hat inzwischen sogar Microsoft die Designschwächen der Registry erkannt und sie mit Windows Vista zum Auslaufmodell erklärt.
> Wofür denn eine Registry, wenn man ein schönes > Verzeichnis mit Konfigurationsdateien hat?
Damit es zentral administrierbar ist. Schon mal jenseits von Verschwörungstheorien & Co. darüber nachgedacht, weshalb die schottische Polizei auf Windows umsteigt? Vielleicht, um ihre Administrationskosten zu senken? Konfigurationsdateien sind nicht "schön", sondern die Hölle.
Man stelle sich nur mal vor, man müsse eine Anwendung implementieren, die Desktopeinstellungen modifiziert. Wunderbar, mit "schönen" "menschenlesbaren" Konfigurationsdateien ist ein spezieller Parser fällig. Sehr "schön".
> Klar, ich kenne gconf, das ist noch nicht so schlimm, > weil alle Daten in einem für Menschen lesbaren XML- > Format gespeichert werden (anders als bei einem > Betriebssystem aus Redmond).
Microsoft Windows speichert die Registry als binären Memory-Dump und erreicht somit eine höhere Performace als gconf, wo alles erst durch einen komplexen und langsamen XML-Parser geschickt wird. Die Entscheidung für XML bei gconf war allerdings notwendig, weil das System andernfalls aus ideologischen Gründen in der UNIX-Welt überhaupt nicht angenommen worden wäre.
> Aber dennoch ist es mir lieber, wenn jedes Programm > seine eigenen Konfigurationsdateien mitbringt, die > man bei Bedarf einfach löschen kann.
Für Einzelplatzrechner in Privathaushalten ist das tatsächlich besser, aber nicht für zentral administrierte Desktops in Netzwerken.
> Das ist übersichtlicher, als erst in einer Unmenge > von Verzweigungen herum suchen zu müssen.
Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch regedit.exe mit Suchfunktion (und gconftool-2 sowie gconf-editor, die beiden jedoch leider nach wie vor ohne Suchfunktion).
> Gerüchten zurfolge hat inzwischen sogar Microsoft > die Designschwächen der Registry erkannt und sie > mit Windows Vista zum Auslaufmodell erklärt.
Wo hast Du den Unsinn denn her? Die Windows-Registry erleichtert den Windows-Entwicklern das Leben und trägt mit dazu bei, dass Windows eine ungleich attraktivere Plattform für Softwareentwickler ist als alle Alternativen. Warum sollten sie diesen Vorteil aufgeben?
> > Aber dennoch ist es mir lieber, wenn jedes Programm > > seine eigenen Konfigurationsdateien mitbringt, die > > man bei Bedarf einfach löschen kann.
> Für Einzelplatzrechner in Privathaushalten ist das tatsächlich besser, aber nicht für > zentral administrierte Desktops in Netzwerken.
Wieso? Das ist doch die Unix-eigene Philosophie, dass global in /etc/foobar konfiguriert wird, einzelne Benutzer aber in ~/.foobar überschreiben können. Ich finde dieses Konzept genial und es macht *gerade* für zentral administrierte Desktops Sinn.
> Microsoft Windows speichert die Registry als binären Memory-Dump und erreicht somit eine > höhere Performace als gconf, wo alles erst durch einen komplexen und langsamen XML-Parser > geschickt wird.
Ob XML die richtige Wahl bei einer Konfigurationsdatei ist, sei mal dahingestellt. Mein Fall ist es auch nicht. Aber ein Speichern von Konfigurationsdateien in einem binären Format ist in einer *nix-Umgebung die denkbar schlechteste Lösung, weil man dadurch das zugrundeliegende Konzept der textorientierten Speicherung untergräbt. Ohne diese Textorientierung wären Utilities wie sed, awk, grep, head, sort sinnlos und man würde deutlich an Flexibilität verlieren.
> Die Entscheidung für XML bei gconf war allerdings notwendig, weil das System andernfalls > aus ideologischen Gründen in der UNIX-Welt überhaupt nicht angenommen worden wäre.
Damit hast Du Dich soeben (nicht nur fachlich) disqualifiziert.
> > Das ist übersichtlicher, als erst in einer Unmenge > > von Verzweigungen herum suchen zu müssen.
> Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch regedit.exe mit Suchfunktion
Wie soll man nach etwas suchen, das nicht dokumentiert ist?
Von Ralph Miguel am Mo, 15. August 2005 um 06:06 #
Zitat: "Schon mal jenseits von Verschwörungstheorien & Co. darüber nachgedacht, weshalb die schottische Polizei auf Windows umsteigt?"
http://www.infoworld.com/article/05/08/11/HNscottishpolice_1.html . Die hatten auch vorher schon Windows auf den Desktops, die brauchen nicht umzusteigen. Es wird Star-Office durch MS-Office ersetzt, mehr nicht.
Zum Thema Registry: http://www.tomshardware.com/hardnews/20050727_172553.html .
> Wo hast Du den Unsinn denn her? Die Windows-Registry erleichtert den > Windows-Entwicklern das Leben und trägt mit dazu bei, dass Windows > eine ungleich attraktivere Plattform für Softwareentwickler ist als > alle Alternativen. Warum sollten sie diesen Vorteil aufgeben? Nun ja, es stand in der aktuellen iX... Sie erlauben mit .NET 2.0 auch die Speicherung der Anwendungs-Einstellungen in XML-Dateien (à la Mac OS X)
| Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch | regedit.exe mit Suchfunktion (und gconftool-2 sowie gconf-editor, | die beiden jedoch leider nach wie vor ohne Suchfunktion).
gconf-editor besitzt seit gnome 2.8 eine suchfunktion. :)
> Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch regedit.exe mit Suchfunktion (und gconftool-2 sowie > gconf-editor, die beiden jedoch leider nach wie vor ohne Suchfunktion).
hast du diese auch schon mal praktisch verwendet? in der regel sucht man dann nochmals in den suchergebnissen, weil ähnliche werte unter x pfaden abgelegt werden. der gconf-editor hat übrigens schon seit einiger zeit eine suchfunktion, die meiner meinung nach der von regedit überlegen ist.
> Wo hast Du den Unsinn denn her? Die Windows-Registry erleichtert den Windows-Entwicklern das Leben und trägt mit dazu > bei, dass Windows eine ungleich attraktivere Plattform für Softwareentwickler ist als alle Alternativen. Warum > sollten sie diesen Vorteil aufgeben?
da ich generell plattforumunabhänig entwickle hab ich noch nie die windows eigenen funktionen zum zugriff auf die registry direkt verwendet. doch wenn ich einige konfigurationsdaten speichern will ist es mir vollkommen egal ob diese in einer registry liegen, in einer ini oder in einem anderen nicht lesbaren format abgelegt werden. was wichtig ist, ist wie man auf diese daten zugreifen kann. schau dir z.b. wxconfig von wxwidgets an, dem sagt du einfach du - mehr oder weniger - welche daten du speichern willst, und alles andere übernimmt die lib. verwende ich windows wird in der registry gespeichert, unter linux im homeverzeichnis als .* datei.
> Wofür denn eine Registry, wenn man ein schönes Verzeichnis mit Konfigurationsdateien hat? Klar, ich kenne gconf, das ist noch nicht so schlimm, > weil alle Daten in einem für Menschen lesbaren XML-Format gespeichert werden (anders als bei einem Betriebssystem aus Redmond). > Aber dennoch ist es mir lieber, wenn jedes Programm seine eigenen Konfigurationsdateien mitbringt, die man bei Bedarf einfach löschen kann
Man kann gconf-schemata auch ganz einfach wieder entfernen/"unapplyen".
Wer ein Konfigurationssystem haben will bei dem man mit einem beliebigen Programm die ganze Konfiguration editieren kann, welches aber gleichzeitig im beliebigen Format (ini, file, berkley,...) die Konfiguration durch Backends auf Festplatte schreiben kann sollte sich http://elektra.sf.net anschauen.
...und KDE hat schon lange KConfig. Anstatt hier irgendwelche Trollstories nach Vorbild des G.W. zu verbreiten, empfehle ich dir dich gelegentlich auch mal vom Monitor weg zu bewegen und ein gutes Buch zu lesen. Das erhöht die Wahrscheinlichkeit soziale Kompetenz zu erreichen ungemein.
G.W. scheint ja kein ungeschriebenes Blatt in diesem Forum zu sein. Mir ist aufgefallen, das dieser G.W. gerne Leute auf anderen Foren diffamiert. Aber zurück zum Thema - richtig, KConfig haben wir und auch KConfigXT. Wenn GConf so eine geniale Lösung ist, dann frage ich mich, warum sich die GNOME Leute einen Kopf um DConf machen. Die gegenwärtigen Lösungen bei GNOME scheinen wohl eher eine Übergangslösung darzustellen.
Warum sollten sie sich keinen Kopf über DConf machen?
Viele Leute haben sich in den letzten Jahren Gedanken über ein Desktop/Toolkit/Was auch immer unabhängiges Konfigurationssystem gemacht und diverse Systeme entwickelt.
Vielleicht schafft man es ja unter dem Dach (oder in der Lehmhütte) von fd.o sich auf etwas zu einigen, was von den gängigen DEs eingesetzt werden wird.
> Warum sollten sie sich keinen Kopf über DConf machen?
Dafür sollte man erstmal klären, was denn an den bisherigen Lösungen falsch ist.
> Vielleicht schafft man es ja unter dem Dach (oder in der Lehmhütte) von fd.o sich auf etwas zu > einigen, was von den gängigen DEs eingesetzt werden wird.
Dies wird jedoch ein riesiges Problem darstellen, da einfach zu viele Egos an den führenden Desktops werkeln. Die Einen mögen GConf, die Anderen KConfigXT, wiederum Andere finden es lästig jedes Jahr auf ein neues Konfigurationssystem umsteigen zu müssen, da diese Prozedur doch sehr Zeitaufwendig ist und teilweise mit Arbeit am Code verbunden ist. Und dann kommen auch noch die Leute, die noch andere Konfigurationslösungen in den Raum schmeissen, die sie dann auch mit blumigen Texten begründen, so daß es am Ende alles sehr plausibel und gut klingt. Wenn das mal alles so einfach wird. Wir haben schon genug Probleme den KDE Entwicklern DBUS, HAL, GStreamer schmackhaft zu machen und da gibts schon regelrechte Blockaden, dann auch noch GConf (DConf) anbieten....
»Dafür sollte man erstmal klären, was denn an den bisherigen Lösungen falsch ist.«
Sicher. Was mir vorallem am Herzen liegt wäre eine brauchbare und einheitliche Möglichkeit zur zentralen Verwaltung in größeren Netzen. Sowas ist zwar mit Einschränkungen möglich, aber man muss momentan leider recht oft für jedes System eine Extrawurst basteln. Ein einheitliches Backendsystem für Gnome, KDE, OOo, usw wäre schon recht hilfreich.
»Dies wird jedoch ein riesiges Problem darstellen, da einfach zu viele Egos an den führenden Desktops werkeln. Die Einen mögen GConf, die Anderen KConfigXT, wiederum Andere finden es lästig jedes Jahr auf ein neues Konfigurationssystem umsteigen zu müssen, da diese Prozedur doch sehr Zeitaufwendig ist und teilweise mit Arbeit am Code verbunden ist. ...«
Es sind ja nichtnur die Egos. In vielen Fällen (vorallem bei KDE) existieren schon brauchbare Lösungen, die aber teilweise recht stark an das jeweilige System gebunden sind.
Das viele Vorschläge aus dem Gnome Bereich kommen liegt meiner Meinung nach auch an den etwas höheren Leidensdruck. Wobei ich beim durchlesen der Mailinglisten auch das Gefühl habe, dass man im Gnome Lager in den letzten Jahren verstärkt bemüht ist desktopübergreifende Lösungen zu finden (Was aber nicht umbedingt zu besseren Ergebnissen führt :)
DBUS ist vielleicht ein recht gutes Beispiel. Der Leidensdruck im Gnome Lager war dort recht groß. Eigentlich blieb den Leuten ja nur 2 Sachen übrig. Entweder man bastelt seinen eigen Scheiss, der wieder nur von gtk/gnome benutzt wird, oder man versucht den Ersatz Desktop/Toolkit unabhägig aufzuziehen. Ich persönlich empfinde DCOP als recht schöne Lösung, weshalb ich es begrüße, dass DBUS sich sehr stark daran orientiert. Allerdings bezweifle ich, dass es möglich gewesen wäre DCOP in anderen (nicht qt) Systemen einzusetzen ohne erhebliche Änderungen daran vorzunehmen. Und ein sauberer rewrite (ok, wie sauber der code ist weiss ich nicht) ist mir persönlich lieber als ein zurechtgebasteltes DCOP.
Von Kevin Krammer am Mo, 15. August 2005 um 13:30 #
Was mir vorallem am Herzen liegt wäre eine brauchbare und einheitliche Möglichkeit zur zentralen Verwaltung in größeren Netzen.
Angeblich das kann UniConf: http://open.nit.ca/wiki/index.php?page=UniConf
Einer der Entwickler davon war in der DConf Diskussion beteiligt und hat dort gesagt, daß er sowohl KCOnfig als auch GCong Backends für UniConf hat und ich glaube auch was für OOo.
Allerdings bezweifle ich, dass es möglich gewesen wäre DCOP in anderen (nicht qt) Systemen einzusetzen ohne erhebliche Änderungen daran vorzunehmen.
DCOP hat ansich keine Qt Abhängigkeiten, abgesehen von den Namen der Datentypen. Das binär Format der Daten ist unter anderem in der Qt Dokumentation genau beschrieben, man kann also auch eine Implementation ohne Qt machen. Das Hauptproblem der derzeitigen DCOP Implementation ist die Abhängigkeit von ICE und somit von X11. Es gibt da zwar angeblich alternative Implementationen, aber nicht sehr verbreitet.
Außerdem ist einfach die Meinung, DCOP würde eine Qt Abhängigkeit haben, zu stark. Ist zwar nachweislich falsch, aber wenn mal Meinungen festgefahren sind, hilfen die besten Tatsachen nichts mehr
»Außerdem ist einfach die Meinung, DCOP würde eine Qt Abhängigkeit haben, zu stark. Ist zwar nachweislich falsch, aber wenn mal Meinungen festgefahren sind, hilfen die besten Tatsachen nichts mehr:)«
Was die Abhängigkeit angeht habe ich mich nur auf die Implementierung bezogen. Bzw eigentlich nur den Server (die Client libs müssen sowieso angepasst werden damit sie gut in die jeweiligen Toolkits integriert sind).
Die Internas des Protokolls kenne ich nicht und ich will darüber auch keine Aussagen machen.
Das Problem bei einem "unabhängigen" System ist ja zugleich den größten und kleinsten gemeinsammen Nenner an Funktionen zu finden, der das Zeugs nicht zu sehr aufbläht und gleichzeit aber alle Beteiligten zufriedenstellt. Ob das DBUS wirklich leistet kann ich nicht sagen, da mich die KDE und Gnome Entwicklung nur tangiert.
> http://www.freedesktop.org/wiki/Software_2fgtk_2dqt Wird aber (glaube ich) nicht mehr weiterentwickelt, was irrsinnig schade ist. Imho sollten die Entwickler beider Desktops so zusammenarbeiten, dass man unter KDE nicht merkt eine GNOME Anwendung vor sich zu haben und umgedreht - ja, ja ein Traum, aber was solls...
Wollt ich auch grad sagen, KDE apps sehen genauso wenn nicht noch beschissener aus in ner gnome umgebung, ich nutze zb. Amarok am iebsten, ist es aber "leider" ein KDE app und sieht somit total doof aus unter gnome...
Und ehrlich gesagt sehen gnome apps immer noch anstaendiger aus unter KDE als KDE dinger unter gnome. Ich finde wems net passt sollte nur commandline nutzen lol, da sieht alles gleich dann aus
Kann ich nicht nachvollziehen. Mit dem Plastik-KDE-Theme faellt eine KDE-App nicht so sehr unter Industrial-Gnome auf. Zur not kann man auch noch die Farben etwas angleichen.
Natuerlich faellt eine einzelne Applikation des einen Desktops unter allen anderen Applikationen des anderen Desktops aus dem Rahmen.
Ich benutze daher einfach icewm und starte kde/qt/gtk/gnome/tk/etc-Applikationen, wie ich sie gerade brauche.
Wäre ja durchaus mal sinnvoll, wenn die Qt Laute sich um bessere Integration in GNOME bemühen würden. Es gibt Sinn für zwei Desktopumgebungen oder mehr, aber Qt unter GNOME muss in GNOME sich besser integrieren. Besonders im Konfigurationsbereich und bei den Farbschemata ist die Inkompatibilität schon ein sichtbares Ding. Unter der Haube noch viel schlimmer. Das führt dann dazu, dass Programmierer lieber eine separate Gtk-Applikation bauen, um nicht ein Alien zu werden. Als ob das GUI Entwicklungssystem mit der Desktopumgebung verheiratet wäre. Warum soll eine Qt Applikation unter GNOME nicht nach GNOME integrieren, unter Windows nach Win, unter Mac OS X nach Mac OS X und unter KDE nach KDE? Warum muss eine Qt Application krampfhaft anders aussehen als eine Gtk Application?
Warum sollten sich nur die Qt-Leute bemühen müssen? Von der Zusammenarbeit auf Basis von Freedesktop.org hat man auch schon von Beschwerden gelesen, dass die GTK-/GNOME-Leute zu sehr davon ausgehen, dass am Ende einfach auf ihr Zeug gesetzt wird und die anderen sich halt anpassen müssen.
Warum sollten sich nur die Qt-Leute bemühen müssen?
Warum sollen sich nur die gtk-Leute bemühen müssen?... Wenn du es nicht gemerkt hast, mein Text ist eine 1:1 Kopie von gerd, nur unter umgekehrten Vorzeichen... ;)
Ein sehr schönes Stilmittel um aufzuzeigen warum eine Integration sich so schwierig gestaltet... Leider sind die Standpunkte auf beiden Seiten ziemlich festgefahren. Es lohnt sich allerdings wirklich mal die freedesktop.org Mailingliste zu studieren. Abgesehen von den zahlreichen Flamewars wird da relativ schnell ersichtlich, dass die Welten nicht mal so weit auseinander liegen und das tatsächlich eine Annährung zu beobachten ist - auch wenn 'nur' zwischen den Entwicklern während die Trolle sich weiterhin Beiträge wie den von dir zitierten liefern
Punkt ist, dass es ein ideologisches KDE Bashing von der Gnome-Seite gab mit der geringen Bereitschaft sich um Interoperabilität zu bemühen. Leute wie Nat Friedman haben fiese Propagandaschlachten mit FUD losgetreten. Dabei ist dann schon die Frage, warum man künstlich etwas inkompatibel halten muss und nicht eine Vereinheitlichung vollziehen kann wo sie sinnvoll ist.
Freedesktop = Gnome-Aktivisten erklären ihre unreifen Lösungen zum "Standard".
Es wäre grundsätzlich sinnvoll, hier eine Vereinheitlichung jedenfalls auf Ebene von GTK vorzunehmen. Es ist doch ziemlicher Bullshit, dass alle Applikationen für KDE mit QT basiert entwickelt werden sollen. Warum also nicht die Möglichkeit zur Angelichung geben.
Wir haben es bei dem filedialog gesehen. Lange gab es nichts vernünftiges. Hätte man einfach die KDE Lösung nachbauen können, nein, man baut sein eigenes Ding. Das ist ja auch alles gut, fragt sich nur, warum man unter KDE nicht den KDE-Filedialog anbietet, unter Gnome auf den Gnome-Filedialog, unter Windows auf den Win-filedialog, unter Mac OS X auf den Mac Os X filedialog setzt.
Wir haben es bei dem filedialog gesehen. Lange gab es nichts vernünftiges. Hätte man einfach die KDE Lösung nachbauen können, nein,... ...weil sonst hätte man ja immer noch keine vernünftige Lösung. ;)
Das ist ja auch alles gut, fragt sich nur, warum man unter KDE nicht den KDE-Filedialog anbietet, unter Gnome auf den Gnome-Filedialog, unter Windows auf den Win-filedialog, unter Mac OS X auf den Mac Os X filedialog setzt.
Von Kevin Krammer am Mo, 15. August 2005 um 15:15 #
Das Frage ich mich bei Qt auch immer.
Ist ist da mehr ein Build-Problem. Qt kann auf Windows oder OS X die dortigen Filedialoge benutzen weil die zum Zeitpunkt des Qt Builds schon vorhanden sind (API mäßig).
Da Qt aber die Vorraussetzung für KDE ist, ist die KFileDialog API zum Zeitpunkt der Qt Kompilierung noch nicht verfügbar. Man bräuchte da eher was im Sinne eines Plugins, daß erst zur Laafzeit geladen wird und Filedialoge zur Verfügung stellt.
Der funktionelle Unterschied ist aber eh nicht so groß: Bookmarks und konfigurierbare Locations auf der Seite.
Jeder WM/DM bringt seine eigenen Gruppies mit die dann hal auch mal liebend gerne ihre Überzeugung in Form von bashing vertreten. Genau solche Formulierungen ("von der Gnome-Seite" und "Gnome-Aktivisten [...] unreifen Lösungen" sind es dann auch, die zu solchen ideologischen Schlammschlachten führen. Auch wenn es nicht umbedingt der Philosophie von fd.org entspricht, hätte ich mir gewünscht, daß man die Mailingliste moderiert und solche unsinnigen bashing-Beiträge inklusive deren Verfasser einfach rauswirft. Das ist leider nicht geschehen...
Von Kevin Krammer am Mo, 15. August 2005 um 16:32 #
Ansich finde ich die xdg Liste vom Ton her relativ ruhig.
Bis auf ein paar kleinere Geplänkel in der D-VFS Diskussion gab es in letzter Zeit eigentlich keine Konflikte an die ich mich erinnern könnte. Und selbst in der D-VFS Diskussion kamen die Störenfriede nicht aus den Entwicklerkreisen der DEs.
Sag mal was würdet ihr mom. für eine GraKa bevorzugen in Hinblick auf GTK+/OpenGL ... Ich seh da langsam nicht mehr durch, ATI scheint ja für Linux nicht so super zu sein, NVidea?? Oder gibt es evt. von Maxtor OS Treiber die vernüftig mit OpenGL zusammenarbeiten. In Zukunft wird das ja eine immer größere Rolle spielen.
ich empfehle Matrox G550 oder eine ausgewählte ATI Karte, beide bringen imho anständige OpenGL Leistung auf Basis Freier Software für "nicht-Gamer" und "gelegentliche-tuxracer-gamer"
Das hängt aber stark von der Karte ab. Bei ATI ist alles ab 8500 noch immer closed source und auch die Dokumentation geht gegen Null. Man bemüht sích zwar bei ATI inzwischen um einen besseren Linux Support aber im Moment sind IMHO die Bemühungen von Nvidia doch besser. Matrix scheint eben erst wieder auf den Zug aufzuspringen nachdem man ihn schon eine Weile mal vorbeiziehen liless.
Bei ATI ist alles ab 8500 noch immer closed source
Bis einschliesslich Radeon 9250 gibt es schon länger 3D-Beschleunigung durch die freien DRI-Treiber. Für die Karten mit "höheren Versionsnummern" bieten die freien Treiber vom R300-Projekt 3D-Beschleunigung, diese wurden sogar vor kurzem in X.org aufgenommen.
und auch die Dokumentation geht gegen Null.
Hä? Die freien Treiber sind doch dokumentiert.
Man kann also zur Zeit die ATI Radeons bis einschliesslich 9250 für Linux empfehlen und dann in ein paar Monaten auch Radeons mit "höheren Versionsnummern".
Wenn Du kein OS-Extremist bist, dann nehme NVidia. Die Treiber sind meiner Erfahrung nach sehr stabil, werden gut von NVidia unterstützt und bringen eine sehr gute Geschwindigkeit. Arbeite seit über einem Jahr auf Linux-Workstations mit Maya (8 oder mehr Stunden am Tag) und konnte bis heute keinen einzigen Absturz erleben. Mit ATI hatte ich schlechte Erfahrungen und Matrox ist gut um kurz glxgears zu starten, aber nicht um damit ernsthaft zu arbeiten.
Nicht alles im "view" anzeigen, was sich im "buffer" befindet :)
Die Trennung zwischen der Anzeige und dem Dokument kann auch dazu benutzt werden nicht alles anzuzeigen was sich gerade im Datenobjekt befindet. Sowas kann ganz nützlich sein, wenn man unwichtige Dinge ausbleden will ohne an den Daten rumzuwurschteln. Ansonsten müsste man die Daten doppelt haben (einmal für die Anzeige und einmal das Original).
Aber das ging doch schon vorher. Ich konnte z.B. als Datenobjekt ein ListStore mit zwei strings und zwei ints haben und im Treeview dann nur den ersten string und den ersten int Wert als Spalten anzeigen.
Also so ganz habe ich das mit dem "unsichtbaren Text" auch noch nicht verstanden...
Funktioniert der NVidia-Treiber unter Ubuntu?
ok das kann man auch umdrehen. Wieso integriert sich Qt nicht in einen GTK-basierten Desktop?
Wenn man möchte, dass es optisch passend aussieht gibt es ja einige Themes und Engines, die versuchen dass z.B. GTK wie Qt aussieht.
Aber ich bezweifle, dass die Entwickler eines Toolkits unbedingt daran interessiert sind, dass sich ihr Toolkit in Anwendungen eines anderen integriert. Sicherlich wäre es nicht schlecht, aber es wird nicht das Hauptziel sein. Und selbst dann stellt sich eben die Frage, welches Toolkit sich in welches integrieren sollte.
Gruß
Mike
Gerade im Bereich Konfiguration wird ja derzeit bei KDE sowieso recht laut über radikale Ansätze nachgedacht, Registry und dergleichen. Da wäre es gut, wenn nicht jeder sein eigenes Süppchen kocht, sondern zusammen gearbeitet wird.
Welches sich in welches intergriert ist letztenendes Wumpe. Es geht nicht um die Integration in ein anderes Toolkit, sondern die Integration in eine Desktopumgebung.
Gerüchten zurfolge hat inzwischen sogar Microsoft die Designschwächen der Registry erkannt und sie mit Windows Vista zum Auslaufmodell erklärt.
> Verzeichnis mit Konfigurationsdateien hat?
Damit es zentral administrierbar ist. Schon mal jenseits von Verschwörungstheorien & Co. darüber nachgedacht, weshalb die schottische Polizei auf Windows umsteigt? Vielleicht, um ihre Administrationskosten zu senken? Konfigurationsdateien sind nicht "schön", sondern die Hölle.
Man stelle sich nur mal vor, man müsse eine Anwendung implementieren, die Desktopeinstellungen modifiziert. Wunderbar, mit "schönen" "menschenlesbaren" Konfigurationsdateien ist ein spezieller Parser fällig. Sehr "schön".
> Klar, ich kenne gconf, das ist noch nicht so schlimm,
> weil alle Daten in einem für Menschen lesbaren XML-
> Format gespeichert werden (anders als bei einem
> Betriebssystem aus Redmond).
Microsoft Windows speichert die Registry als binären Memory-Dump und erreicht somit eine höhere Performace als gconf, wo alles erst durch einen komplexen und langsamen XML-Parser geschickt wird. Die Entscheidung für XML bei gconf war allerdings notwendig, weil das System andernfalls aus ideologischen Gründen in der UNIX-Welt überhaupt nicht angenommen worden wäre.
> Aber dennoch ist es mir lieber, wenn jedes Programm
> seine eigenen Konfigurationsdateien mitbringt, die
> man bei Bedarf einfach löschen kann.
Für Einzelplatzrechner in Privathaushalten ist das tatsächlich besser, aber nicht für zentral administrierte Desktops in Netzwerken.
> Das ist übersichtlicher, als erst in einer Unmenge
> von Verzweigungen herum suchen zu müssen.
Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch regedit.exe mit Suchfunktion (und gconftool-2 sowie gconf-editor, die beiden jedoch leider nach wie vor ohne Suchfunktion).
> Gerüchten zurfolge hat inzwischen sogar Microsoft
> die Designschwächen der Registry erkannt und sie
> mit Windows Vista zum Auslaufmodell erklärt.
Wo hast Du den Unsinn denn her? Die Windows-Registry erleichtert den Windows-Entwicklern das Leben und trägt mit dazu bei, dass Windows eine ungleich attraktivere Plattform für Softwareentwickler ist als alle Alternativen. Warum sollten sie diesen Vorteil aufgeben?
> > seine eigenen Konfigurationsdateien mitbringt, die
> > man bei Bedarf einfach löschen kann.
> Für Einzelplatzrechner in Privathaushalten ist das tatsächlich besser, aber nicht für
> zentral administrierte Desktops in Netzwerken.
Wieso? Das ist doch die Unix-eigene Philosophie, dass global in /etc/foobar konfiguriert wird, einzelne Benutzer aber in ~/.foobar überschreiben können. Ich finde dieses Konzept genial und es macht *gerade* für zentral administrierte Desktops Sinn.
> Microsoft Windows speichert die Registry als binären Memory-Dump und erreicht somit eine
> höhere Performace als gconf, wo alles erst durch einen komplexen und langsamen XML-Parser
> geschickt wird.
Ob XML die richtige Wahl bei einer Konfigurationsdatei ist, sei mal dahingestellt. Mein Fall ist es auch nicht. Aber ein Speichern von Konfigurationsdateien in einem binären Format ist in einer *nix-Umgebung die denkbar schlechteste Lösung, weil man dadurch das zugrundeliegende Konzept der textorientierten Speicherung untergräbt. Ohne diese Textorientierung wären Utilities wie sed, awk, grep, head, sort sinnlos und man würde deutlich an Flexibilität verlieren.
> Die Entscheidung für XML bei gconf war allerdings notwendig, weil das System andernfalls
> aus ideologischen Gründen in der UNIX-Welt überhaupt nicht angenommen worden wäre.
Damit hast Du Dich soeben (nicht nur fachlich) disqualifiziert.
> > Das ist übersichtlicher, als erst in einer Unmenge
> > von Verzweigungen herum suchen zu müssen.
> Warum solltest Du denn herumsuchen müssen? Dafür gibt es doch regedit.exe mit Suchfunktion
Wie soll man nach etwas suchen, das nicht dokumentiert ist?
*plonk*
Du bist raus!
http://www.infoworld.com/article/05/08/11/HNscottishpolice_1.html . Die hatten auch vorher schon Windows auf den Desktops, die brauchen nicht umzusteigen. Es wird Star-Office durch MS-Office ersetzt, mehr nicht.
Zum Thema Registry: http://www.tomshardware.com/hardnews/20050727_172553.html .
> Windows-Entwicklern das Leben und trägt mit dazu bei, dass Windows
> eine ungleich attraktivere Plattform für Softwareentwickler ist als
> alle Alternativen. Warum sollten sie diesen Vorteil aufgeben?
Nun ja, es stand in der aktuellen iX...
Sie erlauben mit .NET 2.0 auch die Speicherung der Anwendungs-Einstellungen in XML-Dateien (à la Mac OS X)
Es hätte gereicht, frei zugängliche MSDN-Artikel zu lesen …
| regedit.exe mit Suchfunktion (und gconftool-2 sowie gconf-editor,
| die beiden jedoch leider nach wie vor ohne Suchfunktion).
gconf-editor besitzt seit gnome 2.8 eine suchfunktion. :)
http://www.gnomejournal.org/article/3/looking-at-gnome-28
> gconf-editor, die beiden jedoch leider nach wie vor ohne Suchfunktion).
hast du diese auch schon mal praktisch verwendet?
in der regel sucht man dann nochmals in den suchergebnissen, weil ähnliche werte unter x pfaden abgelegt werden.
der gconf-editor hat übrigens schon seit einiger zeit eine suchfunktion, die meiner meinung nach der von regedit überlegen ist.
> Wo hast Du den Unsinn denn her? Die Windows-Registry erleichtert den Windows-Entwicklern das Leben und trägt mit dazu
> bei, dass Windows eine ungleich attraktivere Plattform für Softwareentwickler ist als alle Alternativen. Warum
> sollten sie diesen Vorteil aufgeben?
da ich generell plattforumunabhänig entwickle hab ich noch nie die windows eigenen funktionen zum zugriff auf die registry direkt verwendet. doch wenn ich einige konfigurationsdaten speichern will ist es mir vollkommen egal ob diese in einer registry liegen, in einer ini oder in einem anderen nicht lesbaren format abgelegt werden.
was wichtig ist, ist wie man auf diese daten zugreifen kann.
schau dir z.b. wxconfig von wxwidgets an, dem sagt du einfach du - mehr oder weniger - welche daten du speichern willst, und alles andere übernimmt die lib. verwende ich windows wird in der registry gespeichert, unter linux im homeverzeichnis als .* datei.
> weil alle Daten in einem für Menschen lesbaren XML-Format gespeichert werden (anders als bei einem Betriebssystem aus Redmond).
> Aber dennoch ist es mir lieber, wenn jedes Programm seine eigenen Konfigurationsdateien mitbringt, die man bei Bedarf einfach löschen kann
Man kann gconf-schemata auch ganz einfach wieder entfernen/"unapplyen".
mfg Markus
Anstatt hier irgendwelche Trollstories nach Vorbild des G.W. zu verbreiten, empfehle ich dir dich gelegentlich auch mal vom Monitor weg zu bewegen und ein gutes Buch zu lesen. Das erhöht die Wahrscheinlichkeit soziale Kompetenz zu erreichen ungemein.
Viele Leute haben sich in den letzten Jahren Gedanken über ein Desktop/Toolkit/Was auch immer unabhängiges Konfigurationssystem gemacht und diverse Systeme entwickelt.
Vielleicht schafft man es ja unter dem Dach (oder in der Lehmhütte) von fd.o sich auf etwas zu einigen, was von den gängigen DEs eingesetzt werden wird.
Dafür sollte man erstmal klären, was denn an den bisherigen Lösungen falsch ist.
> Vielleicht schafft man es ja unter dem Dach (oder in der Lehmhütte) von fd.o sich auf etwas zu
> einigen, was von den gängigen DEs eingesetzt werden wird.
Dies wird jedoch ein riesiges Problem darstellen, da einfach zu viele Egos an den führenden Desktops werkeln. Die Einen mögen GConf, die Anderen KConfigXT, wiederum Andere finden es lästig jedes Jahr auf ein neues Konfigurationssystem umsteigen zu müssen, da diese Prozedur doch sehr Zeitaufwendig ist und teilweise mit Arbeit am Code verbunden ist. Und dann kommen auch noch die Leute, die noch andere Konfigurationslösungen in den Raum schmeissen, die sie dann auch mit blumigen Texten begründen, so daß es am Ende alles sehr plausibel und gut klingt. Wenn das mal alles so einfach wird. Wir haben schon genug Probleme den KDE Entwicklern DBUS, HAL, GStreamer schmackhaft zu machen und da gibts schon regelrechte Blockaden, dann auch noch GConf (DConf) anbieten....
Sicher.
Was mir vorallem am Herzen liegt wäre eine brauchbare und einheitliche Möglichkeit zur zentralen Verwaltung in größeren Netzen.
Sowas ist zwar mit Einschränkungen möglich, aber man muss momentan leider recht oft für jedes System eine Extrawurst basteln.
Ein einheitliches Backendsystem für Gnome, KDE, OOo, usw wäre schon recht hilfreich.
»Dies wird jedoch ein riesiges Problem darstellen, da einfach zu viele Egos an den führenden Desktops werkeln. Die Einen mögen GConf, die Anderen KConfigXT, wiederum Andere finden es lästig jedes Jahr auf ein neues Konfigurationssystem umsteigen zu müssen, da diese Prozedur doch sehr Zeitaufwendig ist und teilweise mit Arbeit am Code verbunden ist. ...«
Es sind ja nichtnur die Egos.
In vielen Fällen (vorallem bei KDE) existieren schon brauchbare Lösungen, die aber teilweise recht stark an das jeweilige System gebunden sind.
Das viele Vorschläge aus dem Gnome Bereich kommen liegt meiner Meinung nach auch an den etwas höheren Leidensdruck. Wobei ich beim durchlesen der Mailinglisten auch das Gefühl habe, dass man im Gnome Lager in den letzten Jahren verstärkt bemüht ist desktopübergreifende Lösungen zu finden (Was aber nicht umbedingt zu besseren Ergebnissen führt :)
DBUS ist vielleicht ein recht gutes Beispiel.
Der Leidensdruck im Gnome Lager war dort recht groß.
Eigentlich blieb den Leuten ja nur 2 Sachen übrig. Entweder man bastelt seinen eigen Scheiss, der wieder nur von gtk/gnome benutzt wird, oder man versucht den Ersatz Desktop/Toolkit unabhägig aufzuziehen.
Ich persönlich empfinde DCOP als recht schöne Lösung, weshalb ich es begrüße, dass DBUS sich sehr stark daran orientiert.
Allerdings bezweifle ich, dass es möglich gewesen wäre DCOP in anderen (nicht qt) Systemen einzusetzen ohne erhebliche Änderungen daran vorzunehmen.
Und ein sauberer rewrite (ok, wie sauber der code ist weiss ich nicht) ist mir persönlich lieber als ein zurechtgebasteltes DCOP.
Angeblich das kann UniConf:
http://open.nit.ca/wiki/index.php?page=UniConf
Einer der Entwickler davon war in der DConf Diskussion beteiligt und hat dort gesagt, daß er sowohl KCOnfig als auch GCong Backends für UniConf hat und ich glaube auch was für OOo.
Allerdings bezweifle ich, dass es möglich gewesen wäre DCOP in anderen (nicht qt) Systemen einzusetzen ohne erhebliche Änderungen daran vorzunehmen.
DCOP hat ansich keine Qt Abhängigkeiten, abgesehen von den Namen der Datentypen.
Das binär Format der Daten ist unter anderem in der Qt Dokumentation genau beschrieben, man kann also auch eine Implementation ohne Qt machen.
Das Hauptproblem der derzeitigen DCOP Implementation ist die Abhängigkeit von ICE und somit von X11.
Es gibt da zwar angeblich alternative Implementationen, aber nicht sehr verbreitet.
Außerdem ist einfach die Meinung, DCOP würde eine Qt Abhängigkeit haben, zu stark. Ist zwar nachweislich falsch, aber wenn mal Meinungen festgefahren sind, hilfen die besten Tatsachen nichts mehr
Was die Abhängigkeit angeht habe ich mich nur auf die Implementierung bezogen. Bzw eigentlich nur den Server (die Client libs müssen sowieso angepasst werden damit sie gut in die jeweiligen Toolkits integriert sind).
Die Internas des Protokolls kenne ich nicht und ich will darüber auch keine Aussagen machen.
Das Problem bei einem "unabhängigen" System ist ja zugleich den größten und kleinsten gemeinsammen Nenner an Funktionen zu finden, der das Zeugs nicht zu sehr aufbläht und gleichzeit aber alle Beteiligten zufriedenstellt. Ob das DBUS wirklich leistet kann ich nicht sagen, da mich die KDE und Gnome Entwicklung nur tangiert.
gibt es schon und läuft bei mir einwandfrei. nur der ungedrehte weg also qt wie gtk aussehen zu lassen ist meines wissens nicht möglich.
Wird aber (glaube ich) nicht mehr weiterentwickelt, was irrsinnig schade ist. Imho sollten die Entwickler beider Desktops so zusammenarbeiten, dass man unter KDE nicht merkt eine GNOME Anwendung vor sich zu haben und umgedreht - ja, ja ein Traum, aber was solls...
Und ehrlich gesagt sehen gnome apps immer noch anstaendiger aus unter KDE als KDE dinger unter gnome. Ich finde wems net passt sollte nur commandline nutzen lol, da sieht alles gleich dann aus
Natuerlich faellt eine einzelne Applikation des einen Desktops unter allen anderen Applikationen des anderen Desktops aus dem Rahmen.
Ich benutze daher einfach icewm und starte kde/qt/gtk/gnome/tk/etc-Applikationen, wie ich sie gerade brauche.
Von der Zusammenarbeit auf Basis von Freedesktop.org hat man auch schon von Beschwerden gelesen, dass die GTK-/GNOME-Leute zu sehr davon ausgehen, dass am Ende einfach auf ihr Zeug gesetzt wird und die anderen sich halt anpassen müssen.
PS: Da fehlen ein paar Bindestriche …
Warum sollen sich nur die gtk-Leute bemühen müssen?... Wenn du es nicht gemerkt hast, mein Text ist eine 1:1 Kopie von gerd, nur unter umgekehrten Vorzeichen... ;)
PS: Da fehlen ein paar Bindestriche
Werde ich gleich mal an gerd weiterleiten
Freedesktop = Gnome-Aktivisten erklären ihre unreifen Lösungen zum "Standard".
Es wäre grundsätzlich sinnvoll, hier eine Vereinheitlichung jedenfalls auf Ebene von GTK vorzunehmen. Es ist doch ziemlicher Bullshit, dass alle Applikationen für KDE mit QT basiert entwickelt werden sollen. Warum also nicht die Möglichkeit zur Angelichung geben.
Wir haben es bei dem filedialog gesehen. Lange gab es nichts vernünftiges. Hätte man einfach die KDE Lösung nachbauen können, nein, man baut sein eigenes Ding. Das ist ja auch alles gut, fragt sich nur, warum man unter KDE nicht den KDE-Filedialog anbietet, unter Gnome auf den Gnome-Filedialog, unter Windows auf den Win-filedialog, unter Mac OS X auf den Mac Os X filedialog setzt.
Das ist ja auch alles gut, fragt sich nur, warum man unter KDE nicht den KDE-Filedialog anbietet, unter Gnome auf den Gnome-Filedialog, unter Windows auf den Win-filedialog, unter Mac OS X auf den Mac Os X filedialog setzt.
Das Frage ich mich bei Qt auch immer.
Ist ist da mehr ein Build-Problem.
Qt kann auf Windows oder OS X die dortigen Filedialoge benutzen weil die zum Zeitpunkt des Qt Builds schon vorhanden sind (API mäßig).
Da Qt aber die Vorraussetzung für KDE ist, ist die KFileDialog API zum Zeitpunkt der Qt Kompilierung noch nicht verfügbar.
Man bräuchte da eher was im Sinne eines Plugins, daß erst zur Laafzeit geladen wird und Filedialoge zur Verfügung stellt.
Der funktionelle Unterschied ist aber eh nicht so groß: Bookmarks und konfigurierbare Locations auf der Seite.
Qt4 benutzt unter Windows den Windows-Filedialog, unter MacOS X den MacOS X-Filedialog und unter den restlichen UNIXoiden seinen eigenen.
Auch wenn es nicht umbedingt der Philosophie von fd.org entspricht, hätte ich mir gewünscht, daß man die Mailingliste moderiert und solche unsinnigen bashing-Beiträge inklusive deren Verfasser einfach rauswirft. Das ist leider nicht geschehen...
Bis auf ein paar kleinere Geplänkel in der D-VFS Diskussion gab es in letzter Zeit eigentlich keine Konflikte an die ich mich erinnern könnte.
Und selbst in der D-VFS Diskussion kamen die Störenfriede nicht aus den Entwicklerkreisen der DEs.
...die aber letztlich doch Sean zur Resignation getrieben haben. Hat im Moment keine Lust mehr, der Arme.
Ich seh da langsam nicht mehr durch, ATI scheint ja für Linux nicht so super zu sein, NVidea?? Oder gibt es evt. von Maxtor OS Treiber die vernüftig mit OpenGL zusammenarbeiten. In Zukunft wird das ja eine immer größere Rolle spielen.
Danke Euch!
Bis einschliesslich Radeon 9250 gibt es schon länger 3D-Beschleunigung durch die freien DRI-Treiber. Für die Karten mit "höheren Versionsnummern" bieten die freien Treiber vom R300-Projekt 3D-Beschleunigung, diese wurden sogar vor kurzem in X.org aufgenommen.
und auch die Dokumentation geht gegen Null.
Hä? Die freien Treiber sind doch dokumentiert.
Man kann also zur Zeit die ATI Radeons bis einschliesslich 9250 für Linux empfehlen und dann in ein paar Monaten auch Radeons mit "höheren Versionsnummern".
Was will man denn damit?
MfG Peschmä
Der Kommentar hat mir wirklich gefallen :-)
Gruß an alle Aliens
Die Trennung zwischen der Anzeige und dem Dokument kann auch dazu benutzt werden nicht alles anzuzeigen was sich gerade im Datenobjekt befindet. Sowas kann ganz nützlich sein, wenn man unwichtige Dinge ausbleden will ohne an den Daten rumzuwurschteln. Ansonsten müsste man die Daten doppelt haben (einmal für die Anzeige und einmal das Original).
Also so ganz habe ich das mit dem "unsichtbaren Text" auch noch nicht verstanden...
fetzt, das wollte ich schon immer haben...
nein mal ehrlich, für was braucht man das?
vielleicht kann der admin meinen beitrag wieder löschen
komisch