Punto della situazione e start-up progetto

[dorje]

In sostanza, le chiamate ai vari screens arriverebbero via dbus, correct?

Ma ciò non rallenterebbe il tutto?

[djdas]

@monto: sarebbe il caso di parlarne con i devs della UI per capire se usando semplicemente i temi si possa fare, l'idea è buona però non riesco ad immaginare come si possa realizzare una GUI dinamica implementandola direttamente (citando il tuo esempio: dentro la gui.missed_calls() il programmatore QT mette il display e i tasti in un certo modo, ma poi a runtime mica li puoi spostare, idem per chi fa la GTK...o mi sono perso qualcosa?)
@dorje: dbus chiamato via API in C è low latency quindi (a meno di non sovraccaricarlo con migliaia di messaggi, ma a quanto pare l'unica cosa che lo ha messo in ginocchio finora sul moko - ma in python! - è stata la lettura dei dati dagli accelerometri) dovrebbe essere abbastanza veloce.
Ciau!

[dorje]

@monto: sarebbe il caso di parlarne con i devs della UI per capire se usando semplicemente i temi si possa fare, l'idea è buona però non riesco ad immaginare come si possa realizzare una GUI dinamica implementandola direttamente (citando il tuo esempio: dentro la gui.missed_calls() il programmatore QT mette il display e i tasti in un certo modo, ma poi a runtime mica li puoi spostare, idem per chi fa la GTK...o mi sono perso qualcosa?)

Penso lui intendesse dire di "spaccare" le cose in modo che poi... Noi con la nostra distro facciamo comunque la nostra gui, ma altri possono sfruttare lo stesso "coso" con gui implementate in maniera del tutto diversa.

La cosa che mi sfugge è però come si possa creare un "contenitore" che precarichi tutto (perché le "main apps" abbiamo deciso di precaricarle tutte, no?)... Perché in questo modo i vari dialer, messages ecc. diventano applicazioni a se stanti, no?

[djdas]

Beh basta fare un demone che viene lanciato all'apertura di X per inizializzare la parte grafica correttamente senza mostrarla, rispondendo via dbus quando serve per cui tu lo chiami chiedendogli lo show del dialer piuttosto dei messaggi e lui fa apparire la finestra già precaricata
Almeno questo è quello che mi pare di intuire da ciò che ha scritto monto anche in altri post, se mi sbaglio chiedo scusa
Qtopia fa già così, se provi ad aprire ad es l'orologio o il calendario e poi li richiudi, se killi il processo applauncher (mi pare) ti appare la popup che dice che hai killato anche clock e calendar.
Ciau!

[monto]

no no io intendevo compilarla staticamente dentro il programma e basta, se vogliamo velocizzare il tutto va tralasciato ogni sorta di dinamismo, vorrei altrimenti guardare se esiste (sicuro comunque che c'è) un sistema di "plugin" per c/c++, quindi magari basterebbe implementare la gui, compilarla in un .so che rispetti le specifiche e rimpiazzare quello di default con quello nuovo. Comunque è tutto da vedere.

[djdas]

Sinceramente non ho mai sentito cose del genere a parte libglade per GTK che ti consente di creare al volo le GUI passando un semplice .glade (che è un XML) al programma anche a runtime, ma onestamente non l'ho mai usato 
Ciau!

[dorje]

Sinceramente non ho mai sentito cose del genere a parte libglade per GTK che ti consente di creare al volo le GUI passando un semplice .glade (che è un XML) al programma anche a runtime, ma onestamente non l'ho mai usato 

Mmmmm.... Credo che non sia da usare un .xml per configurare la GUI a runtime...

Anche se la home di qtopia e il dialer stesso mi pare siano implementati proprio così!

[djdas]

Diciamo che sono strascichi da desktop, però visto che ci sono....tanto si può sempre fare del test di velocità bruta
Ciau!

[monto]

no no no nulla di tutto quello che pensate.
Un "plugin" ovvero ho il programma linkato a gui.so che implementa di default la gui in gtk+ per esempio, io prendo e faccio un gui.so che implementa la gui in qt e lo sostituisco a quello di default. compilato statico e grezzo volendo ma efficace penso (supponendo per assurdo che si possa fare).
Se ci mettiamo a usare i glade, dbus per la gui o altro si aumenta la complessità della cosa di parecchio e soprattutto si aggiungono layer di astrazione a runtime che secondo me rendono il tutto parecchio più lento.
Ovviamente sto parlando senza aver fatto un minimo test e senza sapere se la mia idea è fattibile.

[djdas]

Uhm...teoricamente è fattibile, però sempre attraverso un nostro framework, mi spiego:
- bisogna realizzare una libgui.so (per citare il tuo esempio) le cui API sono un po' come quello che scrivevo sopra (l'idea geniale di Xela ) dopodiché si fanno due (o più) libgui che sotto hanno GTK, QT (etc) con le implementazioni delle interfacce;
- all'atto della compilazione si linka una delle due e la si utilizza come default oppure si linka una libgui che ha i metodi delle API ma senza implementazioni (potrebbe ad es essere la versione per console )
- nel "pacchetto" si rilasciano tutte le altre e si permette tramite dei link soft di scegliere quale libgui usare.
Ciau!

[nicola.mfb]

Alcune considerazioni:

*) alcuni toolkit, come QT o E, non si limitano solo a creare interfacce grafiche, ma sono dei veri e propri framework che hanno caratteristiche ben precise, ossia hanno un loro loop event, e supportano tantissime altre cose come dbus, xml, network, etc.
*) gli internals sono difficili da wrapperizzare, ad esempio il meccanismo di signal/slot proprio di qt, o gli evas signal di E

ciò implica che andrebbe wrapperizzato tutto per QT ed E, non solo la parte widget, e *scritto* il "driver" di astrazione per i toolkit che non si interessano di dbus, xml e soprattutto per la parte loop event.

La vedo davvero un lavoraccio enorme, ma se si trova una soluzione...

[dorje]

La vedo davvero un lavoraccio enorme, ma se si trova una soluzione...

Anch'io lo vedo come lavoraccio enorme...

Io propongo: facciamo l'applicazione "all in one" (per le apps principali, ovvio) e in parallelo (se avanza tempo) vediamo di fare anche 'sta cosa?

Perché sarebbe bello non dover aspettare 1 annetto per aver qualcosa da "far vedere".

[monto]

scuate, è un lavoro grosso ok, ma non enorme come la vedete voi, ovvero il concetto è di tenere TUTTO separato in varie classi.
Ognuno si implementa poi come gli pare le varie parti "periferiche" dell'applicazione, ad esempio per dbus si fanno delle chiamate ad un oggetto che wrappa dei metodi ad esempio di glib, a te glib non piace e vuoi usare qt? reimplementi quella classe e la metti al posto di quella glib. Per la grafica istess. Questo evidentemente porta ad avere 2 mainloop se si usano libs che lo richiedono che girano in thread separati e uno si preoccupa della gestione dbus, mentre l'altro si preoccupa della gestione GUI.

[nicola.mfb]

scuate, è un lavoro grosso ok, ma non enorme come la vedete voi, ovvero il concetto è di tenere TUTTO separato in varie classi.
Ognuno si implementa poi come gli pare le varie parti "periferiche" dell'applicazione, ad esempio per dbus si fanno delle chiamate ad un oggetto che wrappa dei metodi ad esempio di glib, a te glib non piace e vuoi usare qt? reimplementi quella classe e la metti al posto di quella glib. Per la grafica istess. Questo evidentemente porta ad avere 2 mainloop se si usano libs che lo richiedono che girano in thread separati e uno si preoccupa della gestione dbus, mentre l'altro si preoccupa della gestione GUI.

Possiamo scendere ad un livello + tecnico? inizio io con qt:

*) classe fsolib: pilota fso via dbus, ho uno SLOT chiamato: occupyResourceCpu()
*) classe MiaFinestra: ha un push button chiamato "non sospendere", con un segnale clicked()
*) main.cpp: crea un'instanza di fsolib e mia finestra, collega clicked con occupyResourceCpu()
*) main.cpp esegue: app.exec()

app.exec() è l'event loop di qt, ed in questo caso ascolta gli eventi di X e di dbus, se riceve il pushbutton richiama automaticamente il metodo occupyResourceCpu senza che le due classi si conoscano.

Ora supponiamo di avere il gui wrapper, a quel punto ho un creafinestra, creabottone etc che mi restituisce un *GenericWindow, (e già qui ho problemi perchè chi mi genera la metaobject di qt? devo scrivere anche un wrapper per uic/moc etc?) lancio un altro thread con gtk, come faccio a fare in modo che quando premo il pulsante in gtk mi venga chiamato lo slot qt in fsolib? dovrei scrivere un wrapper che dipende contemporaneamente sia da gtk che da qt, poi da E etc, che mi simuli un oggetto QT etc (oggetto che ha sempre bisogno di moc - metaobject compiler).

Insomma, io nel ragionamento mi sto perdendo, se avete le idee + chiare tiratele fuori

[monto]

no il concetto che forse non è chiaro è la SPECIALIZZAZIONE delle varie classi. La classe GUI si occupa della gestione della GUI, si occupa solo di creare finestre con bottoncini o immagini tramite i parametri che gli vengono passati. La classe dbus si occupa solo di fare da tramite tra il mondo e dbus.
Esempi pratici:
teniamo in considerazione la seguente implementazione, ogni classe ha un thread:
dbus_manager, gui_manager, call_manager, contact_manager

Arriva una chiamata
dbus_manager intercetta l'evento
lo passa a call_manager.incoming_call()
call_manager chiama contact_manager.do_we_know_this_number()
contact_manager controlla se abbiamo il contatto da qualche parte
si chiama gui_manager.show_incoming_call()
premendo sul pulsantino "accetta/rifiuta" di gui_manager si chiama call_manager.accept()
call_manager chiama dbus_manager.accept_call()
call_manager chiama gui_manager.close_show_incoming_call()
call_manager chiama gui_manager.show_active_call()
si parla
premendo sul pulsantino "attacca" di gui_manager si chiama call_manager.kill_call() e si chiude la finestra
call_manager chiama dbus_manager.kill_call()
fine della telefonata.

In realtà il chiamare dbus_manager non dovrebbe essere così, altrimenti ci sarebbe da fare un implementazione per ogni oggett/funzione, sarebbe più una cosa generica tipo
dbus_manager.call_method(dbus_object, method_name, params)
o qualcosa di simile.

In questo modo la gui è ridotta a tale scopo e ogni toolkit viene usato SOLO ed esclusivamente per la grafica nella classe GUI.
Ora è tutto come mi è venuto, penso che in realtà sarù più pulito.