Ti ringrazio per la Tua disponibilità, prendi tranquillamente tutto il tempo che Ti serve




... comunque, ho il sospetto che il problema derivi dai decoratori "@property" e "@<metodo>.setter" utilizzati nella classe definente l'elemento "drag-drop", apparentemente non vengono ereditati correttamente.
Infatti, implementando specifici metodi getter e setter (tipo set_dragable(self, variabile) e get_dragable(self)) le variabili di classe self._dragable e self._dropable vengono variate (prima non avveniva) e si ha conformità nelle valutazioni tra classe ed oggetto.

Approfondirò, intanto grazie del Tuo interessamento.




Edit: bah ... forse non pongo domande "giuste" nelle mie ricerche, ma non ho trovato informazioni direttamente associate al caso specifico, però ho trovato più volte indicato che "l'incapsulazione delle classi non è completa in python", penso che la problematica da me riscontrata possa ricadere in tale ambito.

In effetti, utilizzando i decoratori built-in prima indicati non faccio altro che incapsulare dei metodi di classe in funzioni, forse è possibile che l'ulteriore incapsulamento che avviene utilizzando l'ereditarietà non arrivi a definire tale circostanza.

Comunque, evitando i decoratori ed utilizzando metodi diretti per l'impostazione delle proprietà _dragable e _dropable, la funzionalità dello insieme tornano nei criteri da me conosciuti.

Pur se esistono varianti possibili da studiarsi (non ultima la definizione di classi-decoratore per i widget) credo che la metodologia a "metodo diretto" raggiunga un sufficiente compromesso tra semplicità ed elasticità, permettendo di svolgere l'intero lavoro (a parte i metodi astratti) all'interno della classe-madre ...



--- Ultima modifica di nuzzopippo in data 2024-11-22 10:22:33 ---

L'effetto sembra quello, e la cosa mi ha un po' stupito, mi aspettavo, avendo "trasferito" i metodi "dragable" e "dropable" della classe originale ad un widget, che i valori fossero conformi, invece no :

Python 3.12.3 (main, Sep 11 2024, 14:17:37) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.

= RESTART: /home/ngiuseppe/src/prove/varie/tk/dragdrop/step02/drag_and_drop.py =

====== RESTART: /home/ngiuseppe/src/prove/varie/tk/dragdrop/step02/test.py =====
dragable classe True, dragable oggetto True
dropable classe True, dropable oggetto False
dragable classe True, dragable oggetto False
dropable classe True, dropable oggetto True

c'è qualcosa che, certo, non ho compreso adeguatamente.





@Palmux, so che non approvi ma collego tre files che debbono essere posti nella stessa directory, così, nel caso Ti andasse e Ti fosse possibile, puoi vedere bene ciò che ho fatto

Allora ... dal punto di vista "operativo" ritengo di aver definito dei processi abbastanza bene funzionali, però c'è certamente qualche concetto che non ho capito.




Per "astrarre" il discorso ho definito, appunto, una classe astratta, ove nel corpo della classe ho implementato staticamente i metodi di visualizzazione della "transizione", lasciando astratti i metodi per lo scambio dei dati tra widget, giusto per spiegarmi meglio, stralcio di codice della classe astratta:

    def __init__(self, obj: callable, tipe: str='text', *args, **kwargs):
        self.obj = obj
        self._dragable = True
        self._dropable = True
        self.obj.dropable = self.dropable
        self.obj.dragable = self.dragable
        self.tipe = tipe
        self.obj.tipe = self.tipe
        self.obj.drop_data = self.drop_data
        self.obj.drag_data = self.drag_data
        self.mwin = None
        self.obj.bind("<Button-3>", self._on_press)
        self.obj.bind("<B3-Motion>", self._on_motion)
        self.obj.bind("<ButtonRelease-3>", self._on_release)

    @property
    def dragable(self) -> bool:
        return self._dragable
    @dragable.setter
    def dragable(self, value: bool) -> None:
        self._dragable = value
    
    @property
    def dropable(self) -> bool:
        return self._dropable
    @dropable.setter
    def dropable(self, value: bool) -> None:
        self._dropable = value

    def _on_press(self, evt: callable) -> None:
        print(self._dragable, self.obj.dragable)
        if not self.obj.dragable: return
        x,y = self.obj.winfo_pointerxy()
        self.mwin = DragWin(self.obj)
        self.mwin.geometry(f'+{x}+{y}')
...
    @abc.abstractmethod
    def drop_data(self, descriptor, data: any) -> None:
        pass

    @abc.abstractmethod
    def drag_data(self) -> any:
        pass

ed implementato i metodi astratti nei sub-classamenti "reali" che sono andato a definire per specifiche problematiche, sotto un esempio di definizione per una ttk.Treeview che nel test mi sposta un record completo di un elenco di comuni :

class DADTreeComuni(DAD.DragDropElement):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    def drop_data(self, descriptor, data: any) -> None:
        if not self.obj.dropable: return
        if descriptor != self.obj.tipe: return
        self.obj.set_comune(data)

    def drag_data(self) -> str:
        return self.obj.get_element()

ora, noterete quel "print(self._dragable, self.obj.dragable)", è un test di controllo che ho inserito per controllare cosa avviene per gli stati di abilitazione tanto per il "drag" (variabile di istanza self._dragable) quanto per il drop (variabile di istanza self._dropable) che ritenevo venissero ereditate e modificate dai setter applicati sugli oggetti istanziati (istruzioni self.obj.dropable = self.dropable e self.obj.dragable = self.dragable), così non è :


le variabili di istanza rimangono come impostate nella classe astratta mentre la risposta degli oggetti varia secondo le impostazioni ... suppongo che l'insieme di istruzioni sopra indicata causi la creazione di nuove proprietà "_dragable" e "_dropable" negli oggetti passati alle definizioni "reali" della classe astratta : è così?




Fermo restando che che andrò a rileggermi la docs tanto di ABC quanto delle classi in genere e di python in particolare non mi dispiacerebbe avere conforto di utenti più addentrati.




P.S. : vedo che non c'è stato molto interesse sull'argomento, evito quindi di allegare i files delle definizioni e di test, tre in complesso, se vi è interesse lo si indichi, il prodotto finale di ciò che ho fatto è la possibilità di definire dei widget con capacità "drag and drop" attivabile/disattivabile a piacere, con selezione di copia per tipologia di dato.




Grazie dell'attenzione

Ok ci ho provato, ho visto che si può incollare del codice ed ho inserito qui il codice di un ulteriore step di prova, nel quale sto provando ad astrarre un pochino il concetto definendo una classe che riceve un oggetto (ovviamente un widget tkinter), gli aggiunge delle proprietà e metodi e poi usa quell'oggetto per azioni "drag and drop".




L'idea è di usare la classe come base per poi definire ulteriori classi "specializzate" a fini specifici ereditando la parte "drag" così come è, utilizzando il polimorfismo per il "drop" adattando il solo metodo "drop_data" della classe "DragDropElement" ai fini specifici occorrenti per un dato compito ... ecco, qui pareri esperti non mi farebbero male, principalmente sulla maniera utilizzata per passare il metodo "drop_data" all'oggetto riferito

Per altro, ho definito delle proprietà di controllo "_dragable" e "_dropable" per il controllo dello stato di attivazione delle capacità implementate oltre che una proprietà "tipe" per la definizione del tipo di dato che viene scambiato.




Qualcuno ha qualcosa da suggerire?

Strano, ho effettuato un "Edit" indicando che inviavo una versione di codice con integrata la visualizzazione del trascinamento, il file è stato allegato ma l'edit non è stato riportato.

Grazie per la Tua attenzione.
Anche per me è una "prima volta", il altri frangenti ho avuto disponibili interfacce native per tali operazioni ... a dirla tutta, ci sarebbe anche per tkinter una interfaccia di tal genere ma una istruzione tipo

root = TkinterDnD.Tk()  # notice - use this instead of tk.Tk()

mi è così sgradita da rifiutare la minestra e cucinamela da me.

Allo stato è realizzato solo il prototipo funzionale essenziale, privo anche della visualizzazione del trascinamento (lo fornirò appena implementato), è una base su cui vorrei ragionare al fine di impostare una "tecnica" da adottare nelle mie implementazioni ... ci voglio riflettere su al fine di limare detta tecnica ed in tal senso ogni eventuale feedback è graditissimo.



Edit : cosa, la visualizzazione del trascinamento, molto semplice da implementare, ho perso più tempo a selezionare l'icona che a creare una classe "DragWin" che disegna la finestra da trascinare, allego il file modificato, mostra l'effetto in maniera più soddisfacente


--- Ultima modifica di nuzzopippo in data 2024-11-16 08:38:30 ---

I miei saluti.

Sto, al momento, studiando come realizzare un "drag and drop" in tkinter, che non fornisce (a quanto ne so) una interfaccia nativa in merito, l'idea di fondo è realizzare dei widget con tale capacità, per scambio di dati tra diverse finestre di una stessa applicazione tramite trascinamento.
Con l'aiuto della documentazione, principalmente di winfo mi è riuscito di realizzare una bozza di base funzionante, sub-classando una tkinter.Entry, scambiando testo tra due oggetti di detto sub-classamento posti in finestre diverse, per trascinamento con il tasto destro del mouse premuto.

... però, anche se funziona, non sono pienamente convinto della metodologia adottata, al momento, al rilascio del pulsante destro del mouse l'oggetto su cui si è avviato il "drag" esamina tutta la gerarchia dei parent sino a trovare la main-window (root per gli amici) e utilizza questa per estrarre tra i widget figli quello su cui è stato rilasciato il pulsante, se quest'ultimo ha uno specifico attributo ("dragable") vi viene aggiunto il testo del widget "draggato".

Come detto, è solo un abbozzo preliminare di studio della funzionalità, prima di integrare il concetto in vari elementi (penso almeno a treeview ed entry che si scambino oggetti) non mi dispiacerebbero consigli circa approcci migliori e/o accorgimenti da tenere.
Se qualcuno vuol provare il codice sin ora implementato (106 righe) è in allegato:

Per nulla, esistono varie possibilità, cercando in rete e nella docs se ne trovano, si potrebbe, ad esempio, operare in un contesto temporaneamente modificato, vedi il test sotto, effettuato in una sessione idle

Python 3.12.3 (main, Sep 11 2024, 14:17:37) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
import numpy as np
data = np.arange(80).reshape(4,20)
data
array([[ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
        16, 17, 18, 19],
       [20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,
        36, 37, 38, 39],
       [40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
        56, 57, 58, 59],
       [60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75,
        76, 77, 78, 79]])
import pandas as pd
df = pd.DataFrame(data)
df
   0   1   2   3   4   5   6   7   8   ...  11  12  13  14  15  16  17  18  19
0   0   1   2   3   4   5   6   7   8  ...  11  12  13  14  15  16  17  18  19
1  20  21  22  23  24  25  26  27  28  ...  31  32  33  34  35  36  37  38  39
2  40  41  42  43  44  45  46  47  48  ...  51  52  53  54  55  56  57  58  59
3  60  61  62  63  64  65  66  67  68  ...  71  72  73  74  75  76  77  78  79

[4 rows x 20 columns]
pd.option_context('display.max_columns', None)
<pandas._config.config.option_context object at 0x7ecc63b6e480>
df
   0   1   2   3   4   5   6   7   8   ...  11  12  13  14  15  16  17  18  19
0   0   1   2   3   4   5   6   7   8  ...  11  12  13  14  15  16  17  18  19
1  20  21  22  23  24  25  26  27  28  ...  31  32  33  34  35  36  37  38  39
2  40  41  42  43  44  45  46  47  48  ...  51  52  53  54  55  56  57  58  59
3  60  61  62  63  64  65  66  67  68  ...  71  72  73  74  75  76  77  78  79

[4 rows x 20 columns]
with pd.option_context('display.max_columns', None):
    df

    
   0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18  \
0   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18   
1  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38   
2  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58   
3  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78   

   19  
0  19  
1  39  
2  59  
3  79  

come puoi vedere, al secondo tentativo d'uso tutte le colonne vengono mostrate.




Ciao

Hai provato con Pypi? Lato python viene richiesto genericamente la versione 3, perciò "dovrebbe" essere Ok.




Se i problemi vengono dalla versione di windows (spesso incompatibile con il pregresso) passo, non uso quel s.o. dagli anni '90




Ciao e auguri

Ciao ... beh, forse esiste

Python 3.12.3 (main, Sep 11 2024, 14:17:37) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
import itertools
data = ['a', 'b', 'c']
result = itertools.combinations_with_replacement(data, 4)
for c in result:
    print(''.join(c))

    
aaaa
aaab
aaac
aabb
aabc
aacc
abbb
abbc
abcc
accc
bbbb
bbbc
bbcc
bccc
cccc

Leggendo meglio, forse vorresti ottenere "Tutte" le possibili combinazioni, dato che quella sopra non è completa ... in tal caso combinando con itertools.permutations e smanettando un pochino si potrebbe (occhio sono TANTE)

comp = []
result = itertools.combinations_with_replacement(data, 4)
for e in result:
    per = itertools.permutations(e)
    for c in per:
        comp.append(''.join(c))

        
final = sorted(list(set(comp)))
for v in final:
    print(v)

    
aaaa
aaab
aaac
aaba
aabb
aabc
aaca
aacb
aacc
abaa
abab
abac
abba
...
accc
baaa
baab
baac
baba
...
etc ...

--- Ultima modifica di nuzzopippo in data 2024-10-14 09:43:20 ---