2009-10-29 14 views
8

Come è possibile utilizzare il browser come interfaccia utente per un'app desktop? I modi in cui sono arrivato fino ad ora sono ...Utilizzo del browser per l'interfaccia utente del desktop

  1. Usa tutto HTML/Javascript. Problema: impossibile accedere al filesystem o qualsiasi altra cosa.
  2. Eseguire un server web locale mentre l'applicazione è in uso. Problema: come posso ucciderlo quando l'utente ha finito? I miei utenti non sono abbastanza tecnici per Ctrl + C.
  3. Incorpora un componente del browser in una GUI regolare. Problema: i componenti del browser incorporati tendono a essere al massimo glitch. Il supporto per Javascript/CSS non è mai buono come in un browser reale.
  4. ...?

La soluzione ideale funzionerebbe con qualsiasi tecnologia. So che ci sono opzioni come scrivere estensioni di Firefox, ma voglio avere completa libertà nella tecnologia back-end e l'indipendenza del browser.

+1

Interessante si dovrebbe chiedere: Sto creando un plug-in NPAPI (Firefox, Chrome) per scoprire "applicazioni desktop" disponibili tramite HTTP. È basato su Avahi mdns Service Discovery. – jldupont

+1

Ho anche aperto alcuni "bug" su Chromium per aiutare a raggiungere questo obiettivo. – jldupont

risposta

2

In Windows, è possibile incorporare il controllo ActiveX di IE, che utilizza lo stesso motore di rendering di IE. (Questo è un plus e un meno) È possibile impostare la proprietà ScriptObject nel codice host e accedervi in ​​Javascript come window.external per fare cose che Javascript non può fare.

Se si esegue un server Web locale, è possibile avere un collegamento di uscita nell'app che uccide il websever.

+0

Quello che ho problemi a capire è come scrivere il kill link. Ho trovato una soluzione, ma è molto hacky. I server che ho provato sono tutti stati Python, ma qualsiasi tipo di esempio concreto sarebbe stato interessante. –

+0

E ovviamente c'è il problema che l'utente non può fare clic sul collegamento kill. –

+0

Se si ospita un controllo WebBrowser, è possibile chiudere il server quando l'app host viene chiusa.Altrimenti, potresti uccidere il server qualche tempo dopo l'ultima richiesta e inviare heartbeat nelle tue pagine nel caso in cui l'utente lasci da solo per un po '. Oppure, potresti lasciarlo funzionare. – SLaks

1

Non hai menzionato il sistema operativo che dovrai scegliere come target. Ma potresti essere in grado di creare un server Web statared del programma, quindi pubblicare il browser predefinito. Attendere fino alla fine del browser da parte dell'utente e quindi spegnere il server Web.

Quindi per esempio su Windows è possibile utilizzare CreateProcess() per generare il processo quindi MsgWaitForMultipleObjects() per attendere fino al termine dell'esecuzione.

+0

L'indipendenza del sistema operativo sarebbe favolosa, ma Windows è ciò su cui sto lavorando. Sembra che potrebbe funzionare. L'utente potrebbe comunque lasciare aperto il browser e usarlo per navigare in altri siti, ma almeno so * alla fine * si chiuderà. Potrebbe esserci un problema se il browser decide di aprire l'app in una nuova scheda anziché in un nuovo browser. Penso che Firefox lo faccia anche quando viene chiamato dalla riga di comando. –

+2

Se aspetti che il browser si chiuda, non smetteremo mai di aspettare. Ricorda che tutti i browser moderni supportano le schede, in modo che molte persone, me compreso, eseguano un browser 24 ore su 24, 7 giorni su 7. – SLaks

+1

Inoltre, se il browser è già in esecuzione, non sarà nemmeno possibile attendere un nuovo processo. – SLaks

8

Si noti che se si sceglie di eseguire un server Web locale, si sta creando un rischio per la sicurezza.

Qualsiasi pagina Web in esecuzione sulla stessa macchina che conosce la tua app può inviare richieste al tuo server utilizzando Javascript e non hai un modo semplice e affidabile per sapere da che cosa proviene la richiesta. (Non fidatevi dell'intestazione referer)

Google Desktop, che utilizza un approccio simile, ha avuto diverse vulnerabilità reali che consentono a qualsiasi pagina Web di leggere qualsiasi file sul disco.

Esistono diversi modi per proteggersi da questo; Suggerirei che ogni richiesta richieda una chiave di autenticazione generata in modo casuale per macchina (e che scada a un certo punto), che è possibile inserire nella sorgente per le pagine effettive. La protezione XHR impedirebbe ai siti Web malintenzionati di leggere la chiave di autenticazione, rendendoli impotenti.

+1

Impossibile impostare il server locale in modo che accetti solo le richieste dalla stessa macchina su cui è in esecuzione? –

+0

Sì; Intendevo che Javascript sullo stesso client potesse inviare tali richieste. – SLaks

+1

Interessante .... –

1

Applicazioni HTML (HTA, in breve) sono in circolazione da un po 'di tempo. Puoi leggere tutto su di loro here. Sono fondamentalmente HTML e Javascript con alcune opzioni extra per creare una finestra e con accesso al file system locale. Sembrano essere esattamente ciò che vuoi. È la tecnologia Microsoft, quindi funzionerà solo con IE su sistemi Windows. L'ho usato con successo come front-end per un CD-ROM che è stato usato per distribuire software agli studenti del primo anno

Un'altra opzione sarebbe quella di utilizzare Adobe Air. Non sono così familiare con la tecnologia, ma sembra fornire una struttura per distribuire le pagine Web come applicazioni desktop.Non posso pubblicare un secondo link come ospite, ma google e lo troverete abbastanza presto.

+0

In realtà, questo è esattamente ciò che non voglio, perché "Voglio avere completa libertà nella tecnologia back-end e indipendenza del browser". –

4

Se si sta cercando un server Web Python con un collegamento Kill, è possibile verificare sempre CherryPy.

import webbrowser 
import cherrypy 
import threading 

class MyApp: 
    """ Sample request handler class. """ 

    @cherrypy.expose 
    def index(self): 
     return """<html><head><title>An example application</title></head> 
<body> 
<h1>This is my sample application</h1> 
Put the content here... 
<hr> 
<a href="/exit">Quit</a> 
</body></html>""" 

    @cherrypy.expose 
    def exit(self): 
     raise SystemExit(0) 


class MyBGThread(threading.Thread): 
    def __init__(self): 
     threading.Thread.__init__(self) 
     self.start() 

    def run(self): 
     cherrypy.tree.mount(MyApp()) 
     cherrypy.quickstart() 

myThread = MyBGThread() 
webbrowser.open("http://127.0.0.1:8080") 

Questo codice è basato sul campione dalla SingleClickAndRun sul sito cherrypy: http://tools.cherrypy.org/wiki/SingleClickAndRun

Nota che in una WebApp normale si sarebbe probabilmente utilizzare un motore di template e modelli di carico da metodi come principale.

Qualcosa che sarebbe bello sarebbe quello di emettere un controllo del browser in una finestra di Gui e chiudere il server quando l'app si chiude.

Per la sicurezza, è possibile aggiungere uno schema di autenticazione. Ce ne sono alcuni che sono supportati da cherrypy, ma potresti anche implementarne uno tuo, usando i moduli degli strumenti.

+0

Questo è il tipo di cose che sto cercando. Grazie. –

4

Sto cercando di fare esattamente la stessa cosa (applicazione desktop che utilizza un browser HTML5/CSS3 aggiornato come interfaccia grafica dell'applicazione desktop), solo con Ruby (vari motivi per cui ho deciso di lavorare con Ruby). È sorprendente il numero di librerie multipiattaforma che le persone hanno escogitato. Ma ancora, pochi a nessuno, ha lavorato sul tentativo di far diventare un browser web un'interfaccia utente per desktop. Problema cross platform ... beh non lo dirò risolto, ma dirò diversi passi nella giusta direzione presa.

Per me questo sarebbe perfetto con i nuovi standard HTML5/CSS3 in uscita. So che può essere fatto con un server web in esecuzione localmente.

Un altro modo potrebbe essere come i ragazzi di "280 North" stanno facendo quello che fanno. Hanno sviluppato Objective-J (un'estensione del normale JavaScript che imita il modo in cui Objective-C estende C) e Cappuccino (l'equivalente Objective-J del frame Cocoa di Objective-C funziona sul MAC). Hanno anche sviluppato "Atlas" che è la versione 280 di North "Interface Builder" di Apple da Xcode, per i loro framework Objective-J e Cappuccino per creare applicazioni Internet. Atlas è in realtà un'applicazione web Cappuccino in esecuzione sul desktop come app desktop. In questo caso usano il Narwhal ... una piattaforma multipiattaforma, di uso generale, piattaforma JavaScript per lo sviluppo di app JS al di fuori del browser (fondamentalmente un server web specializzato).

Se qualcuno ha un'idea per far funzionare "Browser, direct connect to Desktop App" senza la necessità di un server Web coesistente e comunque di manipolare le FS locali, sarei molto interessato ... Hmmm ... Ora che ci penso, mi chiedo se il nuovo progetto "Native Client" di Google Chrome possa essere usato per farlo. NaCL è molto simile a Active X tranne che non sei limitato a una piattaforma Windows (ma sarà limitato al browser Google Chrome, almeno per ora). Solo c'è una maggiore sicurezza tramite Sandboxing, ma puoi manipolare le FS locali ... Più ci penso, più comincio a sospettare che possa essere fatto.

Qualche idea?

Problemi correlati