|
|
 Up |
|
|
  |
Author: Y3sY3s
Date: Dec 16, 2006 17:41
Il Sun, 17 Dec 2006 02:25:20 +0100, Giovanni Bajo ha scritto:
> Y3s wrote:
>
>> Nel senso che una cosa del genere viola ogni principio e guideline di
>> usabilità .
>
> Il fatto di avere dei controlli "custom" non viola nessuna guideline di
> usabilità . Chiaramente, non stiamo parlando di controlli assurdi, ma di
> semplici modifiche e potenziamenti a controlli già di base esistenti.
>
Dipende...ogni piattaforma ha la sua guideline, e violarla non è una buona
idea a meno che non sia davvero indispensabile
> Il fatto di fare una scrollbar un po' più stretta non è assolutamente brutto a
> vedersi né scomodo ad usarsi. Sotto Windows per esempio le "tool window" hanno
> sempre dei controlli in "miniatura" (tool button più piccoli dei push button,
> la title bar più sottile, così come anche il tasto "x" di chiusura). In queste
> finestre, una scrollbar più sottile è addirittura migliore a vedersi e più in
> linea con l'aspetto grafico.
>
|
| Show full article (3.96Kb) |
|
| |
1 Comment |
|
|
Author: Y3sY3s
Date: Dec 16, 2006 16:40
Il Sun, 17 Dec 2006 00:43:54 +0100, Hobbit ha scritto:
>> produrre, immagino che siano veramente pochi quelli che hanno bisogno di
>> un controllo così preciso sulle dimensioni, a parte chi scrive CAD o altro
>> genere di programmi di grafica, ma a quel punto ci si affida a opengl et
>> similia...
>
> In che senso? Con OpenGL fai il renderering, ma per i controlli ti serve
> una gui come qt o wx!
>
> Bye
>
Nel senso che una cosa del genere viola ogni principio e guideline di
usabilità . Con qt si può fare, con altri toolkit è difficile o
impossibile, ma in ogni caso nel caso generale non si desidera farlo in
quanto è un errore di progettazione della gui. A meno che non si tratti di
programmi tipo cad/cam ecc, ma in quel caso meglio utilizzare altri
sistemi, tipo appunto opengl per il 3D e magari le primitive di disegno
esposte dagli oggetti wxDC per il 2D...
|
| |
|
| |
1 Comment |
|
|
Author: Y3sY3s
Date: Dec 16, 2006 12:48
Il Sat, 16 Dec 2006 20:06:30 +0000, Manlio Perillo ha scritto:
[CUT]
>> Quindi, a meno di non
>> riscrivere la classe wxDialog da zero (non che sia impossibile,
>> soprattutto in python è semplice sostituirla in modo trasparente
>> all'utente), questo approccio non può funzionare.
>>
>
> E se eseguissi le sole finestre di dialogo modali in un thread?
> Sono thread safe?
>
Non lo so, ma a questo punto meglio cercare un'altra strada...
--
Digital circuits are made from analog parts.
-- Don Vonada
|
| |
|
no comments
|
|
|
Author: Y3sY3s
Date: Dec 16, 2006 12:47
Il Sat, 16 Dec 2006 19:58:36 +0000, Manlio Perillo ha scritto:
> Il Sat, 16 Dec 2006 19:09:01 +0000, Y3s ha scritto:
>
>> [...]
>>> Puoi fare così:
>>>
>>> internet.TimerService(0, gtk.main_interaction, ...)
>>>
>>
>> Ecco, questo non lo conoscevo...ma come reattività , com'è su gtk?
>>
>
> Non lo so, ma con le GTK usi il reattore dedicato, quindi il problema non
> si pone.
>
Certo, era giusto una curiositÃ
|
| Show full article (2.76Kb) |
|
no comments
|
|
|
Author: Manlio PerilloManlio Perillo
Date: Dec 16, 2006 12:06
Il Sat, 16 Dec 2006 19:56:48 +0000, Y3s ha scritto:
>> Se la GUI si mantiene "pronta" e il reattore non si blocca troppo a lungo,
>> potrebbe essere un buon compromesso (tra l'altro è così che funziona il
>> reattore per Windows).
>>
>> Fammi sapere, mi interessa.
>>
>>
>
> Ok, il problema (come avevo letto e mi ero scordato) è che i dialog modali
> bloccano il reactor.
Ok, quindi avevo avuto l'impressione giusta quando ho letto il capitolo
demo del libro riguardo le finestre di dialogo ;-).
> Questo perchè le finestre di dialogo, quando utilizzate come "modal"
> utilizzano un proprio event loop interno, e questo è anche il problema
> principale del wxreactor se non sbaglio.
Mi sembra che anche le GTK facciano qualcosa di simile.
|
| Show full article (1.09Kb) |
|
no comments
|
|
|
Author: Manlio PerilloManlio Perillo
Date: Dec 16, 2006 11:58
Il Sat, 16 Dec 2006 19:09:01 +0000, Y3s ha scritto:
> [...]
>> Puoi fare così:
>>
>> internet.TimerService(0, gtk.main_interaction, ...)
>>
>
> Ecco, questo non lo conoscevo...ma come reattività , com'è su gtk?
>
Non lo so, ma con le GTK usi il reattore dedicato, quindi il problema non
si pone.
|
| Show full article (1.97Kb) |
|
no comments
|
|
|
|
|
|
|
|
|
Author: Y3sY3s
Date: Dec 16, 2006 11:03
Il Sat, 16 Dec 2006 19:51:00 +0100, Giovanni Bajo ha scritto:
> Y3s wrote:
>
>> IMHO nessuno dei tre toolkit che vanno per la maggiore (wx,gtk,qt) ha una
>> netta prevalenza sugli altri. Ognuno è leggermente meglio in qualche
>> specifico dettaglio, ma sono del tutto equivalenti. Escludo tkinter perchè
>> ha pochissimi widgets di suo e la resa grafica è davvero bruttina, quindi
>> perde di netto su almeno due punti che per una GUI sono piuttosto
>> importanti.
>
> Il problema principale di wxPython è la sua intrinseca mancanza di portabilitÃ
> dovuto all'uso delle API native della piattaforma. Finché sviluppi semplici
> applicazioni con poche pretese, e usi tutti widget "normali", non c'è alcun
> problema ovviamente.
>
Dipende da che punto di vista lo guardi. Per te è un problema, per altri è
il vantaggio principale. Tutto ovviamente dipende dal genere di uso che ne
devi fare...
|
| Show full article (4.18Kb) |
|
1 Comment |
|
|
|
|
|
Author: Manlio PerilloManlio Perillo
Date: Dec 16, 2006 10:59
Il Sat, 16 Dec 2006 18:31:46 +0000, Y3s ha scritto:
> [...]
>
>> Un'altra soluzione è eseguire Twisted nel thread principale e ad ogni
>> ciclo del mainloop aggiornare la gui.
>>
>> Ad esempio:
>>
>> reactor.callLater(0, gtk.main_iteration, block=False)
>>
>
> Funziona bene? E dove chiami questa callLater?
>
Puoi fare così:
internet.TimerService(0, gtk.main_interaction, ...)
|
| Show full article (1.15Kb) |
|
no comments
|
|
|
|
|
|
|
