Tap Manager - Preview Disponibile

[iAN CooG]

 Oki, ora parte.
Primo baco da fixare. Apri un tap, esci subito dall'applicazione: ci sono 2500 bytes "0" accodati al file. Non ho fatto null'altro.
Non ho capito a cosa serva il pulsante "salva" se le scritture sono immediate. Appena fai drag/drop da un pannello all'altro i tap sono gia' aggiornati, cosi' pure per la cancellazione (questa e' meglio renderla piu' sicura con conferma dell'utente ed eventuale undo)
Poi l'apertura della dir SEMPRE in documenti\ e' davvero fastidiosa, andrebbe memorizzato l'ultimo path visitato. Non e' un baco, una richiesta, quando gestirai un file ini ricordatelo.

[eregil]

 In realtà, è buona pratica avvertire se si sta per rimuovere un attributo readonly da un file; un utente potrebbe pur sempre avercelo messo apposta. Potresti aggiungere una richiesta di conferma?

Comunque, sotto Linux e con Java 1.5.0 update 14 non riesco a trascinare (letteralmente! clicco su un programma, tengo cliccato, sposto il mouse e mi si sposta la selezione invece del programma).

Quando succede, ho una serie di messaggi nella console, simili a:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: gui/CustomPanel$Dummy
        at gui.CustomPanel$CustomDragGestureListener.dragGestureRecognized(CustomPanel.java:121)
        at java.awt.dnd.DragGestureRecognizer.fireDragGestureRecognized(DragGestureRecognizer.java:339)
        at sun.awt.X11.XMouseDragGestureRecognizer.mouseDragged(XMouseDragGestureRecognizer.java:202)
        at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:262)
        at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:261)
        at java.awt.Component.processMouseMotionEvent(Component.java:5565)
        at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3153)
        at java.awt.Component.processEvent(Component.java:5286)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3984)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3819)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3909)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        at java.awt.Container.dispatchEventImpl(Container.java:2010)
        at java.awt.Window.dispatchEventImpl(Window.java:1791)
        at java.awt.Component.dispatchEvent(Component.java:3819)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

ripetuto n volte.

Riscontri? Qualcun altro sotto Linux e/o Java 1.5.0?

[Alberto]

 Ciao ragazzi

Primo baco da fixare. Apri un tap, esci subito dall'applicazione: ci sono 2500 bytes "0" accodati al file. Non ho fatto null'altro.

C'e' una ragione precisa dietro a questo fatto.
Se si sceglie di accodare un programma a un file TAP,generalmente VICE non riconosce il programma accodato;questo perchè un'header viene riconosciuta tale solo se preceduta da una sequenza sufficientemente lunga di short pulses (da cui il motivo per il quale vengono preliminarmente accodati bytes 0x30).
Questo comportamento dell'emulatore è normale,infatti questo preambolo è necessario per permettere al registratore di arrivare a velocità di regime prima di riconoscere una tape-header (a questo proposito,sarebbe interessante se qualcuno volesse provare a trasferire il file TAP su un nastro reale per vedere se il tutto funziona).

In ogni caso,grazie all'impostazione di un flag questa "normalizzazione" avviene una sola volta.

Non ho capito a cosa serva il pulsante "salva" se le scritture sono immediate.

Dopo la normalizzazione,il programma non apporta più modifiche al/i file TAP finchè non si preme il pulsante 'Salva',perchè durante ogni operazione di trasferimento lavora su array e non direttamente su file.

Se ti riferisci all'accodamento del preambolo,hai pienamente ragione:la normalizzazione la si può fare "al volo" quando si accoda un prg a un file TAP non "normalizzato".

Poi l'apertura della dir SEMPRE in documenti\ e' davvero fastidiosa, andrebbe memorizzato l'ultimo path visitato

Concordo,altro task in cima alla lista dei todo.

Comunque, sotto Linux e con Java 1.5.0 update 14 non riesco a trascinare (letteralmente! clicco su un programma, tengo cliccato, sposto il mouse e mi si sposta la selezione invece del programma).

Quando succede, ho una serie di messaggi nella console, simili a:


QUOTE 
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: gui/CustomPanel$Dummy
        at gui.CustomPanel$CustomDragGestureListener.dragGestureRecognized(CustomPanel.java:121)
        at java.awt.dnd.DragGestureRecognizer.fireDragGestureRecognized(DragGestureRecognizer.java:339)
        at sun.awt.X11.XMouseDragGestureRecognizer.mouseDragged(XMouseDragGestureRecognizer.java:202)
        at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:262)
        at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:261)
        at java.awt.Component.processMouseMotionEvent(Component.java:5565)
        at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3153)
        at java.awt.Component.processEvent(Component.java:5286)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3984)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3819)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3909)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        at java.awt.Container.dispatchEventImpl(Container.java:2010)
        at java.awt.Window.dispatchEventImpl(Window.java:1791)
        at java.awt.Component.dispatchEvent(Component.java:3819)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
 



ripetuto n volte.

Ohhhh,finalmente un problema di portabilità;fortunatamente dispongo di una distro Linux installata sul PC e posso verificare facilmente  :lol:

Modifiche tra oggi e domani,grazie a tutti dell'attenzione

Alberto
 

[Alberto]

 

In realtà, è buona pratica avvertire se si sta per rimuovere un attributo readonly da un file; un utente potrebbe pur sempre avercelo messo apposta. Potresti aggiungere una richiesta di conferma?

Azz,questa considerazione non l'avevo vista.

Tieni presente che senza sproteggere il file da R/O non ci si può scrivere sopra per modificarlo;al massimo,per tenere conto di una protezione intenzionale,il programma può sproteggere il file e poi riproteggerlo dopo averci lavorato sopra.
 

[Loky]

 

Ma puoi anche non rimetterlo il readonly, da' solo fastidio. E' sicuramente un rimasuglio di qualcuno che l'ha copiato da cdrom.

secondo me fa bene a rimetterlo readonly...o è perchè è rimasuglio di cd, o è perchè non lo è, ma le cose vanno rimesse a posto, soprattutto in informatica.
Comunque, sono scelte banali.

In realtà, è buona pratica avvertire se si sta per rimuovere un attributo readonly da un file; un utente potrebbe pur sempre avercelo messo apposta. Potresti aggiungere una richiesta di conferma?

o in alternativa ti copi il file in un file temp mantenendone l'attributo readonly, poi levi il readonly al file temp senza toccare l'originale...forse così è ancora più corretto, anche se è richiesto un pochino più tempo per le elaborazioni.

 

[koseidon72]

 Un altra cosa da implementare potrebbe essere il salvataggio di un tap con nome diverso dall'originale.
Nel frattempo che non c'e' ancora la possibilita' di creare da zero un file Tap, e' necessario poter salvare le modifiche magari in un file temporaneo
Il sistema non fara' altro che creare una copia del file modificato con il nuovo nome che si scegliera'.

Altra cosa ancora:

E' possibile (so che non e' semplice) emulare i caratteri del c64, nel momento che si visualizza l'interno di un tap, dal momento che ci sono vari caratteri mal interpretati.
E' vero che poi le operazioni su tali nomi dei file anche con caratteri strani non influiscono
al momento del caricamento sull'emulatore, ma e' piu' per una questione visiva.

Oppure c'e' un modo per aggirare la questione senza dover emulare il c64 char?

Rinnovo ancora i miei complimenti a Fab per quello che sta facendo!
   

[Alberto]

 

Un altra cosa da implementare potrebbe essere il salvataggio di un tap con nome diverso dall'originale.
Nel frattempo che non c'e' ancora la possibilita' di creare da zero un file Tap, e' necessario poter salvare le modifiche magari in un file temporaneo
Il sistema non fara' altro che creare una copia del file modificato con il nuovo nome che si scegliera'.

Sarà la fame?Non ho ben capito quello che vuoi dire

Oppure c'e' un modo per aggirare la questione senza dover emulare il c64 char?

Emulare i caratteri speciali?Carino ma un casino laborioso, in questo momento la trovo *davvero* una cosa di contorno

Cmq ho visto che lavorando sempre su array si possono aggirare molte complicazioni,seguirò questo approccio.

Ciauz

[eregil]

Tieni presente che senza sproteggere il file da R/O non ci si può scrivere sopra per modificarlo;al massimo,per tenere conto di una protezione intenzionale,il programma può sproteggere il file e poi riproteggerlo dopo averci lavorato sopra.

secondo me fa bene a rimetterlo readonly...o è perchè è rimasuglio di cd, o è perchè non lo è, ma le cose vanno rimesse a posto, soprattutto in informatica.
Comunque, sono scelte banali.

Forse non sono stato chiaro, cercherò di esserlo ora:

Togliere l'attributo readonly (o cambiare i permessi in *nix) senza avvertire l'utente è sbagliato. La mancanza di una richiesta di conferma è un bug a tutti gli effetti.

L'attributo readonly posso averlo messo io utente, deliberatamente, proprio per evitare che un programma mi sovrascriva il file senza avvertirmi. Certo, sono un po' pollo se non mi tengo un backup da qualche parte, ma questo non cambia il concetto di fondo.

Che sia eliminato l'attributo readonly senza avvertire l'utente, anche se - anzi a maggior ragione se - l'attributo readonly viene poi ripristinato altrettanto silenziosamente, è un BUG che prego vivamente di correggere nella prossima release.

Ancora meglio sarebbe, naturalmente, lavorare su un file temporaneo e salvare su quello di origine solo dietro richiesta esplicita dell'utente, ma una miglioria è meno urgente di un bugfix.

Non si tratta di scelte banali, e non si può (non si deve) prendere alla leggera l'attributo readonly: altrimenti, tale attributo non l'avrebbero proprio inventato. Il comportamento corrente e quello proposto sono SBAGLIATI sia in un senso (togliere il readonly) che nell'altro (ripristinare il readonly).

[Alberto]

 Ciao eregil

Ok,credo di aver capito cosa intendi e provvederò al più presto.

Grazie
 

[Loky]

 Come suggerivo io...
=PPP

[koseidon72]

Sarà la fame?Non ho ben capito quello che vuoi dire
 

Il classico SALVA CON NOME intendo dire

[Alberto]

 

Il classico SALVA CON NOME intendo dire

ma lol  :lol:  

[Alberto]

 Aggiornamento veloce:

- ricompilando su JVM Sun sotto Linux ho risolto il problema segnalato da eregil (nei prossimi rilasci beta non fornirò più i compilati .class ma solo i sorgenti e uno script per compilare il programma da shell o prompt)

- ho rivisto il motore di scansione,adesso lavora sempre su array e (come era prevedibile) è molto più veloce di prima

- adesso sto lavorando alla richiesta di conferma di overwrite (sempre richiesta da eregil),vorrei rendere la cosa più comoda possibile per l'utente finale quindi la vorrei implementare *come si deve*,anche a costo di metterci più tempo del previsto

- in coda la memorizzazione del path richiesto da iAN CooG

Upperò le modifiche a lavoro completato.
Le altre richieste verranno accontentate nelle prossime rls

Grazie dell'attenzione

[iAN CooG]

 

nei prossimi rilasci beta non fornirò più i compilati .class ma solo i sorgenti e uno script per compilare il programma da shell o prompt

Aspetta un attimo, gia' e' un MIRACOLO che io abbia il runtime di java installato, tra l'altro a mia insaputa perche' lo installo' Opera, ma di mettermi anche il compilatore non se ne parla nemmeno. Fornisci per cortesia sia compilati che sorgenti, magari divisi in 2 directories.

[Loky]

 Se li metterai su un sito in genere si mettono due link...un per scaricarela versione compilata ed uno per scaricare i sirgenti.
Un link serve per gli eventuali sviluppatori, l'altro per gli utilizzatori.