Theios Giorgos
Κατ’ αρχήν, εάν το συγκεκριμένο θέμα δεν πρέπει να αναρτηθεί ως νήμα, αλλά ως ερώτηση (μέσω pm) σε γνώστες ή στο support, ας διαγραφεί, εφόσον μου δοθούν διευκρινήσεις για το που θα πρέπει να απευθυνθώ…
Επί του θέματος…
Σκέφτηκα να ασχοληθώ λίγο με κάτι διαφορετικό, όπως είναι η δημιουργία ενός skin, μιας και οι γνώσεις μου σε html (αν και απαιτείται xml) και Photoshop – Corel είναι αρκετά καλές. Αλλά…
1. Κατ’ αρχήν, χρησιμοποιώντας το Notepad++, προσπάθησα να προβάλω στον Browser κάποιο έτοιμο Skin (που είχα κατεβάσει και αποσυμπιέσει). Σε κάθε περίπτωση (Firefox, Chrome, IE) μου έβγαζε σφάλμα. Γιατί συμβαίνει αυτό? Τελικά, με ποιο τρόπο μπορεί κανείς να προβάλει το αποτέλεσμα ενός xml αρχείου?
2. Αν και στις οδηγίες αναφέρεται ότι το αρχείο οφείλει να έχεις τις διαστάσεις του skin, παρατήρησα (σε όσα skins αποσυμπίεσα για να δω το png αρχείο), ότι κάθε στοιχείο (από το background μέχρι το εκάστοτε icon) σχεδιάζεται ανεξάρτητα και όχι όλα μαζί (layers). Γιατί προτιμάται αυτό?
3. Κάποια στιγμή, κάπου είχα διαβάσει για “βαρύ” skin? Αυτό έχει να κάνει με τον συνολικό αριθμό των (διαφορετικών ή μη) σχεδίων ή κάτι άλλο και τί?
4. Κατά τον σχεδιασμό, υπάρχουν κάποια θέματα που θα έπρεπε να έχει κάποιος προκαταβολικά υπόψη του, ώστε να μην ανακαλύψει – διαπιστώσει προβλήματα κατόπιν εορτής και εάν ναι, ποια είναι αυτά?
Ευχαριστώ προκαταβολικά, όποιον ασχοληθεί – απαντήσει…
Επί του θέματος…
Σκέφτηκα να ασχοληθώ λίγο με κάτι διαφορετικό, όπως είναι η δημιουργία ενός skin, μιας και οι γνώσεις μου σε html (αν και απαιτείται xml) και Photoshop – Corel είναι αρκετά καλές. Αλλά…
1. Κατ’ αρχήν, χρησιμοποιώντας το Notepad++, προσπάθησα να προβάλω στον Browser κάποιο έτοιμο Skin (που είχα κατεβάσει και αποσυμπιέσει). Σε κάθε περίπτωση (Firefox, Chrome, IE) μου έβγαζε σφάλμα. Γιατί συμβαίνει αυτό? Τελικά, με ποιο τρόπο μπορεί κανείς να προβάλει το αποτέλεσμα ενός xml αρχείου?
2. Αν και στις οδηγίες αναφέρεται ότι το αρχείο οφείλει να έχεις τις διαστάσεις του skin, παρατήρησα (σε όσα skins αποσυμπίεσα για να δω το png αρχείο), ότι κάθε στοιχείο (από το background μέχρι το εκάστοτε icon) σχεδιάζεται ανεξάρτητα και όχι όλα μαζί (layers). Γιατί προτιμάται αυτό?
3. Κάποια στιγμή, κάπου είχα διαβάσει για “βαρύ” skin? Αυτό έχει να κάνει με τον συνολικό αριθμό των (διαφορετικών ή μη) σχεδίων ή κάτι άλλο και τί?
4. Κατά τον σχεδιασμό, υπάρχουν κάποια θέματα που θα έπρεπε να έχει κάποιος προκαταβολικά υπόψη του, ώστε να μην ανακαλύψει – διαπιστώσει προβλήματα κατόπιν εορτής και εάν ναι, ποια είναι αυτά?
Ευχαριστώ προκαταβολικά, όποιον ασχοληθεί – απαντήσει…
Mensajes Mon 05 Feb 18 @ 6:02 am
PhantomDeejay
1. Τι εννοείς σου βγάζει σφάλμα; Κατ αρχήν ένα αρχείο skin δεν είναι βάση δεδομένων (κάτι που συνήθως προσπαθούν να διαβάσουν οι browsers)
Γενικά ένας browser δεν έχει τίποτα να σου δείξει σε ένα αρχείο skin / XML
2. Σε ποιες οδηγίες αναφέρεσαι; (Γιατί έχουν αλλάξει μερικές φορές και κυκλοφορούν διάφορες εκδοχές)
Στις επίσημες οδηγίες αυτό που αναφέρεται είναι οτι το αρχείο γραφικών (PNG) πρέπει να έχει κατ' ελάχιστον διαστάσεις ίσες με αυτές που ορίζονται σαν διαστάσεις του skin.
Πριν το VirtualDJ 8, η skin engine δεν υποστήριζε σωστά (και εύκολα) transparency. Έτσι συνήθως οι skin designers έφτιαχναν 2-3 όψεις του skin και από αυτές τις όψεις διάλεγαν τα γραφικά που χρειαζόντουσαν.
Στο VirtualDJ 8 η χρήση transparency έγινε εύκολη, και έτσι πλέον οι skin designers φτιάχνουν το βασικό layout / background και πάνω σ' αυτό τοποθετουν τα στοιχεία που χρειάζονται. Έτσι ένα skin μπορεί να γίνει πιο δυναμικό... αντί να φτιάχνεις δεκάδες views γραφικά, μπορείς να φτιάξεις δεκάδες views προγραμματιστικά μετακινόντας απλά τα διάφορα elements στην οθόνη!
3. Έχει να κάνει με τον αριθμό των panels που χρησιμοποιεί, τον αριθμό των nested panels (ή ορθότερα το μέγιστο βάθος στο οποίο φτάνουν τα nested panels για κάθε panel) καθώς και το πλήθος των conditional views (όταν ορίζεις μια εντολή vdj script να ελέγχει αν ένα panel ή ένα κουμπί κτλ είναι ορατό)
Γενικά δεν θα ανησυχούσα για το βάρος του skin αν δεν έχεις σκοπό να φτιάξεις ένα skin που θα αποτελείτε από εκατοντάδες conditional panles.
4. Προσπάθησε να καταλάβεις την αξία των definitions και να τα χρησιμοποιείς όσο πιο συχνά μπορείς.
Γενικά ένας browser δεν έχει τίποτα να σου δείξει σε ένα αρχείο skin / XML
2. Σε ποιες οδηγίες αναφέρεσαι; (Γιατί έχουν αλλάξει μερικές φορές και κυκλοφορούν διάφορες εκδοχές)
Στις επίσημες οδηγίες αυτό που αναφέρεται είναι οτι το αρχείο γραφικών (PNG) πρέπει να έχει κατ' ελάχιστον διαστάσεις ίσες με αυτές που ορίζονται σαν διαστάσεις του skin.
Πριν το VirtualDJ 8, η skin engine δεν υποστήριζε σωστά (και εύκολα) transparency. Έτσι συνήθως οι skin designers έφτιαχναν 2-3 όψεις του skin και από αυτές τις όψεις διάλεγαν τα γραφικά που χρειαζόντουσαν.
Στο VirtualDJ 8 η χρήση transparency έγινε εύκολη, και έτσι πλέον οι skin designers φτιάχνουν το βασικό layout / background και πάνω σ' αυτό τοποθετουν τα στοιχεία που χρειάζονται. Έτσι ένα skin μπορεί να γίνει πιο δυναμικό... αντί να φτιάχνεις δεκάδες views γραφικά, μπορείς να φτιάξεις δεκάδες views προγραμματιστικά μετακινόντας απλά τα διάφορα elements στην οθόνη!
3. Έχει να κάνει με τον αριθμό των panels που χρησιμοποιεί, τον αριθμό των nested panels (ή ορθότερα το μέγιστο βάθος στο οποίο φτάνουν τα nested panels για κάθε panel) καθώς και το πλήθος των conditional views (όταν ορίζεις μια εντολή vdj script να ελέγχει αν ένα panel ή ένα κουμπί κτλ είναι ορατό)
Γενικά δεν θα ανησυχούσα για το βάρος του skin αν δεν έχεις σκοπό να φτιάξεις ένα skin που θα αποτελείτε από εκατοντάδες conditional panles.
4. Προσπάθησε να καταλάβεις την αξία των definitions και να τα χρησιμοποιείς όσο πιο συχνά μπορείς.
Mensajes Mon 05 Feb 18 @ 5:48 pm
Theios Giorgos
Γιώργο σ’ ευχαριστώ πολύ! Σχετικά με τις ερωτήσεις μου…
@ 1. Θα το διατυπώσω αλλιώς. Εάν θεωρήσουμε ότι ολοκληρώθηκε το png file και αρχίζουμε τον προγραμματισμό σε xml, πως εγώ θα παρατηρώ το τελικό αποτέλεσμα step – by – step? Συμπιέζοντας (σχεδόν σε κάθε βήμα) τα αρχεία (xml, png) και τρέχοντάς τα (μέσω VDj)? Ή υπάρχει άλλος πιο άμεσος και πρακτικός τρόπος?
@ 2. Στο SilverSleek 3, για παράδειγμα, επέλεξες να μην έχεις τα elements τοποθετημένα πάνω στο background, αλλά από κάτω (άρα και το ύψος του png file είναι κατά πολύ μεγαλύτερο των διαστάσεων του skin). Την αποφυγή διπλότυπων elements (Deck A, Deck B, κ.τ.λ.) την καταλαβαίνω (αν και δεν νομίζω ότι "βαραίνουν" τόσο πολύ το αρχείο, εκτός και εάν κάνω λάθος), όπως και των διαχωρισμό όσων θα έχουν τις ίδιες ακριβώς διαστάσεις και συντεταγμένες (αλλά διαφορετική όψη, ανά λειτουργία). Αλλά η τοποθέτηση όλων ανεξαιρέτως, κάτω από το background, σε τι εξυπηρετεί?
@ 1. Θα το διατυπώσω αλλιώς. Εάν θεωρήσουμε ότι ολοκληρώθηκε το png file και αρχίζουμε τον προγραμματισμό σε xml, πως εγώ θα παρατηρώ το τελικό αποτέλεσμα step – by – step? Συμπιέζοντας (σχεδόν σε κάθε βήμα) τα αρχεία (xml, png) και τρέχοντάς τα (μέσω VDj)? Ή υπάρχει άλλος πιο άμεσος και πρακτικός τρόπος?
@ 2. Στο SilverSleek 3, για παράδειγμα, επέλεξες να μην έχεις τα elements τοποθετημένα πάνω στο background, αλλά από κάτω (άρα και το ύψος του png file είναι κατά πολύ μεγαλύτερο των διαστάσεων του skin). Την αποφυγή διπλότυπων elements (Deck A, Deck B, κ.τ.λ.) την καταλαβαίνω (αν και δεν νομίζω ότι "βαραίνουν" τόσο πολύ το αρχείο, εκτός και εάν κάνω λάθος), όπως και των διαχωρισμό όσων θα έχουν τις ίδιες ακριβώς διαστάσεις και συντεταγμένες (αλλά διαφορετική όψη, ανά λειτουργία). Αλλά η τοποθέτηση όλων ανεξαιρέτως, κάτω από το background, σε τι εξυπηρετεί?
Mensajes Mon 05 Feb 18 @ 7:01 pm
PhantomDeejay
1. Δεν χρειάζεται να συμπιέζεις τα αρχεία. Απλά ανοίγεις το VirtualDJ πας στην καρτέλα skins και κάνεις κλικ πάνω στο αρχείο του skin. Αν χρησιμοποιείς ήδη το skin που προγραμματίζεις τότε μπορείς να προγραμματίσεις ένα keyboard shortcut σαν "reload_skin" ώστε να το πατάς και να βλέπεις άμεσα τις αλλαγές. Απλά, δουλεύεις τόσο το png όσο και το αρχείο xml ΜΕΣΑ στο φάκελο skins του VirtualDJ
2. Έχε υπόψην σου οτι το πάνω μέρος του png (τα πρώτα 1920χ1080 pixels) είναι το "background" του skin. Αν το σκιν σου είναι γενικά "στατικό" (έχει μόνο μία όψη) τότε μπορείς να ζωγραφίσεις εκεί. Αν όμως φτιάξεις ένα πιο δυναμικό skin (όπως το SilverSleek #3 που έχει ένα σωρό διαφορετικά views) τότε αν το background σου είναι ζωγραφισμένο, αντί να τοποθετείς απλά ένα κουμπί στην οθόνη, θα πρέπει σε κάθε view να φτιάχνεις διαφορετικά backgrounds για να "βάψεις" πάνω από το default background.
Για να στο κάνω πιο απλό: Αν το μέρος που θα βάλεις τις κυματομορφές rhythm/scratch είναι σταθερό και με σταθερές διαστάσεις, τότε μπορείς να βάλεις το "παράθυρο" αυτό στο default background. Τι γίνεται όμως αν θες ο χρήστης να μπορεί να του αλλάξει θέση; Θα πρέπει αφενός να φτιάξεις γραφικά για τη νέα θέση του παράθυρου rhythm/scratch και αφετέρου να φτιάξεις γραφικά για να "σβήσεις" την παλιά θέση.
Ελπίζω τώρα να κατάλαβες γιατί όλα τα σύνθετα skins είναι φτιαγμένα με αυτή τη λογική.
Το SilverSleek #3 αν θυμάμαι τα νούμερα καλά έχει 2*5*4*2*3= 240 βασικά διαφορετικά views. Αν για κάθε view έφτιαχνα μια "flat" περιοχή με γραφικά για background τότε το μέγεθος του αρχείου png θα ήταν σαφώς πολύ μεγαλύτερο. Ακόμα και με "οικονομία" στην περιοχή του browser το ύψος του θα ξεπερνούσε άνετα τα 120.000 (120k) pixels!!!
2. Έχε υπόψην σου οτι το πάνω μέρος του png (τα πρώτα 1920χ1080 pixels) είναι το "background" του skin. Αν το σκιν σου είναι γενικά "στατικό" (έχει μόνο μία όψη) τότε μπορείς να ζωγραφίσεις εκεί. Αν όμως φτιάξεις ένα πιο δυναμικό skin (όπως το SilverSleek #3 που έχει ένα σωρό διαφορετικά views) τότε αν το background σου είναι ζωγραφισμένο, αντί να τοποθετείς απλά ένα κουμπί στην οθόνη, θα πρέπει σε κάθε view να φτιάχνεις διαφορετικά backgrounds για να "βάψεις" πάνω από το default background.
Για να στο κάνω πιο απλό: Αν το μέρος που θα βάλεις τις κυματομορφές rhythm/scratch είναι σταθερό και με σταθερές διαστάσεις, τότε μπορείς να βάλεις το "παράθυρο" αυτό στο default background. Τι γίνεται όμως αν θες ο χρήστης να μπορεί να του αλλάξει θέση; Θα πρέπει αφενός να φτιάξεις γραφικά για τη νέα θέση του παράθυρου rhythm/scratch και αφετέρου να φτιάξεις γραφικά για να "σβήσεις" την παλιά θέση.
Ελπίζω τώρα να κατάλαβες γιατί όλα τα σύνθετα skins είναι φτιαγμένα με αυτή τη λογική.
Το SilverSleek #3 αν θυμάμαι τα νούμερα καλά έχει 2*5*4*2*3= 240 βασικά διαφορετικά views. Αν για κάθε view έφτιαχνα μια "flat" περιοχή με γραφικά για background τότε το μέγεθος του αρχείου png θα ήταν σαφώς πολύ μεγαλύτερο. Ακόμα και με "οικονομία" στην περιοχή του browser το ύψος του θα ξεπερνούσε άνετα τα 120.000 (120k) pixels!!!
Mensajes Tue 06 Feb 18 @ 11:49 am
Theios Giorgos
Γιώργο, ήσουν απόλυτα σαφής και κατανοητός!
Γενικά, η φιλοσοφία μου είναι να δημιουργήσω ένα skin, το οποίο θα περιλαμβάνει αποκλειστικά και μόνον όλες τις πληροφορίες, οι οποίες δεν υφίστανται - εμφανίζονται σε έναν οποιονδήποτε (σύγχρονο) controller, χωρίς οθόνη.
Συνεπώς, θα απουσιάζουν παντελώς ενδείξεις ή εντολές (και κατ’ επέκταση αντίστοιχα γραφικά), τα οποία φαίνονται ή υλοποιούνται μέσω controller (όπως, π.χ. τα vu leds ή ακόμη και το Play / Cue / Sync). Αυτό βέβαια, θα έχει ως αποτέλεσμα το εν λόγω skin να μην μπορεί να χρησιμοποιηθεί (@ home) χωρίς την σύνδεση controller, αλλά (@ work) τουλάχιστον οι πληροφορίες θα είναι αρκετά πιο ευανάγνωστες (και ιδίως όταν έχεις συνειδητοποιήσει ότι τελείωσες το μπουκάλι του Tanqueray και η ώρα είναι μόνον 3 a.m :P), καθότι θα υπάρχει "επάρκεια" χώρου...
Υπό αυτό το σκεπτικό, νομίζω ότι το skin θα είναι (εκ των πραγμάτων) περισσότερο στατικό, παρά δυναμικό…
Γενικά, η φιλοσοφία μου είναι να δημιουργήσω ένα skin, το οποίο θα περιλαμβάνει αποκλειστικά και μόνον όλες τις πληροφορίες, οι οποίες δεν υφίστανται - εμφανίζονται σε έναν οποιονδήποτε (σύγχρονο) controller, χωρίς οθόνη.
Συνεπώς, θα απουσιάζουν παντελώς ενδείξεις ή εντολές (και κατ’ επέκταση αντίστοιχα γραφικά), τα οποία φαίνονται ή υλοποιούνται μέσω controller (όπως, π.χ. τα vu leds ή ακόμη και το Play / Cue / Sync). Αυτό βέβαια, θα έχει ως αποτέλεσμα το εν λόγω skin να μην μπορεί να χρησιμοποιηθεί (@ home) χωρίς την σύνδεση controller, αλλά (@ work) τουλάχιστον οι πληροφορίες θα είναι αρκετά πιο ευανάγνωστες (και ιδίως όταν έχεις συνειδητοποιήσει ότι τελείωσες το μπουκάλι του Tanqueray και η ώρα είναι μόνον 3 a.m :P), καθότι θα υπάρχει "επάρκεια" χώρου...
Υπό αυτό το σκεπτικό, νομίζω ότι το skin θα είναι (εκ των πραγμάτων) περισσότερο στατικό, παρά δυναμικό…
Mensajes Tue 06 Feb 18 @ 12:22 pm
Theios Giorgos
PhantomDeejay wrote :
4. Προσπάθησε να καταλάβεις την αξία των definitions και να τα χρησιμοποιείς όσο πιο συχνά μπορείς.
Έγινε κατανοητό το θέμα... Η ερώτησή μου είναι εάν ο βασικός σκοπός είναι η επίτευξη ενός τελικού αρχείου xml μικρότερου μεγέθους (κάτι το οποίο μπορεί να συμβάλει θετικά, είτε στο VDj, είτε στην καταναλισκόμενη μνήμη) ή απλά και μόνον στην ευκολία προγραμματισμού. Επίσης, εάν η συντόμευση ορισμών (π.χ. txt αντί text ή bt αντί button) έχει τον ίδιο σκοπό επίσης...
Mensajes Fri 09 Feb 18 @ 4:03 pm
PhantomDeejay
Πάλι δεν κατάλαβα ακριβώς την ερώτηση σου, αλλά:
1) Το μέγεθος του αρχείου png και του αρχείου xml (σε bytes) δεν παίζουν κανένα πρακτικό ρόλο στο τελικό "μέγεθος" του skin
2) Στο τελικό μέγεθος του skin (όπως αυτό αποσυμπιέζεται στην μνήμη RAM του υπολογιστή) παίζουν ρόλο το πλήθος των elements (στοιχείων) που χρησιμοποιεί το skin, η ορατότητα τους, καθώς και πόσα από αυτά χρησιμοποιούν εντολές (actions) για να είναι ορατά ή κρυμμένα. Γενικά ένα skin "βαραίνει" με την χρήση πολλών conditional panels (panels που η ορατότητα τους εξαρτάται από συγκεκριμένες συνθήκες). Για να μην τρομάξεις όμως σου λέω οτι ο αριθμός των conditional panels που αρχίζει να επιβαρύνει ένα skin είναι αρκετά μεγάλος (ανάλογα και με την φύση των panels, πάντως σίγουρα μετριέται σε μερικές χιλιάδες)
3) Το μέγεθος του ονόματος ενός element (καθώς και η ίδια η ονομασία του αυτή καθ' αυτή) δεν παίζει επίσης κανένα πρακτικό ρόλο στο τελικό μέγεθος του "αποσυμπιεσμένου" skin. Προσωπικά χρησιμοποιώ συντμήσεις σαν συνήθεια λόγω της ενασχόλησης μου με προγραμματισμό γενικότερα. Γενικά όταν προγραμματίζεις σε διάφορες γλώσσες σου γίνεται συνήθεια να βάζεις πριν το όνομα του κάθε object μια σύντμηση που να δείχνει τι είναι το εν λόγω object.
Έτσι λόγου χάρη δεν έχει καμία διαφορά αν θα κάνεις define ένα κουμπί σαν bt_Play, button_Play, btPlay, buttonPlay, Play, PlayButton κ.ο.κ.
4) Η συμβουλή που σου έδωσα για τα definitions αφορά το γεγονός οτι διευκολύνουν απίστευτα τον προγραμματισμό και τις αλλαγές που μπορεί να κάνεις στην πορεία μέχρι να τελειώσεις το skin (ή και αργότερα σε μελλοντική αναθεώρηση)
Για παράδειγμα έστω οτι δεν κάνεις define ένα play button αλλά το γράφεις 4 φορές (για skin 4 deck) κατευθείαν μέσα στο XML.
Έστω οτι στην πορεία για τον Χ-Υ-Ζ λόγο αποφασίζεις να μετακινήσεις τα γραφικά του κουμπιού μέσα στο PNG αρχείο.
Με definitions, κάνεις μία φορά ένα edit δίνοντας τις καινούργιες συντεταγμένες (ή διαστάσεις ή και τα 2) στο definition του κουμπιού και είσαι έτοιμος.
Χωρίς definitions θα πρέπει να κάνεις την ίδια διαδικασία 4 φορές (αντί για μία)
Αν τώρα αλλάξεις όλη την "τριάδα" των πλήκτρων (CUE/PLAY/SYNC) έχουμε 3 edits VS 12.
Καταλαβαίνεις οτι και φόρτο εργασίας αυξάνεις, και είναι πιο εύκολο να σου ξεφύγει κάτι (πχ 12x4 edits -για αλλαγή posx, posy, width & height- = 48 edits VS 12)
Τέλος όταν ένα κουμπί είναι defined είναι σίγουρο οτι θα εκτελεί την ΙΔΙΑ ακριβώς εντολή όπου κι αν το χρησιμοποιήσεις. Έτσι δεν διατρέχεις κίνδυνο σε κάποιο deck ένα κουμπί να μην δουλεύει σωστά γιατί έκανες κάποιο λάθος κατά την πληκτρολόγηση του action κτλ, οπότε και ελαχιστοποιείς τα σφάλματα στον κώδικα, αλλά και διευκολύνεις την επίλυση τους αν πέσεις πάνω σε κανένα...
1) Το μέγεθος του αρχείου png και του αρχείου xml (σε bytes) δεν παίζουν κανένα πρακτικό ρόλο στο τελικό "μέγεθος" του skin
2) Στο τελικό μέγεθος του skin (όπως αυτό αποσυμπιέζεται στην μνήμη RAM του υπολογιστή) παίζουν ρόλο το πλήθος των elements (στοιχείων) που χρησιμοποιεί το skin, η ορατότητα τους, καθώς και πόσα από αυτά χρησιμοποιούν εντολές (actions) για να είναι ορατά ή κρυμμένα. Γενικά ένα skin "βαραίνει" με την χρήση πολλών conditional panels (panels που η ορατότητα τους εξαρτάται από συγκεκριμένες συνθήκες). Για να μην τρομάξεις όμως σου λέω οτι ο αριθμός των conditional panels που αρχίζει να επιβαρύνει ένα skin είναι αρκετά μεγάλος (ανάλογα και με την φύση των panels, πάντως σίγουρα μετριέται σε μερικές χιλιάδες)
3) Το μέγεθος του ονόματος ενός element (καθώς και η ίδια η ονομασία του αυτή καθ' αυτή) δεν παίζει επίσης κανένα πρακτικό ρόλο στο τελικό μέγεθος του "αποσυμπιεσμένου" skin. Προσωπικά χρησιμοποιώ συντμήσεις σαν συνήθεια λόγω της ενασχόλησης μου με προγραμματισμό γενικότερα. Γενικά όταν προγραμματίζεις σε διάφορες γλώσσες σου γίνεται συνήθεια να βάζεις πριν το όνομα του κάθε object μια σύντμηση που να δείχνει τι είναι το εν λόγω object.
Έτσι λόγου χάρη δεν έχει καμία διαφορά αν θα κάνεις define ένα κουμπί σαν bt_Play, button_Play, btPlay, buttonPlay, Play, PlayButton κ.ο.κ.
4) Η συμβουλή που σου έδωσα για τα definitions αφορά το γεγονός οτι διευκολύνουν απίστευτα τον προγραμματισμό και τις αλλαγές που μπορεί να κάνεις στην πορεία μέχρι να τελειώσεις το skin (ή και αργότερα σε μελλοντική αναθεώρηση)
Για παράδειγμα έστω οτι δεν κάνεις define ένα play button αλλά το γράφεις 4 φορές (για skin 4 deck) κατευθείαν μέσα στο XML.
Έστω οτι στην πορεία για τον Χ-Υ-Ζ λόγο αποφασίζεις να μετακινήσεις τα γραφικά του κουμπιού μέσα στο PNG αρχείο.
Με definitions, κάνεις μία φορά ένα edit δίνοντας τις καινούργιες συντεταγμένες (ή διαστάσεις ή και τα 2) στο definition του κουμπιού και είσαι έτοιμος.
Χωρίς definitions θα πρέπει να κάνεις την ίδια διαδικασία 4 φορές (αντί για μία)
Αν τώρα αλλάξεις όλη την "τριάδα" των πλήκτρων (CUE/PLAY/SYNC) έχουμε 3 edits VS 12.
Καταλαβαίνεις οτι και φόρτο εργασίας αυξάνεις, και είναι πιο εύκολο να σου ξεφύγει κάτι (πχ 12x4 edits -για αλλαγή posx, posy, width & height- = 48 edits VS 12)
Τέλος όταν ένα κουμπί είναι defined είναι σίγουρο οτι θα εκτελεί την ΙΔΙΑ ακριβώς εντολή όπου κι αν το χρησιμοποιήσεις. Έτσι δεν διατρέχεις κίνδυνο σε κάποιο deck ένα κουμπί να μην δουλεύει σωστά γιατί έκανες κάποιο λάθος κατά την πληκτρολόγηση του action κτλ, οπότε και ελαχιστοποιείς τα σφάλματα στον κώδικα, αλλά και διευκολύνεις την επίλυση τους αν πέσεις πάνω σε κανένα...
Mensajes Mon 12 Feb 18 @ 1:41 pm
Theios Giorgos
Δεν έχω λόγια, ήσουν σαφέστατος, όπως κάθε φορά (που έχεις όρεξη… :P).
Σχετικά με την ονοματοδοσία, επέλεξα την περίπτωση under_score. Κάπου είχα διαβάσει ότι η περίπτωση camelCase είναι κοινή ονοματοδοσία σε JavaScripts. Τώρα, το εάν και που θα μπορούσε να φανεί χρήσιμη η εν λόγω περίπτωση δεν ξέρω, αλλά εάν όντως (μπορεί να φανεί ή) είναι χρήσιμη, να την επιλέξω…
Σχετικά με τα definitions, ναι, είχες απόλυτο δίκιο! Μέχρι και το logo (που λέει ο λόγος) αξίζει να είναι define…
Με την ευκαιρία, 3 ερωτήσεις:
Στις οδηγίες, αναφέρει: “New in VDJ8 is action instead of format”. Και φαντάζομαι ότι όπου μπορεί να χρησιμοποιηθεί το action, αντί του format, καλό θα είναι…
Στις εντολές, δεν βρήκα κάτι σχετικό με get_battery, όπως π.χ. την εντολή: %cpu για την χρήση επεξεργαστή. Είναι παράλειψη στις οδηγίες ή δεν έχει συμπεριληφθεί ακόμη στις εντολές? Το ίδιο ισχύει και με την Ram, όπου (θεωρώ) ότι θα ήταν αρκετά χρήσιμο…
1. Έχω text με σύνταξη: format="CPU: %cpu%". Πώς θα μπορούσα να έχω ακριβώς το ίδιο αποτέλεσμα για το ποσοστό της μπαταρίας? Ότι συνδυασμό δοκίμασα με get_battery, δεν μου εμφανίζει, είτε το κείμενο BATTERY, είτε το ποσοστό. Εκτός και εάν, στην συγκεκριμένη περίπτωση, πρέπει να έχω 2 διαφορετικά texts.
2. Στο text με σύνταξη: format="CPU: %cpu%", θα μπορούσα να εφαρμόσω delay στην εμφάνιση τιμών και εάν ναι, με ποια σύνταξη?
3. Στο άνω text, εάν ήθελα να αλλάζει το χρώμα του ποσοστού (ανάλογα με την τιμή του), θα μπορούσα να το υλοποιήσω και εάν ναι, με ποια σύνταξη?
Ευχαριστώ και πάλι...
Σχετικά με την ονοματοδοσία, επέλεξα την περίπτωση under_score. Κάπου είχα διαβάσει ότι η περίπτωση camelCase είναι κοινή ονοματοδοσία σε JavaScripts. Τώρα, το εάν και που θα μπορούσε να φανεί χρήσιμη η εν λόγω περίπτωση δεν ξέρω, αλλά εάν όντως (μπορεί να φανεί ή) είναι χρήσιμη, να την επιλέξω…
Σχετικά με τα definitions, ναι, είχες απόλυτο δίκιο! Μέχρι και το logo (που λέει ο λόγος) αξίζει να είναι define…
Με την ευκαιρία, 3 ερωτήσεις:
Στις οδηγίες, αναφέρει: “New in VDJ8 is action instead of format”. Και φαντάζομαι ότι όπου μπορεί να χρησιμοποιηθεί το action, αντί του format, καλό θα είναι…
Στις εντολές, δεν βρήκα κάτι σχετικό με get_battery, όπως π.χ. την εντολή: %cpu για την χρήση επεξεργαστή. Είναι παράλειψη στις οδηγίες ή δεν έχει συμπεριληφθεί ακόμη στις εντολές? Το ίδιο ισχύει και με την Ram, όπου (θεωρώ) ότι θα ήταν αρκετά χρήσιμο…
1. Έχω text με σύνταξη: format="CPU: %cpu%". Πώς θα μπορούσα να έχω ακριβώς το ίδιο αποτέλεσμα για το ποσοστό της μπαταρίας? Ότι συνδυασμό δοκίμασα με get_battery, δεν μου εμφανίζει, είτε το κείμενο BATTERY, είτε το ποσοστό. Εκτός και εάν, στην συγκεκριμένη περίπτωση, πρέπει να έχω 2 διαφορετικά texts.
2. Στο text με σύνταξη: format="CPU: %cpu%", θα μπορούσα να εφαρμόσω delay στην εμφάνιση τιμών και εάν ναι, με ποια σύνταξη?
3. Στο άνω text, εάν ήθελα να αλλάζει το χρώμα του ποσοστού (ανάλογα με την τιμή του), θα μπορούσα να το υλοποιήσω και εάν ναι, με ποια σύνταξη?
Ευχαριστώ και πάλι...
Mensajes Mon 12 Feb 18 @ 5:39 pm
PhantomDeejay
Δοκίμασε τα εξής:
<define class="txt_Battery">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_battery"/>
<tooltip>Battery Level: `get_battery`</tooltip>
</define>
<define class="txt_Battery2">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_text 'Battery: `get_battery`'"/>
<tooltip>Battery Level: `get_battery`</tooltip>
</define>
<define class="txt_CPU">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_cpu"/>
</define>
<define class="txt_CPU2">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_cpu & param_cast 'percentage'"/>
</define>
<define class="txt_CPU3">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_text 'CPU: `get_cpu & param_cast percentage & param_cast int_trunc`%'"/>
</define>
<define class="txt_CPU4">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="`param_bigger 0.75 get_cpu ? color 'red' : param_bigger 0.5 get_cpu ? color 'yellow' : param_bigger 0.25 get_cpu ? color 'cyan' : color 'green'`" align="center" weight="bold" scroll="no" action="get_text 'CPU: `get_cpu & param_cast percentage & param_cast int_trunc`%'"/>
</define>
Γενικά το "delay" όπως το έχεις στο μυαλό σου ξέχνα το. Σε ένα skin ΔΕΝ θες delay εκτός από ελάχιστες περιπτώσεις. Στο μέλλον ίσως προστεθεί κάτι αλλά γενικά μην υπολογίζεις σε "delay"
Αντίθετα μπορείς να φτιάξεις visuals που τα γραφικά θα είναι τα ίδια για ένα Α εύρος τιμών. Έτσι μπορείς να κάνεις "smoothing" ευκολότερα.
Επίσης αν πρόσεξες σε κάποια από τα textzones που σου έδωσα παραπάνω κάναμε smoothing απλά κόβοντας το δεκαδικό μέρος...
Δεν βαριέμαι να σου εξηγήσω τι έχω κάνει σε κάθε textzone αλλά προτιμώ πρώτα να τα μελετήσεις μόνος σου και μετά αν έχεις απορίες να σου τις λύσω. Έτσι θα μάθεις καλύτερα!
Υ.Γ.:
Κάνε copy/paste τα definitions από εδώ σε ένα απλό text editor όπως το Notepad++
MHN χρησιμοποιήσεις σε καμία περίπτωση επεξεργαστή κειμένου όπως το Word που θα κρατήσει και το HTML formatting του Forum
Επίσης μην προσπαθήσεις να πληκτρολογήσεις τις εντολές χωρίς να τις κάνεις copy/paste. Το πιθανότερο είναι να σου ξεφύγει κάποια υποδιαστολή (') κάποια εισαγωγικά (") ή κάποια ανάποδη υποδιαστολή (`)
<define class="txt_Battery">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_battery"/>
<tooltip>Battery Level: `get_battery`</tooltip>
</define>
<define class="txt_Battery2">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_text 'Battery: `get_battery`'"/>
<tooltip>Battery Level: `get_battery`</tooltip>
</define>
<define class="txt_CPU">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_cpu"/>
</define>
<define class="txt_CPU2">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_cpu & param_cast 'percentage'"/>
</define>
<define class="txt_CPU3">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="#bebebe" align="center" weight="bold" scroll="no" action="get_text 'CPU: `get_cpu & param_cast percentage & param_cast int_trunc`%'"/>
</define>
<define class="txt_CPU4">
<pos x="+145" y="+0"/>
<size width="85" height="36"/>
<text size="26" color="`param_bigger 0.75 get_cpu ? color 'red' : param_bigger 0.5 get_cpu ? color 'yellow' : param_bigger 0.25 get_cpu ? color 'cyan' : color 'green'`" align="center" weight="bold" scroll="no" action="get_text 'CPU: `get_cpu & param_cast percentage & param_cast int_trunc`%'"/>
</define>
Γενικά το "delay" όπως το έχεις στο μυαλό σου ξέχνα το. Σε ένα skin ΔΕΝ θες delay εκτός από ελάχιστες περιπτώσεις. Στο μέλλον ίσως προστεθεί κάτι αλλά γενικά μην υπολογίζεις σε "delay"
Αντίθετα μπορείς να φτιάξεις visuals που τα γραφικά θα είναι τα ίδια για ένα Α εύρος τιμών. Έτσι μπορείς να κάνεις "smoothing" ευκολότερα.
Επίσης αν πρόσεξες σε κάποια από τα textzones που σου έδωσα παραπάνω κάναμε smoothing απλά κόβοντας το δεκαδικό μέρος...
Δεν βαριέμαι να σου εξηγήσω τι έχω κάνει σε κάθε textzone αλλά προτιμώ πρώτα να τα μελετήσεις μόνος σου και μετά αν έχεις απορίες να σου τις λύσω. Έτσι θα μάθεις καλύτερα!
Υ.Γ.:
Κάνε copy/paste τα definitions από εδώ σε ένα απλό text editor όπως το Notepad++
MHN χρησιμοποιήσεις σε καμία περίπτωση επεξεργαστή κειμένου όπως το Word που θα κρατήσει και το HTML formatting του Forum
Επίσης μην προσπαθήσεις να πληκτρολογήσεις τις εντολές χωρίς να τις κάνεις copy/paste. Το πιθανότερο είναι να σου ξεφύγει κάποια υποδιαστολή (') κάποια εισαγωγικά (") ή κάποια ανάποδη υποδιαστολή (`)
Mensajes Tue 13 Feb 18 @ 4:59 pm
Theios Giorgos
PhantomDeejay wrote :
Αυτό, εμφανίστηκε μια χαρά! Εγώ στην εντολή δεν είχα προσθέσει ανάποδες αποστρόφους, οπότε και δεν εμφάνιζε τίποτε......action="get_text 'Battery: `get_battery`'"/>
PhantomDeejay wrote :
Αυτό μου κάνει, αν και το συνέταξα: color="`param_bigger 0.75 get_cpu ? color 'red' : param_bigger 0.5 get_cpu ? color 'yellow' : param_bigger 0.25 get_cpu ? color 'cyan' : color 'green'`" align="center" weight="bold" scroll="no" format="CPU: %cpu%"/>, κοινώς χρησιμοποιώντας την εντολή format αντί για action. Μήπως θα πρέπει να την αποφεύγω (χρησιμοποιώντας την action), όμως, όπου μπορώ?color="`param_bigger 0.75 get_cpu ? color 'red' : param_bigger 0.5 get_cpu ? color 'yellow' : param_bigger 0.25 get_cpu ? color 'cyan' : color 'green'`" align="center" weight="bold" scroll="no" action="get_text 'CPU: `get_cpu & param_cast percentage & param_cast int_trunc`%'"/>
PhantomDeejay wrote :
Συμφωνώ σε αυτό που λες. Απλά, θέλω να δοκιμάσω κάτι "διαφορετικό"... Γενικά το "delay" όπως το έχεις στο μυαλό σου ξέχνα το. Σε ένα skin ΔΕΝ θες delay εκτός από ελάχιστες περιπτώσεις. Στο μέλλον ίσως προστεθεί κάτι αλλά γενικά μην υπολογίζεις σε "delay". Αντίθετα μπορείς να φτιάξεις visuals που τα γραφικά θα είναι τα ίδια για ένα Α εύρος τιμών. Έτσι μπορείς να κάνεις "smoothing" ευκολότερα. Επίσης αν πρόσεξες σε κάποια από τα textzones που σου έδωσα παραπάνω κάναμε smoothing απλά κόβοντας το δεκαδικό μέρος...
PhantomDeejay wrote :
Δεν το συζητώ! Ήδη βοηθάς πολύ, χωρίς να είσαι υποχρεωμένος και σε ευχαριστώ πολύ γι αυτό! Απλά, μάλλον, έχω ξεκινήσει ανάποδα. Κοινώς έχω την ιδέα και ψάχνω τον κώδικα να την υλοποιήσω, ενώ θα έπρεπε (λογικά) πρώτα να μάθω καλά τον κώδικα και μετά να αρχίσω τα ακροβατικά...Δεν βαριέμαι να σου εξηγήσω τι έχω κάνει σε κάθε textzone αλλά προτιμώ πρώτα να τα μελετήσεις μόνος σου και μετά αν έχεις απορίες να σου τις λύσω. Έτσι θα μάθεις καλύτερα!
Mensajes Tue 13 Feb 18 @ 7:35 pm
PhantomDeejay
Θεωρητικά το format="%cpu" θεωρείται "ξεπερασμένο" (deprecated) και μπορεί ανά πάσα στιγμή να καταργηθεί ή να εμφανίσει προβλήματα συμβατότητας σε μελλοντικές εκδόσεις. Όχι η χρήση του format="Some Nice Text", αλλά η χρήση των % special textzone commands
Αυτό τουλάχιστον θεωρητικά...
Πρακτικά τώρα μιας και τώρα μαθαίνεις να προγραμματίζεις skin καλό θα είναι να μάθεις να προγραμματίζεις με τον "νέο" πιο σωστό και αποδοτικό τρόπο από την αρχή.
Έτσι λοιπόν η συμβουλή μου είναι να αποφύγεις τα %textzones και να χρησιμοποίεις format='Some Text' για στατικό κείμενο και action='get_something_via_script' για δυναμικό κείμενο (κείμενο που αλλάζει είτε από μόνο του, είτε ανάλογα με κάποιες συνθήκες)
Τέλος ένα hint:
Ο καλύτερος τρόπος να μάθεις να κάνεις skin είναι να κοιτάς και να "κλέβεις" (δανείζεσαι) κομμάτια κώδικα ενός άλλου skin. Έτσι θα μπεις στο νόημα αρκετά πιο γρήγορα απ' το αν προσπαθείς να κάνεις παρθενογένεση... Όπως και στον προγραμματισμό, χωρίς παραδείγματα (έτοιμα κομμάτια κώδικα) η κατανόηση εννοιών και λειτουργιών είναι αρκετά πιο δύσκολη.
Αυτό τουλάχιστον θεωρητικά...
Πρακτικά τώρα μιας και τώρα μαθαίνεις να προγραμματίζεις skin καλό θα είναι να μάθεις να προγραμματίζεις με τον "νέο" πιο σωστό και αποδοτικό τρόπο από την αρχή.
Έτσι λοιπόν η συμβουλή μου είναι να αποφύγεις τα %textzones και να χρησιμοποίεις format='Some Text' για στατικό κείμενο και action='get_something_via_script' για δυναμικό κείμενο (κείμενο που αλλάζει είτε από μόνο του, είτε ανάλογα με κάποιες συνθήκες)
Τέλος ένα hint:
Ο καλύτερος τρόπος να μάθεις να κάνεις skin είναι να κοιτάς και να "κλέβεις" (δανείζεσαι) κομμάτια κώδικα ενός άλλου skin. Έτσι θα μπεις στο νόημα αρκετά πιο γρήγορα απ' το αν προσπαθείς να κάνεις παρθενογένεση... Όπως και στον προγραμματισμό, χωρίς παραδείγματα (έτοιμα κομμάτια κώδικα) η κατανόηση εννοιών και λειτουργιών είναι αρκετά πιο δύσκολη.
Mensajes Tue 13 Feb 18 @ 9:00 pm
Theios Giorgos
Έχω προχωρήσει με τον κώδικα (xml) αρκετά, χωρίς να έχω κρατήσει backup τις τελευταίες 2 ημέρες και συμβαίνει το απίστευτο:
Μόλις πληκτρολογώ μία συγκεκριμένη γραμματοσειρά, παρουσιάζει σφάλμα το Notepad++, κατόπιν κλείνει και όταν πλέον ξανα-ανοίγω την εφαρμογή, το αρχείο xml παρουσιάζεται “μηδενικού μεγέθους” (0 bytes) και φυσικά άνευ περιεχομένου!!! Χώρια που οι “Προηγούμενες Εκδόσεις” είναι απενεργοποιημένες και τελικά μάλλον χάθηκε όλη η δουλειά 2 ημερών…
Καμιά ιδέα του γιατί συνέβη αυτό και εάν υπάρχει περίπτωση επανάκτησης? Phantom? Dad?
Μόλις πληκτρολογώ μία συγκεκριμένη γραμματοσειρά, παρουσιάζει σφάλμα το Notepad++, κατόπιν κλείνει και όταν πλέον ξανα-ανοίγω την εφαρμογή, το αρχείο xml παρουσιάζεται “μηδενικού μεγέθους” (0 bytes) και φυσικά άνευ περιεχομένου!!! Χώρια που οι “Προηγούμενες Εκδόσεις” είναι απενεργοποιημένες και τελικά μάλλον χάθηκε όλη η δουλειά 2 ημερών…
Καμιά ιδέα του γιατί συνέβη αυτό και εάν υπάρχει περίπτωση επανάκτησης? Phantom? Dad?
Mensajes Thu 15 Feb 18 @ 10:31 am
PhantomDeejay
Κοίτα εδώ μήπως υπάρχει τίποτα:
C:\Users\YourUserName\AppData\Roaming\Notepad++\backup
C:\Users\YourUserName\AppData\Roaming\Notepad++\backup
Mensajes Thu 15 Feb 18 @ 12:04 pm
Theios Giorgos
Γιώργο…
Δυστυχώς στην θέση που ανέφερες, το αρχείο υπήρχε μεν, αλλά “κατεστραμμένο” δε. Συνεπώς, το ξεκίνησα απ’ την αρχή…
Κάποιες παρατηρήσεις – ερωτήσεις, για όταν έχεις το χρόνο…
1. Παρατηρώ στην λίστα με τα VDJScripts ότι κάποια από αυτά (και ιδίως scripts της μορφής get_...) είναι “deprecated”. Πλην, όμως, δεν βρίσκω αντίστοιχα, πέραν της μορφής %....
Η απορία μου είναι, πώς θεωρούνται “ξεπερασμένα” από την στιγμή κατά την οποία δεν υφίστανται αντικατάστατα (π.χ. η εντολή get_artist)?
Επίσης, σε άλλα scripts δεν υφίσταται καν get_... παρά μόνον %... Μήπως είμαστε τελικά σε “μεταβατική περίοδο”?
2. Προσπάθησα να ενσωματώσω font ανά group και μου βγάζει σφάλμα. Είδα κάποια παραδείγματα, στα οποία αναφέρονταν μόνο οι συντεταγμένες ως κοινές. Η γραμματοσειρά ή το μέγεθος ή το χρώμα αυτής, δεν μπορούν να είναι κοινά ανά group? Εάν ναι, ποια είναι η σύνταξη?
3. Έστω ότι έχουμε το text CPU: 50%. Για να μπορέσω να έχω την λέξη CPU με ένα σταθερό χρώμα και την τιμή με μεταβλητό χρώμα (αναλόγως την τιμής), χρειάστηκε να γράψω 2 definitions μεν (απλό), αλλά με τις συντεταγμένες παιδεύτηκα δε.
Το ερώτημα είναι εάν μπορούμε να έχουμε το άνωθεν αποτέλεσμα σε 1 define, ώστε ο ορισμός των συντεταγμένων να είναι πολύ πιο απλός?
Δυστυχώς στην θέση που ανέφερες, το αρχείο υπήρχε μεν, αλλά “κατεστραμμένο” δε. Συνεπώς, το ξεκίνησα απ’ την αρχή…
Κάποιες παρατηρήσεις – ερωτήσεις, για όταν έχεις το χρόνο…
1. Παρατηρώ στην λίστα με τα VDJScripts ότι κάποια από αυτά (και ιδίως scripts της μορφής get_...) είναι “deprecated”. Πλην, όμως, δεν βρίσκω αντίστοιχα, πέραν της μορφής %....
Η απορία μου είναι, πώς θεωρούνται “ξεπερασμένα” από την στιγμή κατά την οποία δεν υφίστανται αντικατάστατα (π.χ. η εντολή get_artist)?
Επίσης, σε άλλα scripts δεν υφίσταται καν get_... παρά μόνον %... Μήπως είμαστε τελικά σε “μεταβατική περίοδο”?
2. Προσπάθησα να ενσωματώσω font ανά group και μου βγάζει σφάλμα. Είδα κάποια παραδείγματα, στα οποία αναφέρονταν μόνο οι συντεταγμένες ως κοινές. Η γραμματοσειρά ή το μέγεθος ή το χρώμα αυτής, δεν μπορούν να είναι κοινά ανά group? Εάν ναι, ποια είναι η σύνταξη?
3. Έστω ότι έχουμε το text CPU: 50%. Για να μπορέσω να έχω την λέξη CPU με ένα σταθερό χρώμα και την τιμή με μεταβλητό χρώμα (αναλόγως την τιμής), χρειάστηκε να γράψω 2 definitions μεν (απλό), αλλά με τις συντεταγμένες παιδεύτηκα δε.
Το ερώτημα είναι εάν μπορούμε να έχουμε το άνωθεν αποτέλεσμα σε 1 define, ώστε ο ορισμός των συντεταγμένων να είναι πολύ πιο απλός?
Mensajes Fri 16 Feb 18 @ 12:14 pm
PhantomDeejay
1) Συνήθως όσες εντολές get βλέπεις σαν deprecated δουλεύουν και θα δουλεύουν για πολύ καιρό ακόμα. Αυτό που μπορεί να καταργηθεί πιο γρήγορα στο μέλλον είναι το %specialtext
Βλέπεις deprecated όσα get έχουν αντικατασταθεί από άλλη εντολή. Για παράδειγμα η get_artist έχει αντικατασταθεί από την get_loaded_song 'artist' Το ίδιο ισχύει και για άλλες παρόμοιες εντολές όπως get_year, get_genre κτλ (είναι πλέον όλες μία εντολή get_loaded_song 'attribute')
2) Μπορείς να το εξηγήσεις καλύτερα τι εννοείς; Γενικά ένα <define font=""/> είναι για όλο το skin, κι όχι μόνο για το group/panel κτλ μέσα στο οποίο το βάζεις.
3) Όχι. Αλλά για να μην παιδεύεσαι με τις συντεταγμένες μάθε να χρησιμοποιείς σχετικές συντεταγμένες και μαθηματικά στις ίδιες τις συντεταγμένες.
π.χ:
<textzone class=cpuLabel>
<pos x="50" y="15"/>
<size width="100" height="20"/>
</textzone>
<textzone class=cpuPercent>
<pos x="50+100" y="15"/>
<size width="90" height="20"/>
</textzone>
Και ακόμα πιο όμορφα:
<panel id="CpuMeter">
<pos x="50" y="15"/>
<textzone class=cpuLabel>
<pos x="+0" y="+0"/>
<size width="100" height="20"/>
</textzone>
<textzone class=cpuPercent>
<pos x="+100" y="+0"/>
<size width="90" height="20"/>
</textzone>
</panel>
Στην τελευταία περίπτωση αλλάζοντας τις συντεταγμένες του panel αλλάζεις ταυτόχρονα την θέση και των δύο textzones ;)
Βλέπεις deprecated όσα get έχουν αντικατασταθεί από άλλη εντολή. Για παράδειγμα η get_artist έχει αντικατασταθεί από την get_loaded_song 'artist' Το ίδιο ισχύει και για άλλες παρόμοιες εντολές όπως get_year, get_genre κτλ (είναι πλέον όλες μία εντολή get_loaded_song 'attribute')
2) Μπορείς να το εξηγήσεις καλύτερα τι εννοείς; Γενικά ένα <define font=""/> είναι για όλο το skin, κι όχι μόνο για το group/panel κτλ μέσα στο οποίο το βάζεις.
3) Όχι. Αλλά για να μην παιδεύεσαι με τις συντεταγμένες μάθε να χρησιμοποιείς σχετικές συντεταγμένες και μαθηματικά στις ίδιες τις συντεταγμένες.
π.χ:
<textzone class=cpuLabel>
<pos x="50" y="15"/>
<size width="100" height="20"/>
</textzone>
<textzone class=cpuPercent>
<pos x="50+100" y="15"/>
<size width="90" height="20"/>
</textzone>
Και ακόμα πιο όμορφα:
<panel id="CpuMeter">
<pos x="50" y="15"/>
<textzone class=cpuLabel>
<pos x="+0" y="+0"/>
<size width="100" height="20"/>
</textzone>
<textzone class=cpuPercent>
<pos x="+100" y="+0"/>
<size width="90" height="20"/>
</textzone>
</panel>
Στην τελευταία περίπτωση αλλάζοντας τις συντεταγμένες του panel αλλάζεις ταυτόχρονα την θέση και των δύο textzones ;)
Mensajes Fri 16 Feb 18 @ 12:38 pm
Theios Giorgos
PhantomDeejay wrote :
Ok, οπότε εφαρμόζω αυτή την σύνταξη από δω και πέρα...1) ...Για παράδειγμα η get_artist έχει αντικατασταθεί από την get_loaded_song 'artist' Το ίδιο ισχύει και για άλλες παρόμοιες εντολές όπως get_year, get_genre κτλ (είναι πλέον όλες μία εντολή get_loaded_song 'attribute')...
PhantomDeejay wrote :
Το "γενικό" έγινε κατανοητό. Απλά, καταργώντας το γενικό και προσπαθώντας να ορίσω font ανά group (π.χ. άλλη γραμματοσειρά σε "Top Bar" και άλλη σε "Deck"), έβγαζε σφάλμα... 2) Μπορείς να το εξηγήσεις καλύτερα τι εννοείς; Γενικά ένα <define font=""/> είναι για όλο το skin, κι όχι μόνο για το group/panel κτλ μέσα στο οποίο το βάζεις.
PhantomDeejay wrote :
Αυτό κάνω, προς το παρόν σε groups, καθότι panels δεν έχω δημιουργήσει ακόμα...3) Όχι. Αλλά για να μην παιδεύεσαι με τις συντεταγμένες μάθε να χρησιμοποιείς σχετικές συντεταγμένες και μαθηματικά στις ίδιες τις συντεταγμένες.
Λύσε μου και αυτή την απορία: Το panel το χρησιμοποιούμε στις περιπτώσεις ενός π.χ. extra "παραθύρου" (με buttons, κ.τ.λ.) ή στην περίπτωση skin όπου υπάρχει η δυνατότητα τροποποίησης εμφάνισης (όπως τα δικά σου skins). Είναι οπουδήποτε αλλού χρήσιμη η εφαρμογή του? Εάν δεν υφίσταται στο skin κάποια από τις 2 άνωθεν περιπτώσεις, "χρειάζεται" πουθενά αλλού η εντολή panel?
Mensajes Fri 16 Feb 18 @ 1:21 pm
PhantomDeejay
Τα panels χρησιμοποιούνται για πολλούς λόγους. Όχι, το να δείξεις ένα έξτρα παράθυρο δεν απαιτεί απαραίτητα panel
Ο συνηθέστερος λόγος που χρησιμοποιούμε panels είναι για να ομαδοποιήσουμε στοιχεία. Το ίδιο κάνει και το group (σε πρόλαβα) αλλά το group δεν δέχεται background graphics.
Άλλοι λόγοι είναι η ομαδοποίηση στοιχείων που εμφανίζονται υπό όρους (π.χ στοιχεία που είναι ορατά μόνο όταν μια loop είναι ενεργή) καθώς και όταν θέλουμε όπως πολύ σωστά ανέφερες να αλλάζουμε τα στοιχεία που κρατάει μια περιοχή.
Ο συνηθέστερος λόγος που χρησιμοποιούμε panels είναι για να ομαδοποιήσουμε στοιχεία. Το ίδιο κάνει και το group (σε πρόλαβα) αλλά το group δεν δέχεται background graphics.
Άλλοι λόγοι είναι η ομαδοποίηση στοιχείων που εμφανίζονται υπό όρους (π.χ στοιχεία που είναι ορατά μόνο όταν μια loop είναι ενεργή) καθώς και όταν θέλουμε όπως πολύ σωστά ανέφερες να αλλάζουμε τα στοιχεία που κρατάει μια περιοχή.
Mensajes Fri 16 Feb 18 @ 1:50 pm
Theios Giorgos
Απόλυτα κατανοητό. Και εδώ κολλάει η "καλή" ερώτηση...
Έστω ότι επιθυμούμε να σχεδιάσουμε ένα skin, το οποίο να διαθέτει Night και Day mode. Θεωρητικά, ο κώδικας μπορεί να είνα γραμμένος με αρκετούς τρόπους, όπως:
Α. Αρχικά κώδικας με όλα τα απολύτως "κοινά" στοιχεία των 2 modes (π.χ. texts, commands, scripts, font, sizes, aligns, positions, e.t.c). Κατόπιν 2 panels, όπου το καθένα θα περιέχει μόνο διαφορετικά γραφικά και texts colors.
B. 2 διαφορετικά panels, με ολόκληρο κώδικα το καθένα (και ας είναι πολλά στοιχεία κοινά).
C. 1 κώδικας με αρκετά var_equal και 2 panels (απλά για το διαφορετικό background μόνο)...
Πρακτικά, τι είναι το "καλύτερο" και γιατί? Θεωρώ πως θα μου απαντήσεις για την C περίπτωση, αλλά λύσε μου και την απορία για την A... :-)
Έστω ότι επιθυμούμε να σχεδιάσουμε ένα skin, το οποίο να διαθέτει Night και Day mode. Θεωρητικά, ο κώδικας μπορεί να είνα γραμμένος με αρκετούς τρόπους, όπως:
Α. Αρχικά κώδικας με όλα τα απολύτως "κοινά" στοιχεία των 2 modes (π.χ. texts, commands, scripts, font, sizes, aligns, positions, e.t.c). Κατόπιν 2 panels, όπου το καθένα θα περιέχει μόνο διαφορετικά γραφικά και texts colors.
B. 2 διαφορετικά panels, με ολόκληρο κώδικα το καθένα (και ας είναι πολλά στοιχεία κοινά).
C. 1 κώδικας με αρκετά var_equal και 2 panels (απλά για το διαφορετικό background μόνο)...
Πρακτικά, τι είναι το "καλύτερο" και γιατί? Θεωρώ πως θα μου απαντήσεις για την C περίπτωση, αλλά λύσε μου και την απορία για την A... :-)
Mensajes Fri 16 Feb 18 @ 4:03 pm
djdad
Εγώ ψηφίζω την επιλογή D !
Eίμαι της άποψης ότι όταν κάποια πληροφορία, εμφάνιση κλπ, μπορεί να χρησιμοποιηθεί-προβληθεί πολλές φορές κατά τη χρήση του σκιν, τότε αυτά πρέπει να μπαίνουν σε panels στο ίδιο skin.
Αν όμως πρόκειται για μια αλλαγή προβολής που μπορεί να κάνεις μόνο ίσως στην αρχή της χρήσης του ή έστω μια φορά μέσα σε μία χρήση, τότε καλό είναι να δημιουργήσεις ξεχωριστά skins αντί για panels
Για το day/night εκεί αλλάζουν πολλά πράγματα (σε γραφικά και κώδικα), προσωπικά θα το έκανα σε ξεχωριστά skins.
Eίμαι της άποψης ότι όταν κάποια πληροφορία, εμφάνιση κλπ, μπορεί να χρησιμοποιηθεί-προβληθεί πολλές φορές κατά τη χρήση του σκιν, τότε αυτά πρέπει να μπαίνουν σε panels στο ίδιο skin.
Αν όμως πρόκειται για μια αλλαγή προβολής που μπορεί να κάνεις μόνο ίσως στην αρχή της χρήσης του ή έστω μια φορά μέσα σε μία χρήση, τότε καλό είναι να δημιουργήσεις ξεχωριστά skins αντί για panels
Για το day/night εκεί αλλάζουν πολλά πράγματα (σε γραφικά και κώδικα), προσωπικά θα το έκανα σε ξεχωριστά skins.
Mensajes Sun 25 Feb 18 @ 11:54 pm
Theios Giorgos
djdad wrote :
Από αυτά που έχω δει - μελετήσει έως τώρα, το προσωπικό μου συμπέρασμα ήταν ότι η χρήση της εντολής panel χρησιμοποιείται μόνον όταν επιθυμούμε και την διαφοροποίηση του background. Ειδάλλως, χρήση της εντολής group είναι υπερ-αρκετή. Κάνω κάπου λάθος? Εάν ναι, μπορείς να μου το αποσαφηνίσεις? Eίμαι της άποψης ότι όταν κάποια πληροφορία, εμφάνιση κλπ, μπορεί να χρησιμοποιηθεί-προβληθεί πολλές φορές κατά τη χρήση του σκιν, τότε αυτά πρέπει να μπαίνουν σε panels στο ίδιο skin.
djdad wrote :
Η προτίμησή σου οφείλετε στο ότι σε κάθε εντολή θα πρέπει να συμπεριλαμβάνεται επιπλέον κώδικας, με ότι αυτό συνεπάγεται σε χρόνο και πολυπλοκότητα ή κάπου αλλού?
Αν όμως πρόκειται για μια αλλαγή προβολής που μπορεί να κάνεις μόνο ίσως στην αρχή της χρήσης του ή έστω μια φορά μέσα σε μία χρήση, τότε καλό είναι να δημιουργήσεις ξεχωριστά skins αντί για panels. Για το day/night εκεί αλλάζουν πολλά πράγματα (σε γραφικά και κώδικα), προσωπικά θα το έκανα σε ξεχωριστά skins.
Mensajes Mon 26 Feb 18 @ 11:49 am
