Προσφατα ειδα ενα αρθρο σχετικα με το Crow-Translate που μου κεντρισε την περιεργεια. Μπηκα μεσα στο αποθετηριο τους στο Github και κατεβασα το deb πακετο. Η εγκατασταση στο Debian 10.7 εγινε χωρις να υπαρχει προβλημα με τις εξαρτησεις αλλα καθως πηγα να το τρεξω… δεν ειδα καποιο παραθυρο να ανοιγει… ουτε κατι αλλο να τρεχει.
Μιας και μου μπηκαν ψυλλοι στ’αυτια… ανοιγω τερματικο και τρεχω:
/usr/bin/crow
και βλεπω τα εξης:
!strcmp(locale, "C"):Error:Assert failed:in file baseapi.cpp, line 209
Segmentation fault
Με τις ταπεινες μου γνωσεις αυτο που καταλαβαινω ειναι οτι κατι παιζει με τα locales… και μετα απο ψαξιμο βρηκα οτι για να τρεξει περιμενει η μεταβλητη του συστηματος LC_ALL να εχει την τιμη C, δηλαδη
LC_ALL=C
εαν λοιπον τρεξουμε το προγραμμα με την μεταβλητη μπροστα να εχει την συγκεκριμενη τιμη, δηλαδη
LC_ALL=C /usr/bin/crow
τοτε το προγραμμα θα εκτελεστει κανονικα.
Για να μπορεσουμε λοιπον να το τρεξουμε κανονικα και απο την συντομευση του στο μενου πρεπει να αλλαξουμε το αρχειο:
Και αφου σωσουμε τις αλλαγες μας να δοκιμασουμε απο την συντομευση του menou μας για να δουμε αν οντως δουλευει.
Βεβαια ολα τα παραπανω δεν συμβαινουν σε ολα τα συστηματα και σε ολες τις διανομες και ισως να μην συμβαινει και στο Debian κανονικα παρα μονο στον δικο μου υπολογιστη… αλλα αν ψυλιαστειτε οπως εγω οτι κατι δεν παει καλα με το Crow-Translate ακριβως μετα την εγκατασταση του πακετου τοτε τουτο εδω το μικρο αρθρακι να σας βοηθησει να το κανετε να τρεξει.
Για τα τυπικά και για να μην υπάρξει σύγχυση μελλοντικά, το Crow Translate δεν εμφανίζει κάποιο παράθυρο αρχικά (πρακτικά δε χρειάζεται αν χρησιμοποιούμε τις συντομεύσεις του πληκτρολογίου) παρά μόνο ένα εικονίδιο στο system tray.
Επίσης, αποφεύγουμε να πειράζουμε αρχεία του συστήματος. Για την αλλαγή που αναφέρεις, είναι προτιμότερο να αντιγράψουμε το αρχείο στον φάκελο $HOME/.local/share/applications και να προσαρμόσουμε αυτό.
Αν δεν απατωμαι (και μπορει να ειμαι και πολυ λαθος οποτε αν θες διορθωσε με) νομιζω οτι βγαζει ενα παραθυρο στην αρχη για να ορισει με τι γλωσσες θα δουλεψουμε μαζι με το εικονιδιο στο System tray.
Ναι εαν θελουμε οι αλλαγες να ειναι μονο μεμονομενες στον χρηστη που το τρεχει. Αν ομως υπαρχουν και αλλοι χρησες στο συστημα το ιδιο αρχειο θα πρεπει να αντιγραφει τοσες φορες οσοι οι χρηστες στο συστημα.
Update #1:
Φιλε @anon54176929 δεν θα συμφωνησω. Δεν ειναι αρχειο του /etc/ για να πω οτι ειναι αρχειο του συστηματος. Ειναι απλα αρχειο του πακετου σε προστατευμενη περιοχη.
@Asfodelus, νομιζω οτι ειναι hardwired στον κωδικα για καποιο λογο. Ισως αν ανοιξω καποιο bug να το διορθωσουν.
Μάλλον είναι επιλεγμένη ρύθμιση από τη διανομή σου. Από προεπιλογή δε βγάζει παράθυρο και οι ρυθμίσεις για τις γλώσσες είναι στο αυτόματο (ανίχνευση του ξενόγλωσσου και σύμφωνα με τη γλώσσα του συστήματος, αντίστοιχα).
Υπάρχει η ασφαλής προσέγγιση και η βολική προσέγγιση. Σπάνια ταυτίζονται αυτά τα δύο. Και πάλι όμως, σε μια τέτοια περίπτωση θα γίνει η αντιγραφή μία φορά για όλους και θα παραμείνει. Δε θα πειράξουμε αρχείο συστήματος και δε θα χρειαστεί να το ξαναπειράξουμε όταν το επαναφέρει κάποια μελλοντική αναβάθμιση της εφαρμογής.
!strcmp(locale, "C"):Error:Assert failed:in file baseapi.cpp, line 209 Segmentation fault
αυτό κάνει ένα έλεγχο στο runtime να δει αν το LOCALE είναι C, Τι είναι το locale? Οι ρυθμίσεις εντοπιότητας, μεταφράσεις και πως θα εμφανίσεις ημερομηνίες και αριθμούς μεταξύ άλλων.
Προγραμματιστικά δεν μπορώ να καταλάβω την απαίτηση, μάλλον θα είναι κάποιο γρήγορο hack (οπότε κακώς δεν υπάρχει ήδη στο αρχείο desktop) και κάποια στιγμή θα το κάνουν σωστά και θα αφαιρεθεί. Τεχνικά λοιπόν – σε αυτήν την περίπτωση – είναι καλύτερο όπως το λέει ο @GNUTechie. Αν φτιαχτεί θα ενημερωθεί σε κάποια αναβάθμιση, αν και θα πρέπει να ξανακάνεις την αλλαγή κάθε φορά μέχρι να μην είναι απαραίτητο.
Δεν ξέρω αν είναι hack αλλά με μια γρήγορη αναζήτηση θα βρεις αρκετές αναφορές για το ίδιο πρόβλημα σε εφαρμογές της C++. Στην περίπτωση του Crow Translate, το σφάλμα βρίσκεται στο Tesseract που χρησιμοποιείται για το OCR και έχει ήδη διορθωθεί από την έκδοση 4.1 αυτού (η τρέχουσα είναι η 4.1.1 με ημερομηνία διάθεσης 26/12/2019), οπότε δεν υπάρχει κάτι να διορθωθεί στην εφαρμογή παρά μόνο στο πακέτο του Debian που χρησιμοποιεί παρωχημένη έκδοση.
Θα ήθελες να μου εξηγήσεις αυτό το «τεχνικά» που ανέφερες; Ποιο συγκριτικό πλεονέκτημα έχει αυτή η προσέγγιση, χωρίς δυνητικό κόστος; Εγώ δε μπορώ να σκεφτώ κανένα.
Αν θέλεις το C locale κάνεις “imbue” το iostream με το “C” locale ή αν παίζεις με C API με τον τρόπο που δείχνω στο pdf που ανέβασα στην προηγούμενη απάντηση. Κάπως έτσι (δεν το έτρεξα)
// C++ Streams
std::ios_base::sync_with_stdio(false);
std::locale c_locale{"C"};
cout.imbue(c_locale);
cin.imbue(c_locale);
// C Streams
setlocale(LC_ALL, "C");
// .. or at start of main()
std::locale::global(std::locale("C"));
και γενικά έχεις όποιο locale και όποια εντοπιότητα θες για κάθετι. Εφόσον είναι στον έλεγχο σου γιατί να κάνεις assert;
Οπότε δεν υπάρχει λόγος να το θέσεις εξωτερικά. Το μόνο πρόβλημα είναι πως το imbue δεν υπάρχει στα περισσότερα βιβλία και δεν είναι γνωστό, όπως γενικά δεν είναι τα locale στους περισσότερους προγραμματιστές. Στο pdf λέω κάποια πραγματάκια , αν και δεν μπήκα ούτε βαθιά, ούτε στην C++. Αυτά τα βαριά τεχνικά.
Χωρίς να έχω δει τον κώδικα, τα παραπάνω αρκούν πιστεύω για να κάνει κάποιος ένα pull request και να λυθεί το πρόβλημα. Αν τώρα λυθεί και έχεις κάνει αλλαγή στο $HOME δεν θα ωφεληθείς, πιθανά μια επόμενη έκδοση να έχει μεταφραστεί στα ελληνικά, πιθανά να κάνει χρήση του ελληνικού locale για μορφοποίηση αριθμών (είναι μια εφαρμογή που έχει ίσως νόημα). Αυτά τα λίγα για τα επι του πρακτέου διαδικαστικά.
Έχει λυθεί το πρόβλημα στην έκδοση 4.1 του Tesseract (το επιβεβαιώνω γιατί αυτήν έχω και δεν το συνάντησα καν και εδώ είναι ένα σχετικό commit που βρήκα.
Η απαίτηση για το C locale εισήχθη εξαιτίας προβλημάτων που αναφέρθηκαν σε non-english locales (τονίζω ότι μιλάμε για τη λειτουργία OCR, όχι για τη διεπαφή ή οτιδήποτε άλλο αφορά το Crow Translate, άρα δεν έχει σχέση η μετάφραση της διεπαφής) και πλέον παραμένει μόνο για το debugging (λογικό, γιατί ένα μήνυμα σφάλματος στα Αραβικά π.χ. είναι άχρηστο για τον προγραμματιστή).
Αποδέχομαι τη διαφωνία σου αλλά είναι θέμα νοοτροπίας και ορθής πρακτικής. Ναι, ένας έμπειρος χρήστης μπορεί να γνωρίζει πότε μπορεί να κάνει κάτι και πότε όχι. Ο άπειρος όμως που θα δει το «προσαρμόστε το τάδε αρχείο στο /usr» δε μπορεί να αντιληφθεί τη διαφορά και πιθανότατα στο μέλλον θα κάνει το ίδιο με άλλα αρχεία. Και κάπως έτσι αρχίζουν τα προβλήματα. Ακριβώς γι’ αυτό υπάρχουν οι αντιστοιχίες στο $HOME/.local/share. Η προσαρμογή οποιουδήποτε αρχείου εκτός του $HOME πρέπει να είναι πάντα η τελευταία λύση, όχι να αναφέρεται άκριτα.
Επετρεψε μου ξανα να μην συμφωνησω με αυτο το χαρακτηρισμο καθως δεν συνηθηζω να προτεινω πραγματα… ακριτα. Αυτο που προτεινω ειναι κατι που παρατηρησα στην διανομη που χρησιμοποιω και ειναι ενα workaround μεχρι οι προγραμματιστες του Crow-Translate να το σημαζεψουν. Δεν ειναι γενικη κατευθυνση. Με την εκδοση που εχω και τις εξαρτησεις στις εκδοσεις που η διανομη μου διαθετει βγαζει αυτο το λαθος. Βρηκα λυση και την παραθετω
Οπως επισεις οτι δεν υπαρχει παντα αντιστοιχη τοποθεσια στο $ΗΟΜΕ για ολα τα αρχεια το συστηματος οπως πχ το /etc/hosts το /etc/resolv.conf κλπ κλπ.
Εαν ο απειρος χρηστης θελει να κανει την αλλαγη που προτεινα υπαρχει το mozo για το MATE το alacarte για το GNOME οπως και το arronax που στον απειρο χρηστη επιτρεπουν να κανουν την εν λογω αλλαγη.
Και οντως η λυση που αναφερεις με το $HOME/.local/share/applications ειναι οντως καλη και σε μερικες περιπτωσεις καλυτερη απο αυτη που προτεινα. Αλλα πιστευω θα πρεπει να δουμε αν οντως ο χρηστης που θελει να κανει τετοιες αλλαγες θελει να τις κανει στο $HOME ή στο /usr παντα με βαση το δικο του workflow. Αρκετοι χρηστες θα θελησουν να πανε με την χρηση του $HOME/.local/share/applications και αλλοι με το /usr/share/applications.
Το «άκριτα» δεν πήγαινε σε εσένα προσωπικά αλλά είναι γενικότερη διαπίστωση γιατί έχω συναντήσει πάμπολλες παρόμοιες «συμβουλές».
Δύο φορές το έγραψα, θα το γράψω και τρίτη: το πρόβλημα δεν είναι στο Crow Translate αλλά στο Tesseract και έχει ήδη διορθωθεί εδώ και δύο χρόνια. Στη δική σου περίπτωση, χρησιμοποιείς Debian που έχει παρωχημένη έκδοση του Tesseract. Οπότε το ουσιαστικό πρόβλημα είναι η πολιτική του Debian.
Γιατί κάποια δεν πρέπει να τα πειράζουμε ποτέ. Και εκεί όμως υπάρχει παρόμοια λογική. Π.χ. το systemd έχει αρχεία στο /usr/lib. Αυτά δεν τα πειράζουμε αλλά τα αντιγράφουμε στο /etc και κάνουμε προσαρμογές εκεί. Δεν είναι θέμα workflow αλλά νοοτροπίας, το ξαναλέω. Το Linux μας επιτρέπει να κάνουμε πολλά πράγματα, αυτό όμως δε σημαίνει και ότι πρέπει να τα κάνουμε. Για να ευθυμήσουμε λίγο, παραθέτω μια φράση που ισχύει στο έπακρο και για το Linux:
It is not UNIX’s job to stop you from shooting your foot. If you so choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows.
Εδω θα μου επιτρεψεις να σου επισυμανω λαθος. Και η 4.1.1 εκδοση του tesseract ειναι ηδη μεσα στο testing αλλα δεν θα χαλασω το stable για ενα πακετο που εχει παλια εκδοση μονο και μονο για να τρεξω ενα προγραμμα.
Παντως ειναι περιεργο που σε ενα προγραμμα σαν το Crow-Translate θα βγει αυτο το προβλημα αλλα στο gimagereader που στην ουσια εχει το ιδιο dependency στην ιδια βιβλιοθηκη την libtesseract4 δεν θα το βγαλει στην stable εκδοση του Debian 10.7. Γιαυτο δεν νομιζω οτι εναι κατι στο libtesseract4 (και μπορει να ειμαι και λαθος) αλλα μαλλον στο Crow-Translate. Δεν γινεται στο crow να κανει segfault στην libtesseract4 οπως βγαζει το dmesg μου παρακατω:
και στο gimagereader να μην βγαλει κατι αν οντως ειναι bug του tesseract. Κατι αλλο παιζει στο Crow φιλε @anon54176929 και αυτο λεει η δικια μου μικρη εμπειρια στον προγραμματισμο. Δεν ειναι θεμα της διανομης ουτε της πολιτικης της ιδιως οταν το ιδιο το προγραμμα εχει σαν dependency το Tesseract 4.0+ (δες το στο github τους).
Οσο για το θεμα της νοοτροπιας δεν θα διαφωνησω εντελως αλλα δεν θα συμφωνησω και εντελως. Οπως λενε και οι αγγλοφωνοι φιλοι μας… “There’s more than one way to skin a cat” οποτε και ο δικος σου τροπος ειναι σωστος και ο δικος μου.
Αν θελουμε ο χρηστης να μην μαθει ποτε να πειραζει αρχεια του συστηματος παρα μονο τα δικα του ναι θα παω πασο.
Αλλα αν θελουμε ο χρηστης να μην πνιγεται σε μια κουταλιτσα νερο και να ψαχνεται λες και δεν υπαρχει αλλος τροπος ενω υπαρχει θα πρεπει και να του δειξουμε και τους δυο τροπους (οπως κανουμε με την συζητηση μας εδω) αλλα και να του πουμε (γνωμη μου και μπορει να ειμαι λαθος) και τι γινεται σε καθε περιπτωση και για πια περιπτωση ειναι σωστη η καθε προσεγγιση. Και αν αργοτερα θελησει να πυροβολησει τον εαυτο του στο ποδαρι του… θα το κανει… θα κλαφτει θα παιδευτει αλλα θα μαθει επισεις.
Καταρχάς, καλό είναι να μη μπλέκουμε τις ονομαστικές συμβάσεις που κάνει κάθε διανομή στα αποθετήριά της με την πραγματικότητα του λογισμικού. Η ίδια έκδοση που λες ότι βρίσκεται στο Testing του Debian διατίθεται ως σταθερή από τους προγραμματιστές. Μάλλον αυτοί που το φτιάχνουν ξέρουν καλύτερα, δε νομίζεις;
Δεύτερον, το πρόβλημα είναι όντως στο Tesseract και το είχαν και άλλες εφαρμογές που το χρησιμοποιούν ως βιβλιοθήκη. Παραπάνω έδωσα και το commit που το διορθώνει. Το ότι κάποια άλλη εφαρμογή δεν εμφανίζει το πρόβλημα μπορεί απλά να σημαίνει ότι χρησιμοποιεί με διαφορετικό τρόπο το Tesseract. Μια βιβλιοθήκη δεν είναι απαραίτητο να χρησιμοποιείται στο 100% και συνήθως έχει πολλαπλούς τρόπους υλοποίησης, σωστά;
Τρίτον, η προσωπική μου γνώμη είναι ότι ένα σύγχρονο λειτουργικό που επιθυμεί να απευθύνεται στον μέσο χρήστη, δε θα πρέπει σε καμία περίπτωση να τον φέρει σε επαφή με τα ενδότερα του συστήματος. Ας το αφήσουμε αυτό όμως. Όταν υπάρχει κάποιο πρόβλημα το οποίο έχει περισσότερες της μιας λύσεις, θεωρώ ότι πρέπει να προκρίνεται πάντα η λιγότερο παρεμβατική στα ενδότερα του συστήματος.
Σωστα αλλα δεν σημαινει ομως οτι επηδει βγαζει λαθος το συγκεκριμενο προβλημα στο libtesseract4 οτι ειναι οντως προβλημα στην συγκεκριμενη βιβλιοθηκη ουτε οτι εφοσον υπαρχει προβλημα σε αλλα προγραμματα οτι ειναι της βιβλιοθηκης το θεμα. Μηπως ολες οι αλλες εφαρμογες χρησιμοποιουν το Qt5? Μηπως εκει ειναι το προβλημα; Γιατι το gImageReader δεν δουλευει με Qt5 αλλα με GTK2/3 και δεν εχει θεμα.
Με δεδομένα ότι υπάρχουν πέραν του ενός issues στο GitHub αποθετήριο του Tesseract, αναγνωρίστηκε ως πρόβλημα στη βιβλιοθήκη από τους προγραμματιστές της και διορθώθηκε με commit στον κώδικα της βιβλιοθήκης, δε βρίσκεις κάπως παράλογη ακόμα και την υπόθεση ότι το πρόβλημα μπορεί να εντοπίζεται κάπου αλλού εκτός του Tesseract; Ένα από τα issues μάλιστα ήταν για κάποια Python-based υλοποίηση. Ούτε Qt ούτε τίποτα.
Οχι (και παλι μπορει να ειμαι λαθος και αν βεβαια εχεις την ωρα και την ορεξη δειξε μου κατι αλλο εκτος απο το συγκεκριμενο patch) εφοσον ολες οι ενδειξεις που βλεπω με οδηγουν στο συμπερασμα οτι ειναι θεμα συνδεσης του libtesseract4 με το υπολοιπο προγραμμα.
Σε παρομοιο (αλλα οχι επακριβως για αυτο που μιλαμε) bug βλεπεις οτι ακομα και με το Tesseract 4.1.1 υπαρχει θεμα στο εν λογω προγραμμα. Ισως να μην αναφερεται επακριβως στο patch που ανεφερες προηγουμενως αλλα και παλι το εν λογω προγραμμα δεν ειναι τελειο. Εχει τα λαθακια του και αυτο ειναι απολυτως ενταξει. Κανενα λογισμικο δεν ειναι τελειο. Ουτε το Tesseract Ουτε το Qt5 ουτε το Crow-Translate.
Σε ενα προγραμμα που εχει πολλαπλες βιβλιοθηκες και πολλαπλα σημεια στα οποια μπορει να υπαρχει θεμα (Points of failure οπως τα λενε οι αγγλοφωνοι φιλοι μας) το προβλημα δεν παρουσιαζεται ποτε ( κατα την δικια μου μικρη εμπηρειια ) μονο σε ενα σημειο (πχ στο tesseract4.1.1).
Τωρα η διαφορα στις προσεγγισεις μας ειναι εμφανης. Και ναι γινεται ευκολα με το να αντιγραψεις το .desktop αρχειο στο $HOME/.local/share/applications/ κατι που η δικια μου προσεγγιση δεν κατεδειξε.
Παρολα αυτα το αποτελεσμα ειναι οτι με την μεταβλητη LC_ALL=C μπροστα απο την εντολη crow τρεχει κανονικα. Οσο για τους απλους χρηστες… εφοσον δεν ειδαν εναν γραφικο τροπο για να κανουν αυτο που τους λεμε εδω… και παλι δεν θα βγουν κερδισμενοι.
Στο screenshot αυτο που εγινε στο Debian 10.7 με το MATE Desktop η εφαρμογη με την οποια θα γινει ευκολα αυτη η αλλαγη λεγεται mozo και στο αγγλικο μενου την βλεπουμε στο System → Preferences → Look & Feel → Main Mainu
Αναλογες εφαρμογες υπαρχουν και για τα υπολοιπα περιβαλλοντα οπως για παραδειγμα το alacarte για το GNOME3
Τώρα θα καταργήσουμε και τη λογική; Ας τα πάρουμε με τη σειρά:
Αναφέρθηκε ένα bug σχετικό με το Tesseract, το οποίο είναι ακριβώς ίδιο τόσο στο Crow Translate όσο και σε εντελώς διαφορετικές υλοποιήσεις
Οι προγραμμαστιστές του Tesseract παραδέχτηκαν ότι ήταν δικό τους σφάλμα και μάλιστα εξήγησαν το γιατί έκαναν την υλοποίηση με αυτό το «hack» που λέει και ο @Asfodelus παραπάνω
Το commit διόρθωσης στον κώδικα του Tesseract αφαιρεί εντελώς το «hack» και ακολουθεί άλλη υλοποίηση
Όσοι έχουν ενημερωμένη έκδοση του Tesseract δεν αντιμετωπίζουν το πρόβλημα
Πώς λοιπόν επιμένεις ότι το πρόβλημα μπορεί να είναι οπουδήποτε αλλού πλην του ίδιου του Tesseract;
Ακόμα και το καθόλου σχετικό με το θέμα μας bug που ανέφερες είναι πάλι bug του Tesseract και σχετίζεται με τα traineddata files που χρησιμοποιεί αυτό για το OCR. Ορίστε μια από τις αποδείξεις, άλλη μία και η επίλυσή του.
Σαφέστατα ισχύει γενικά, στη δική μας ειδική περίπτωση όμως το κοινό σημείο όλων των bugs είναι η χρήση του Tesseract. Δεν καταλαβαίνω γιατί επιμένεις σε κάτι διαφορετικό.
Δεν ειπα αυτο. Ειπα οτι μπορει να ειναι και σε καποιο αλλο σημειο το προβλημα. Οπως για παραδειγμα στο ιδιο το Crow-Translate. Αν παρατηρησες για να τρεξει στηριζεται στο Qt5 και τις βιβλιοθηκες του. Δεν εχω κατι με το Qt5 απλα ειναι ενα αλλο point of failure. Οπως ειναι κατα την γνωμη μου και την εμπειρια μου (μικρη ή μεγαλη αυτο το κρινουν αλλοι) point of failure ειναι και το tesseract. Δεν σημαινει οτι ειναι μονο αυτο υπευθυνο για το bug.
Γιατι επιμενεις οτι ειναι οντως μονο το tesseract στο οποιο μπορει να υπαρχει θεμα; Παρεπιπτοντως και το τελευταιο σου link που παρεθεσες για το tesseract δεν αναφερει κατι για locales που τουλαχιστον για το Debian 10.7 ειναι αυτο που το κανει και τρεχει σωστα. Αναφερεται στα training data τα οποια δεν μπορει να διαβασει σωστα. Αλλο το ενα αλλο το αλλο.
Τελος παντων, απο περιεργεια και μονο εβαλα σε ενα VM το Debian Testing (Bullseye Alpha3) και το Crow-Translate και οντως τρεχει χωρις αλλαγες αφου πρωτα βγαλει μυνημα για τα tessdata που δεν εβρισκε (διοτι επισεις χρειαζεται το tesseract-ocr-eng για τα αγγλικα και tesseract-ocr-ell για τα Ελληνικα) και μυνημα για το οτι δεν βρησκει service για το org.qt-project.qt.mediaplayer
Εμενα αυτο μου λεει οτι ναι μεν τρεχει αλλα και παλι το προγραμμα δεν ειναι ετοιμο, χρειαζεται δουλεια. Επισεις το συγκεκριμενο προβλημα για το οποιο εγραψα το παρον how-to βγαινει στο Debian 10.7 (Buster) που ειναι η σταθερη εκδοση… διοτι οχι μονο εχει παλιοτερη εκδοση του Tesseract αλλα κατα βασα πιθανοτητα και παλιες εκδοσεις αλλων βιβλιοθηκων που δεν βοηθανε την κατασταση. Εσενα μπορει να σου λεει απλα οτι ειναι μονο το Tesseract ο φταιχτης. Οκ δεκτο. Δεν χρειαζεται να συμφωνουμε παντα. Ουτε να βγαζουμε τα ιδια συμπερασματα. Οι αναγνωστες του παροντως θα κρινουν ποιος παει να καταργησει την λογικη και ποιος οχι.
Γιατί υπάρχουν διαφορετικές υλοποιήσεις (σε Qt, σε Python κλπ.) και εμφανίζουν όλες τα ίδια bugs. Οπότε είτε έχουν όλες οι υλοποιήσεις πρόβλημα είτε το πρόβλημα εντοπίζεται στο Tesseract. Με δεδομένο λοιπόν ότι αυτό είναι ο μοναδικός κοινός παρονομαστής για όλα τα bugs, και όλα σχετίζονται απευθείας με αυτό, το βρίσκω παράλογο να υποθέσω ότι πολλαπλές διαφορετικές υλοποιήσεις έχουν όλες πρόβλημα.
Είναι διαφορετικό bug που πάλι έχει γίνει report τόσο στο Crow Translate όσο και σε Python-based υλοποίηση και πάλι προέρχεται από το Tesseract.
Αυτό δεν είπα στο πρώτο σχόλιο, ότι δηλαδή είναι και θέμα της πολιτικής του Debian; Εγώ σε Arch δεν έχω κανένα από τα προβλήματα που αναφέραμε εδώ. Ούτε ένα. Και βεβαίως οι προγραμματιστές του Tesseract δε θα “φτιάξουν” την έκδοση 3 π.χ. αλλά συνιστούν αναβάθμιση στην 4.1. Αν κάποια διανομή δε μπορεί να το πράξει, είναι δικό της πρόβλημα.
Είναι ένα πράγμα το να υπάρχει πρόβλημα σε τρέχουσα έκδοση λογισμικού και άλλο το να υπάρχει πρόβλημα σε παρωχημένη έκδοση, το οποίο έχει επιλυθεί στην τρέχουσα. Στην περίπτωση των Qt-based λογισμικών το Debian έχει γνωστό πρόβλημα εδώ και πολλά χρόνια. Δε μπορεί να ακολουθήσει τις ταχύτητες ανάπτυξης και σε ορισμένες περιπτώσεις κάνει κακές υλοποιήσεις με ανακάτεμα βιβλιοθηκών.
Δηλαδη οτι δεν ειναι rolling με το τελευταιο και το πιο νεο εχει θεμα πολιτικης; Οτι δεν ειναι Arch-based εχει θεμα; Μηπως ειναι λιγο στρεβλο το οπτικο σου πεδιο; Και εμενα δεν μου αρεσουν ορισμενα ειδη διανομων αλλα δεν θα τις αναθεματισω κιολας.
Ολες οι διανομες… ακομα και το Arch εχουν την θεση τους. Και δεδομενου οτι το Qt παει commercial στην LTS εκδοση του και εχει ηδη χασει ορισμενους απο τους opensource developers του η χρηση του σε GNU/Linux διανομες ειναι μαλλον καπως shakey για την ωρα.
Οποτε δεν θα στεναχωρηθω και παρα πολυ αν δεν υπαρχει στο μελλον
Ουτε για την αποψη οτι στο Debian ειναι προβληματικα τα QT-based λογισμικα. Βεβαια το QBittorrent και αλλα QT5-based λογισμικα στην σταθερη εκδοση τρεχουν παρα μα παρα πολυ καλα… ειναι αυτα τα latest and greatest… τα αδοκιμαστα που εχου το θεματακι τους με το Buster
Εφοσον το θεμα εχει ηδη στοιχειοθετηθει αρκετα νομιζω δεν υπαρχει αναγκη για περαιτερω συζητηση Η λυση που προτεινα ειναι μονο για το Debian 10.7 (εφοσων αυτο χρησιμοποιω) και αν υπαρχουν ατομα με διαφορετικο λειτουργικο αλλα το ιδιο προβλημα μπορουν αν θελουν να δοκιμασουν την αλλαγη που προτεινα ειτε κανοντας την αλλαγη στο /usr/share/applications/io.crow_translate.CrowTranslate.desktop ειτε στο $HOME/.local/share/applications/io.crow_translate.CrowTranslate.desktop που προτεινες ειτε με το mozo ή καποιο αλλο παρομοιο λογισμικο οπως εδειξα με screenshot πιο πανω.
Δεν είπα αυτό. Κάθε διανομή ακολουθεί συγκεκριμένη πολιτική ανάπτυξης, με υπέρ και κατά. Στην περίπτωση του Debian (και των *based κατ’ επέκταση), είναι συχνό φαινόμενο η αδυναμία παρακολούθησης των εξελίξεων σε κάποια λογισμικά, λόγω του πολύ αργού ρυθμού ανάπτυξης. Αυτό έχει ως αποτέλεσμα είτε να μην τα υποστηρίζουν καθόλου είτε να κάνουν κακό «mix and match» βιβλιοθηκών κλπ. Από 'κει και πέρα, θα συμφωνήσεις πιστεύω πως όταν το ίδιο λογισμικό έχει πρόβλημα σε μια διανομή αλλά όχι σε κάποια άλλη, προφανώς είναι και θέμα διανομής.
Ούτε καν. Διάβασε τι έγραψα στο σχετικό θέμα και εδώ είμαστε να τα ξαναπούμε στο μέλλον.
Δεν είναι δική μου άποψη. Εκπεφρασμένη διαπίστωση είναι εδώ και πολλά χρόνια και βεβαίως δεν ισχύει για οποιοδήποτε Qt-based λογισμικό στον πλανήτη. Για παράδειγμα, οι προγραμματιστές του Plasma δε συνιστούν να επιλέγεται κάποια Debian-based διανομή (πλην Neon που το αναπτύσσουν οι ίδιοι) ακριβώς γιατί το Plasma αναπτύσσεται με ταχύτατους ρυθμούς, το Debian δεν το προλαβαίνει και η εμπειρία χρήσης δεν είναι ιδανική, με αποτέλεσμα να εμφανίζονται bugs που είτε έχουν επιλυθεί σε άλλες διανομές με νεότερες εκδόσεις είτε προκύπτουν από τον κακό συνδυασμό εκδόσεων λογισμικών που ανέφερα.
Γενικότερα, όλες οι διανομές έχουν τη θέση τους όπως το είπες αλλά ταυτόχρονα όλες έχουν μικρά ή μεγάλα μειονεκτήματα. Το να τα επισημαίνουμε δεν είναι ανάθεμα, πληροφόρηση είναι.
