Fenstermanager und Desktopumgebungen, eure Vorlieben?

Fenstermanager und Desktopumgebungen, eure Vorlieben?

  • Unity

    Votes: 0 0.0%
  • XFCE

    Votes: 5 29.4%
  • GNOME

    Votes: 7 41.2%
  • KDE

    Votes: 3 17.6%
  • LXDE

    Votes: 1 5.9%
  • Enlightenment

    Votes: 1 5.9%
  • ROX

    Votes: 0 0.0%
  • Fluxbox

    Votes: 0 0.0%
  • Ratpoison

    Votes: 0 0.0%
  • IceWM

    Votes: 0 0.0%

  • Total voters
    17
  • Poll closed .

Also wer sich für dwm interessiert, aber nicht unbedingt seine configs in c schreiben möchte
kann sich auch mal i3 - improved tiling wm anschauen.
Möchte damit nicht sagen das er besser oder schlechter als dwm ist, aber man muss nicht zwangsläufig c können ^^
Wobei es natürlich auch ein anreitz ist c zu lernen ^^

werde mir dwm wohl doch mal anschauen und sei es nur um meine c kenntnisse zu erweitern ^^

9.
The usual elitism amongst minimal window managers: Don’t be bloated, don’t be fancy (simple borders are the most decoration we want to have).
However, we do not enforce unnecessary limits such as a maximum amount of source lines of code. If it needs to be a bit bigger, it will be.
 
Die Konfiguration von dwm ist unproblematischer als man als Nicht-C-Programmierer vielleicht annimmt. Die Datei ist gut kommentiert und die Variablen haben eindeutige Namen. Ich finde es nicht schwerer, als ein Configfile zu editieren. Man muss natürlich jedes Mal dwm neu kompilieren, aber bei knapp unter 2.200 Zeilen Code dauert das nicht wirklich lange ;)
 
jhw said:
Die Konfiguration von dwm ist unproblematischer als man als Nicht-C-Programmierer vielleicht annimmt. Die Datei ist gut kommentiert und die Variablen haben eindeutige Namen. Ich finde es nicht schwerer, als ein Configfile zu editieren. Man muss natürlich jedes Mal dwm neu kompilieren, aber bei knapp unter 2.200 Zeilen Code dauert das nicht wirklich lange ;)
Wie gesagt ansehen werde ich es mir defintv, klingt zumindest interessant, ob ich wechsel weiß ich allerdings nicht bin mit i3 ziemlich glücklich.
Das compilieren sollte ziemlich fix gehen ist ja nicht gerade viel
Wobei stand da nicht irgendwo das sie nur max 2k lines als source haben wollen? - bin der meinung das irgendwo gelesen zu haben.
 
taake said:
Wobei stand da nicht irgendwo das sie nur max 2k lines als source haben wollen? - bin der meinung das irgendwo gelesen zu haben.
Ja, das steht auf deren Seite. Genau dran halten tun sie sich offensichtlich nicht:
Code:
<i>
</i>$ wc -l dwm.c
2146 dwm.c
Wobei, wenn man das Ganze etwas bereinigt, schaut's auch schon wieder anders aus ;)
Code:
<i>
</i>$ egrep -v "}" dwm.c | wc -l
1918
 
LOC ist eh eine schwachsinnige Einheit:
int main() {printf("Hello World\n");return 0}
ist ein mit gcc valider Code für ein Hello World in nur einer Zeile!!!!1111elf.

Zumal man geringe LOC oft auch durch mangelhafte Dokumentation erreicht - und das sollte auch nicht das Ziel sein.
 
Von wegen valide!!!!111elf
Code:
<i>
</i>$ echo 'int main() {printf("Hello World\n");return 0}' > ziz.c && gcc -Wall ziz.c
ziz.c: In function 'main':
ziz.c:1:1: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
ziz.c:1:13: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default]
ziz.c:1:45: error: expected ';' before '}' token
;)

Die Frage ist halt, wie man LOC definiert. Wenn ich Kommentare direkt raus rechne, ist es ja durchaus legitim. Da einem C aber von Grund auf sehr viele Freiheiten lässt, was die Gestaltung des Codes angeht (was ich im Übrigen sehr schön finde), kann man, wenn man's nicht bereinigt, sehr schnell auf sehr wenige bzw. sehr viele LOC kommen.
 
Back
Top