Ho letto in giro che quando vengono creati programmi Linux si inizia a creare l' applicazione funzionante da console e poi la gui.
Nel software che realizzo dovrò prevedere dunque la possibilità di inviare comandi da console.
Nel caso di un videoplayer dovrò quindi prevedere la possibilità di inviare il comando "Pausa" da console.
Il dubbio è questo. So che i parametri al programma possono essere passati solo quando questo viene lanciato.
Ci sono dunque delle contraddizioni.
Deve esserci qualcosa di inesatto in ciò che ho letto.
Non posso postare la fonte in quanto ho letto ciò parecchio tempo fa e non ricordo dove.
Grazie!
Programma in c da console
Moderatori:
Paolino,
fairyvilje
21 messaggi
• Pagina 1 di 3 • 1, 2, 3
0
voti
non programmo in linux, tuttavia è vero che i parametri si passano solo all'avvio; ma il comando "pausa" non è un parametro ma un comando, dunque deve essere lanciato successivamente all'avvio del programma (con o senza parametri).
In pratica, lanci il tuo programma, il quale avrà una interfaccia utente (grafica o testuale) dalla quale lancerai i tuoi comandi (come "pausa", "play", ecc...).
In pratica, lanci il tuo programma, il quale avrà una interfaccia utente (grafica o testuale) dalla quale lancerai i tuoi comandi (come "pausa", "play", ecc...).
0
voti
Attualmente eseguo i comandi da tastiera ad esempio tasto s=play tasto p=pausa.
Utilizzo lo switch per chiamare la funzione specifica.
A me non interessa tanto la presenza di una gui ma il fatto che possano essere eseguiti comandi quali pausa, play, etc. mediante uno script esterno.
Quando ho letto l' articolo non avevo in mente tutto ciò e quindi non l' ho neppure preso in considerazione.
E' possibile anche che volesse dire tutt' altro.
Utilizzo lo switch per chiamare la funzione specifica.
A me non interessa tanto la presenza di una gui ma il fatto che possano essere eseguiti comandi quali pausa, play, etc. mediante uno script esterno.
Quando ho letto l' articolo non avevo in mente tutto ciò e quindi non l' ho neppure preso in considerazione.
E' possibile anche che volesse dire tutt' altro.
0
voti
E cosa dovrebbe fare questo script esterno? Quale dovrebbe essere la sua funzione?
E' un file batch? Una sequenza di tasti o di comandi da inviare al programma ... o cosa?
E' un file batch? Una sequenza di tasti o di comandi da inviare al programma ... o cosa?
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
non intendo che debbano essere inviati necessariamente da console. Mi interessa fornire solo un' alternativa.
Avere un eseguibile per ogni comando è la cosa migliore in quanto utilizzando una gui si può associare ai vari pulsanti un eseguibile. Inoltre ci sarebbe la possibilità di interfacciarsi con un' altra applicazione.
Avere un eseguibile per ogni comando è la cosa migliore in quanto utilizzando una gui si può associare ai vari pulsanti un eseguibile. Inoltre ci sarebbe la possibilità di interfacciarsi con un' altra applicazione.
0
voti
in teoria, dovresti progettare il programma in modo che si lanci e abbia 2 finestre, una di console dove il programma vero e proprio è contenuto. Questo programma crea e lancia un oggetto finestra, o comqune una gui che metti sempre nello stesso progetto, che contiene un oggetto capace di visualizzare il video secondo l'algoritmo contenuto nel programma principale... ovviamente, la console, rimanendo aperta, puo accettare intanto degli input, come la parola "play" per avviare, ecc ecc...
Spero che mi abbiate capito.. ;)
Spero che mi abbiate capito.. ;)
0
voti
A che livello sei con la programmazione in C?
Te la cavi bene?
E con i sistemi UNIX come te la cavi? Hai mai usato il comando man? Lo usi regolarmente e sai interpretare le sue pagine?
Una possibilità per fare quello di cui parli è l'utilizzo delle code di messaggi. Si tratta di chiamate di sistema che servono proprio a scambiare messaggi tra diversi processi.
Te lo devi studiare un po', perché non è il massimo della semplicità (una volta che hai capito come funziona, non è difficile, ma prima devi capire il meccanismo e i suoi limiti).
In particolare le chiamate di sistema che possono interessarti sono:
msgget, msgctl, msgsnd, msgrcv.
Con questi puoi creare un server (l'applicazione principale, che contiene il nocciolo del tuo programma e riceve i messaggi dai client) e dei client (che inviano i comandi).
Quello che farai quindi sarà mettere il server in lettura sulla coda, il client invece sarà un semplice programma che riceve un parametro, apre la coda di messaggi, invia sulla coda il parametro che gli è stato dato e finisce qui il suo lavoro.
Edit:
Ci tengo a precisare che la questione di cui hai parlato:
è vera. Ma il motivo per cui questa vale è che gli ambienti UNIX-like funzionano prevalentemente da terminale, perché hanno un terminale eccezionale.
Sviluppare il software per il terminale ti permetterà di usarlo anche qualora il server grafico (X con GDM, KDM o altro) dovesse non essere disponibile. Aggiungere separatamente l'interfaccia grafica renderà il programma utilizzabile sia da terminale sia da interfaccia grafica.
Se però il programma che stai scrivendo ha un uso solamente grafico (hai parlato di video), allora probabilmente diventa inutile complicarsi la vita facendo questa separazione, se poi tanto il programma non potrebbe essere usato da terminale.
Aggiungo un'ultima nota: il fatto che un programma sia scritto per il terminale non implica che non possa avere una grafica o che non possa mostrare immagini e video; grazie al framebuffer è possibile mostrare immagini con risoluzione normale (e non quella limitata che c'è spesso nel terminale).
Però non credo che tu stia sviluppando il software per funzionare in queste modalità, perciò probabilmente la cosa migliore per te è quello di fare un unico programma, direttamente con l'interfaccia grafica.
Ma ciò non toglie che tu possa implementare comunque la parte con le code di messaggi, che potrebbe essere utile per interagire con il tuo software dall'esterno (tramite script o altri programmi). Anzi, se hai voglia di implementarla, te lo consiglio, perché è una funzionalità molto utile.
Te la cavi bene?
E con i sistemi UNIX come te la cavi? Hai mai usato il comando man? Lo usi regolarmente e sai interpretare le sue pagine?
Una possibilità per fare quello di cui parli è l'utilizzo delle code di messaggi. Si tratta di chiamate di sistema che servono proprio a scambiare messaggi tra diversi processi.
Te lo devi studiare un po', perché non è il massimo della semplicità (una volta che hai capito come funziona, non è difficile, ma prima devi capire il meccanismo e i suoi limiti).
In particolare le chiamate di sistema che possono interessarti sono:
msgget, msgctl, msgsnd, msgrcv.
Con questi puoi creare un server (l'applicazione principale, che contiene il nocciolo del tuo programma e riceve i messaggi dai client) e dei client (che inviano i comandi).
Quello che farai quindi sarà mettere il server in lettura sulla coda, il client invece sarà un semplice programma che riceve un parametro, apre la coda di messaggi, invia sulla coda il parametro che gli è stato dato e finisce qui il suo lavoro.
Edit:
Ci tengo a precisare che la questione di cui hai parlato:
Daniele78 ha scritto:Ho letto in giro che quando vengono creati programmi Linux si inizia a creare l' applicazione funzionante da console e poi la gui.
è vera. Ma il motivo per cui questa vale è che gli ambienti UNIX-like funzionano prevalentemente da terminale, perché hanno un terminale eccezionale.
Sviluppare il software per il terminale ti permetterà di usarlo anche qualora il server grafico (X con GDM, KDM o altro) dovesse non essere disponibile. Aggiungere separatamente l'interfaccia grafica renderà il programma utilizzabile sia da terminale sia da interfaccia grafica.
Se però il programma che stai scrivendo ha un uso solamente grafico (hai parlato di video), allora probabilmente diventa inutile complicarsi la vita facendo questa separazione, se poi tanto il programma non potrebbe essere usato da terminale.
Aggiungo un'ultima nota: il fatto che un programma sia scritto per il terminale non implica che non possa avere una grafica o che non possa mostrare immagini e video; grazie al framebuffer è possibile mostrare immagini con risoluzione normale (e non quella limitata che c'è spesso nel terminale).
Però non credo che tu stia sviluppando il software per funzionare in queste modalità, perciò probabilmente la cosa migliore per te è quello di fare un unico programma, direttamente con l'interfaccia grafica.
Ma ciò non toglie che tu possa implementare comunque la parte con le code di messaggi, che potrebbe essere utile per interagire con il tuo software dall'esterno (tramite script o altri programmi). Anzi, se hai voglia di implementarla, te lo consiglio, perché è una funzionalità molto utile.
0
voti
Berello ha scritto:A che livello sei con la programmazione in C?
Te la cavi bene?
E con i sistemi UNIX come te la cavi? Hai mai usato il comando man? Lo usi regolarmente e sai interpretare le sue pagine?
E' da parecchio che uso C (non C++) quindi in qualche modo me la cavo. Conosco in qualche modo le librerie SDL e OpenCV. Come sistema operativo uso maggiormente Ubuntu.
Il programma una volta lanciato apre una finestra mostrante il video.
Avrò finestra video + finestra terminale(manca il prompt perché il programma è in esecuzione).
Utilizzando le code di messaggi si possono inviare quindi nuove informazioni al programma mentre è in esecuzione?
21 messaggi
• Pagina 1 di 3 • 1, 2, 3
Chi c’è in linea
Visitano il forum: Nessuno e 56 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)




