GTK2/Gimp Theming - Bash scripting

[migf1]

Ο τίτλος ίσως δείχνει λίγο άσχετος με προγραμματισμό, αλλά νομίζω πως εδώ έχω καλές πιθανότητες να πάρω σοβαρή απάντηση ή απάντηση γενικώς (αν όχι για το theming part, τουλάχιστον για το bash-scripting).

 

Πρώτα, μια περιγραφή του προβλήματος:

 

Έχω μοντάρει μερικά themes για το Gimp 2.8. Όπως μπορείτε να διαβάσετε στο link, δείτε το Update  (ή αν δεν τα πάτε καλά με τα Αγγλικά, δείτε εδώ) αντιμετώπισα πρόβλημα στο Linux, και συγκεκριμένα με τη χρήση relative path στα file inclusions, στα "gtkrc" αρχεία των themes.

 

Τα Gimp themes είναι κανονικά GTK2 themes, το καθένα με δικό του φάκελο, μέσα στον οποίο υπάρχει ένα "gtkrc" αρχείο. Αυτό είναι βασικά το αρχείο που "διευθύνει" την όλη διαδικασία του theming.

 

Είναι αρκετά συνηθισμένο τα "gtkrc" αρχεία να σπάνε σε μικρότερα, τα οποία (μικρότερα) μπορούμε και τα κάνουμε μετά include μέσα στο "gtkrc" αρχείο (ακριβώς όπως είναι π.χ. τα #include pre-processor directives στην C/C++).

 

Για παράδειγμα, στα δικά μου themes, το κάθε θέμα έχει μέσα στον φάκελό του ένα αρχείο "imagerc" κι ένα "gtkrc". Μέσα στο "gtkrc" αρχείο, το 1ο πράγμα που γίνεται είναι το:

include "imagerc"                      # include image resources

Μέχρι εδώ όλα ωραία και καλά.

 

Το 3ο πράγμα που γίνεται στα "gtkrc" αρχεία των themes μου είναι το:

include "../_flat_gimp_icons/_darkrc"  # include base-theme

Αυτό το τελευταίο είναι παράδειγμα παρμένο από τα "gtkrc" αρχεία ΟΛΩΝ των Dark themes (υπάρχουν συνολικά 5 Dark themes: Dark Blue, Dark Orange, Dark Pink, Dark Red και Dark Teal), και η βασική ιδέα είναι πως όλα χρησιμοποιούν ένα κοινό base-theme (gtkrc like) αρχείο που ονομάζεται "_darkrc". Και το κάθε θέμα κάνει μετά (ή πριν) μόνο τις αλλαγές που είναι specific για το εκάστοτε συγκεκριμένο θέμα.

 

Όπως προφανώς καταλάβατε ήδη, το κοινό "_darkrc" αρχείο ΔΕΝ υπάρχει duplicated μέσα στον φάκελο κάθε Dark θέματος. Στο ίδιο επίπεδο με τους φακέλους των θεμάτων υπάρχει ένα φάκελος "_flat_gimp_icons/" που περιέχει το αρχείο "_darkrc".

 

Με αυτόν τον τρόπο με γλιτώνω από το να έχω ένα κάρο duplicated content μέσα στους φακέλους του κάθε θέματος. Το ίδιο πράγμα κάνω και με άλλα κοινά resources, όπως π.χ. τα icons (εκεί btw δεν υπάρχει πρόβλημα με τα relative paths, μάλλον επειδή εκεί δεν γίνεται inclusion, αλλά χρησιμοποιούνται απευθείας τα relative paths.... δείτε για παράδειγμα το "imagerc" αρχείο οποιουδήποτε θέματος).

 

Σε Windows τα πάντα λειτουργούν as expected. Σε Ubuntu 12.04 LTS όμως (που έστησα πρόχειρα χτες με wubi, με 6 μόλις Gb χώρο, μόνο και μόνο για να δοκιμάσω τα themes) βαράνε τα relative paths στη γραμμή: include "../_flat_gimp_icons/bla-bla", στα "gtkrc" αρχεία.

 

Βρήκα πως θέλει να βάλω absolute paths, δηλαδή:

include "/home/{user}/.gimp-2.8/themes/_flat_gimp_icons/bla-bla"

το οποίο όμως όπως καταλαβαίνουμε αν το κάνω, δεν θα λειτουργεί στα Windows μετά.

 

Από το έως τώρα ψάξιμο που έχω κάνει, έχω καταλάβει πως ο μόνος cross-platform τρόπος για να δουλεύουν τα themes χωρίς να χρειαστεί να κάνει τίποτα ο χρήστης, πέρα από το να τα ξεζιπάρει στον "themes/" φάκελο του Gimp 2.8 (που σημειωτέον διαφέρει μεταξύ Windows και Linux) είναι ο φάκελος του κάθε θέματος να είναι τελείως αυτόνομος, να περιέχει δηλαδή ΜΕΣΑ του τα πάντα όσα χρειάζεται, άρα να πήξουμε πάλι σε duplicated content (χώρια ότι έτσι μιλάμε πια και για maintenance/upgrade nightmare... διότι μιλάμε για 5 Dark themes, 5 Light themes, και οσονούπω 5 Darker themes, με το καθένα από αυτά να έχει κι από 5 Small παραλλαγές).

 

Η 1η μου ερώτηση λοιπόν είναι αν υπάρχει κάποιος τρόπος να κάνω τα "gtkrc" αρχεία να δουλεύουν με relative-path inclusions και σε Linux.

 

Επειδή εγώ δεν βρήκα τρόπο, σκέφτηκα ως λύση να φτιάξω ένα bash-script ειδικά για όσους βάλουν τα themes σε Linux (ενδεχομένως και σε Mac OSX) το οποίο να πηγαίνει και να αλλάζει αυτόματα το relative path σε absolute, στα "gtkrc" αρχεία ΟΛΩΝ των themes.

 

Η 2η ερώτησή μου λοιπόν είναι αν το σκριπτάκι που έγραψα είναι της προκοπής, ή ενδέχεται να τα κάνει μαντάρα σε τίποτα corner-cases. Το δοκίμασα και δείχνει να δουλεύει, αλλά επειδή τα *nix skills μου είναι (στην καλύτερη των περιπτώσεων) σκουριασμένα, θα ήθελα τη γνώμη όσων είναι εξοικειωμένοι σε καθημερινή βάση με αυτά τα πράγματα.

#!/bin/bash

gimp_themes=$HOME/.gimp-2.8/themes

SAVEIFS=$IFS
IFS=$(echo -en "\n\b")

find . -type f -name 'gtkrc' -print0 | while IFS= read -r -d '' file; do
  printf 'checking/fixing: %s\n' "$file"
  sed -i -e "s|\../_flat_gimp_icons|$gimp_themes/_flat_gimp_icons|g" $file
done

IFS=$SAVEIFS

echo 'done'

Μπορείτε να το κατεβάσετε κι έτοιμο από εδώ: https://app.box.com/s/yt5wjalwzhyldz102jax

 

Η ιδέα είναι να μπει στον ίδιο φάκελο με τα themes, και κατόπιν να εκτελεστεί από τερματικό:

./_fix_for_nix.sh

(ίσως χρειαστεί πρώτα να του δώσετε execute permissions: chmod u+x _fix_for_nix.sh)

 

Έχω ποστάρει σχετικά και στο φόρουμ του ubuntu-gr.org (σαφώς πιο εξειδικευμένο για το θέμα μου, αλλά θεωρώ με επίσης σαφώς λιγότερη κίνηση από το insomnia). Αν δεν βρεθεί καλύτερη λύση από αυτήν, τότε θέλω να ανεβάσω το σκριπτ (είτε αυτό είτε όποιο άλλο μου υποδειχθεί ως καλύτερο) ως προσωρινή λύση στην σελίδα των themes στο DA.

 

Έχω ξεκινήσει ήδη να φτιάχνω νέα έκδοση των themes, που υπολογίζω να τα έχω έτοιμα αυτή την εβδομάδα. Οπότε, επίσης, αν δεν βρεθεί καλύτερη λύση, θα ενσωματώσω το σκριπτ μέσα στο πακέτο της επόμενης έκδοσης. Βέβαια, ιδανικά, θα ήθελα να το αποφύγω τελείως το σκριπτ, και να τρέξουν σωστά τα relative paths και σε Linux (Mac OSX).

 

Αν είστε σε Linux (ή σε Mac OSX) και θελήσετε να δοκιμάσετε τα themes, κάνετε έναν κόπο και δοκιμάστε τα πρώτα χωρίς το fix. Σε μένα, έτρεχαν περίπου 1 στις 10 φορές (κι αυτή προβληματική), ενώ στις υπόλοιπες 9 το Gimp έδινε core-dump (το έτρεχα από τερματικό... από GUI απλώς έκλεινε πριν καν βγάλει το splash-screen).

 

ΥΓ. Σόρι για το σεντόνι, αλλά θέλησα να τα εξηγήσω λεπτομερώς για να αυξήσω τις πιθανότητες να βρεθεί κάποια σωστή λύση.

[brute-force]

Δοκίμασε να χρησιμοποιήσεις absolute path χρησιμοποιώντας την περιβαλλοντική μεταβλητή $HOME η οποία υπάρχει και σε Windows και σε Unix.

 

Όσο για το σκριπτάκι, εγώ τουλάχιστον χρησιμοποιώ #!/usr/bin/env bash αντί #!/bin/bash γιατί (αν και δεν έχω συναντήσει κάποιο προσωπικά) σε μερικά distros το executable του bash δεν βρίσκεται στο /bin/ .

 

DISCLAIMER: Δεν είμαι εντελώς εξοικιωμένος με bash scripting, απλά τους τελευταίους μήνες έχω αρχίσει και μαθαίνω.

[migf1]

Συμβαίνουν περίεργα πράγματα. Στο ubuntu-gr.org απάντησαν 2 παιδιά πως δεν είχαν κανέναν πρόβλημα με τα themes, δεν χρειάστηκαν καν το fix. Ο ένας τα δοκίμασε σε Debian και σε Arch, και ο άλλος σε Ubuntu 14.10.

 

Αρχίζω να πιστεύω πως το πρόβλημα μπορεί οφείλεται στο ότι εγώ το έχω στημένο με wubi το Ubuntu 12.04. Μπορεί κάποιος ή κάποιοι με Linux/Unix να δοκιμάσουν και να ενημερώσουν σχετικά εδώ στο νήμα;

 

@brute-force: To #!/usr/bin/env bash έχει + και -, αλλά ίσως είναι καλή ιδέα αν τελικά χρειαστεί το fix σε κάποιο Unix, που ενδέχεται να μην έχει το bash στο /bin (τα Linux νομίζω το έχουν πάντα στο /bin).

 

To - με το #!/usr/bin/env bash είναι πως διαβάζει την μεταβλητή $PATH και τρέχει όποιο bash βρει πρώτο μέσα στο $PATH. Αυτό άλλοτε είναι καλό (π.χ. για portability), άλλοτε κακό (π.χ. να υπάρχουν περισσότερα του 1ος bash στο $PATH και αυτό που είναι πρώτο να είναι π.χ. κάποια δοκιμαστική non-stable έκδοση).

 

Πάντως αν δεν σου κάνει κόπο, κι αν ευκαιρήσεις, θα μπορούσες να δοκιμάσεις τα themes? Σε τι Linux είσαι;

[brute-force]

Ευχαριστώ για την διευκρίνηση, ακούγεται λογικό.

 

Τους τελευταίους μήνες έχω γυρίσει στα Windows λόγω κάποιων προβλημάτων που είχα με τα αγαπητά Crunchbang που χρησιμοποιούσα τελευταία αλλά σύντομα θα ξαναγυρίσω γιατί μου λείπει πολύ το customizability και ο μινιμαλισμός του Openbox. Χρησιμοποιώ πολύ VM όμως (Debian και Crunchbang) και αν ευκαιρίσω αύριο θα το κοιτάξω εκεί.

[pmav99]

Πάντως migf1, μην ασχολείαι με Wubi. Μόνο προβλήματα έβγαζε για αυτό και σταμάτησε την ανάπτυξή του και η ίδια η Canonical. Για ό,τι θες να κάνεις, στήσε ένα VM και θα 'σαι κομπλέ.

[migf1]

 

 

@pmav

 

Το μηχανάκι στο οποίο το έστησα (dual boot με XP) είναι ένα παλιό laptop με 1.5Gb μνήμη. Οπότε δεν σηκώνει VM με τίποτα.

 

Και ο επιτραπέζιος όμως (που είναι και το βασικό μου PC στο σπίτι), πάλι με XP είναι, με 2Gb μνήμης (τα XP έτσι κι αλλιώς δεν βλέπουν πάνω από 2Gb μνήμης... υπάρχει μια χακιά αλλά δεν έχω ασχοληθεί).

 

Xώρια ότι αυτό έχει ήδη της Παναγιάς τα μάτια. Είναι το μηχανάκι που σε κάποιο άλλο νήμα σας έλεγα πως έχω να του κάνω φορμάτ 10-15 χρόνια, και παρά τις 2 αλλαγές μητρικής πάει μια χαρά. Έτσι για τον χαβαλέ, δες Start menu: http://imgur.com/NRD4lLE (χωρίς να υπολογίζουμε και τα μυριάδες portable apps που δεν φαίνονται εκεί μέσα )

 

Οπότε μάλλον ούτε αυτό σηκώνει VM.

 

Οπότε μένει το άλλο laptop με τα 4Gb μνήμης και τα Win7 64-bit, αλλά σε αυτό αποφεύγω να κάνω εξω-επαγγελματικούς πειραματισμούς και προσπαθώ να το κρατάω καθαρό και ελαφρύ (είναι το καθημερινό μου, "κουβαλητικό" μηχανάκι στις διάφορες επισκέψεις). Τελικά όμως μάλλον θα του βάλω κι ένα VM... ήδη το έχω τρενάρει πολύ (τα VM συνηθίζω να τα βάζω σε μη δικά μου μηχανάκια ).

 

 

Τελικά κανείς δεν τα δοκίμασε ρε παιδιά σε Linux ή/και σε Mac OSX τα themes να μου δώσει λίγο feedback?

Μόνο από το ubuntu-gr.org μου έδωσαν feedback 2 παιδιά, αλλά θα ήθελα αν είναι δυνατόν να ανεβάσω παραπάνω το δείγμα.

 

Περιμένω και feedback για το σκριπτ (μα καλά, που είναι εκείνος ο ημίθεος όταν τον χρειάζεσαι; )

[pmav99]

@migf1

 

 

 

(τα XP έτσι κι αλλιώς δεν βλέπουν πάνω από 2Gb μνήμης... υπάρχει μια χακιά αλλά δεν έχω ασχοληθεί).

Τα XP 32bit βλέπουν θεωρητικά 4, πρακτικά 3.5GB RAM και χωρίς καμία χακιά.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx#physical_memory_limits_windows_xp

 

Πάντως, με 1.5/2.0 GB αν βάλεις VM ξεχνάς X, οπότε δώρο άδωρο στην προκειμένη.

 

Σε μηχάνημα με XP και 4GB έχω δοκιμάσει VM και το Unity (Ubuntu) σερνόταν (laptop ψιλο-σάπιο με nvidia και το image του Virtual σκληρού ήταν στον ίδιο μηχανικό σκληρό). Θέλει πιο ελαφριά desktop environments ή/και δεύτερο σκληρό.

 

Εγώ στη θέση σου θα έπαιρνα και ένα PC. Αν δεν σε παίρνει να αλλάξεις, τότε βάλε όπως και δήποτε SSD. Έχουν πέσει οι τιμές πολύ και η διαφορά είναι απίστευτη (αλλά θέλει να έχεις και SATA III αλλιώς δεν είναι τόσο μεγάλη).

 

Έτσι για τον χαβαλέ, δες Start menu: http://imgur.com/NRD4lLE

Κάνε βρε άνθρωπε ένα sort by name τουλάχιστον

 

 

 

Βγάζει κάτι warnings αλλά φαίνεται να είναι ΟΚ (archlinux + awesome). Δεν έτρεξα το bash script

http://i.imgur.com/hbIvpvX.png

username at hostname in /tmp 
$ pacman -Qs gimp
local/gimp 2.8.14-1
    GNU Image Manipulation Program

username at hostname in /tmp 
$ uname -a
Linux hostname 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux

[migf1]

 

 

@migf1

Τα XP 32bit βλέπουν θεωρητικά 4, πρακτικά 3.5GB RAM και χωρίς καμία χακιά.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_xp

 

Πάντως, με 1.5/2.0 GB αν βάλεις VM ξεχνάς X, οπότε δώρο άδωρο στην προκειμένη.

 

Σε μηχάνημα με XP και 4GB έχω δοκιμάσει VM και το Unity (Ubuntu) σερνόταν (laptop ψιλο-σάπιο με nvidia και το image του Virtual σκληρού ήταν στον ίδιο μηχανικό σκληρό). Θέλει πιο ελαφριά desktop environments ή/και δεύτερο σκληρό.

 

Εγώ στη θέση σου θα έπαιρνα και ένα PC. Αν δεν σε παίρνει να αλλάξεις, τότε βάλε όπως και δήποτε SSD. Έχουν πέσει οι τιμές πολύ και η διαφορά είναι απίστευτη (αλλά θέλει να έχεις και SATA III αλλιώς δεν είναι τόσο μεγάλη).

SATA II είναι. Πάντως έχεις δίκιο για τα 4Gb. 3 με 3.5 Gb βλέπουν τα 32-μπιτα XP (πώς μου είχε μείνει πως βλέπουν μόνο μέχρι 2? Κι είμαι και προγραμματιστής τρομάρα μου

Δεν αλλάζω PC, δεν τίθεται τέτοιο θέμα. Απλώς αύριο θα πάω να πάρω 4Gb φρέσκιας μνήμης να του κουμπώσω στη θέση των 2Gb που έχει τώρα

 

Το laptop με τα 64-μπιτα win7 καλύπτει οποιαδήποτε σύγχρονη ανάγκη μου μέχρι στιγμής. Έχω πρόσβαση και σε laptop με 64-μπιτα Win8.1 αν θελήσω τίποτα πολύ τελευταίο, απλά δεν είναι δικό μου αυτό το laptop.

 

Btw, κι εγώ στο laptop, με Unity 2D το τρέχω το wubi Ubuntu 12.04 (και συγκεκριμένα με gnome-panel). Με το Unity 3D παγώνει πριν καν μπει στο Desktop

 

Κάνε βρε άνθρωπε ένα sort by name τουλάχιστον

Χε, χε. Επίτηδες το έχω έτσι. Βασικά άμα το παρατηρήσεις, μόνο η 3η στήλη είναι ασορτάριστη. Υποτίθεται πως ότι υπάρχει εκεί έχει μπει δοκιμαστικά μέχρι να αποφασίσω αν θα τα κρατήσω ή αν θα τα κάνω uninstall. Ε, μερικά από αυτά έχω αποφασίσει πως θα τα κρατήσω, αλλά δεν κάνω sort γιατί θα μου αλλάξουν σειρά και τα υπόλοιπα (θα τα φτιάξω κάποια στιγμή κι αυτά)

 

 

 

Βγάζει κάτι warnings αλλά φαίνεται να είναι ΟΚ (archlinux + awesome). Δεν έτρεξα το bash script

http://i.imgur.com/hbIvpvX.png

username at hostname in /tmp 
$ pacman -Qs gimp
local/gimp 2.8.14-1
    GNU Image Manipulation Program

username at hostname in /tmp 
$ uname -a
Linux hostname 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux

 

Thanks! Από το screenshot καταλαβαίνω πως μάλλον λείπει η GTK2 Clearlooks theming engine από την διανομή σου. Τα disabled entries (όπως το Mode label και το Normal list-entry στο ss σου, δεν πρέπει να είναι έτσι άσπρα. Από ότι μπορώ να διακρίνω, μάλλον τα έχει τρέξει τα themes με την GTK2 Aurora theming engine (μάλλον είναι η engine που χρησιμοποιεί το theme του GUI σου).

 

Αν θες να βάλεις και την clearlooks (και άλλες) ρίξε μια ματιά εδώ: http://superuser.com/questions/337639/how-to-fix-unable-to-locate-theme-engine-in-module-path-murrine (ή κι εδώ: http://askubuntu.com/questions/175352/how-to-install-gtk-clearlooks-and-murrine-to-fix-this-problem-on-ubuntu-wit ... είναι για Ubuntu αυτό το τελευταίο, αλλά η 1η απάντηση είναι γενικώς κατατοπιστική). Γενικώς για GTK theming στο Arch linux, υπάρχει ειδικό wiki: https://wiki.archlinux.org/index.php/GTK%2B

Βλέπω ότι δίνει και link ειδικά για κατέβασμα των gtk2-engines: https://www.archlinux.org/packages/?name=gtk-engines

 

Σε ευχαριστώ πολύ που το δοκίμασες. Άσχετα με την engine, φαίνεται να μην έχεις ούτε εσύ πρόβλημα με τις σχετικές διαδρομές στα "gtkrc" αρχεία των themes μου.

[pmav99]

 

Από ότι θυμάμαι σε SATA II το bottleneck δεν είναι η ταχύτητα του σκληρού αλλά η ταχύτητα μεταφοράς δεδομένων. Σε καθημερινή χρήση πάλι θα υπάρχει διαφορά φυσικά σε σχέση με ένα μηχανικό σκληρό, φαντάζομαι κυρίως σε random reads, αλλά πιθανότατα δεν ειναι τόσο μεγάλη όσο θα είναι σε SATA III. Ρώτα αν θες στον ενότητα του hardware και θα σου πουν. Εν γένει πάντως η προσθήκη SSD ειναι η πιο value for money αλλαγή που μπορείς να κάνεις.

 

 

Εβαλα τo πακέτο gtk-engines και έφυγε το warning και τα γράμματα φτιάξαν.

 

Για το issue at hand, και εγώ συμφωνω ότι τα *.gtkrc πρέπει να είναι ΟΚ, που είναι και λογικό αν το σκεφτείς. Δεν είναι δυνατό να υπήρχε τόσο χοντρό θέμα και να μην είχε λυθεί.

 

Αλλη μια #@!#$@!$ που κάνουν τα Wubi.