Interfacce e comportamento pulsanti

[Allanon]

• 

Io sto usando la 4.5.4(2356) ma a parte questa cosa strana della tool bar non ho avuto altri malfunzionamenti, e sai che lo uso come editor principale per programmare, per me è uno dei migliori editor free che ci sono in giro, peccato che non hanno ancora implementato il fold/unfold delle funzioni

[cdimauro]

• 

Mi sono fermato alla 4.5.2 (2241); comunque non so come riprodurre quei fastidiosi bug. So solo che tornando alla 4.5.2 non si sono più presentati, per cui mi tengo quella.

Comunque lo uso solo come editor di testo. Per sviluppare in Python o Java uso NetBeans. Per C# ovviamente Visual Studio, come pure per C e C++. Altro per adesso non uso.

[Allanon]

• 

Vediamo se stavolta mySQL mi cancella il post  

Allora, sempre nel contesto della mia libreria GUI, sono alle prese con la classe <button>, messo in chiaro il discorso degli eventi e del focus (grazie ancora Antonio   ) avevo un'altro dubbio.

Ho previsto la possibilità di inserire nei pulsanti delle icone con i vari allineamenti e con l'opzione di "sistemare" il testo per non far sovrapporre i due elementi. Inoltre ho previsto la possibilità di inserire delle immagini vettoriali e quindi scalabili con la dimensione del pulsante, per il momento in un formato custom molto semplice (poi vedremo), il mia domanda è: ha senso dare la possibilità di inserire tutti e tre gli elementi nel pulsante? Ossia icona, immagine vettoriale e testo? Io credo di non aver mai incontrato pulsanti con all'interno sia una bitmap che un'immagine vettoriale, ma volevo sapere se voi avete incontrato questa possibilità e se entrambi gli elementi grafici sono realmente necessari o se è sufficiente uno dei due assieme ad un eventuale testo.

Lo so che vi stresso, ma a 'sto giro vorrei scriverla per bene questa libreria  8-)
Magari nei crediti ci metto anche NSA  

[TheKaneB]

• 

generalmente i pulsanti hanno una sola immagine + testo.

L'immagine può essere a sua volta vettoriale o bitmap. Questo si può implementare avendo una classe generica Image, e le due derivate Bitmap : public Image e Vectorial : public Image.

Non ho mai visto pulsanti con 2 o più immagini dentro, e sinceramente non ne ho mai sentito il bisogno.

[cdimauro]

• 

Se vi può consolare, io ho avuto più volte l'esigenza d'infilare un intero pannello con informazioni, immagini, e addirittura altri bottoni, all'interno di un Button (classe di WPF/Silverlight) su Windows Phone 7 (e presto con WPF, perché devo realizzare un'applicazione per Windows dotata di GUI per l'ultimo lavoro che ho preso).

Ad esempio, devo visualizzare una lista di file o cartelle con alcuni loro attributi (nome, timestamp di creazione, chi l'ha creato, dimensione per i file) e un paio di bottoni per cancellare l'elemento o espandere il pannello visualizzando dei commenti a esso annessi. Il click su questo pannello serve, invece, ad aprire una pagina per visualizzarne il contenuto.

In generale su WPF/Silverlight i Button sono in grado di "inglobare" un oggetto qualunque, e di "renderizzarlo" opportunamente. Normalmente è una stringa, che viene "incastonata" in un pannello predefinito internamente che è costituito da un oggetto border che all'interno ha poi un oggetto TextBlock che si occupa di renderizzare la stringa. Ma con Button, come pure con qualunque altro controllo di questi framework, è possibile ridefinire completamente il template (si chiama così in gergo) associato che specifica dettagliatamente quali elementi visualizzare, in che modo, quali attribuiti vanno "prelevati" dalla classe Button, e il tutto per ogni possibile stato (disabilitato, abilitato, con focus, clickato), ed eventualmente con specifici effetti di transizione (anche molto complessi) quando si passa da uno stato all'altro.

Tutta questa flessibilità deriva da una geniale gerarchia di oggetti che è stata pensata per evitare di dover estendere spesso una classe per realizzare un componente che abbia determinate caratteristiche (per lo più visive / comportamentali). In genere si cambia lo stile e/o il relativo template (in realtà ce ne sono due: uno per il binding dei dati, e un altro per specificare accuratamente ogni singolo aspetto del controllo, ed è quello di cui ho parlato prima).

Ovviamente anch'io realizzo nuovi controlli, anche derivati da Button, quando si serve, sia chiaro. Solo che lo faccio raramente.

[Allanon]

• 

Ok, quindi secondo il concetto "meglio una feature in più che una in meno" darò la possibilità di inserire anche un'immagine vettoriale con i relativi allinamenti.

@cdimauro
La lib che sto creando permette a qualsiasi controllo di avere dei child, quindi anche all'interno di un pulsante posso inserire qualsiasi altro controllo. Per gli effetti di transizione Hollywood è veramente messo bene e sarà una bazzecola inserirli alla fine quando tutto funzionerà a modino :-)
Dovrò semplicemente aggiungere un paio di campi per il controllo degli effetti e sostituire il comando DisplayBrush con DisplayBrushFX il tutto appoggiandomi ad un'altra libreria che ho scritto tempo fa per gestire le transizioni in maniera asincrona  

[cdimauro]

• 

Ottimo. Comunque io non metterei la possibilità di inserire un'immagine, di qualunque natura essa sia.

Un Button nel suo uso normale prevede soltanto una stringa da visualizzare, per cui il contenitore classico dovrebbe prevedere un controllo Label/TextBlock che la visualizzi.

Se il programmatore ha bisogno di inserire anche un'immagine (o soltanto un'immagine), può benissimo sostituire il contenitore standard con uno ad hoc allo scopo.

[Allanon]

• 

Ottimo. Comunque io non metterei la possibilità di inserire un'immagine, di qualunque natura essa sia.

Un Button nel suo uso normale prevede soltanto una stringa da visualizzare, per cui il contenitore classico dovrebbe prevedere un controllo Label/TextBlock che la visualizzi.

Se il programmatore ha bisogno di inserire anche un'immagine (o soltanto un'immagine), può benissimo sostituire il contenitore standard con uno ad hoc allo scopo.

Al giorno d'oggi ci sono moltissime applicazioni che hanno icone/immagini all'interno dei pulsanti, anche nel settore mobile i pulsanti principali, oltre ad avere un testo, sono spesso accompagnati da un'immagine esplicativa per cui in questo modo semplificherei molto il lavoro di colui che dovrà inserire un'eventuale immagine, pensa solo alla noia di dover allineare a mano l'immagine in base al testo... cmq prima di considerare definitivo il lavoro farò dei benchmarks e se la gestione di eventuali immagini "consuma troppo" la toglierò.
Il sistema per come è progettato non si dovrebbe appesantire specialmente se il programmatore sceglie di utilizzare la cache (switchabile per ogni singolo gadget), in questo caso, in fase di creazione, il gadget viene renderizzato in un brush e successivamente il rendering sarà solo del brush, quindi non ha molta importanza quanti elementi ci sono stati inseriti ma l'impatto lo da solo la dimensione del brush che rappresenta il gadget (comprensivo di eventuali trasparenze della skin).
In caso di modifica o resize invece la cache degli oggetti interessati sarà ricostruita e in quel momento potrei avere qualche piccola perdita di performance...

Inoltre non utilizzo un controllo label all'interno del pulsante ma quattro che rappresentano i singoli stati del pulsante in modo da avere il massimo della personalizzazione e una semplificazione delle routine di rendering/caching.



...dopo alcuni minuti...  
Stavo riflettendo sulla possibiltà di rappresentare il <button> con una classe label e una image proprio come elementi child, questo però non è possibile perchè nel caso volessi renderizzare il testo sopra l'immagine il sistema di layout non me lo permetterebbe perchè può solo gestire elementi con allineamento verticale e orizzontale (forse in futuro anche a griglia), ma non sovrapposti... esiste in altri sistemi questa possibilità?

[cdimauro]

• 

Coi Button di WPF/Silverlight ho totale controllo su quello che dev'essere visualizzato.

Questo significa che l'unico child può essere costituto da:
- uno stack panel con elementi allineati tutti in verticale oppure orizzontale;
- una grid in cui definisco quante righe e/o quante colonne, con relativi allineamenti e vincoli sulle dimensioni (es: i primi 2 controlli e l'ultimo hanno dimensione automatica, mentre il terzo prende tutto lo spazio che può);
- un canvas in cui specificare in maniera precisa dove piazzare i singoli componenti.

Questo solo per fare qualche esempio.

Io non ho problemi di allineamento verticale oppure orizzontale, perché il Button calcola automaticamente la sua dimensione in base ai child che contiene (e i vincoli imposti); è poi la sua area totale a subire, a sua volta, i vincoli definiti per se stesso in base agli altri controlli con cui deve "relazionarsi".

Quindi posso definire se l'area del Button ha allineamento orizzontale e verticali coi rispettivi vincoli (a sinistra, destra, centro, o "stretchato" per riempire lo spazio a disposizione; alto, basso, centrato o stretchato). E ci sono vincoli analoghi per definire l'allineamento del child nell'area a disposizione del Button.

Per fare un esempio pratico, se devo avere un bottone con etichetta + immagine, il suo child lo posso impostare come segue:

Codice: [Seleziona]

<StackPanel Orientantion=Horizontal>
    <TextBlock Text="Questa è una prova" />
    <Image Source="Images/TrashIcon.png" />
</StackPanel>Label a destra, immagine a sinistra; stesso spazio occupato da entrambi.

Codice: [Seleziona]

<StackPanel>
    <Image Source="Images/TrashIcon.png" />
    <TextBlock Text="Questa è una prova" />
</StackPanel>Immagine in alto, label in basso (l'orientamento di default degli StackPanel è verticale); stesso spazio occupato da entrambi.

Codice: [Seleziona]

<Grid>
   <Grid.ColumnsDefinitions>
    <ColumnDefinition Width="Auto" />
    <ColumnDefinition Width="*" />
   </Grid.ColumnsDefinitions>
    <Image Grid.Column="0" Source="Images/TrashIcon.png" />
    <TextBlock Grid.Column="1" Text="Questa è una prova" />
</Grid>Immagine a sinistra, etichetta a destra; l'immagine occupa lo spazio strettamente necessario, mentre il testo tutto lo spazio che può.

[Allanon]

• 

Ok, quindi a parte il fatto che non ho ancora un supporto XML/XAML e un orientamento Grid direi che ci siamo, infatti il tuo stesso esempio posso realizzarlo con:

Codice: [Seleziona]

GroupGad = HGui.Gadget:new(#HGUI_GROUP_GADGET, { caption = { "GROUP" }, window = mywin })
LabelGad = HGui.Gadget:new(#HGUI_LABEL_GADGET, { caption = { "Label gadget" }, window = mywin })
ImageGad = HGui.Gadget:new(#HGUI_IMAGE_GADGET, { image = "test.png" }, window = mywin })

GroupGad:setlayout({ gadgets = { LabelGad, ImageGad }} )
[*]
I layout possono essere nidificati fino a che c'è spazio per visualizzarli.

Ho omesso una miriade di opzioni quali "i pesi" dei due gadget all'interno del gruppo, l'allineamento (vericale di default), i bordi e altri parametri di tuning. Così come ho scritto i due gadget saranno ridimensionabili in base al contenitore con dimensioni equamente ripartite.

Un esempio di definizione di un pulsante con icona uguale su tutti e quattro gli stati potrebbe essere:

Codice: [Seleziona]

myButton = HGui.Gadget:new(#HGUI_BUTTON_GADGET,
                           { look = { icons = { iname = "Test_Icon",
                                                alignment = #HGUI_ALIGN_LEFT + #HGUI_ALIGN_VCENTER }},
                             caption = { "BUTTON", "YEAH!" },
                             actions = { onpushed = EventTester },
                             window = mywin3 })
In questo modo, di default, avrò l'icona posizionata a sinistra e centrata verticalmente nel pulsante, mentre il testo sarà centrato orizzontalmente nello spazio rimanente e verticalmente nel pulsante.
Tuttavia se avessi specificato il tag seguente nello stesso scope di <icons>:

Codice: [Seleziona]

AdjText = False
Il testo sarebbe stato centrato orizzontalmente senza tenere conto dell'icona e quindi con la possibilità di sovrascriverla che in alcuni casi potrebbe venire utile, tipo (mockup):

Questa visualizzazione utilizzando due child non è possibile




[*]
Avrei potuto anche nidificare la costruzione degli oggetti direttamente nella definizione del layout:

Codice: [Seleziona]

GroupGad = HGui.Gadget:new(#HGUI_GROUP_GADGET, { caption = { "GROUP" }, window = mywin })

GroupGad:setlayout({ gadgets = { HGui.Gadget:new(#HGUI_LABEL_GADGET, { caption = { "Label gadget" }, window = mywin }),
                                 HGui.Gadget:new(#HGUI_IMAGE_GADGET, { image = "test.png" }, window = mywin }) }} )

Ma così è meno leggibile e più incasinato in caso di modifiche del codice...

EDIT: corretto un errore di digitazione

[cdimauro]

• 

OK, è molto flessibile anche questo sistema.

Riguardo alla sovrapposizione di più controlli, in WPF/Silverlight si può fare con la Grid se non si definiscono righe e/o colonne, oppure col Canvas, che permette di piazzare arbitrariamente i controlli dove si vuole.

Adesso ti manca, appunto, qualcosa come XAML (il massimo sarebbe XAML stesso, se fosse possibile, in modo da riciclare paro paro gli editor di GUI di casa Microsoft, che sono spettacolari), che nonostante sia XML come vedi è semplicissimo da utilizzare per definire la struttura della GUI senza ricorrere al codice.

[Allanon]

• 

Appena avrò implemento tutti i controlli base passerò a XAML sicuramente
Grazie per ora per tutte le dritte e a risentirci al prossimo dubbio  :lol:

[Allanon]

• 

Riesumo questo thread per sottoporvi una soluzione possibile che vorrei implementare per reallizare una sorta di connessione fra i vari elementi delle GUI.

Allora, ho appena implementato la classe <Switch> nella mia libreria e stavo pensando a come implementare la prossima classe che serve ad ottenere gruppi di elementi <Options> e <Radio> buttons.
Alla fine questi gruppi non sono altro che insiemi di <Switch> dove nel primo caso, <Options>, possono essere selezionati elementi multipli, mentre nel secondo caso, <Radio> una selezione esclude tutte le altre.

Al fine di rendere l'implementazione più semplice, ma anche più flessibile, ho pensato di non implementare una classe apposita ma bensì di lasciare al programmatore la facoltà di creare questi gruppi si switch liberamente all'interno della propria GUI e successivamente implementare una funzione che raggruppi questi elementi così che l'engine sia in grado di riconscere questi gruppi per gestirli correttamente.

Esempio, supponiamo che voglia creare una GUI del genere:

Codice: [Seleziona]

--- layout GUI ---
[SwitchA][RadioA ]
[SwitchB][RadioB ]
[SwitchC][SwitchD]
         [RadioC ]
Tutti gli elementi sono <Switch>, ma ho bisogno di identificare il gruppo che racchiude tutti i Radio per poterli gestire correttamente, quindi avevo pensato ad una funzione che possa fare questa operazione:

Codice: [Seleziona]

HGui.Links:new(link_type, data)
In questo esempio specifico sarebbe:

Codice: [Seleziona]

HGui.Links:new(#HGUI_LINKTYPE_RADIO, { objects = { RadioA, RadioB, RadioC }})
Questa funzione creerebbe un oggetto <Link> che mi tiene traccia del collegamento fra gli switch e memorizzerebbe il puntatore a tale oggetto in un campo <Links> di ogni oggetto coivolto.
In questo modo quando ho un'interazione con l'oggetto posso immediatamente verificare nel suo campo link se ci sono connessioni o raggruppamenti e gestire con estrema semplicità la sua funzione.
Ovviamente ogni oggetto potrà avere più link e quindi uno stesso Radio ad esempio potrebbe far parte di due o più gruppi permettendo dinamiche semplici da realizzare per gui complesse.

Questa stessa funzione avrei intenzione di utilizzarla anche per creare link fra oggetti di tipo diverso, per esempio potrei collegare una ListView ad una Label o una StringBox per fare in modo che una volta selezionato un elemento della lista view l'oggetto collegato venga automaticamente aggiornato senza alcun codice supplementare.

Spero di essermi spiegato bene perchè stamattina l'elettricità che c'è nell'aria mi sta fulminando quei quattro neuroni che ho nella capoccia

Più che altro vorrei sapere se secondo voi un'implementazione del genere potrebbe essere buona cosa oppure se implementare una classe "Options" o "Radio" sarebbe meglio (anche se secondo me molto più limitante).
 :ugeek:

[cdimauro]

• 

In questi casi è meglio una classe "container" / panel che raggruppi, appunto, un certo insieme di elementi.

Tutti gli elementi alla fine hanno sempre un "parent", e tramite questa relazione è possibile discriminare se sono figli dello stesso padre , per cui nel caso dei RadioButton si può sapere quali sono gli altri "fratelli" e agire di conseguenza quando ne viene selezionato uno (deselezionando quello precedente, eventualmente).

Non ho capito, invece, l'utilità di poter aver un oggetto collegato a più gruppi.

Per collegare oggetti diversi in modo da automatizzare alcune operazioni, potresti implementare il modello dei binding di Silverlight/WPF, di cui ti ho parlato prima.

[Allanon]

• 

In questi casi è meglio una classe "container" / panel che raggruppi, appunto, un certo insieme di elementi.

In effetti sono partito proprio con questa idea che è quella più naturale poi però ho pensato alla possibilità di gestire insiemi di opzioni con elementi non compatibili e da li ho partorito questa idea, supponi di voler rappresentare due insiemi di opzioni con alcuni elementi non compatibili fra loro:

A, B, C, D possono avere una selezione multipla
E, F sono incompatibili con A, B, C, D, ma compatibili fra loro quindi se li seleziono qualsiasi opzione incompatibile dev'essere disattivata
Come li rappresenti con una GUI classica?

Col mio sistema dovrei definire un container che contenga le opzioni A, B, C, D, E, F (solo per fini estetici per il layout).
Poi con la funzione supposta farei:

Codice: [Seleziona]

HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { A, E } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { B, E } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { C, E } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { D, E } })

HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { A, F } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { B, F } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { C, F } })
HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { D, F } })

Se invece dovessi implementare il classico gadget dei RADIO basterebbe una sola riga:

Codice: [Seleziona]

HGui.Link:new(#HGUI_LINKTYPE_RADIO, { Objects = { A, B, C, D, E, F } })

Tutti gli elementi alla fine hanno sempre un "parent", e tramite questa relazione è possibile discriminare se sono figli dello stesso padre , per cui nel caso dei RadioButton si può sapere quali sono gli altri "fratelli" e agire di conseguenza quando ne viene selezionato uno (deselezionando quello precedente, eventualmente).

Si, questo è chiaro, ma in questo specifico caso le opzioni sono trattate come entità singole, ma se il programmatore vuole le "infila" in un cantainer (classe Group) e se li ritrova tutti nel campo Childs del contenitore.

Non ho capito, invece, l'utilità di poter aver un oggetto collegato a più gruppi.

Come vedi nell'esempio che ho fatto gli oggetti switch sono collegati fra loro da molteplici relazioni (2 per A, 2 per B, ... 4 per E e 4 per F), oltre a questo caso, con questa implementazione, sarebbe molto semplice collegare gli oggetti fra loro per degli aggiornamenti automatici, metti che ho una ListView e che il suo elemento corrente vorrei che fosse rappresentato nello Switch A, dovrei solo aggiungere nel codice questa riga (sto ancora teorizzando ):

Codice: [Seleziona]

HGui.Link:new(#HGUI_LINKTYPE_CAPTION, { Source = MyListViewObject, Destination = A })

Non lo so se sto prendendo una cantonata, ma questa implementazione mi sembrerebbe decisamente più flessibile di una classe separata apposita per questo tipo di gadget, senza contare poi il discorso di collegamente multipli fra oggetti e delle automazioni sugli aggiornamenti dei gadget senza ustilizzare codice aggiuntivo da parte del programmatore (e quindi risparmio di tempo).
E' ancora tutto a livello teorico, non ho scritto una sola riga di codice perchè, appunto, volevo qualche parere


...mumble mumble...