Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - nuzzopippo

Pagine: 1 [2] 3 4 5
16
Base / Re:Storage parametri applicazione : un consiglio
« il: Luglio 24, 2019, 14:03 »
Se vuoi parlare dell'installazione di wxPython, ti direi di aprire una nuova discussione, riportando anche il sistema operativo che usi.

PS: dai un occhio qua: https://www.wxpython.org/pages/downloads/

Grazie della segnalazione @bebo ma no, non volevo parlare delle wx (comunque, il sistema : kubuntu 18.04 mi sembrava sufficientemente indicato).

Probabilmente non sono stato felice nella mia esposizione, ciò che veramente desta il mio interesse è lo spunto di @RicPol sull'opportunità di fornire adeguate procedure di installazione e disinstallazione per una eventuale applicazione, comparato alla notevole "dinamicità" del linguaggio ed alla diversa efficacia delle procedure relative alla installazione di librerie constatata in ambienti similari.

Le wx, come pillow, erano solo esempio, i procedimenti utilizzati ed efficaci per sistemi con gnome ed unity di Ubuntu 18.04 falliscono su di un sistema con Ubuntu 18.04 con  KDE eppure tutte e tre le macchine sono linux a 64 bit ed adottano python 3.6.8.
Tale circostanza mi impone delle riflessioni in merito a quanto possa essere complesso "distribuire" una propria applicazione se si ipotizza sia destinata a sistemi operativi diversi quando già in similari si trovano difficoltà ad installare una stessa libreria.

Maggiore perplessità mi sorge dall'aver constatato che non può ragionarsi neanche per generiche "versioni" di python, in effetti questo codice
NzP:~$ python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import pathlib
>>> cartella_dati = pathlib.Path(input('  '))
  script
>>> cartella_dati
PosixPath('script')
>>> for data_file in sorted(os.listdir(cartella_dati)):
...     print(data_file)
...
pyt
script
test
>>>

Funzionante con la versione 3.6.7 di python (è di un po' di tempo fa) fallirebbe con la versione 3.5.2 per diversità funzionale della libreria "pathlib", oltre tutto presente solo dalla versione 3.4 di python.

Tutte queste "perplessità" sono riferite all'argomento "installer/uninstaller" già introdotto in precedente post da @RicPol, era nelle premesse e pensavo fosse chiaro, probabilmente non è così, comunque la domanda da me intesa è :

Considerate le perplessità da me esposte, Voi che avete "pratica", come Vi regolate riguardo la distribuzione delle Vostre applicazioni? Quali accorgimenti adottate?

... lo so, la domanda è un po' generica e forse anche OT rispetto al contesto del post, ma non mi interessano "soluzioni", quelle le cercherò quando sarà il momento, bensì linee di pensiero di chi ha esperienza in merito, linee che possano evitarmi di intraprendere vicoli ciechi nei miei "tentativi".

Ciao :)

17
Base / Re:Storage parametri applicazione : un consiglio
« il: Luglio 23, 2019, 07:43 »
Riprendo, dopo tanto tempo, questo post ... in particolare, per una riflessione sulla parte "installer/uninstaller" sollevata dal buon @Ric.

Tra i continui inceppamenti che la vita commina, sto continuando a "guardarmi" python, notando differenze funzionali tra versioni "vicine" (tipo 3.5 - 3.6) e, cosa ben peggiore, anche nella stessa versione nello stesso operativo di base.
Mi riferisco, nello specifico, alla distribuzione linux "Ubuntu" vers. 18.04 ove trovo differenze funzionali rilevanti nelle installazione di librerie, tramite pip o altro, tra le versioni basate su gnome/unity ed una basata su KDE che sto cercando di "prepararmi" per utilizzarla off-line dato che per alcuni mesi sarò fuori sede e senza internet disponibile.

Or bene, procedimenti applicati efficacemente su gnome, tipo questo per le wx ma anche nella installazione di pillow per ovviare ad alcuni problemi di PIL, falliscono nella installazione in ambiente KDE.
Intendiamoci, non sto cercando supporto in tal senso, risolverò con calma per fatti miei, ma constatare la differenza funzionale già nella sola installazione delle stesse librerie, nella stessa versione di python sullo stesso s.o. di base, con solo l'interfaccia grafica di differenza mi fa tremare i polsi ... come farei ad affrontare "mari ignoti" tipo l'agitato windows (spesso incompatibile con se stesso) o il nebbiosamente remoto Mac?

Vorreste parlare, in maniera discorsiva, su come si affrontano o quali accorgimenti si adottano per tali problematiche?

Chiaramente, non ho ancora affrontato l'argomento, non lo farò sin quando non sarò un minimo soddisfatto del mio modo di "operare" in python, ho si visto alcune cose ma le mie idee sono nebulose e certamente non si chiariranno sin quando non affronterò sistematicamente il discorso ma, penso, aver preliminarmente indicazioni "pratiche" potrebbe aiutare molto.

Grazie dell'attenzione :)

18
Database / Re:Problema ASSURDO con PyODBC
« il: Giugno 20, 2019, 13:25 »
Ciao, da quel che esponi, in effetti il Tuo problema è strano, anche quando utilizzavo access e VB (20 anni fa) non mi è mai capitato un errore di indice in un update.

Come è strutturata la Tavola? A quali relazioni è soggetta? Logid è un valore univoco oppure no?
Domande giusto per avere una idea di base.

Poi, hai provato ad inserire la procedura di aggiornamento dei dati in un blocco "try -> except" e farti stampare la query che ti da errore (e magari anche la precedente) per poterla valutare?

[Edit] ... e pensandoci un po' su :
Il testo da inserire è costante? Se la risposta è "SI", hai provato ad utilizzare la discriminante per l'estrazione dei dati per l'update, invece dello Logid?, in sostanza una query di questo tipo :

   testo_da_aggiungere = 'quello che vuoi'
   NuovaSQL = 'UPDATE Tabella  SET campoa= CONCAT(campoa, "' + testo_da_aggiungere + '") WHERE (Anno = 2018, Dipartimento=10)'
  cursor.execute(NuovaSQL)

... anche se, a dire il vero, non ricordo proprio se Access implementi "CONCAT()" ... da una ricerca fatta ora, dovrebbe essere :
   NuovaSQL = 'UPDATE Tabella  SET campoa=  "' + testo_da_aggiungere + '" + campoa WHERE (Anno = 2018, Dipartimento=10)'

19
Sono nuovo alla programmazione, come dovrebbe essere strutturato un programma che fonde i file?

Ciao @Nextage, bruttissima idea "riaprire" un post di 8 anni fa, la tecnologia cambia in tempi mooolto più brevi, non credi sia meglio porre una Tua specifica domanda ad un Tuo specifico problema?

La "fusione" di files potrebbe dipendere dalle condizioni dei files.
Provo, comunque, a risponderti in maniera generica su di una ipotesi semplice : supponiamo di avere un insieme di tre file di logs con righe di log che iniziano con dati "temporali" (l'indicazione di @riko), come questi :

# file 1
2019-06-20T09:23:08.065568 : Avvio di mypyd1
2019-06-20T09:24:08.125763 : Variante 1 - eseguo istruzione 1
2019-06-20T09:25:08.137456 : Variante 1 - eseguo istruzione 2
2019-06-20T09:26:08.187182 : Variante 1 - eseguo istruzione 3
2019-06-20T09:27:08.247503 : Variante 1 - eseguo istruzione 4
2019-06-20T09:28:08.270459 : Variante 1 - eseguo istruzione 5

# File 2
2019-06-20T09:23:42.371260 : Avvio di mypyd2
2019-06-20T09:24:42.410702 : Variante 2 - eseguo istruzione 1
2019-06-20T09:25:42.470946 : Variante 2 - eseguo istruzione 2
2019-06-20T09:26:42.474092 : Variante 2 - eseguo istruzione 3
2019-06-20T09:27:42.479148 : Variante 2 - eseguo istruzione 4
2019-06-20T09:28:42.539483 : Variante 2 - eseguo istruzione 5

#File 3
2019-06-20T09:23:48.130851 : Avvio di mypyd3
2019-06-20T09:24:48.184124 : Variante 3 - eseguo istruzione 1
2019-06-20T09:25:48.206591 : Variante 3 - eseguo istruzione 2
2019-06-20T09:26:48.246429 : Variante 3 - eseguo istruzione 3
2019-06-20T09:27:48.306743 : Variante 3 - eseguo istruzione 4
2019-06-20T09:28:48.363951 : Variante 3 - eseguo istruzione 5


e che i tre file risiedano in una sotto-direttrice "logs" di quella che contiene il programma che deve fonderli, potresti farlo facilmente in questo modo :

#!/usr/bin/python3
# -*- coding : utf-8 -*-

import os

sumlogs = []
for log_file in os.listdir('logs'):
    f = open('logs/' + log_file, 'r')
    logtmp = f.read().splitlines()
    sumlogs += logtmp
    f.close()

sumlogs.sort()
f = open('totalgos', 'w')
for riga in sumlogs:
    f.write(riga + '\n')
f.close()

... ovviamente le cose potrebbero essere molto più complicate, se il contesto fosse diverso ;)

[Edit] Corretti gli import, avevo "ereditato" quelli di un modulo utilizzato per estrarre l'esempio.

20
Benvenuto e regolamento / Re:Salve
« il: Giugno 12, 2019, 07:26 »
Ciao @Transea, ben venuto

Piacciono i Litfiba anche a Te?

... magari impareremo assieme ;)

21
Benvenuto e regolamento / Re:Presentazione
« il: Giugno 12, 2019, 07:24 »
Ciao @ cavasayan, ben venuto :)

22
Ciao,

Interessato da alcuni aspetti del discorso ho fatto un po' di ricerche, tra le tante ho trovato questa pagina su html.it che mi sembra interessante (non ho ancora effettuato nessun test in merito), la segnalo

[Edit] Fatto un test preliminare in un virtualenv per python 2.7, su sistema ubuntu 18.04, installando da pip camelot-py e opencv-python, una tabella dati contenuta in un pdf creato con libreoffice viene letta ed esportata correttamente in formato csv, per excell credo occorrerebbero le librerie pandas, mi da errore e penso sia quello in motivo

23
In primo luogo, il codice che hai postato non dovrebbe neanche essere accettato in una sessione di shell

Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
>>> class Prova:

def funzione(self):
print('Qualcosa')
funzione()


Traceback (most recent call last):
  File "<pyshell#21>", line 1, in <module>
    class Prova:
  File "<pyshell#21>", line 5, in Prova
    funzione()
TypeError: funzione() missing 1 required positional argument: 'self'


Ciò perché la chiamata di "funzione()" non ha riferimenti all'interno dell'oggetto (classe) in cui risiede ... ma non è questo l'errore che Tu indichi, supposto di porre una strutturazione di classe accettabile, il Tuo errore lo si riceve provando ad applicare direttamente la classe, bisogna prima istanziarla e poi richiamare il metodo di classe "funzione()", vedi sotto

>>> class Prova:
def funzione(self):
print('Qualcosa')


>>> Prova.funzione()
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    Prova.funzione()
TypeError: funzione() missing 1 required positional argument: 'self'
>>> my_ogg = Prova()
>>> my_ogg.funzione()
Qualcosa
>>>

Probabilmente sei ai primi approcci, suggerirei di partire da qui e seguenti, farsi i concetti generali sulle classi e riprovare, ti sarà utile :)

[Edit] dimenticavo, non necessariamente la classe istanziata deve essere assegnata, va bene anche un utilizzo del genere :

>>> Prova().funzione()
Qualcosa
>>>

che istanzia la classe Prova e richiama il metodo "funzione()" in unica soluzione

24
Base / Re:Libri per imparare Python
« il: Maggio 05, 2019, 13:04 »
Ciao :)

Iniziando a mia volta, questo libro l'ho trovato buono, tant'è che ho intenzione di rileggerlo.

Ti suggerirei di dare una guardata nella sezione "Documentazione" ed anche nelle altre sezioni, vi sono post in merito e materiale indicato per vari aspetti.

25
I miei saluti a Voi.

Cercando di realizzare un "controllo" personalizzato (assemblando vari widget) ho provato, tra l'altro, una "composizione" che prevede l'utilizzo di una scrollbar non associata alla view di un secondo widget.
L'utilizzo della scrollbar è relazionato al solo scorrimento di un indice di lista dati.

La prova, tutto sommato, ha avuto successo, almeno in linea di massima, in questo modo :
dichiarazione nello __init_della classe :
        self.pivot_scroll = tk.Scrollbar(self,
                                         orient=tk.VERTICAL,
                                         jump=1,
                                         command=self._scrollEvent)

l'opzione "jump=1" è data per limitare gli eventi al solo rilascio del tasto del mouse

definizione del "set" per la scrollbar al caricamento dei dati :
    def set_data(self, dati):
        self.dati = dati
        self.pivot = 0
        for riga in self.rows:
            riga.clear()
        # configurazione scrollbarr
        self.pivot_scroll.set(0, len(self.dati) - self.righe)
        # fine per scroll
        self._refresh_rows()

ove viene impostato, per la scrollbar, un "intervallo" pari alla consistenza dei dati decurtata degli elementi visualizzati, tale impostazione è necessaria, in assenza si hanno "out of range" ad ogni evento proveniente dalla scrollbar

gestito valutando i dati passati dalla scrollbar al gestore (handler, se volete) associato
    def _scrollEvent(self, *L):
        """Gestisce lo scroll della vertical barr associata."""
        if not self.dati: return
        for elem in L: print(elem, end=' - ')
        print()
        op, valore = L[0], L[1]
        if op == 'scroll':
            modo = L[2]
            if modo == 'pages':
                val = int(valore) * self.righe
            else:
                val = int(valore)
            if (self.pivot + val) < 0:
                self.pivot = 0
            elif (self.pivot + val) > (len(self.dati) - self.righe):
                self.pivot = len(self.dati) - self.righe
            else:
                self.pivot += val
        elif op == 'moveto':
            self.pivot += int(len(self.dati) * float(valore)) - 1
            if self.pivot < 0:
                self.pivot = 0
            elif self.pivot > len(self.dati) - self.righe:
                self.pivot = len(self.dati) - self.righe
        self._refresh_rows()


Come detto, le impostazioni sopra per funzionare funzionano ma in modo insoddisfacente : lo slider della scrollbar assume la dimensione dell'intera area disponibile, cosa non sorprendente, e (questo è strano) si "ridimensiona" in caso di trascinamento a partire dai bordi estremi dello stesso, tale ridimensionamento permate e da quel momento è possibile "agganciare" e trascinare lo slider, la "precisione" lascia a desiderare ed il posizionamento effettivo dello slider è insussistente.
Se occorressero maggiori dettagli od una visualizzazione grafica della circostanza potete vedere qui, sono semplici appunti di apprendimento.

Non so se è possibile farlo ma vorrei realizzare un controllo adeguato della rappresentazione dei dati visualizzati in rapporto all'insieme degli stessi, il tutto completamente avulso da view di elementi grafici.
Ho molto cercato e letto ma ho trovato pochissimo, se non nulla, di specifico in merito ad una definizione  delle specifiche dello slider o, magari, ci sono incappato e non ho compreso, data la mia ignoranza dell'inglese.

Qualcuno di Voi avrebbe indicazioni e/o suggerimenti in merito?

Grazie dell'attenzione  :caffè:

26
Base / Re:Storage parametri applicazione : un consiglio
« il: Aprile 23, 2019, 18:21 »
Grazie delle info @RicPol

Leggersi il s.o., quindi, poi regolarsi.

...Poi per fare questo sarebbe buona educazione fornire anche un installer/uninstaller che pulisce correttamente i vari pezzetti lasciati in giro...
Se però si trattta del solito programmino distribuito alla selvaggia, allora è di gran lunga preferibile usare una sub-directory "interna" ...
beh, la parte evidenziata rientra tra le "intenzioni" in divenire, anche se argomento che temo metterà a dura prova le mie denutrite meningi, allo stato men che selvagge.
La sub interna alla directory applicativa l'avevo considerata ma in genere non la uso per abitudine, più che altro perché le piccole applicazioni che faccio a mio uso e consumo le porto in giro su chiavetta e le faccio girare su diversi computer, tutti linux ma con caratteristiche differenti, alla lunga ho una preferenza per lo storage sulla macchina in uso ... anche se come motivo non è per nulla buono :)

Grazie, ciao

27
Base / Re:Storage parametri applicazione : un consiglio
« il: Aprile 22, 2019, 07:40 »
Vi ringrazio delle risposte.

Per lo meno, ho conferma che detto metodo è applicabile nei s.o. più diffusi, anche se "nascondere" lascia il tempo che trova.

Interessante la proposta di standard segnalata da @bebo, sarebbe ora che si adottassero schemi di comportamento unificati, per limitare la confusione nelle home-dir ... già ci pensa l'utente a crearla :)
da una veloce verifica nel mio Ubuntu 18.04, sembrerebbe parzialmente adottata solo da unity per sue specifiche esigenze, da verificare circa i permessi in scrittura

NzP:~$ echo "$XDG_DATA_HOME"

NzP:~$ echo "$XDG_CONFIG_HOME"

NzP:~$ echo "$XDG_CONFIG_DIRS"
/etc/xdg/xdg-unity:/etc/xdg
NzP:~$ echo "$XDG_CACHE_HOME"

NzP:~$ echo "$XDG_RUNTIME_DIR"
/run/user/1000
NzP:~$ ls "$XDG_RUNTIME_DIR"
bus     dconf  gnupg  gvfs-burn  pulse    unity
dbus-1  gdm    gvfs   keyring    systemd  update-notifier.pid
NzP:~$

Comunque, faccenda da tener d'occhio

28
Base / Storage parametri applicazione : un consiglio
« il: Aprile 20, 2019, 12:43 »
Buon giorno a Voi ... e buona Pasqua, data la prossimità :)

Desidererei un consiglio :
nei sistemi unix-like è ampiamente usato memorizzare parametri opzionali di una applicazione scelti da un utente in una direttrice nascosta nella home dell'utente, cosa semplice da realizzare con python

import os
...
def load_app_configurations():
    '''Acquisisce, se esistono, le scelte applicative salvate.'''
    home = os.path.expanduser('~')
    app_dir = os.path.join(home, '.app_name')
    if not os.path.exists(app_dir):
        os.mkdir(app_dir)

mi apprestavo ad utilizzare una tale metodologia ma mi son fermato un attimo, so che "funzionerebbe" anche in windows, almeno per alcune versioni, ma mi chiedo se esiste una qualche convenzione/linea guida in merito, almeno per l'ambito python ...  sapreste darmi suggerimenti in merito?

29
Tkinter / Re:layout "grid", classi e persistenza oggetti
« il: Aprile 16, 2019, 06:23 »
Risolto, il problema era nella notazione "unica" utilizzata per definire il widget e la sua posizione nella griglia : non da errore ma non restituisce l'oggetto creato. Bisogna, quindi, tener separate le definizioni ed i posizionamenti.

Mi hanno "fregato" la mancanza di eccezioni e "vecchie" esperienze.

Per improbabili interessati :

Notazione accettata ma inutilizzabile :

        self.lbl_dida = tk.Label(self,
                                text='...',
                                justify='left',
                                ).grid(row=0, column=1, sticky='nsew')


Notazione funzionale :

        self.lbl_dida = tk.Label(self,
                                text='...',
                                justify='left',
                                )
...
        self.lbl_dida.grid(row=0, column=1, sticky='nsew')


Mi si perdoni se Vi ho fatto perdere tempo a leggere.

30
Tkinter / [Risolto] layout "grid", classi e persistenza oggetti
« il: Aprile 15, 2019, 09:19 »
I miei saluti a Voi :)

Intrigato da una idea reperita altrove, mi sono avventurato a costruire una specie di "controllo" composito con tkinter che provvede ad esporre righe di immagini miniaturizzate e didascalie. Nel costruirlo mi sono anche scritto una serie di test per verificare la "resa" di quanto fatto in vali punti di sviluppo.

Ho implementato una versione utilizzante il metodo "pack()" costituita da due classi, una definente una singola "riga" dati (immagine/didascalia) mentre la seconda visualizza un insieme di tali righe e fornisce i metodi per la navigazione tra i dati. Tale versione è funzionante.

Insoddisfatto da alcune questioni di resa grafica degli automatismi di pack() ho provato a definire una variante dell'oggetto utilizzante il metodo "grid()" ed incappando già alla definizione della singola riga in una serie di problematiche che, dopo un po' di ricerche e prove, credo si individuino in una mancata persistenza degli oggetti invocati dal codice per una qualche peculiarità del metodo grid() che non mi riesce di individuare, probabilmente per la mia ignoranza dell'inglese (enorme palla al mio piede)

Appresso, esemplifico il codice, funzionante, del costruttore di una riga, versione utilizzante pack(), e della sua invocazione, con inseriti del print di debug.

costruttore :

class FRMTumbnail(tk.Frame):
    '''Pannello per singola miniatura (tumbnail) con descrizione.'''
    def __init__(self, master, mater, imgdim=60):
        self.mater = mater
        self.f_img = ''
        super().__init__(master)
        self.dim_tmb = imgdim
        self._curr_img = None
        self.indice = None
        self.default_bc = self.cget('bg')
        self.configure(relief='sunken', border=2, padx=2, pady=2)
        self.cnv_tmb = tk.Canvas(self,
                                 width=self.dim_tmb,
                                 height=self.dim_tmb,
                                 bg='#ffffc0',
                                 relief='raised',
                                 border=2
                              )
        self.cnv_tmb.pack(side='left')
        print('self.cnv_tmb è : ', self.cnv_tmb)
        print(self.cnv_tmb)
        self.cnv_tmb.bind('<Button-1>', self._scelto)
        f = tk.Frame(self, height=self.dim_tmb+4)
        f.pack(side='left', expand=True, fill='x')
        #f.pack_propagate(0)
        self.lbl_dida = tk.Label(f,
                                text='..'*10,
                                justify='left',
                                )
        self.lbl_dida.pack(expand=True, fill='both')
        print('self.lbl_dida è : ', self.lbl_dida)
        self.lbl_dida.bind('<Button-1>', self._scelto)


invocazione:

class GUI_01(tk.Tk):
    ''' Finestra principale test 01 : singola riga. '''

    def __init__(self, fnome='', dim=60):
        super().__init__()
        self.f_nome = fnome
        self.title('Test 01')
        sfondo = tk.Frame()
        sfondo.pack(fill='both')
        self.f = fd.FRMTumbnail(sfondo, None, dim)
        self.f.pack(fill='x')
        print('self.f è : ', self.f)
        f2 = tk.Frame(sfondo, relief='sunken', padx=2, pady=2)
        f2.pack(fill='x')
        btn = tk.Button(f2, text='Mostra immagine', command=self.mostra)
        btn.pack()
        self.minsize(300, self.winfo_reqheight())
        # self.update()
        centraFinestra(self)
   
    def mostra(self):
        self.f.set_fileimg(self.f_nome)
        self.f.set_dida("un po' di testo a caso")


Ed ora analoghi costruttore ed invocazione con grid(), si noti il commento dei "bind()", con ciò la riga viene visualizzata correttamente ma è inutilizzabile.

Costruttore:

class GriFRMTmb(tk.Frame):
    '''Pannello per singola miniatura (tumbnail) con descrizione.'''
    def __init__(self, master, mater, imgdim=60):
        self.mater = mater
        self.f_img = ''
        super().__init__(master)
        self.dim_tmb = imgdim
        self._curr_img = None
        self.indice = None
        self.default_bc = self.cget('bg')
        self.configure(relief='sunken', border=2, padx=2, pady=2)
        self.cnv_tmb = tk.Canvas(self,
                                 width=self.dim_tmb,
                                 height=self.dim_tmb,
                                 bg='#ffffc0',
                                 relief='raised',
                                 border=2
                                 ).grid(row=0, column=0, sticky='w')
        print('self.cnv_tmb è : ', self.cnv_tmb)
        #self.cnv_tmb.bind('<Button-1>', self._scelto)
        self.lbl_dida = tk.Label(self,
                                text='...',
                                justify='left',
                                ).grid(row=0, column=1, sticky='nsew')
        #self.lbl_dida.bind('<Button-1>', self._scelto)
        print('self.lbl_dida è : ', self.lbl_dida)
        self.columnconfigure(1, weight=1)


invocazione:

class GUI_01_G(tk.Tk):
    ''' Finestra principale test 01 - variante layout grid : singola riga. '''

    def __init__(self, fnome='', dim=60):
        super().__init__()
        self.f_nome = fnome
        self.title('Test 01-Grid')
        sfondo = tk.Frame().grid(sticky='nsew')
        self.f = fd.GriFRMTmb(sfondo, None, dim).grid(row=0,
                                                        padx=2,
                                                        pady=2,
                                                        sticky='ew'
                                                        )
        print('self.f è : ', self.f)
        btn = tk.Button(sfondo,
                        text='Mostra immagine',
                        command=self.mostra).grid(row=1,
                                                  padx=2,
                                                  pady=2,
                                                  sticky='nsew'
                                                  )
        self.columnconfigure(0, minsize=300, weight=1)
        self.update()
        centraFinestra(self)
   
    def mostra(self):
        self.f.set_fileimg(self.f_nome)
        self.f.set_dida("un po' di testo a caso")

(mi si perdoni l'incompleta aderenza alla Pep8)

e qui segue l'output del test effettuato per le due versioni :

NzP:~$ python3 test.py 1 risorse/01.jpg 60
self.cnv_tmb è :  .!frame.!frmtumbnail.!canvas
.!frame.!frmtumbnail.!canvas
self.lbl_dida è :  .!frame.!frmtumbnail.!frame.!label
self.f è :  .!frame.!frmtumbnail
NzP:~$ python3 test.py 5 risorse/01.jpg 60
self.cnv_tmb è :  None
self.lbl_dida è :  None
self.f è :  None
NzP:~$


Mi sembra evidente che con l'utilizzo di pack() le variabili di istanza nelle classi vengono correttamente create mentre utilizzando grid() invece no
 ... malgrado abbia cercato nella docs ed in rete mi son fermato qui, non mi riesce di capirne il perché e come rimediare, qualcuno di Voi conosce il problema e può darmi indicazioni in merito?

Scusate la lunghezza del post, non mi riuscirebbe di essere chiaro, altrimenti.

Pagine: 1 [2] 3 4 5