Login
Newsletter
Werbung

Thema: Compiz spaltet sich auf

17 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Catonga am Do, 21. September 2006 um 07:28 #
[QUOTE]
Ferner wird für die Konfiguration von Compiz nicht mehr gconf-editor benötigt, sondern eine separate Applikation »csm«.
[/QUOTE]

Prima, also ein weiterer Parser, ne weitere Eigenwurst und neue Bugs im neuen Confiparser, das wieder zu nichts kompatibel ist als zu sich selbst.

Die hätten lieber auf eine bestehende Konfigurationsbasis setzen sollen,
3rd Party Entwickler werden es jetzt schwer haben, wenn sie z.B. zur besseren Integrierung in ihre Distribution eine eigene Konfigurationsoberfläche für diesen Compiz Fork schreiben wollen.

Mit Elektra wäre das nicht passiert.
Ein Konfigurationssystem aus einem Guss.

[
| Versenden | Drucken ]
  • 0
    Von Henning Rogge am Do, 21. September 2006 um 10:01 #
    Ich habe mir gerade mal ein paar Screenshots zu Elektra angesehen (http://freshmeat.net/screenshots/45092/48188/), das sieht doch genau so grauenhaft wie GConf aus. Das hat nichts mit einer GUI zum Konfigurieren zu tun, das ist wie GConf ne Kopie der Windows Registry.

    CSM ist erst eine frühe Alpha, daraus wird sich (zumindest ist das geplant) ein Tool entwickeln mit dem man Compiz gut konfigurieren kann. Compiz hat schon jetzt so viele Settings das ein Tool wie GConf dafür einfach unbenutzbar wird.

    [
    | Versenden | Drucken ]
    • 0
      Von Catonga am Do, 21. September 2006 um 10:14 #
      > Ich habe mir gerade mal ein paar Screenshots zu Elektra angesehen
      > (http://freshmeat.net/screenshots/45092/48188/), das sieht doch genau so grauenhaft wie
      > GConf aus. Das hat nichts mit einer GUI zum Konfigurieren zu tun, das ist wie GConf ne
      > Kopie der Windows Registry.

      Ähm räusper, ich glaube du hast das mit Elektra und wie so ein System arbeitet noch nicht ganz verstanden.

      Nimm mal GConf als Beispiel und schau dir den Einstellungsdialog von Evolution an.
      Wenn dir das auch nicht auf die Sprünge helfen sollte,
      dann kannst du mich noch einmal fragen, ich werde es dann ausführlich beantworten, versprochen.
      Aber vorher lass ich dich nochmal selber darüber nachdenken.


      > CSM ist erst eine frühe Alpha, daraus wird sich (zumindest ist das geplant)
      > ein Tool entwickeln mit dem man Compiz gut konfigurieren kann.

      Oh toll, aber darum geht es nicht!
      Die Konfiguration von Compiz muß auch mit so Sachen wie einem Distri internen Yast leicht konfigurierbar sein und da hilft dir CSM überhaupt nicht weiter.

      [
      | Versenden | Drucken ]
      • 0
        Von Henning Rogge am Do, 21. September 2006 um 10:21 #
        Ich bezweifle das Suse gewillt ist so viel Arbeit in Yast zu stecken um Compiz komplett aus Yast konfigurierbar zu machen. Compiz (Quinnstorm) hat einige Zeit mit GConf gearbeitet und am Anfang ging es ganz gut. aber die Anzahl der nötigen Optionen ist einer GConf-artigen GUI einfach über den Kopf gewachsen.

        Soweit ich weis gibt es ein paar User die überlegen ob sie GConf als Backend für CSM nutzbar machen können, mehr als ein "hätte gerne" ist bisher aber nicht daraus geworden.

        Zu Evolution kann ich nicht viel sagen da ich es nicht kenne und nicht plane es zu installieren da es mir viel zu viele Gnome spez. Dinge fordert.

        Weg von Gconf war meiner Meinung nach einfach schonmal der richtige Schritt da es Compiz von Gnome löst und auf einer breitere Basis stellt. Ob es für die Settings irgendwann noch andere Backends geben wird kann ich mom. nicht sagen, aber der Backend (momentan CSM) ist ja auch nur ein Plugin für Compiz. Es spricht nichts dagegen das jemand ein neues GConf oder ein Elektra Plugin schreibt und automatisch werden alle Plugins dort ihre Daten speichern.

        [
        | Versenden | Drucken ]
        • 0
          Von Catonga am Do, 21. September 2006 um 10:46 #
          > Ich bezweifle das Suse gewillt ist so viel Arbeit in Yast zu stecken um Compiz
          > komplett aus Yast konfigurierbar zu machen.

          Solange Suse einen eigenen Parser schreiben MUSS, nur um die Compiz Konfigurationsdatei bearbeiten zu können, werden die Suse Leute viel Arbeit in Yast stecken müssen.
          Das ist genau das Problem, welches diese CSM Eigenwurst momentan hervorruft und durch so etwas wie Elektra sehr leicht beseitigt werden könnte.

          Genau dieser Sachverhalt, diese Kompliziertheit und der notwendige Aufwand eigene angepaßte GUIs liefern zu können, ist ja genau das, was mit Elektra behoben werden soll.
          Du müßtest daher also eigentlich ein Befürworter von Elektra sein.

          > aber die Anzahl der nötigen Optionen ist einer GConf-artigen GUI einfach über den Kopf gewachsen.

          Dir ist definitiv nicht klar das GConf eine LowLevel GUI für absolute Ausnahmefälle ist, daher auch dein Einwand das GConf zu kompliziert für den normalen Benutzer sei.
          Aber, deine Befürchtungen sind vollkommen unbegründet.
          Denn genauso wie du Evolution niemals mit GConf konfiguierst, würdest du Compiz nie mit
          diesem Elektra GUI Editor konfigurieren, aber dennoch arbeitet unter der Haube von Evolution GConfig und so würde auch bei Compiz unter der Haube Elektra arbeiten.

          > Weg von Gconf war meiner Meinung nach einfach schonmal der richtige Schritt da es
          > Compiz von Gnome löst und auf einer breitere Basis stellt.

          Du wirst mit CSM niemals eine Konfigurationsgui bekommen, die sich nahtlos in KDE oder Gnome, oder XFCE oder Suses Yast, oder Ubunutus XY oder ... einfügt.
          Genau das ist ja der Haken von CSM und der Grund der für Elektra spricht.

          Elektra ist eine wohl definierte und standardisierte Konfigurationsbasis
          die zustäzlich auch noch eine standardisierte Schnittstelle liefert um
          vereinheitlicht auf diese Konfigurationsbasis zugreifen zu können.
          Und damit, dank dieser vereinheitlichten Schnittstelle, wird es ein Kinderspiel
          eine an KDE, Gnome, XFCE, YAST etc. optimierte und angepaßte GUI für den Endnutzer zu bekommen.
          Genau das ist Elektra!


          CSM dagegen kann höchstens nur an eine einzige Desktop Umgebung angepaßt werden.
          Schreibst du CSM in QT und paßt es an KDE an, dann läßt es sich nicht mit
          der GNOME Human Interface Guidelines (HIG) vereinbaren und es sieht auch nicht so aus,
          wie typische Gnome Programme die GTK verwenden.
          Umgekerht ist es genau das gleiche Problem.
          Paßt du CSM an Gnome an, dann wird es niemals der HIG von KDE entsprechen und sich auch nicht in das Theme von KDE nahtlos einfügen, da es dann ja mit GTK programmiert werden würde.

          Tja und jetzt wirst du sicher sagen das man ja für jeden Desktop eine eigene GUI schreiben kann.
          Richtig, aber für jede dieser GUI mußt du dann noch einmal und noch einmal
          einen eigenen Parser schreiben der die Konfigurationsdatei überhaupt bearbeiten kann und
          genau das fällt mit Elektra weg.

          [
          | Versenden | Drucken ]
          • 0
            Von Henning Rogge am Do, 21. September 2006 um 10:55 #
            Du wirfst da zwei Sachen zusammen die nicht zusammengehören (ist zum guten Teil auch meine Schuld weil ich den Unterschied nicht klar gemacht habe).

            das Compiz-Plugin CSM hat keine GUI, es sorgt für eine zentrale Ablage der Konfigurationsdaten aller Compiz Plugins.

            dazu gibt es eine Applikation namens CSM welche mit Compiz kommuniziert um dem User eine einfache GUI zum ändern der Daten zu bieten.

            Es sollte nicht viel arbeit sein das Plugin CSM durch ein alternatives Elektra Plugin zu ergänzen so das die Ablage der Daten der Compiz-Plugins dann dort passiert.

            CSM (die Applikation) steuert Compiz übrigens über das DBus-Plugin in Compiz.

            Theoretisch (bin mir nicht sicher) müßte die Applikation CSM auch laufen wenn statt dem CSM-Plugin ein anderes läuft.

            [
            | Versenden | Drucken ]
            • 0
              Von Catonga am Do, 21. September 2006 um 11:11 #
              > das Compiz-Plugin CSM hat keine GUI, es sorgt für eine zentrale Ablage der
              > Konfigurationsdaten aller Compiz Plugins.

              Dann stellt dieses Compiz-Plugin CSM System also so etwas wie Elektra da,
              nur halt im kleinen und stark vereinfacht und auch nur im eigenen Raum innerhalb Compiz.

              > dazu gibt es eine Applikation namens CSM welche mit Compiz kommuniziert
              > um dem User eine einfache GUI zum ändern der Daten zu bieten.

              Ok, das ist dann also unsere GUI für den Benutzer.

              > Es sollte nicht viel arbeit sein das Plugin CSM durch ein alternatives Elektra Plugin
              > zu ergänzen so das die Ablage der Daten der Compiz-Plugins dann dort passiert.

              Ok, aber jetzt ist die Frage, warum hat man das nicht gleich von Anfang an gemacht?
              Warum wurde eine eigene Konfigurationsdatebasis die nur innerhalb Compiz funktioniert neu erfunden?

              > CSM (die Applikation) steuert Compiz übrigens über das DBus-Plugin in Compiz.

              Heißt das also, wenn man mal eine eigene GUI schreiben will,
              daß man dann über DBUS, Compiz einheitlich konfigurieren kann?

              > Theoretisch (bin mir nicht sicher) müßte die Applikation CSM auch laufen wenn statt
              > dem CSM-Plugin ein anderes läuft.

              Ja, wenn du das CSM-Pluing durch Elektra ersetzt und dann die Applikation CSM auf die Elektra Schnittstelle zugreifen läßt sollte das funktionieren.

              [
              | Versenden | Drucken ]
              • 0
                Von Henning Rogge am Do, 21. September 2006 um 11:26 #
                > Dann stellt dieses Compiz-Plugin CSM System also so etwas wie Elektra da,
                > nur halt im kleinen und stark vereinfacht und auch nur im eigenen Raum innerhalb Compiz.

                Weniger noch. Das CSM Plugin stellt nur für Compiz die Möglichkeit zur Verfügung Daten persistent zu speichern. Es kommuniziert nur mit Compiz, nicht mit anderen Programmen. Das geschieht über DBus.

                > Ok, aber jetzt ist die Frage, warum hat man das nicht gleich von Anfang an gemacht?
                > Warum wurde eine eigene Konfigurationsdatebasis die nur innerhalb Compiz funktioniert neu erfunden?
                1.) Weil Compiz ein sehr schnelles Projekt im Alpha-Stadium ist und es def. deutlich länger gedauert hätte Elektra zu nutzen
                2.) Weil es wieder ne zusätzliches externes Programm gewesen wäre

                > Heißt das also, wenn man mal eine eigene GUI schreiben will,
                > daß man dann über DBUS, Compiz einheitlich konfigurieren kann?
                Ja. Die gesammte Steuerung und Konfiguration von Compiz geschieht (soweit ich weis) über DBus.

                > Ja, wenn du das CSM-Pluing durch Elektra ersetzt und dann die Applikation CSM auf die Elektra
                > Schnittstelle zugreifen läßt sollte das funktionieren.

                Auch so... die CSM Applikation greift ja per DBus auf Compiz zu... die hat mit dem Compiz-Plugin CSM eher wenig (außer dem Namen und das beide zur gleichen Zeit als Ersatz für GConf entstanden) zu tun.
                Glaube ich zumindest...

                Persönlich würde ich Elektra allerdings nicht nutzen da ich es für nicht sinnvoll halte alle Settings zwangsweise in ein System reinzuzwängen. Dezentrale Speicherung hat ihre Vorteile, außerdem sind Textdateien im Notfall leichter zu bearbeiten und zu sichern.

                [
                | Versenden | Drucken ]
                • 0
                  Von Catonga am Do, 21. September 2006 um 12:07 #
                  >> Ok, aber jetzt ist die Frage, warum hat man das nicht gleich von Anfang an gemacht?
                  >> Warum wurde eine eigene Konfigurationsdatebasis die nur innerhalb Compiz funktioniert neu erfunden?
                  >1.) Weil Compiz ein sehr schnelles Projekt im Alpha-Stadium ist und es def. deutlich länger gedauert hätte Elektra zu nutzen

                  Also das glaube ich nicht. Elektra ist sehr einfach über die libelektra Bibliothek zu benutzen.


                  >2.) Weil es wieder ne zusätzliches externes Programm gewesen wäre

                  Mag sein, aber Elektra ist ja noch recht neu und wird später sicher noch
                  von viel mehr Programmen benutzt werden, so daß es später sowieso bei beinahe jeder Distribution dabei sein wird.

                  Elektra zu nutzen hat übrigens den Vorteil das man keinen Demon benötigt.
                  Das ist bei DBus anders.

                  > Dezentrale Speicherung hat ihre Vorteile,

                  Welche sollen das gegenüber Elektra sein?

                  Um es mal allgemein auszudrücken,
                  X verschiedene Konfigurationsdateien mit ihrer eigenen Syntax, die wieder einen
                  speziellen Parser brauchen, sehe ich jedenfalls nicht als Vorteil.

                  > außerdem sind Textdateien im Notfall leichter zu bearbeiten und zu sichern.

                  Die Konfigurationsdaten in Elektra bestehen aus Textdateien.


                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Henning Rogge am Do, 21. September 2006 um 12:25 #
                    > Mag sein, aber Elektra ist ja noch recht neu und wird später sicher noch
                    > von viel mehr Programmen benutzt werden, so daß es später sowieso bei
                    > beinahe jeder Distribution dabei sein wird.

                    Oder es wird in der Versenkung verschwinden wie so viele andere Projekte.
                    Warten wir es ab.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Catonga am Do, 21. September 2006 um 13:42 #
                      > Oder es wird in der Versenkung verschwinden wie so viele andere Projekte.
                      > Warten wir es ab.

                      Wenn man Elektra willentlich nach dem Motto "laß erstmal die anderen ran" ignoriert,
                      wird man das wohl ganz bewußt sicher erreichen.
                      Der Spruch "Wer den Teufel gleich an die Wand malt" kommt schließlich nicht von ungefähr.


                      Anstatt also abzuwarten, wäre es angebrachter Compiz Elektra gleich beizubringen.
                      Für den Anfang kann man das ja auch über eine ./configure --enable-elektra Option regeln.

                      [
                      | Versenden | Drucken ]
                  0
                  Von fgf am Do, 21. September 2006 um 13:23 #
                  > Dezentrale Speicherung hat ihre Vorteile
                  Welche Vorteile sind das? Was verstehst du unter dezentral?

                  > Textdateien im Notfall leichter zu bearbeiten und zu sichern.
                  Komisch, ich dachte immer Elektra unterstützt Textdateien.

                  [
                  | Versenden | Drucken ]
          0
          Von Sebastian Greiner am Do, 21. September 2006 um 10:52 #
          Du hast nicht verstanden was Catonga Dir mitteilen wollte:
          Es geht nicht darum, dass Du in GConf rumfummelst, sondern dass Du ein Tool wie gset-compiz benutzt und dieses in der GConf- oder Elektra-Datenbank/Config/XML-Datei (wie auch immer die Daten endgültig auf der Platte liegen) die Einstellungen vornimmt. csm hätte EXAKT genauso aussehen können und EXAKT die selbe Funktionalität haben können und trotzdem auf GConf oder Elektra basieren können. Dadurch dass die Schnittstellen zu GConf oder Elektra aber eindeutig definiert sind, hätten Distributoren die Möglichkeit Ihre Config-Tools ganz easy mit Compiz-Unterstützung auszustatten.
          Auch wenn ich als KDE-User die Abhängigkeiten, die für XGL mitinstalliert werden mussten, nicht mag, so würde ich die Idee eines systemweit einheitlichen Konfigurationssystems begrüßen.
          [
          | Versenden | Drucken ]
          • 0
            Von Henning Rogge am Do, 21. September 2006 um 11:01 #
            Compiz kann komplett per DBus konfiguriert werden, was ebenfalls ein Standard ist (und in KDE4 sogar DCOP ersetzen wird). Zumindest ist dies der Fall seitdem der GConf Backend durch zwei Teile ersetzt wurde, die "Settings-Ablage" CSM und die "Fernsteuerung" DBus ersetzt wurde.
            [
            | Versenden | Drucken ]
      0
      Von Kai F. Lahmann am Do, 21. September 2006 um 14:13 #
      das einzige, was diese Dinger mit der Windows-Registry gemeinsam haben, ist dass es eine gemeinsame API gegenüber den Programme gibt, um die Variablen zu ändern und auszulesen. Die Windows-Registry schleppt aber unzählige Probleme mit sich rum, die diese Tools alle nicht haben, allen vorran das es eine riesige Binärdatei ist (mag schneller sein, ist dafür aber extrem anfällig und ohne "Notreperaturmöglichkeit") und dass die Keys willkürlich abgelegt werden können (und auch wirklich werden).
      [
      | Versenden | Drucken ]
      • 0
        Von energyman am Do, 21. September 2006 um 19:17 #
        'diese Dinger' haben noch mehr mit der registry gemein:

        völlig unübersichtlich

        kryptische, nichtsagende 'Schlüssel' deren Werte man irgendwie herleiten muß (weil Information gibt es nicht)

        wenn man Fehler macht, gibt es keinen Weg zurück.

        Das es keinen 'save' und 'restore' oder 'undo' Knopf gibt, sondern jeder Furz direkt übernommen wird, macht es nur noch schlimmer.

        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung