Όχι, όχι όχι. O Window manager είναι ο compositor. Δες εδώ για τις διαφορές και τους τύπους. Δες εδώ την κατάταξη τους. Στην πρώτη σχεδίαση του πρωτοκόλλου Χ ο Window Manager ήταν ένα ανεξάρτητο πρόγραμμα που απλά τακτοποιούσε τα παράθυρα και πρόσθετε τα πλαίσια γύρω τους. Αργότερα είχαμε τους composite window managers που διαχειρίζονταν όλο το παράθυρο μαζί σαν εικόνα. Στο Wayland δεν έχουμε χωριστό Window Manager.
Από το πρώτο λινκ (που είναι το ίδιο με δεύτερο) που δίνεις
Compositing support can be added to non-compositing window managers, through the use of compositors such as compton .
που επιστρέφει σε αυτό που έγραψα.
ο Window Manager ήταν ένα ανεξάρτητο πρόγραμμα που απλά τακτοποιούσε τα παράθυρα και πρόσθετε τα πλαίσια γύρω τους
Ακόμα είναι.
είχαμε τους composite window managers που διαχειρίζονταν όλο το παράθυρο μαζί σαν εικόνα
Ισχύει. Ωστόσο το πρωτόκολλο επιτρέπει να τα έχεις ξεχωριστά. Και μάλιστα ακόμα οι compositing wm σε Xorg μπορούν να χρησιμοποιηθούν είτε σαν standalone wm είτε σαν standalone compositor. (Καθώς το compositing κομμάτι περνάει από τον Xorg.) Π.χ. μπορείς να έχεις fvwm (wm) + Compiz (compositor).
Στο Wayland δεν έχουμε χωριστό Window Manager.
Στο Wayland έχεις συνδυασμό αυτού που κάνει compositor και αυτού που κάνει ο window manager (στο Xorg) στο ίδιο πρόγραμμα. Οι devs του Wayland αποφάσισαν να το ονομάσουν όλο μαζί ως “compositor.” Αλλά αυτό στην ορολογία που χρησιμοποιείται στο Wayland.
Για να μην ξεχάσουμε και όσα ξέρουμε, υπάρχει ένας απλός τρόπος να με πείσεις. Στήσε σε μια εικονική μηχανή ένα οποιοδήποτε Linux. Επέλεξε ένα οποιοδήποτε Window Manager χωρίς compositor της επιλογής σου. Βάλε compiz ή οποιονδήποτε άλλο compositor της επιλογής σου. Ο συνδυασμός fvwm (wm) + Compiz είναι ένα καλό παράδειγμα, αλλά δεν θέλω να σε περιορίσω.
ΥΓ1: Διορθώθηκε το λανθασμένο Link
Σε πιο απλό παράδειγμα, χρησιμοποιώ i3 (non-compositing wm) και picom (standalone compositor) για πάνω από μισή δεκαετία.
2 «Μου αρέσει»
Wow Έξυπνο hack !!!
Έριξα μια πολύ γρήγορη ματιά στον κώδικα. Αυτό που κάνει, αν κατάλαβα καλά (δες την συνάρτηση session_init και ειδικά τις γραμμές 7152-7182) είναι να καμουφλαριστεί σαν XServer και να κάνει τον Proxy. Ο πραγματικός XServer όμως βλέπει ένα Window Manager, όχι δυο. Θαυμαστό το ότι λειτουργεί.
hack
Θα έλεγα πως αποτελεί άμεση απόρροια του να έχεις ένα (window manager) client που μιλάει σε ένα (display) server. Σαν ιδέα δεν είναι περίεργο να μπορείς να βάλεις κάτι ενδιάμεσα στα δύο. Βέβαια πράγματι ίσως αυτός ο τρόπος απόκτησης compositing περιβάλλοντος να μην ήταν κάτι που περίμεναν οι Xorg devs όταν εισήγαγαν το composite extension.
Η πλάκα είναι πως μόλις πριν 2 μέρες διάβαζα αυτό:
ακριβώς το ίδιο πράγμα σε τόσες άλλες περιπτώσεις, απλά δεν είχα σκεφτεί την πιθανότητα να είναι ο Display Manager. Και υπάρχει και το Xephyr που χρησιμοποιώ λολ.
Το γνωστό ανέκδοτο για την διαφορά θεωρίας και πράξης 
. Διαβάσαμε λίγο ωραίο κώδικα σήμερα και σε ευχαριστώ.
Και μετά τη μικρή παράκαμψη πίσω στο κυρίως θέμα.
But what about real theming? At this point libadwaita only allows users to change between light and dark modes.
Πρόσφατα είδα πως στα σχέδια, πιθανώς και ήδη να προστέθηκε, είναι ένα “recoloring” API που θα επιτρέπει εκτενή αλλαγή των χρωμάτων σε όλες τις εφαρμογές που χρησιμοποιούν το libadwaita. Αντί για αλλαγή απλών χρωμάτων όπως π.χ. accent, line highlight, κτλ τώρα θα γίνεται μέχρι και επιλογή χρωμάτων για syntax highlight σε text editor. Αρκετά πέρα από μόνο εναλλαγή μεταξύ light/dark mode.
Ο συγκεκριμένος μάλλον τα έχει γενικά με το Gnome 
Σε ένα άλλο κείμενο του:
A similar dubious decision was made on how Files sorts files: it seems to rely on LC_COLLATE system variable, which means that depending on the distro the user may find, for instance, Virtualbox listed before firefox. One may wonder whether it is just a stupid default, but actually there is no official way to change that.
Μισό: Τι είναι αυτό το LC_COLLATE. Η ρύθμιση για το πως με βάση τις τοπικές παραδόσεις γίνετε η αλφαβητική ταξινόμηση. Ο Πολωνός μπορεί να θέλει πρώτο το firefox και μετά το Virtualbox, και ο Γερμανός το αντίθετο. Γιατί να κακοκαρδίσεις κάποιον από τους δυο; Σε αυτό το κομμάτι λοιπόν, μήπως το κάνουν λάθος οι υπόλοιποι; Όσο για το αν αλλάζει; Όσο εύκολα αλλάζει η γλώσσα. Απλά θέτεις μια μεταβλητή περιβάλλοντος.
Even disregarding these issues, GNOME’s concept of minimalism does not seem to hold. For instance, requiring a full browser engine (i.e. WebKit2GTK) to use a desktop environment is anything but minimalist. … Just to build WebKit2GTK can take one hour and more than 16 GB of RAM, while Xfce on the same machine can be fully built in 5 minutes, requiring less than 500 MB of RAM.
Ποια η σύνδεση του μινιμαλισμού στην χρήση με το πόση ώρα θέλει να γίνει κάτι compile; Θα μπορούσα να έγραφα σεντόνια για απάντηση τα δυο άρθρα, αλλά δεν αξίζει τον κόπο. Ένα γραφικό περιβάλλον είναι και το καθένα έχει τις αρετές του αλλά και τα ελαττώματα του.
Και γιαυτό και μπήκα στον κόπο να γράψω την αρχική δημοσίευση, για να τα δούμε αυτά και να βρει ο καθένας αυτό που του ταιριάζει. Και προφανώς δεν θα αρέσει σε όλους, όπως πχ εμένα δεν μου αρέσει το xfce σήμερα (όπως δεν μου άρεσε καθόλου - μα καθόλου - το Gnome στο παρελθόν). Αλλά με μια διαφορά δεν λέω ότι το xfce είναι για τα σκουπίδια. Αλλά ο κύριος λόγος που το έγραψα, είναι για να του γίνει μια τεχνική κριτική με μια σωστή τεχνική βάση.
Εν το μεταξύ οι LC_ μεταβλητές είναι στη βάση των Unix συστημάτων. Λόγος για rant θα ήταν το ανάποδο. Ένα πρόγραμμα να μη λαμβάνει τις μεταβλητές αυτές υπόψιν.
Για το WebKit που γράφει, το κομμάτι
requiring a full browser engine (i.e. WebKit2GTK) to use a desktop environment
είναι λίγο προβληματικό. Οι GNOME εφαρμογές με εξάρτηση στο WebKit την έχουν γιατί χρειάζεται να χρησιμοποιήσουν web views, π.χ. Υelp (για help pages), Evolution (για mail).
Ίσως θα μπορούσε να διαφωνήσει γιατί κάποιες από αυτές χρησιμοποιούν web views, αλλά μάλλον η απάντηση είναι, γιατί δεν υπάρχει εναλλακτική (τα mails μπορεί να είναι HTML, κάποιες εφαρμογές δίνουν το help τους σε HTML, η σύνδεση σε online λογαριασμούς χρειάζεται πρόσβαση στη σελίδα του παρόχου κτλ).
Εν τέλη όμως κάποιος μπορεί να μη χρησιμοποιήσει τις συγκεκριμένες εφαρμογές (αν έχει τέτοιο πρόβλημα με την εγκατάσταση του WebKit) και πάλι θα χρησιμοποιεί ένα σημαντικό μέρος του GNOME.
Το θέμα δεν είναι να να κατηγορήσουμε το Gnome και το κάθε Gnome, το θέμα είναι να κάνουμε το κέφι μας και να ασκούμε κριτική στους developers που δεν μας δίνουν σημασία…
Βάζουν εξαρτήσεις εκεί που δεν χρειάζεται για λόγους σκοπιμότητας , δεν είναι αυτή η φιλοσοφίας του Linux νομίζω…
Τεσπά εγώ είμαι χαρούμενος που πέτυχε το hacking αλλά δεν είμαι χαρούμενος γιατί βλέπω πολλά στραβά επί σκοπό… στο project.
Συμφωνώ.
Στην σελίδα του έργου που παρέθεσες έχει ένα μεγάλο κείμενο που εξηγεί το σκεπτικό. Επίσης έχει μια λίστα από εναλλακτικές λύσεις και εξηγεί γιατί (κατά τον συγγραφέα) η λύση του είναι η καλύτερη. Παρεμπιπτόντως στο σύστημα μου τρέχω την προτελευταία εναλλακτική την system76-power.
Τώρα θα μπορούσε το Gnome να υποστηρίζει και τις 7 άλλες λύσεις. Και για κάτι άλλο που θα έχει 5 διαφορετικές λύσεις το ίδιο. Τότε ο έλεγχος θα έπρεπε να γίνει σε 35 διαφορετικά configurations. Αν θέλεις επιπλέον επιλογές πολλαπλασίασε ανάλογα
Δεν βγήκε ποτέ το Pop OS σαν διανομή να απαιτήσει από το Gnome να υποστηρίξει την δική του λύση [1]. Αυτό είναι μια δουλεία που θα πρέπει να την κάνει το ίδιο αν θέλει downstream. Θα πρέπει να γίνει κατανοητό πως κανένας developer δεν οφείλει να σου δώσει την παραμικρή σημασία. Θα δώσει τον κώδικα να τον κάνεις οτιδήποτε εσύ θέλεις να του κάνεις downstream. Στην συνέχεια έχει κάθε δικαίωμα να αγνοήσει οποιοδήποτε πρόβλημα προκύψει εμένα επειδή δεν χρησιμοποιώ το configuration πάνω στο οποίο έχουν αναπτύξει την λύση τους και την έχουν ελέγξει.
Τώρα μπορείς να τσεκάρεις τον κώδικα, και να δεις που ακριβώς γίνετε χρήση του systemd. Θα το έκανα αν ήταν στο github, τώρα θέλει clonning και βαριέμαι :-) Τότε και μόνον τότε μπορείς να προβείς στον ισχυρισμό ότι έγινε για λόγους σκοπιμότητας. Και μπορείς να τους στείλεις ένα patch που να καθιστά την χρήση του περιττή. Θυμήσου είναι στο χέρι τους αν το δεχτούν ή όχι. Αν το δεχτούν έχει καλώς. Αν όχι κάνε ότι αλλαγές κρίνεις εσύ downstream. Έτσι λειτουργεί ο ανοικτός κώδικάς.
Όσο για το dBus είναι ότι καλύτερο έχει ανακαλύψει η ανθρωπότητα, μετά την εφεύρεση των μακαρονιών με κιμά Στο τσακ τα γλίτωσα με το να κάθομαι να γράφω σεντόνια.
ΥΓ: Κατέβασα και μελέτησα πολύ βιαστικά τον κώδικα. Το systemd δεν είναι ένα runtime depedency. Είναι building depedency κάτι εντελώς διαφορετικό. Η μόνη χρήση του είναι για να βρει το meson που στο δίσκο θα εγκαταστήσει τα services. Δεν είναι λοιπόν καθόλου δύσκολο να χτιστεί χωρίς το systemd.
[1] Αν και έχουν πάρει από αυτό κάμποσο κώδικα και θέλουν να βάλουν πρώτα κάποιες αλλαγές στον Vanilla Kernel κατα πως λένε. Το ίδιο δεν χρησιμοποιεί από ότι βλέπω systemd.
Ακριβως αυτό λέω, αφου δεν χρειάζεται ουτε για build ουσιαστικά γιατι το κανουν ετσι;
Και για μην παρεξηγηθω, δεν ειμαι αντι-συστεμ ντι κτλ
Εχω ubuntu και mint στο σπίτι. Απλά διαφωνώ με την πολιτική να σε σπρωχνουν κάπου με το ζόρι και χωρις να χρειάζεται…
Τεσπα, πολλα λεω κ εγω τις τελευταίες μερες και θα με κανω ban 2-3 μερες…
Μα χρειάζεται για να γίνει build. Στα γρήγορα που βλέπω τον κώδικα διακρίνω δυο λόγους:
- Για να ξέρει που θα βάλει τα service files. Αν υποστήριζε n init systems και έφτιαχνε n service files θα είχε και n-1 επιπλέον εξαρτήσεις.
- Για να κάνει integration testing.
Τώρα τον χρήστη σε τι τον απασχολεί πόσες building depedency έχει κάποιο λογισμικό; Σε τίποτα. Είτε Ubuntu έχει, είτε Gentoo μια εντολή θα δώσει, στην σύνταξη και στον χρόνο εγκατάστασης έχουμε μόνο διαφορά, και θα το πάρει το συγκεκριμένο πακέτο. Και αν έχει γίνει το χτίσιμο σωστά δεν θα πάρει δωράκι μαζί (στα 3 πακέτα ένα δώρο) το systemd .
Καινούριο, φρέσκο κανάλι στο YT, με ενδιαφέρον υλικό :
PS: Αφού το post-άρα σε 2 άλλα threads, βρήκα επιτέλους το σωστό… 
4 «Μου αρέσει»
Επιτέλους μια χαμογελαστή φάτσα και καλή δουλεία. Ας ευχηθούμε μακροημέρευση στο κανάλι.
2 «Μου αρέσει»