# Devs nehmen mein Computer in Beschlag

## Terrere

Guten Tag, ja der Titel ist bestimmt ned treffend, mir egal, ge-fru-stet.

Sooo, wollte heute mal gentoo ein update spendieren, wurde aber

mehr als sauer, und brach ab.

xdg-utils zieht sich mal locker;

[ebuild     U ] x11-misc/xdg-utils-1.1.0_rc1-r1 [1.0.2_p20100618] USE="-doc" 294 kB

[ebuild  N    ]  dev-perl/File-MimeInfo-0.15-r1  USE="-test" 29 kB

[ebuild     U ]  x11-apps/xset-1.2.1-r1 [1.2.1] 0 kB

[nomerge      ] dev-perl/File-MimeInfo-0.15-r1  USE="-test"

[ebuild  N    ]  dev-perl/File-DesktopEntry-0.04  USE="-test" 14 kB

[ebuild  N    ]   virtual/perl-File-Spec-3.31  0 kB

[ebuild  N    ]    perl-core/File-Spec-3.31  0 kB

[ebuild  N    ]   dev-perl/File-BaseDir-0.03  USE="-test" 6 kB

[ebuild  N    ]    virtual/perl-Module-Build-0.36.07  0 kB

[ebuild  N    ]     perl-core/Module-Build-0.36.07  0 kB

[ebuild  N    ]      virtual/perl-ExtUtils-ParseXS-2.22.05  0 kB

[ebuild  N    ]       perl-core/ExtUtils-ParseXS-2.22.05  40 kB

[ebuild  N    ]        virtual/perl-ExtUtils-CBuilder-0.27.03  0 kB

[ebuild  N    ]         perl-core/ExtUtils-CBuilder-0.27.03  0 kB

[ebuild  N    ]      virtual/perl-Archive-Tar-1.54  0 kB

[ebuild  N    ]      virtual/perl-Test-Harness-3.17  0 kB

[ebuild  N    ]      dev-perl/YAML-Tiny-1.41  36 kB

Einziges Packet das ich habe, das abhängt von dem Ding, ist Gimp. (deinstallationskanditat)

Übles Freedesktop.org Gedöns mitsamt den andern Applikationen.

Bin ich nicht mehr Herr über mein System? Ich bin kein Entwickler, sondern nur  ein 

erbämlicher Benutzer. Aber das ist kein Grund, mir meine Kiste mit unnötigem zu bereichern.

Wollt ihr mir jetzt sagen, das es das alles braucht, um mal ein mc zu  installieren? Brauchts 

Firefox um sich zu installieren? Oder was? Wieso hab ich mc und Firefox jetzt Jahrelang OHNE 

diese fragwürdigen Tools installieren können? Ist es nun geekig, anstatt "file" "dev-perl/File-MimeInfo" aufzurufen?

Und; wieso setzt ich use-Flags (-debug) Global, wen es doch in jedem gefühlten 3 Tool hart gesetzt wird?

Hab mein Gentooleben lang nicht mitgezählt, wieviele rebuilds ich tat. Nur für dieses Flag, heute wären es 2.

Sooo, jetzt erst mal auf den Bock schwingen, und Frust mit lautem Knattern in die Welt posaunen.

----------

## Necoro

Mich wunderts, dass xdg-utils bei dir nur von GIMP abhängt. Die ganze xdg-XXX Sache ist dafür da um übergreifend immer die gleiche Applikation für einen Dateityp zu öffnen. Sehr sinnvolles Teil.

Ansonsten: Die Hälfte der Pakete da sind virtuals -- die kannst du also getrost ignorieren, verändern sie ja nix an deinem System. Insgesamt verstehe ich deine Aufregung jetzt nicht, wegen 8 Perl-Paketen.

----------

## franzf

dev-perl/File-MimeInfo liefert auch zwei executables mit, "mimetype" und "mimeopen".

Wieso sollte xdg-utils nicht darauf zurückgreifen?

----------

## Knieper

 *Necoro wrote:*   

> Mich wunderts, dass xdg-utils bei dir nur von GIMP abhängt. Die ganze xdg-XXX Sache ist dafür da um übergreifend immer die gleiche Applikation für einen Dateityp zu öffnen. Sehr sinnvolles Teil.

 

Mich nervt es auch. Je nach Aufgabe und Programm will man bestimmte Dateitypen mit einem mächtigeren Programm öffnen oder nur in einem kleinen Formatbetrachter. xdg-bla haut erst mal alles durcheinander und einige Programme kennen nur noch diesen Mechanismus.

OT: Ich glaube ich werde langsam zu alt für diesen Linux-Desktop-Scheiß. gtk-Programme, die Assertions werfen (wieso werden die mitkompiliert?), weil Icons (wo sollen die auch angezeigt werden?) oder Themes fehlen. Kiloweise beknackte Dämonen (console-/policy-/dbus-/hal-/Session-Schlagmichtot), die man ja unbedingt braucht, wenn man ein simples Problem lösen will und die Software wird allgemein immer unbenutzbarer. Mein neuestes Hassobjekt sind Browser: Opera ist dermaßen verbugt, dass er zZt. unbenutzbar ist, Firefox ist lahm wie sau, instabil und wenn überhaupt nur mit x Plugins halbwegs nutzerfreundlich, andere brauchen Qt oder die genannten Schrottdämonen (Chromium) oder lassen grundlegende Mechanismen vermissen (midori).

Andere Systeme sind nicht viel besser, aber den Freedesktop/KDE/Mozilla-Typen müsste mal jemand mit dem Gummihammer auf die Rübe hauen und ihnen danach einen Kurs "Softwareentwicklung für Unbegabte" schenken.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Mich wunderts, dass xdg-utils bei dir nur von GIMP abhängt. Die ganze xdg-XXX Sache ist dafür da um übergreifend immer die gleiche Applikation für einen Dateityp zu öffnen. Sehr sinnvolles Teil. 
> 
> Mich nervt es auch. Je nach Aufgabe und Programm will man bestimmte Dateitypen mit einem mächtigeren Programm öffnen oder nur in einem kleinen Formatbetrachter. xdg-bla haut erst mal alles durcheinander und einige Programme kennen nur noch diesen Mechanismus.

 

Denn sind aber die Programme verbuggt und nicht xdg-bla. Sinnvollerweise hat man halt ein Standardprogramm für 90% der Fälle -- und für alle anderen sollte das entsprechende Programm ein "Öffnen mit..." anbieten, dass aber nicht den Default setzt.

 *Quote:*   

> Firefox ist lahm wie sau, instabil

 

Firefox4 erscheint mir schneller und flüssiger zu laufen. Ist aber evtl auch nur Einbildung  :Smile:  (und auch das ~/.mozilla in einer RAM-Disk bringt wohl seinen Teil)

----------

## Knieper

 *Necoro wrote:*   

> Denn sind aber die Programme verbuggt und nicht xdg-bla. Sinnvollerweise hat man halt ein Standardprogramm für 90% der Fälle -- und für alle anderen sollte das entsprechende Programm ein "Öffnen mit..." anbieten, dass aber nicht den Default setzt.

 

Das ist ja das Problem. Einige merken sich das "Öffnen mit..." nicht mehr und vertrauen beim Default auf xdg-bla. Wenn ich ein Programm A habe, das Dateityp X mit C öffnet und ein Programm B soll den Dateityp X mit D öffnen, dann habe ich in 50% der Fälle die Arschkarte. Man mag gar nicht erwähnen, dass xdg-bla nach der Installation auf die Idee kam unbekannte Binärdateien mit dem Firefox zu öffnen?!

 *Quote:*   

>  *Quote:*   Firefox ist lahm wie sau, instabil 
> 
> Firefox4 erscheint mir schneller und flüssiger zu laufen. Ist aber evtl auch nur Einbildung  (und auch das ~/.mozilla in einer RAM-Disk bringt wohl seinen Teil)

 

Ich werde mir nicht 25% meines RAMs mit .mozilla vollkloppen. Wenn der Sack der Add-Ons mit FF4 läuft, werde ich es mal testen. Haben die es inzwischen geschafft, das Suchfeld an den Tab zu binden (wie in Opera)? Es nervt tierisch, nur ein Feld zu haben.

OT: Was außerdem nervt, sind die verschwundenen Einstellungsmenüs (Wo speichert man die Einstellungen zB. für evince?) und die nutzerunfreundlichen Dialoge (Datei öffnen in gtk).

----------

## Terrere

Sooo, also erst mal Danke, das ihr mein Post so freundlich entgegen nahmt.

Leider bin ich aber immer noch sauer,  so dermassen, das ich mich wieder auslogge.

(shice Perl, hehe, sry)

MfG

----------

## AmonAmarth

 *Terrere wrote:*   

> Sooo, also erst mal Danke, das ihr mein Post so freundlich entgegen nahmt.
> 
> Leider bin ich aber immer noch sauer,  so dermassen, das ich mich wieder auslogge.
> 
> (shice Perl, hehe, sry)
> ...

 

vielleicht hilft das zur aufmunterung falls du es noch nicht kennst, denn demnach ist perl vodoo:

http://blog.aegisub.org/2008/12/if-programming-languages-were-religions.html

----------

## slick

 *Knieper wrote:*   

> OT: Ich glaube ich werde langsam zu alt für diesen Linux-Desktop-Scheiß. gtk-Programme, die Assertions werfen (wieso werden die mitkompiliert?), weil Icons (wo sollen die auch angezeigt werden?) oder Themes fehlen. Kiloweise beknackte Dämonen (console-/policy-/dbus-/hal-/Session-Schlagmichtot), die man ja unbedingt braucht, wenn man ein simples Problem lösen will und die Software wird allgemein immer unbenutzbarer. [..] Andere Systeme sind nicht viel besser, aber den Freedesktop/KDE/Mozilla-Typen müsste mal jemand mit dem Gummihammer auf die Rübe hauen und ihnen danach einen Kurs "Softwareentwicklung für Unbegabte" schenken.

 

++

----------

## Terrere

Sooo, werte Gentoobenutzer, das wars.

FreeBSD und Gentoo waren immer meine Lieblinge.

Ich hatte viele Distris auf meinen Rechner installiert, aus lauter Neugier,

Spass, Zeitvertreib, und als Hirnbeschäftigung. Tja, da hatte ich auch noch

keine Kinder, die auch mit mir ihre Zeit verbringen wollen. Zeit ist eine

unbezahlbare Ressource, vorallem, wen man noch nen Job hat.

Hier stehen 5 Rechner, 4 verschiedene Betriebssysteme. So kann es nicht

weitergehen. Ich hab nie mit den "flamewars" mitgemacht, und andere OS

kritisiert. Wer nur richtig sucht, findet überall etwas um zu meckern.

Auch war es mir egal, ob Linux den "Desktop" erreicht. Wer etwas Geduld

mitbringt, kann/konnte sich Klickibunti installieren, ganz ohne Stress.

Für mich jedenfalls ist der Punkt erreicht. Keine howtos erst mal

mit einem Blick aufs Datum vorsortieren. Nix mehr Illusion des frei sein,

und sich dann doch X-Sachen installieren lassen, die man gar nicht braucht/will.

Fertig auf das warten, das der (jo, kack-Geschenk, I-Pod 5G) endlich unterstützt wird.

Erklärt das mal eurerm Kind, dass das Geschenk nix taugt, und schaut zu, wie die 

leuchtenden Augen des Kindes sich verändern. Hab ich natürlich nicht, besitze ja Win-XP.

Seit heute morgen ca. 10:30, neuerdings mit ner Win7 Pro DVD.  :Smile: 

Ja, es gehört nicht mir, unter die Haube darf ich schon gar nicht gucken,

und Probleme wirds auch geben. Aber dem Ziel näherkommend, nämlich Zeitersparnis.

Wie auch immer, ich weiss, das hier nicht jeder Entwickler mitliest. Trotzdem,

grosses Danke, die Zeit war schön, 27 Jahre opensource, freeware, etc.

Nicht unerwähnt sei auch forums.gentoo.org. Hier gehts gemütlich zu,

(ok, 1 - 2 Ausreisser, hehe, nix schlimmes) fand immer Hilfe und Anregungen.

Aus lauter Gewohnheit, werd ich noch so manches mal hier lesend vorbeischauen.

In diesem Sinne, und Ehrlich gemeint; machts gut.

Terrere

----------

## Knieper

 *Terrere wrote:*   

> Wer nur richtig sucht, findet überall etwas um zu meckern.

 

Was ja nicht schlecht ist. Nur dadurch wird etwas besser oder entstehen Alternativen.

 *Quote:*   

> Seit heute morgen ca. 10:30, neuerdings mit ner Win7 Pro DVD. 

 

Ich habe es auch versucht, aber zu mehr als einem Mediaplayer in der Stube taugt es nicht. Keine Möglichkeiten, System oder Fehler zu analysieren, schlechtere Hardwareunterstützung im Vergleich zu Linux, viel zu viel Programme notwendig, um normales Verhalten zu emulieren (zB. AnyDVD), fehlende Software im wissenschaftl. Bereich, zu viel Bloat - wenn auch besser versteckt, für Entwickler ein Alptraum und das Schlimmste: kein zentrales Repository und kein zentraler Aktualisierungsmechanismus.

Momentan bleibt für mich deswegen nur Linux. T2 könnte ich mir als einzige Alternative zu Gentoo noch vorstellen, nur hat das eine ziemlich kleine Nutzerbasis und die damit verbundenen Probleme.

Ich wünsche Dir jedenfalls, dass Dein jetziges System zu Dir passt. Ich warte derweil auf: http://blog.pommesbude.org/uploads/75371005_3a5054df1a.jpg um mich an den Desktop-Codemonkeys zu rächen.

----------

## ChrisJumper

Nun bisher stören mich diese Desktop-Dinge nicht so sehr, ich jage noch nicht jedem Programm und jeder Bibliothek hinter her. Ich denke es kostest viel mehr Zeit sich darüber zu ärgern oder Abhängigkeiten zu Umgehen als diese -wenigen- Pakete zu Kompilieren. Auf Netzwerk-Server-Systemen läuft kein xorg sondern ein schmales Gentoo mit einem sshd.

Auf Systemen mit Desktop habe ich bisher nur die Klassiker (Gnome/Fluxbox/KDE..) weil ich diese ausprobiere usw. natürlich sind mir die Umstände mit HAL/DBUS/UDEV und Consolekit auch schon aufgefallen und es ist definitiv nicht optimal, aber ich Denke trotzdem das der Trend in die richtige Richtung geht (HAL raus, Consolekit glaube ich bald auch..).

Zudem kann man doch diese Dienste ausschalten oder probeweise Deaktivieren und mit Gentoo entsprechend Einstellen. Das "die Entwickeler" nicht jede Einstellungskombination testen können sollte doch auch klar sein. Mir fällt keine bessere Lösung ein. Bei Windows und Co hat man doch immer nur komplett-Pakete (natürlich auch weniger Aufwand/mehr Zeit) aber eben keine Kontrolle mehr über sein System. Daher verstehe ich nicht genau den Grund was beklagt wird.

Generell sollte man aber vielleicht darüber Schreiben oder Bloggen, auch wie man z.B. ein Gentoo mit wenigen Pakten ohne Consolekit/Hal/Xorg erstellen kann und Gleichzeitig noch gut benutzen kann ohne auf "Luxus" (vllt. diverse statische Xorg-Programme) verzichten zu müssen.

Das soll jetzt keine Kritik sein aber ich verstehe den Vorwurf nicht. Natürlich ist es der Digitalen Hygiene wichtig so wenig überflüssigen Code auf dem System haben wie möglich. Aber das ist doch alles relative. Bei "anderen" nicht Linux Systemen finde ich diesen Zustand noch Schlimmer.

 *Quote:*   

> Erklärt das mal eurerm Kind, dass das Geschenk nix taugt, und schaut zu, wie die
> 
> leuchtenden Augen des Kindes sich verändern. Hab ich natürlich nicht, besitze ja Win-XP. 

 

Das sollte doch z.B. auch in einer Virtual-Box funktionieren.

Knieper,

mich interessiert jetzt wirklich wie den System aussieht und wie du damit arbeitest. Verwendest du Fluxbox oder awesome? Für diverse Dinge brauch ich einfach eine WM und somit X.. ich kann z.B. nicht auf OpenOffice verzichten oder den Firefox.

----------

## Knieper

 *ChrisJumper wrote:*   

> Ich denke es kostest viel mehr Zeit sich darüber zu ärgern oder Abhängigkeiten zu Umgehen als diese -wenigen- Pakete zu Kompilieren.

 

Da habe ich andere Erfahrungen gemacht. Die paar Perl-Skripte oben würden mich allerdings weniger stören.

 *Quote:*   

> Zudem kann man doch diese Dienste ausschalten oder probeweise Deaktivieren und mit Gentoo entsprechend Einstellen.

 

Und was machst Du, wenn Programme diese Dienste/Programme erzwingen, obwohl man deren Funktionalität nie nutzt? Ich hatte letztens kcachegrind erwähnt. Je nach Rechner bei mir 300-400MB an Abhängigkeiten, obwohl nahezu keine USE-Flags gesetzt sind. Soll ich erst Ebuilds ändern oder Software patchen müssen, um ein simples Programm (und kcachegrind ist nicht wirklich komplex) nutzen zu können?

 *Quote:*   

> Das "die Entwickeler" nicht jede Einstellungskombination testen können sollte doch auch klar sein.

 

Es geht hier um ganze Mechanismen, nicht nur um einzelne Einstellungen und selbst letztere sollten eine so klare Spezifikation haben, dass man weiß, welche "Einstellungen" voneinander abhängig sind.

 *Quote:*   

> Generell sollte man aber vielleicht darüber Schreiben oder Bloggen, auch wie man z.B. ein Gentoo mit wenigen Pakten ohne Consolekit/Hal/Xorg erstellen kann

 

Kein Problem, einfach nicht installieren.

 *Quote:*   

> Knieper,
> 
> mich interessiert jetzt wirklich wie den System aussieht und wie du damit arbeitest. Verwendest du Fluxbox oder awesome? Für diverse Dinge brauch ich einfach eine WM und somit X.. ich kann z.B. nicht auf OpenOffice verzichten oder den Firefox.

 

Ich bin zwar der Meinung, dass auch X überarbeitet werden sollte, bin aber niemand, der Leute zwingt ohne X auszukommen. Ich nutze es selbst, schon allein weil Textbrowser nur selten befriedigend nutzbar sind. Bei mir laufen eben lediglich xorg-server/-drivers und ein paar wenige andere Pakete mit Xmonad und kein xorg-x11 + fette Desktopumgebung + [gk]dm. Macht nach dem Start weniger als 15 Prozesse (inkl. X, WM, dnsmasq, wpa*, udev, Webserver, fgetty...; ohne Kernprozesse) und der Speicherverbrauch liegt im niedrigen zweistelligen Bereich.

Ich mag Software, die nicht nervt und einfach nur ihre Aufgabe erfüllt, zB. rtorrent - ich speichere die torrent-Datei in einem Ordner, starte es und es lädt alles runter. Dafür braucht man keine graphische Oberfläche und jeder Klick, jede Tastatureingabe, jeder Dienst usw. wäre nur umständlicher und überflüssig.

Was ich hasse ist, wenn Entwickler meinen,

1. sie müssten irgendetwas "einfacher" oder "übersichtlicher" gestalten, dann aber keine Ahnung von UI-Gestaltung haben

- zB. die neue Ein-Knopf-Bedienung der Browser ist nur die alte Steuerung + x Klicks mehr, um den Menüpunkt zu erreichen

- oder der gtk-Datei-öffnen-Dialog zB. in Geany, sortieren nach Dateigröße nicht möglich, navigieren ohne Maus extrem umständlich

2. sie dürften den Nutzer nicht mit vielen Einstellungen verwirren

- gute Defaultwerte und entspr. Dokumentation würden reichen, der wichtigste Punkt an Nutzerfreundlichkeit ist die Einstellbarkeit

- zB. (s. oben) weiß ich heute noch nicht, wie ich evince dazu bringe, immer mit "best fit" zu öffnen - "save current settings as default" klappt jedenfalls nicht und per "man evince" und "evince --help-all" erfährt man nichts, Konfigurationsdateien scheint es nicht zu geben

3. alle Leute bräuchten genau ihre Automatismen und diese dann erzwingen

- Ich kann nicht verstehen, wie man als Anwender noch Fenster selbst positioniert. Das kann der Rechner wirklich besser und wenn man Menschen beobachtet, kommt genau das sehr häufig vor. Kümmert unter den dicken DEs niemanden, aber Session-Verwaltung, Zugriffsbeschränkungen, Prozesskommunikation, Geräteverwaltung, Konfigurationsmenüs für vorhandene Dateien und mehr fette Dienste, die Mechanismen kopieren, die das darunterliegende System schon bietet (oft sogar mächtiger), die muss man unbedingt haben.

Dass viele von denen einfach nicht in der Lage sind, gute und robuste Software zu schreiben, ist ein Problem der ganzen Branche und hat nichts mit Linux oder Windows zu tun.

----------

## Necoro

 *Knieper wrote:*   

> und der Speicherverbrauch liegt im niedrigen zweistelligen Bereich.

 

Also bei 4 GB RAM ist mir persönlich egal, ob der Desktop nun 55MB oder 550MB verbraucht.

 *Quote:*   

> - zB. die neue Ein-Knopf-Bedienung der Browser ist nur die alte Steuerung + x Klicks mehr, um den Menüpunkt zu erreichen

 

Vimperator-Plugin in Firefox und schon schert dich die UI einen Dreck  :Smile: 

 *Quote:*   

> zB. (s. oben) weiß ich heute noch nicht, wie ich evince dazu bringe, immer mit "best fit" zu öffnen - "save current settings as default" klappt jedenfalls nicht und per "man evince" und "evince --help-all" erfährt man nichts, Konfigurationsdateien scheint es nicht zu geben

 

Ich würde fast tippen, dass man es mit USE=gnome installieren muss. Denn das zieht gconf mit sich (und nur das -- warum auch immer das Useflag denn nicht 'gconf' heißt).

 *Quote:*   

> Dass viele von denen einfach nicht in der Lage sind, gute und robuste Software zu schreiben, ist ein Problem der ganzen Branche und hat nichts mit Linux oder Windows zu tun.

 

Viele schreiben aber auch für eine andere Zielgruppe als dich. Tante Emma will, dass wenn sie ihren USB-Stick anschließt, dass denn einfach genau das richtige passiert. Dass sie mit ihrem Zwei-Finger-Such-System nicht auf die Tastatur angewiesen ist. Und dass sie sich nicht erst in Xmonad-Konfiguration einlesen (und verstehen!) muss, um zu surfen und ein, zwei andere Fenster offen zu haben.

----------

## Knieper

 *Necoro wrote:*   

> Also bei 4 GB RAM ist mir persönlich egal, ob der Desktop nun 55MB oder 550MB verbraucht.

 

Dir, mir aber nicht, weil ich öfter mit Berechnungen zu tun habe, die nahezu den kompletten Speicher belegen und wenn dann die Oberfläche im Swap landet, ist der Spaß vorbei.

 *Quote:*   

> Vimperator-Plugin in Firefox und schon schert dich die UI einen Dreck 

 

Und noch ein Plugin... Vim benutze ich seit einiger Zeit nicht mehr, weil es nur für C-ähnliche Sprachen wirklich sinnvoll einsetzbar ist. Ob Vimperator da noch ein Vergnügen ist, müsste man ausprobieren. Ich glaube das letzte Mal hatte ich es für FF1.x auf dem Rechner.

 *Quote:*   

> Ich würde fast tippen, dass man es mit USE=gnome installieren muss. Denn das zieht gconf mit sich (und nur das -- warum auch immer das Useflag denn nicht 'gconf' heißt).

 

Und was will gconf wieder haben? Dbus. Das können die doch nicht ernst meinen.

 *Quote:*   

> Viele schreiben aber auch für eine andere Zielgruppe als dich.

 

Man schreibt nicht für Zielgruppen, sondern löst Probleme. Jede Erleichterung für Emma (und damit erhöhte Komplexität des Programms) muss ein _optionaler_ Zusatz sein. All das, was die versuchen mir zu bieten, will ich doch gar nicht haben.

Ich halte es auch für Augenwischerei, Software für DAUs zu schreiben. DAUs nutzen kein Linux und wollen kein Linux. Wieso muss darunter der professionelle Anwender leiden?

 *Quote:*   

> Und dass sie sich nicht erst in Xmonad-Konfiguration einlesen (und verstehen!) muss, um zu surfen und ein, zwei andere Fenster offen zu haben.

 

Gibt doch genug andere (tiling) WMs und xmonad mit Bluetile sieht auch nicht wirklich kompliziert aus.

----------

## Necoro

 *Knieper wrote:*   

> DAUs nutzen kein Linux und wollen kein Linux.

 

Schau dir die Hanisch-Threads an.

 *Quote:*   

> gibt doch genug andere (tiling) WMs und xmonad mit Bluetile sieht auch nicht wirklich kompliziert aus.

 

Kompliziert für dich ist was anderes als kompliziert für andere. Wenn ich schon sehe, dass ich es nicht hinbekomme meiner Mutter den Unterschied zwischen der Adresszeile im Browser und der Google-Suchmaske zu erklären, so würde an sowas sicherlich verzweifeln.

Ich kann deinen Ärger verstehen, aber du machst es dir ein wenig leicht mit der Annahme, dass alle Linux-User so sind wie du. Wenn das so wäre, gäbe es ja die Probleme nicht. Ich würde sogar sagen: Deine Probleme sind den Anwendungsentwicklern noch nicht mal bekannt. Denn diese entwickeln doch nur für die Usecases die ihnen bekannt sind (und selbst davon wohl nicht alle). Und wenn alle ihre Usecases sagen "10 MB mehr RAM für nen Daemon mehr kratzt niemanden" -- naja -- denn benutzen sie halt nen Daemon mehr.

Und zum Schluss kommt noch was anderes wichtiges hinzu: Der Spieltrieb. Denn fast alle Entwickler macht das Zeugs in ihrer Freizeit. Und dort die Sachen, die sie interessieren. Und dazu gehört halt auch mal, Bloat hinzuzufügen, weil man sich mal mit dem Thema beschäftigen möchte. Als Beispiel: Weil ich mich mal genauer mit XML und XSDs beschäftigen wollte, hatte ich das Pluginsystem für Portato komplett auf XML aufgebaut. Einfach weil ich damit mal rumspielen wollte. Später hab ichs denn wieder rausgeschmissen, weils unpraktikabel war -- aber erstmal war es da. Es gab auch schon Pläne Portage mit DBus zu verquicken etc.

----------

## Knieper

 *Necoro wrote:*   

>  *Knieper wrote:*   DAUs nutzen kein Linux und wollen kein Linux. 
> 
> Schau dir die Hanisch-Threads an.

 

Ich musste eine Suchmaschine nutzen, um zu sehen, was (wen) Du meinst. Was meine Erfahrung angeht, behaupte ich einfach mal das klappt nicht. Jeder, der damit arbeiten will, muss in der Lage sein, sich die nötigen Informationen anzulesen. Ich hatte Linux privat einigen Leuten installiert (sogar mal Ubuntu), aber nach einiger Zeit kam immer: "Wie kann ich Data Beckers Ponydruckerei installieren?", "Auf Arbeit haben wir aber auch Word.", "Wo ist Power Point?" oder "Bei der Weiterbildung nehmen wir aber Windows. Wie soll ich da üben?". Es funktioniert fast nie, selbst bei Rentnern, die nur ab und zu eine E-Mail schreiben oder im Netz surfen.

 *Quote:*   

> Wenn ich schon sehe, dass ich es nicht hinbekomme meiner Mutter den Unterschied zwischen der Adresszeile im Browser und der Google-Suchmaske zu erklären, so würde an sowas sicherlich verzweifeln.

 

Diese Fälle hat jeder in der Familie und die häufigste Suchanfrage bei Google ist (war?) nicht umsonst "google". Meine Eltern tun sich aber auch mit dem Plazieren von Fenstern schwer (Windows) und wenn dann auch noch eine Statusmeldung ausfährt, bricht bald Panik aus.

 *Quote:*   

> aber du machst es dir ein wenig leicht mit der Annahme, dass alle Linux-User so sind wie du

 

Das Gegenteil ist der Fall. Jeder ist verschieden, daher muss Software anpassbar sein, um nur ein Minimum an Nutzerfreundlichkeit zu garantieren. Wenn Gnome-Leute für DAUs schreiben, dann bedienen sie eine Randgruppe und die Mehrheit der Nutzer kommt sich veräppelt vor.

 *Quote:*   

> Und wenn alle ihre Usecases sagen "10 MB mehr RAM für nen Daemon mehr kratzt niemanden" -- naja -- denn benutzen sie halt nen Daemon mehr.

 

Wenn man so argumentiert, dann könnte man auch sagen: "Die paar Byte für ein Kommandozeilenargument "--best-fit" stören niemanden und entsprechen den 'nix-Gewohnheiten.". Du willst mir doch nicht erzählen, dass sie nie darüber nachgedacht haben oder es ihnen nicht in den Sinn gekommen wäre. Sollte dies der Fall sein, würde ich mir eine Liste der Beteiligten ausdrucken und jede Software die nur in der Nähe dieser Programmierer war sofort deinstallieren.

 *Quote:*   

> Der Spieltrieb. Denn fast alle Entwickler macht das Zeugs in ihrer Freizeit.

 

Nichts gegen Spieltrieb, aber wenn es zB. der offizielle Viewer einer Desktopumgebung ist, dann sollte ein Branch existieren, der konservativer ist.

----------

## ChrisJumper

Das Problem ist ein Fließendes, ich würde mir auch eher weniger Speicherverbrauch und diesen ganzen Deamon-Quark bei Bedarf abschalten. Also das ich wenn ich mich in meine Fluxbox-Session einlogge mein System weiß das es nur sehr Minimal mit den Ressourcen umgehen soll.  Nun es macht dies natürlich schon auf einem Level unter der Annahme das jedes System heute viel Speicher hat. Aber gerade wenn man noch die eine oder andere alte Kiste verwendet merkt man das man mit 1-1,5GB Arbeitsspeicher nicht mehr arbeiten (u. Surfen) kann.

Diese ganzen aktuellen Probleme schiebe ich aber erst mal auf die KDE/Xorg Neuzeit. Es hat wie Necoro beschreibt bestimmt auch was mit dem Spieltrieb zu tun so das man die XML-FDIs verwendet hat usw... welche jetzt aber auch bestimmt dafür verantwortlich sind das diese nahezu zero-conf-plugin Möglichkeit mit xorg in Zukunft auch ohne hal/udev funktioniert. Insofern ist es mir egal.

Kneiper ich denke halt das es Sinnvoll wäre wenn du deine Interessen mit anderen Teilst die genauso denken. Also ich kenne jetzt die kcachegrind-Situation nicht und habe meine Gentoo-Aufmerksamkeit in den letzten Monaten sehr vernachlässigt aber:

 *Quote:*   

> Ich hatte letztens kcachegrind erwähnt. Je nach Rechner bei mir 300-400MB an Abhängigkeiten, obwohl nahezu keine USE-Flags gesetzt sind. Soll ich erst Ebuilds ändern oder Software patchen müssen, um ein simples Programm (und kcachegrind ist nicht wirklich komplex) nutzen zu können?

 

Wenn man sich mit anderen zusamen tut und die entstehenden Ebuilds anpasst und in ein Overlay packt haben andere auch etwas davon und im besten Fall man selbst nicht so viel Arbeit. Allerdings ist die pflege sehr aufwendig. (Bzw 300-400MB sind wirklich viel, klingt nach dem kompletten KDE.)

Meine Vermutung: Der Umstand das die Zusammenhänge immer komplizierter werden ist das die Software immer komplexer wird. Da wird dann auch entsprechend drüber nachgedacht wie die Probleme gelöst werden und das so umgesetzt, aber wenn man als Neuling darauf stößt und sich fragt was Consolekit ist und ob man das braucht oder welchen Sinn und Zweck es erfüllt. Das kann man gar nicht abschätzen. Sicher man kann z.B. auf Hal/Consolekit verzichten aber das interessante ist doch auf welche Funktionen muss ich dann verzichten oder welchen Mehrwert bietet mir das Programm. Diese Punkte kann man sich nur sehr mühsam zusammensuchen.

 *Quote:*   

> Ich halte es auch für Augenwischerei, Software für DAUs zu schreiben. DAUs nutzen kein Linux und wollen kein Linux. Wieso muss darunter der professionelle Anwender leiden?

 

Weil es immer mehr Anfänger gibt als Experten, in der Regel sterben Experten irgendwann und sind dann einfach Futsch. Es Anfängern leicht zu machen ist unter Wettbewerbskriterien richtig sexy und gibt mehr Benefit für die längere Lebensphase des Programms. Aber ich bin dafür das man es lieber Intelligent löst, also das der User sich bewusst ist was er tut und diese Entscheidung bewusst trifft (so wie beim Lesen im Vergleich zum Videostream). Verbreitung ist gut solange all diese Dinge optional sind. Ich wünsche mir sehr das ich alle Programme so selbstverständlich unter jedem Betriebsystem nutzen kann wie es aktuell für Windows der Fall ist aber dabei immer die Wahl habe und keine Zwänge.

@Necero

Die Hanisch Situation verschärft sich dadurch das er Gentoo nur virtuell nutzt glaube ich. Daher versteht er auch nicht warum das so aufwendig ist, der Kontext ist ganz fremd. Vielleicht hat er irgendwo auch nur ein fertiges Image benutzt statt Gentoo althergebracht zu installieren.

----------

## ChrisJumper

 *Quote:*   

> "Die paar Byte für ein Kommandozeilenargument "--best-fit"

 

Sicher bin ich mir natürlich nicht, aber ich denke sehr wohl das die meisten Anwendungen von KDE und GNOME eben nicht dazu gedacht sind sie unabhängig von dieser Desktop-Umgebung zu installieren und auszuführen. Die denken darüber nicht nach. Vielleicht machen es die Leute die eine Software für Windows transportieren so habe ich erfreulicher Weise festgestellt das Evince jetzt auch unter Windows verfügbar ist und mir diesen Installiert denn ich hasse die Trägheit von dem Adobe-Reader. Was musste ich Festellen? Es wird ein .gnome Konfigurationsverzeichnis unter Windows angelegt! Das zeigt das Menschen faul sind und sobald es läuft ist ihnen alles egal sie kümmern sich nicht darum das Windows die Benutzereinstellungen anders Verwaltet und ablegt, normalerweise sollten beim Portieren diese Systemdesigneinstellungen berücksichtigt werden.

Mich wundert es dann nicht das jemand dieses "--best-fit" noch nicht integriert hat und für Außenstehende ist der Aufwand (relativ) zu hoch diese Option ein zu pflegen. Also die Komplexität des Programms zu begreifen und sinnvoll zu Modifizieren, also alles relative zum Problem. Ist das Problem zu wichtig wird es ganz bestimmt gemacht.

----------

## Necoro

 *Quote:*   

>  *Quote:*   Und wenn alle ihre Usecases sagen "10 MB mehr RAM für nen Daemon mehr kratzt niemanden" -- naja -- denn benutzen sie halt nen Daemon mehr. 
> 
> Wenn man so argumentiert, dann könnte man auch sagen: "Die paar Byte für ein Kommandozeilenargument "--best-fit" stören niemanden und entsprechen den 'nix-Gewohnheiten.". Du willst mir doch nicht erzählen, dass sie nie darüber nachgedacht haben oder es ihnen nicht in den Sinn gekommen wäre.

 

Mhm doch. Kann passieren, wenn man nach und nach Optionen hinzufügt und denn vergisst sie an allen Stellen anzubieten. Da sie ja "--fullscreen" etc anbieten würde ich sogar darauf tippen, dass sie es schlicht vergessen haben. Hast du schon mal einen Evince-Bug aufgemacht, vielleicht sogar gleich mit Patch? Das behebt denn gleich dein Problem  :Smile: 

 *Quote:*   

>  *Quote:*   Der Spieltrieb. Denn fast alle Entwickler macht das Zeugs in ihrer Freizeit. 
> 
> Nichts gegen Spieltrieb, aber wenn es zB. der offizielle Viewer einer Desktopumgebung ist, dann sollte ein Branch existieren, der konservativer ist.

 

Branches erhöhen die Komplexität. Und 'sollen' müssen sie schon gar nix.

Btw: Vielleicht solltest du dir statt evince mal zathura oder mupdf anschauen  :Very Happy: . Die sind vielleicht eher deine Kragenweite.

----------

## Knieper

 *Necoro wrote:*   

> Vielleicht solltest du dir statt evince mal zathura oder mupdf anschauen . Die sind vielleicht eher deine Kragenweite.

 

Mupdf werde ich mir mal angucken, wenn die letzte Version in Portage ist. Evince nutze ich aber auch wegen der djvu-Unterstützung.

----------

## Yamakuzure

Also irgendwie geht mir da grad ein wenig der Hut hoch. Entweder ich verstehe euch gerade völlig falsch (dank der beknackten Sommerzeit nicht auszuschließen) oder die Wirklichkeit sollte mal Einzug halten.

Wer ein Programm für Windows, Mac OS X, KDE, Gnome, Xfce4 oder welches System auch immer, schreibt, geht doch schlicht davon aus, dass das System da ist. Schließlich wird dafür geschrieben. Wer sich dann also wundert das ein Programm für Gnome Abhängigkeiten unter den Gnome-Systempaketen hat, sollte vielleicht nochmal überlegen.

Dazu kommt die Wiederverwendung von bestehendem Code. Warum soll ich bitteschön Funktionalität X selber schreiben (und dir somit unbemerkt unterjubeln), wenn es selbige Funktionalität schon in Bibliothek Y gibt? Vor Allem weil du durch die Abhängigkeit, die natürlich möglichst optional sein sollte, aber eben nicht immer optional sein kann, informiert bist. Informiert darüber, was du bekommst.

Ich hatte den Ärger tatsächlich mal bei einem Paket, dessen Entwickler der Meinung war nur ein paar Quelldateien (die veraltet waren) der libltdl  (sys-devel/libtool) zum direkten einkompilieren mitzuliefern. da weißte nicht, was du bekommst!

Aber besonders spaßig finde ich die Aussage "Ich kann nicht verstehen, wie man als Anwender noch Fenster selbst positioniert." - Bitte? Um Himmels Willen, ich würde überhaupt nichts mehr geschafft bekommen, wenn ein WM meint meine Fenster positionieren zu müssen. Das wäre absolut katastrophal. Also zuerst sich über "aufgezwungene" Abhängigkeiten aufregen, und dann erzwungene Fensterpositionierung propagieren. Das ist echt ein wenig fragwürdig.

----------

## Knieper

 *Yamakuzure wrote:*   

> Wer ein Programm für Windows, Mac OS X, KDE, Gnome, Xfce4 oder welches System auch immer, schreibt, geht doch schlicht davon aus, dass das System da ist.

 

Betriebssysteme und Desktopumgebungen kann man nicht in einen Topf werfen. Gnome, Kde usw. laufen zu 99% auf *nix-Systemen, also sollte man erst einmal deren vorhandene Mechanismen nutzen und die üblichen Gepflogenheiten beibehalten. Man kann sich vielleicht an nur eine gui-Bibliothek wie gtk binden, wenn man zu viele Drogen nimmt auch an qt, aber dem Nutzer vorschreiben, welche Dienste und DEs er nutzt, das dürfte wohl kein ernsthafter Entwickler beabsichtigen. Als nächstes schreibt man keine man-Pages mehr, weil man ja einen chm-Viewer integriert hat und verlangt einen mysql-Server, weil man keine Konfigurationsdateien einlesen will...

 *Quote:*   

> Dazu kommt die Wiederverwendung von bestehendem Code. Warum soll ich bitteschön Funktionalität X selber schreiben (und dir somit unbemerkt unterjubeln), wenn es selbige Funktionalität schon in Bibliothek Y gibt?

 

ZB. weil Bibliothek Y Schrott ist, kein Upstream mehr existiert, die Architektur nicht zum Rest des Programmes passt etc.. Gründe kann es viele geben. Ich bemängelte aber, dass Bibliotheken und Dienste eingebunden werden, die nicht benötigt werden und mit der Problemstellung des Programmes nichts zu tun haben.

 *Quote:*   

> ich würde überhaupt nichts mehr geschafft bekommen, wenn ein WM meint meine Fenster positionieren zu müssen

 

Das halte ich für einen Trugschluss und für festgefahrene Verhaltensmuster. Es gibt nur sehr wenige Fälle, in denen Einzelfenster sinnvoller per Hand angeordnet werden und dann sind meistens Fehler in der Oberflächengestaltung schuld.

 *Quote:*   

> Also zuerst sich über "aufgezwungene" Abhängigkeiten aufregen, und dann erzwungene Fensterpositionierung propagieren.

 

Lesen kannst Du?

----------

## Yamakuzure

 *Knieper wrote:*   

> ZB. weil Bibliothek Y Schrott ist, kein Upstream mehr existiert, die Architektur nicht zum Rest des Programmes passt etc.. Gründe kann es viele geben. Ich bemängelte aber, dass Bibliotheken und Dienste eingebunden werden, die nicht benötigt werden und mit der Problemstellung des Programmes nichts zu tun haben.

 Natürlich. Wenn besagte Bibliothek garnicht verwendet wird, oder gar "tot" ist, dann ist die Abhängigkeit natürlich völliger Unsinn, da hast du vollkommen recht. *Knieper wrote:*   

>  *Yamakuzure wrote:*   ich würde überhaupt nichts mehr geschafft bekommen, wenn ein WM meint meine Fenster positionieren zu müssen 
> 
> Das halte ich für einen Trugschluss und für festgefahrene Verhaltensmuster. Es gibt nur sehr wenige Fälle, in denen Einzelfenster sinnvoller per Hand angeordnet werden und dann sind meistens Fehler in der Oberflächengestaltung schuld.

 Bei ca. 30-50 Fenstern, und so manche davon sind "Konsole" mit 10-20 Tabs, absolut kein Trugschluss. Es kommt immer darauf an wer was womit wofür tut. Im Übrigen habe ich das unter OpenBox. Ich möchte dich nur ungern verärgern, aber dir wurde, sogar in diesem Thread, schon einmal vorgeworfen, dass du es dir zu einfach machst, wenn du deine Situation als Allgemeingültigkeit darstellst. Ich wette, dass mein Arbeitsalltag extrem anders aussieht als deiner. Ich verwende Linux nicht nur privat, sondern hauptsächlich beruflich.

Aber worauf ich hinaus wollte ist das: *Knieper wrote:*   

> zB. (s. oben) weiß ich heute noch nicht, wie ich evince dazu bringe, immer mit "best fit" zu öffnen - "save current settings as default" klappt jedenfalls nicht und per "man evince" und "evince --help-all" erfährt man nichts, Konfigurationsdateien scheint es nicht zu geben
> 
> (...)
> 
> Und was will gconf wieder haben? Dbus. Das können die doch nicht ernst meinen. 

 evince: "Simple document viewer for GNOME" 

-> Ergo : "konfiguration per gconf, damit sich das Programm für Gnome in Gnome integriert.

gconf: "Gnome Configuration System and Daemon" -> Ergo: Braucht etwas um von anderen Programmen "ansprechbar zu sein"

dbus: "A message bus system, a simple way for applications to talk to each other"

Das ist es, was ich meinte. Es gibt keinen vernünftigen Grund ein Gnome-Programm zu schreiben, dass sich nicht in Gnome einfügt, weil eine verschwindend kleine Anzahl an Benutzer gerne Konfigurationsdateien haben möchten. Es wäre sicher schön, wenn die Evince-Entwickler diese Möglichkeiten mit anböten, aber einen zwingenden Grund gibt es nicht.

----------

## Knieper

 *Yamakuzure wrote:*   

>  *Knieper wrote:*   Das halte ich für einen Trugschluss und für festgefahrene Verhaltensmuster. Es gibt nur sehr wenige Fälle, in denen Einzelfenster sinnvoller per Hand angeordnet werden und dann sind meistens Fehler in der Oberflächengestaltung schuld. Bei ca. 30-50 Fenstern, und so manche davon sind "Konsole" mit 10-20 Tabs, absolut kein Trugschluss. Es kommt immer darauf an wer was womit wofür tut. Im Übrigen habe ich das unter OpenBox.

 

Siehst Du und doch ist es wieder der übliche Trugschluss, Dein Tab-Beispiel zeigt es sogar deutlich. 30-50 Fenster zu positionieren kostet viel Zeit, Du gruppierst sie über Tabs, hast bestimmte Vorlieben oder Regeln, wonach Du sie anordnest und am Ende hast Du keinen Vorteil gegenüber einer automatischen Anordnung. Du darfst nicht vergessen, dass fast alle Tiling WMs auch eine freie Anordnung zulassen. (Programminterne Tabs (nicht die von *Box), wie in <Browser>, <Editor>, <shell multiplexer> sind sogar vollkommen überflüssig mit mächtigerem WM und ordentlicher Architektur.)

 *Quote:*   

> evince: "Simple document viewer for GNOME" 
> 
> -> Ergo : "konfiguration per gconf, damit sich das Programm für Gnome in Gnome integriert.
> 
> gconf: "Gnome Configuration System and Daemon" -> Ergo: Braucht etwas um von anderen Programmen "ansprechbar zu sein"
> ...

 

Du markierst falsch:

 *Quote:*   

> evince: "Simple document viewer for GNOME"

 

Zuerst ein einfacher Dokumentenbetrachter für *nix, zusätzlich mit Gnome-Unterstützung.

 *Quote:*   

> dbus: "A message bus system, a simple way for applications to talk to each other"

 

Keine anderen Applikationen, kein Bedarf an Dbus. Dbus ist nicht umsonst in den meisten Programmen optional.

 *Quote:*   

> Es gibt keinen vernünftigen Grund ein Gnome-Programm zu schreiben, dass sich nicht in Gnome einfügt

 

Du verdrehst immer die Aussagen. Klar darf sich das Programm in Gnome einfügen, es darf nur nicht den Nutzer zwingen, sich Gnome zu fügen.

----------

## ChrisJumper

Dies sind doch nur unterschiedliche Betrachtungsweisen. Generell würde es den Windowsmanagern-Toolsammlungen nicht schaden wenn man Programme auch einzeln verwenden kann und eben für diesen Zweck halte ich Kneipers Argumente durchaus für gerechtfertigt.

Ich kann aber eben auch die Entwickler verstehen die sich ihrer Desktop-Umgebung verschreiben. Man sollte es auch nicht als Vorwurf sehen sondern vielleicht als einen etwas distanzierten Blick. Ich benutze z.B. gerne Amarok oder K3B auch unter GNOME und es nervt schon wenn man dann viele Abhängigkeiten haben muss für vielleicht dieses eine Programm. Konsequenter wäre es wenn es sich bei dem emergen ganz nach Gentoo Art mit den Useflags sinnvoll spezifizieren lässt, was ja meistens auch der Fall ist. 

Aber ich denke die Projekte werden dort auch noch mehr aufeinander Zugehen und man kann dann einfacher auswählen welcher Indizier-Dienst die Daten zählt oder wo Adressbücher und Co gespeichert werden.

Mein Beispiel mit Evince unter Windows sollte einfach andeuten das es sehr gut wäre dort auch etwas "anzubieten" was ein bisschen unabhängiger agiert. Oder das man leichter Programme "portieren" kann oder noch besser diese von selber bemerken welchen Funktionsumfang sie (an)bieten können aufgrund der Lage und gegeben falls darauf Verweisen das sich Funktionen erweitern wenn man dies und jenes noch zusätzlich macht.

Aber da alles Open Source ist möchte ich mich auch nicht beschweren, man kann/könnte die Programme ja auch selber portieren.

----------

## mrsteven

Bitte sag mir jemand, dass das hier ein vorgezogener Aprilscherz ist: http://www.pro-linux.de/news/1/16872/kde-gemeinschaft-diskutiert-verzicht-auf-menueleisten.html

Schön, schachteln wir alle Menüs eine Ebene tiefer, damit kann man dann gleich doppelt so schnell arbeiten. Dank D-BUS ist das Ganze dann super netzwerktransparent und eine technisch saubere Trennung der Aufgaben (lassen wir das Menü doch einfach vom Fenstermanager zeichnen, auch wenn der ja eigentlich nur Fenster verwalten sollte) sorgt dafür, dass alles reibungslos funktioniert. Und wenn wir schon dabei sind, dann können wir eigentlich auch gleich die Schließen-Buttons aus dem Fensterrahmen entfernen. Shortcuts und Kontextmenüs sind auch nur verwirrend. Programme werden dann über Menü->Datei->Beenden beendet, das spart schließlich Platz und ist viel effizienter.

</ironie>

Dieses "Wir verstecken alles hinter einem einzelnen Knopf"-Paradigma ist zum kotzen (gilt nicht nur für diese Idee)!  :Rolling Eyes: 

Da weiß ich gar nicht was übler ist: Die Idee an sich oder der frickelige Implementierungsvorschlag?

----------

## Necoro

 *mrsteven wrote:*   

> Bitte sag mir jemand, dass das hier ein vorgezogener Aprilscherz ist: http://www.pro-linux.de/news/1/16872/kde-gemeinschaft-diskutiert-verzicht-auf-menueleisten.html

 

Werde ich gehauen, wenn ich sage, dass ich das gar nicht schlecht finde? Es gibt glaube ich fast keinerlei Programme wo ich die Menüleiste verwende. Und das Ende der Leiste bedeutet ja nicht das Ende der Shortcuts -- sondern es geht schlicht darum, diese durchaus sinnlose Textzeile auszublenden.

Deine weiteren Ironieausführungen sind doch pure an den Haaren herbeigezogene Übertreibungen. Ich finde sie an dieser Stelle irgendwie sinnfrei...

----------

## cryptosteve

Ich fände es auch ok, solange es weiterhin einen gut erkennbaren Einstieg in die Inhalte der Menüleiste gibt. Ob das nun ein Button in der Titel-, oder Fussleiste ist, ist mir wurscht.

----------

## franzf

Ich hab schon das gnome-globalmenu nicht zum Laufen gebracht, dann wird das mit gtk-Anwendungen mit Menu-Button in der KWin-Deko auch nicht funktionieren. Mozilla-Produkte und [open,libre]office gehen wahrscheinlich sowieso nicht. Von dem her: schöne Lösung, wenn man nur auf kde-Programme setzt, für alle Mischumgebungen holt man sich eine weitere Inkonsistenz mit an Bord.

Da der Vorschlag von kde und nicht von gnome kommt, nehme ich an dass andere DEs/Toolkits da nicht mitmachen. Anders herum wäre sicher schon alle am integrieren  :Very Happy: 

Wie schnell sich z.B. dbus an allen Fronten festgewurzelt hat, war wirklich erstaunlich.

Bei mir legen im Moment alle Qt-Programme ihr Menu ala Mac in die "XBar", die Fenster haben also kein Menu. Da ich sehr selten die Menus brauch, wäre ich froh, wenn der Bereich auf meinem kleinen Monitor nicht belegt wäre. Die Deko-Titelleiste ist sowieso fast komplett nackt, die kann man wirklich sinnvoller nutzen.

----------

## sirro

 *Necoro wrote:*   

> Werde ich gehauen, wenn ich sage, dass ich das gar nicht schlecht finde?

 

Ne, ich stehe dem offen gegenüber. Fand das beim ersten benutzen zwar auch eher nervig, aber wenn man sich vor Augen hält wie selten man diese Leiste bei den meisten Programmen eigentlich benutzt...

Zumal im Artikel ja steht, dass der alte Modus verfügbar bleibt. Wenn das dann noch pro Programm ginge, fände ich es auf jeden Fall eine Verbesserung

----------

## Knieper

 *mrsteven wrote:*   

> Bitte sag mir jemand, dass das hier ein vorgezogener Aprilscherz ist: http://www.pro-linux.de/news/1/16872/kde-gemeinschaft-diskutiert-verzicht-auf-menueleisten.html

 

... wird bei mir allerdings scheitern, weil ich gar keine Fensterleisten anzeigen lasse. Die bekannten DEs kopieren doch eh alle untereinander und sind wenig innovativ. Diesmal eben ein wenig Mac mit "moderner" Browseroberfläche.

Der Trend hängt vermutlich mit dem Aufkommen der Widescreen-Monitore (besonders bei tragbaren Kleinrechnern) zusammen. Kein Platz mehr in der Höhe, um ein Dokument vollständig anzuzeigen, dafür aber zwei halbe nebeneinander.  :Wink:  Immer mehr Programme implementieren Seitenleisten für den "Schnellzugriff", die dann allen möglichen Kram unsortiert enthalten und die Normalformatnutzer nerven. Daher mein Reden -> Anpassbarkeit. Ob man eine 75% leere Menüzeile haben will oder eine komische Seitenleiste, sollte doch der Nutzer entscheiden dürfen.

----------

## schmidicom

 *Knieper wrote:*   

> OT: Ich glaube ich werde langsam zu alt für diesen Linux-Desktop-Scheiß. gtk-Programme, die Assertions werfen (wieso werden die mitkompiliert?), weil Icons (wo sollen die auch angezeigt werden?) oder Themes fehlen. Kiloweise beknackte Dämonen (console-/policy-/dbus-/hal-/Session-Schlagmichtot), die man ja unbedingt braucht, wenn man ein simples Problem lösen will und die Software wird allgemein immer unbenutzbarer. Mein neuestes Hassobjekt sind Browser: Opera ist dermaßen verbugt, dass er zZt. unbenutzbar ist, Firefox ist lahm wie sau, instabil und wenn überhaupt nur mit x Plugins halbwegs nutzerfreundlich, andere brauchen Qt oder die genannten Schrottdämonen (Chromium) oder lassen grundlegende Mechanismen vermissen (midori).
> 
> Andere Systeme sind nicht viel besser, aber den Freedesktop/KDE/Mozilla-Typen müsste mal jemand mit dem Gummihammer auf die Rübe hauen und ihnen danach einen Kurs "Softwareentwicklung für Unbegabte" schenken.

 

Beispiel: gnome-system-tools

Dieses eine kleine Paket hat einen eigenen Dienst im Hintergrund am laufen kommuniziert mit dbus und hat Abhängikeiten wo ich mich immer wieder Frage "Was zum Teufel soll der Mist eigentlich?". Dabei will man meistens nur eine einfache Sache erledigen wie einen Benutzer hinzufügen, entfernen oder ändern. Wobei man sich bei diesem .... Tool noch glücklich schätzen kann wenn es überhaupt funktioniert.

----------

## mrsteven

 *Necoro wrote:*   

> Deine weiteren Ironieausführungen sind doch pure an den Haaren herbeigezogene Übertreibungen.

 

Zugegeben, der zweite Teil, in dem ich mit den Schließen-Buttons anfange, schon. Ich wollte damit nur demonstrieren, dass es sinnvoll ist, wenn man Dinge, die man oft braucht (wie z.B. der Schließen-Knopf) oder die sonst irgendwie elementar zur Bedienung notwendig sind, auch schnell erreichen kann. Gut, man kann natürlich darüber streiten, ob eine Menüleiste so wichtig ist. Das hängt sicher auch vom jeweiligen Programm ab. Dennoch finde ich es unsinnig, für ein paar Pixel mehr das Menü irgendwo hinter einem Button in der Titelleiste zu vergraben. Wohlgemerkt, ich schreibe das hier auf einem Laptop mit einer vertikalen Auflösung von gerade einmal 800 Pixeln. Scrollen mit dem Touchpad oder einem Mausrad geht schnell, solange sich der Cursor irgendwo (!) im Fenster befindet, außerdem muss man das meistens sowieso, da bringen einem die paar Pixelzeilen mehr auch nichts.

Noch was zum Thema "Schnelle Erreichbarkeit von Funktionen": Ich habe hier eine kleine Seitenleiste am linken Bildschirmrand. Da sind alle Programme drin, die ich oft benutze. Wenn ich etwas starte, sehe ich das Icon sofort und kann das Programm mit genau einem einzigen Mausklick starten, anstatt mich durch irgendwelche Menüs zu hangeln. Das ist super praktisch und den Platz dafür gebe ich gerne her.

Was meine Bedenken zur technischen Umsetzung anbelangt, so bleibe ich dabei: Das ist alles andere als sauber, denn der Fenstermanager übernimmt dabei Aufgaben, die eigentlich nicht zu seinem Gebiet gehören. Die Modularisierung geht also flöten. Und D-BUS ist nunmal nicht netzwerktransparent, es gibt also Probleme, wenn man X-Forwarding betreibt.

Das einzige (und zugegebenermaßen wesentliche), was ich übersehen habe, ist, dass man zwischen dem neuen und meiner Meinung nach schlechteren Weg und der traditionellen Lösung wählen kann. Dann bin ich wenigstens wieder einigermaßen beruhigt.

----------

## Necoro

 *mrsteven wrote:*   

> Was meine Bedenken zur technischen Umsetzung anbelangt, so bleibe ich dabei: Das ist alles andere als sauber, denn der Fenstermanager übernimmt dabei Aufgaben, die eigentlich nicht zu seinem Gebiet gehören. Die Modularisierung geht also flöten. Und D-BUS ist nunmal nicht netzwerktransparent, es gibt also Probleme, wenn man X-Forwarding betreibt.

 

Mhm? War ich blind? Ich konnte in dem Link von dir nix zum Thema Implementierung finden... Daher hab ich deine Sätze zu DBus & Co auch als "an den Haaren herbei gezogen" kritisiert. Hättest du, sollte das aus einer anderen Quelle stammt, nochmal den Link? Weil Menüleiste entfernen und durch einen Button ersetzen geschieht doch wenn dann überhaupt auf Ebene des Grafiktoolkits (also hier: Qt), insofern versteh ich nicht, was DBus (das ich btw immer noch für eine richtig brauchbare und sinnvolle Software halte) und der Windowmanager damit zu tun haben.

----------

## Knieper

 *Necoro wrote:*   

> Mhm? War ich blind? Ich konnte in dem Link von dir nix zum Thema Implementierung finden...

 

Im Artikel:

 *Quote:*   

> Statt dessen regt er an, ähnlich wie die aktuellen Browserversionen, ein in der Titelleiste eingebundenes Menü zu nutzen.

 

Und wer ist für die "Titelleiste" verantwortlich? Der WM... Seine Bedenken sind verständlich.

----------

## slick

 *mrsteven wrote:*   

> Bitte sag mir jemand, dass das hier ein vorgezogener Aprilscherz ist: http://www.pro-linux.de/news/1/16872/kde-gemeinschaft-diskutiert-verzicht-auf-menueleisten.html

 

Die haben doch den Schuss nicht gehört.

 *Quote:*   

> Laut Penz wird die Leiste allerdings weniger zum Navigieren benutzt, sondern eher, um Tastenkombinationen zu erlernen oder Funktionen der Anwendung zu überblicken. Bei der täglichen Arbeit findet nur selten ein wirklicher Einsatz der Leiste statt. 

 

Das mag vielleicht für einige Devs gelten, aber nicht für den Durchschnitt (Lasse mich gern durch Studien, aber nicht durch einzelne vom Gegenteil überzeugen) Ich habe erst diese Woche mal eines der aktuelle M$ Office in the Wild gesehen mit so einem Knopf. Das verwirrt ja erstmal total. Bin ich garnicht mit klar gekommen. 

Ok, das ist vielleicht noch Gewohntheit, aber ich denke man wird dadurch deutlich langsamer (wenn man mit der Maus arbeitet). Vorher war es so, man wollte in den Einstellungen was ändern .. also Maus zur Menüleiste -> Einstellungen ... fertig. Man wußte auch wo die war, denn hatte die immer im Blick. Mit der Button-Lösung verschwindet die jedesmal wieder und man muss sie erst neu nach dem aufklappen der "Menü-Leiste" finden. 

Für mich könnte man den typischen Menüpunkt "Bearbeiten" -> Kopieren/Einfügen weglassen, da ich Strg-c/v beherrsche. Das ist aber wieder subjektives Empfinden, so wie vermutlich bei jedem der das einfach gutheißt.

Bei meiner Mutter ists schon ein Wunder wenn sie den Menüpunkt Kopieren/Einfügen findet und nicht Dokument 1 ausdruckt um einen Satz in Dokument 2 abzutippen. Wie soll man solchen Leuten einen großen Knopf schmackhaft machen hinter dem sich alles verbirgt? Letzlich versteckt man die Funktionen noch mehr.

Dazu kommt, jedes Programm kocht dann vermutlich noch mehr sein eigenes Süppchen, im Moment ists ja noch halbwegs gleich bei allen.

(Ob jetzt der WM oder der Lila-Laune-Bär die Meüleiste zeichnet bzw. bereitstellt, ist mir als Anwender dabei völlig schnuppe.)

Erst dieses nachimmitierte beschi.. Windows-Startmenü im KDE und jetzt sowas? Da krieg ich Plack...

----------

## Knieper

 *slick wrote:*   

>  *Quote:*   Bei der täglichen Arbeit findet nur selten ein wirklicher Einsatz der Leiste statt.  
> 
> Das mag vielleicht für einige Devs gelten, aber nicht für den Durchschnitt (Lasse mich gern durch Studien, aber nicht durch einzelne vom Gegenteil überzeugen)

 

Vor allem: wie viele Programme nutzt man häufig (Editor, Window Manager...) und merkt sich die Tastenkürzel und welche nutzt man eher selten? In Gimp würde ich per Tastenkürzel gerade mal ein Bild öffnen können und bin auf die Menüs angewiesen.

 *Quote:*   

> Für mich könnte man den typischen Menüpunkt "Bearbeiten" -> Kopieren/Einfügen weglassen, da ich Strg-c/v beherrsche.

 

Ich bin beim Apple-Stil noch gar nicht angekommen und verwende wie früher Strg+Einfg/Shift+Einfg, meistens allerdings die Maus - eines der wenigen Szenarien (freies Selektieren von Text, Browser mit Mausgesten), wo ich mit der Maus schneller bin.

 *Quote:*   

> (Ob jetzt der WM oder der Lila-Laune-Bär die Meüleiste zeichnet bzw. bereitstellt, ist mir als Anwender dabei völlig schnuppe.)

 

Dann stört es Dich bestimmt nicht, wenn KDE-, GNOME-, Enlightenment-, ...-Programme verschiedene Titelleisten anzeigen?

 *Quote:*   

> nachimmitierte

 

Nachgemacht oder imitiert.

Edit: Mit fällt gerade ein, dass es kurzzeitig mal den Trend gab, Menüleisten per Maushover aus- und einzuklappen. Das wurde verworfen und wäre trotzdem eine bessere Alternative zum Einknopfmenü.

----------

## manuels

Mal aus Usability-Sicht gesehen:

Pro: die Menüeinträge sind vertikal und nicht horizontal, wodurch sie sich vom Nutzer schneller "scannen" lassen.

Kontra: Es gibt eine Menüebene mehr, was für den Nutzer ziemlich nervig ist.

----------

## mrsteven

 *Necoro wrote:*   

> 
> 
> Mhm? War ich blind? Ich konnte in dem Link von dir nix zum Thema Implementierung finden...

 

Der Artikel verlinkt auf einen Blogeintrag eines KDE-Entwicklers, in dem dieser gleich zu Beginn die Umsetzung mit D-BUS erwähnt:  *Quote:*   

> Peter Penz blogged about removing the Menu from Dolphin. While this is very interesting and nice looking I have a better idea: why not move the menu into the decoration? All what we need is already there. We have the awesome DBus Menu which allows us to send the menu to any other application (in most cases Plasma). So we could use this technology to direct the menu from the window into its decoration.

 

 *Necoro wrote:*   

> Weil Menüleiste entfernen und durch einen Button ersetzen geschieht doch wenn dann überhaupt auf Ebene des Grafiktoolkits (also hier: Qt)...

 

Ja, so ist das normalerweise, aber wie erhält die Anwendung Zugriff auf den Zeichenbereich ihrer Titelleiste? Bei diesem Vorschlag schickt das Programm sein Menü über D-BUS an den Fenstermanager. Und ich habe keine Lust bei Programmen, die auf einem anderen als dem lokalen Rechner laufen, auf die Menüleiste zu verzichten. Ein ähnliches Problem ergibt sich, wenn ein KDE-Programm nicht unter KWin, sondern einem anderen Windowmanager laufen soll.

Aber gut, wenn es die alte Darstellung immer noch gibt, wird man diese hoffentlich als Fallback einsetzen.

----------

## Knieper

 *manuels wrote:*   

> Mal aus Usability-Sicht gesehen:
> 
> Pro: die Menüeinträge sind vertikal und nicht horizontal, wodurch sie sich vom Nutzer schneller "scannen" lassen.
> 
> Kontra: Es gibt eine Menüebene mehr, was für den Nutzer ziemlich nervig ist.

 

Bezog sich das auf die Ausklappleiste? IA. stimmt das zwar, aber Menüs der ersten Stufe enthalten oft wenige Einträge, dh. links erwartet man File, Edit, View, rechts immer Help und irgendwo dazwischen etwas, was man gerade sucht. Man kann mit der Maus schon den groben Bereich anpeilen und liest nur einen Ausschnitt der Zeile. Beim Knopf musst Du immer dort hin, draufklicken und dann den Menüpunkt anpeilen.

----------

## Yamakuzure

Also das einzige Programm, dass mir spontan einfällt, bei dem ich die Menüleiste nicht brauche, ist ... äh ... mir fällt keines ein. Irgendwelche Optionen/Werkzeuge/Was-auch-immer gibts überall. Allerdings brauche ich das nicht im Minutentakt, also wäre mir im Zweifelsfall eine Ein-Knopf-Lösung sogar ganz recht. Sicherlich gewöhnungsbedüftig am Anfang, aber im Endeffekt würde die zusätzliche "Menüebene" nicht wirklich stören, glaube ich.

@Knieper: Danke für deine Ausführungen. Mein Fehler war einfach nicht zu verdeutlichen, was ich mit 30-50 Fenstern meine. Da sind eine Menge Fenster dabei, die ganz unterschiedliche Größenanforderungen haben (Eclipse auf zwei Monitoren aht gleich vier) und vor allem nach Projekten gruppierte Fenster die sich überlappen dürfen, sollen oder gar müssen. Eine Tiling-WM wäre da extrem unübersichtlich, da die unterschiedlichen Anordnungen in kein Schema reinpassen.

Ich habe fluxbox ausprobiert, aber die fenster müssen häufig unterschiedliche Größen haben.

Ich habe awesome ausprobiert, aber kein Schema (oder heißt das da "Stil"?) passt auch nur im entferntesten.

Letztendlich öffne ich nicht alle Fenster gleichzeitig, und das Positionieren nimmt pro Fenster höchstens 1-2 Sekunden in anspruch, da ich ja weiß, wo ich es hin haben möchte.

Somit bin ich bei OpenBox gelandet, das ist schön blank, aufgeräumt und bietet viel Platz.  :Wink: 

Btw zum Thema Abhängigkeiten:

Ich habe mir eine Mini-VM eingerichtet, da ich mal schauen wollte wie viel Platz ein Minimalsystem (ohne "Desktop-Profil") und einem kleinem WM (witzigerweise habe ich mich für "awesome" entschieden) verbraucht. Nach dem Neustart des Basissystems gab ich ein: "emerge --ask xorg-server slim awesome" und derzeit kompiliert die VM die drei Pakete plus der 140 Abhängigkeiten. (naja, das Meiste davon ist der ganze aufgesplittete Xorg Kram... natürlich)

Hmmm.. Es ist schon eine Weile her, das ich awesome ausprobiert habe, mal schauen was es Neues gibt.

Oh! Schon fertig! Also. Minimales amd64-System mit awesome als WM, slim als Login Manager, noch keinerlei extra Programme installiert (außer eix, gentoolkit und ufed):

```
~ # df -h | egrep "(Size|sd)"

Filesystem             Size  Used Avail Use% Mounted on

/dev/sda2              7.9G  232M  7.3G   4% /

/dev/sda1               49M   12M   34M  27% /boot

/dev/sdb1              7.9G  2.6G  5.0G  34% /usr

/dev/sdc1              7.9G  147M  7.4G   2% /home
```

Hmmm? Oh! Ich habe vergessen DISTDIR zu setzen. Da ist /usr nun voller als es sein sollte. Und ich habe immer FEATURES="splitdebug" gesetzt, das kostet auch Platz. Aber ansonsten kommt man mit rund 3GB also wohl hin. Auch wenn man damit noch rein gar nichts anfangen kann...

----------

## Necoro

 *mrsteven wrote:*   

>  *Necoro wrote:*   Weil Menüleiste entfernen und durch einen Button ersetzen geschieht doch wenn dann überhaupt auf Ebene des Grafiktoolkits (also hier: Qt)... 
> 
> Ja, so ist das normalerweise, aber wie erhält die Anwendung Zugriff auf den Zeichenbereich ihrer Titelleiste? Bei diesem Vorschlag schickt das Programm sein Menü über D-BUS an den Fenstermanager. Und ich habe keine Lust bei Programmen, die auf einem anderen als dem lokalen Rechner laufen, auf die Menüleiste zu verzichten. Ein ähnliches Problem ergibt sich, wenn ein KDE-Programm nicht unter KWin, sondern einem anderen Windowmanager laufen soll.
> 
> Aber gut, wenn es die alte Darstellung immer noch gibt, wird man diese hoffentlich als Fallback einsetzen.

 

Oh Gott   :Shocked:  Denn tut es mir Leid, dass ich da oben ausfallend geworden bin ... du hast ja so Recht: Die haben eine Meise... ich finde, so etwas hat in der Fensterleiste gleich gar nix zu suchen... Vor allem verschwimmt so die Trennung zwischen WM-Optionen und Programm-Optionen: In einem Bildprogramm zB: Macht die "Maximieren" Option jetzt das Bild oder das Fenster größer ... (Und sowas an DBus zu binden ist auch besch..eiden. DBus an sich ist zwar eine nette Idee und funktioniert bei mir auch tadellos -- aber das quasi als eine wichtige Systemkomponente zu haben, finde ich denn doch eher unschön)

Zum Thema Usability: Wo ich einen großen Vorteil der 1-Knopf-Lösung sehe, ist, dass man häufig gebrauchte Menüpunkte auch gleich im ersten Level unterbringen kann: Damit entfällt zB das lästige Suchen nach dem von mir am häufigsten benötigten Punkt: "Einstellungen". Denn dieser residiert je nach Programm (und beim Firefox zB auch noch unterschiedlich nach Betriebssystem) mal in Datei, mal in Bearbeiten, mal in Extras, mal in Hilfe und mal ganz wo anders. Und das ist immer extrem  nervig erst alle Menüs durchschauen zu müssen um ihn zu finden.

----------

## ChrisJumper

 *Yamakuzure wrote:*   

> Also das einzige Programm, dass mir spontan einfällt, bei dem ich die Menüleiste nicht brauche, ist ... äh ... mir fällt keines ein. Irgendwelche Optionen/Werkzeuge/Was-auch-immer gibts überall.

 

Hmm wenn man das mal mit dem Handy vergleicht, oder den Menues moderner Fernseher. So gibt es in der tat immer sehr wenige angezeigte Möglichkeiten aber auch die Option unter einem versteckteren Punkt um Wichtige Einstellungen vorzunehmen oder auch "alles" anzupassen. Am produktivsten kann der Nutzer (ich behaupte das einfach mal) dort arbeiten wo er sich alles selber zusammen stellen kann. Oder die Shortcuts definieren.

Gleichzeitig sollte man auch nicht mit Möglichkeiten erschlagen werden, wie das bei den ersten Office-Programmen der Fall war. Hier gab es ja mal einen Trend, fast alles auf eine Oberfläche zu drücken, gerade Neulinge hat dies doch eher abgeschreckt dieses Programm zu verwenden und sich vielleicht nach einer alternative umzusehen.

Daher denke ich das man Software so anpassbar und Simpel gestalten sollte wie irgendwie möglich. Aber sofern der Nutzer mehr Operationen,  Verantwortung oder Einstellungen wünscht, sollte das Programm mit wachsen. Zwar ist das schon bei vielen Programmen möglich, aber mir immer noch zu schlicht.

Das permanent ein Menü-Leiste angezeigt werden muss, ist definitiv überflüssig, unter der Voraussetzung der Nutzer weiß wo die Menütaste ist.

(Diese Mouse-Over-Menüs, finde ich Schrecklich. Allerdings kenne ich nur verschiedene Web-Applikationen und wenn dort der PC zu langsam ist, oder die Maus nur einen Millimeter über den Rand hinausgeht, schließt sich das ganze Menü. Vielleicht war das jetzt anders gemeint. aber ich bin sicher die Fehler sind die selben. Dann lieber Menü-Tasten und die Pfeiltasten (←↑→↓) . Wobei das bei großen Einträgen auch störte da alle durchgegangen werden müssen. Mein Gnome-Menue arbeitet auch mit Mouse-Over beim öffnen der Unterkategorien... ich erinnere mich noch böse daran wie man alles einzeln anklicken mussete. Da ist Mouse over schon besser. zum einmaligen öffnen allerdings nicht. Genauso stört mich das automatische abspielen von Soundfiles die ich auf dem Desktop gelagert habe wenn ich mit der Maus darüber fahre.

----------

## forrestfunk81

Als damals der Chrome rauskam und keine Menüleiste mehr hatte war ich ziemlich verärgert. Aber da sich die Breitbild Monitore mittlerweile durchgesetzt haben und auch ich nur noch solche hab, bin ich doch erfreut, dass man in der Vertikalen mehr Platz hat (vorallem auf meinem 13" Notebook). Beim neuen Firefox bin ich damit sehr zufrieden, da brauch ich sowieso nur die URL-Box. In die Einstellungen will ich nach einmaligem Einrichten eh nur noch selten. Ich find das auch nicht schlecht, wie es beim Internet-Explorer geregelt ist, die haben da ja nen Button, wo man direkt ans Settings Menü rankommt.

Es wär natürlich schon nett, wenn man das Menü je nach Vorliebe und Programm ein- bzw. ausblenden kann.

----------

## Josef.95

Wenn es um mehr Platz im Browser geht..

Ich finde zb die Vollbild Funktion im Firefox teils recht gut brauchbar (F11 Taste)

Diese gibt es übrigens schon ewig   :Smile: 

BTW

Ähnliches wird auch in anderen Browsern unterstützt. (zb konqueror)

----------

## forrestfunk81

Ich mag den Fenstermodus lieber, hab gern den Überblick über geöffnete Tabs, geöffnete Programme (Taskleiste links im Bild) und außerdem fühlt sich Alt-Tab bei Vollbild Anwendungen mit Compositing nicht so toll an. Aber von mir aus kann der beim täglichen Gebrauch nicht genutzte Mist versteckt werden (solange man ne einfache Möglichkeit hat da wieder ranzukommen). Als einziges Programm, wo ich die Menüleiste dauernd brauch fällt mir Gimp ein. Und das liegt daran, dass ich den zu selten benutz, als dass ich mir die Shortcuts merken könnte. Ansonsten kommts für mich auf den Inhalt an, nicht auf das Programm. Witzig find ich dazu auch diesen Vergleich  :Wink: 

BTW: Wenns nur um die Menüleiste geht, find ich die Alt Taste recht gut brauchbar, dann erscheint auch das versteckte Menü  :Razz: 

----------

## franzf

Warum hier alle mit Gimp kommen versteh ich nicht. Ich verwende das Top-Menü NIE! Und genauso kenn ich die Shortcuts nicht.

Gimp hat über Rechtsklick ins Hauptfenster exakt das selbe Menü wie das Top-Menü, hier würde ich mich über ein Entfernen sehr freuen  :Smile: 

----------

## forrestfunk81

Also ich fühl mich bei Gimp jedesmal vom Funktionsumfang erschlagen und hielt mich bisher in diesem Fall an alt-bewährtes - nächstes mal Context-Menu  :Wink: 

----------

## Yamakuzure

Also mit dem Thema "Menu" könnte man wohl wirklich Ewigkeiten verbringen.  :Smile:  *Necoro wrote:*   

> Damit entfällt zB das lästige Suchen nach dem von mir am häufigsten benötigten Punkt: "Einstellungen". Denn dieser residiert je nach Programm (und beim Firefox zB auch noch unterschiedlich nach Betriebssystem) mal in Datei, mal in Bearbeiten, mal in Extras, mal in Hilfe und mal ganz wo anders. Und das ist immer extrem nervig erst alle Menüs durchschauen zu müssen um ihn zu finden.

 Jetzt wo du es sagst, das wäre wohl einer der wesentlichen Vorteile eines (konfigurierbaren) 1-Knopf-Menüs. Einfach ab in die erste Ebene und nie wieder suchen.

----------

## franzf

Ich weiß nicht, ob das im ersten Blogeintrag nur untergegange ist, oder ob hier was neues steht:

http://blog.zx2c4.com/548

Eine "dbus-API" für Tabs in der Window-Deko soll geschaffen werden, damit dolphin, Firefox, ... ihre Tabs nicht mehr im Fenster aufmachen, sondern die Tabs dann in der Deko liegen.

Keine Ahnung was ich davon halten soll, würde es aber wohl sofort ausschalten (wenns geht). Ich habe für Sewiten, die ich regelmäßig ansteuere, ein Firefox-Fenster offen, mit vielen Tabs. Für Doku zum Programmieren ist ein anderes FF-Fenster mit vielen Tabs offen. Wenn die ganzen Tabs jetzt in der Deko liegen würden - meine Güte - dann auch noch das Menü-Knöpfchen und die Window-Buttons - das wird eng.

Aber ich bin mir sicher, dass es Menschen gibt, denen das taugt.

----------

## mrsteven

Sowas gehört (wenn überhaupt) in das direkte Protokoll zwischen Applikation und Fenstermanager. D-BUS hat da nichts verloren, da es eben nicht netzwerktransparent ist. Abgesehen davon ist es einfach unschön, die Kommunikation über zwei verschiedene Protokolle (D-BUS und NetWM) gleichzeitig ablaufen zu lassen. Inwieweit NetWM erweiterbar ist habe ich jedoch noch nicht recherchiert.

----------

