In questi giorni mi è saltato in testa di voler prendere Translhextion e potenziarlo per essere un pochino più professcional e portarlo alla edizione 2.0. Avrei già qualche idea in mente per modificarlo come si deve, anche se alla fine si tratterebbe di riscriverlo da 0 con MFC più che modificarlo semplicemente. Vorrei però che proponeste idee per renderlo più flessibile e adattabile alle esigenze di un po' tutti o magari semplicemente più carino.
Insomma, PROPONETE, PROPONETE e PROPONETE ANCORA! Anche le cose più strane vanno bene, basta che ci sia almeno l'idea.
Vediamo cosa potrebbe uscirne fuori. :ph34r:
Vi ringrazio per la possibile collaborazione. :clomax mode:
Migliorare la ricerca del testo e dei byte (perché funziona male...)
Migliorare il reinserimento (perché è lentissimo)
Dovrebbe segnalare eventuali conflitti nella table che possono portare a errori nel reinserimento...
forse è una cavolata, ma per a chi ha "poca" ram translextion non apre file più grossi di 10-20 mega...si potrebbe provare a eliminare o a diminuire questo difettaccio
Basta aggiungere RAM...
Come puoi aprire un file più grande della tua ram disponibile ?
Si può, basta vedere il searchr di chop... (Come mi disse tempo fa pixel basta usare gli handle).
Le uniche cose che mi vengono in mente sono 3 (che mancano per rendere il prog perfetto):
- fare in modo di poter aprire anche file più grossi della quantità di ram disponibile.
Teoricamente non è impossibile... basta dire al prog che deve considerare il file come una serie di blocchi da una certa dimensione e a seconda della posizione del file, leggere da un certo blocco (chiaramente la cosa va espansa per supportare ricerche o altre operazioni a tutto il file)
- correggere il caricamento delle tbl che a volte scazza del tutto e fa piantare il programma al momento dell'attivazione (soprattutto con file di una certa dimensione)
- inserimento byte con TBL, immediato (come fa Hex Workshop per le sue tabelle)
E queste sono le cose più importanti...
Poi non sarebbe male sviluppare una bella mascherina che ti scrive i dati su cui si è posizionati in Intero, Float, Signed Double, Byte... e tutti gli altri.
E infine penso sarebbe molto carino un sistema di conteggio byte (per la lunghezza della frase) integrato e funzionale.
Queste diciamo che sono le mie esigenze per un programma coi controfiocchi. L'unica cosa che mi chiedo è se tu sia in grado di fare tutto ciò. In fondo mi pare che non è da tanto che lavori con programmi in C per Windows. Già per fare un programma contatore di frasi un po' decente, che confronta le lunghezze delle frasi di due edit e restituisce un risultato colorato a seconda del risultato stesso, ci vogliono alcune conoscenze che non sono proprio così alla mano. :rolleyes:
Con questo io non voglio scoraggiare nessuno... è solo che ho paura tu stia sottovalutando quello che ti stai proponendo di fare. È un progetto di un certo rilievo, che richiede molto tempo, costanza e discrete conoscenze tecniche.
Il conteggio dei byte sarebbe utile anche per il reinserimento di script...
Aggiungerei una modifica al layout dei dump.
Hai presente come sono ora, no?
Ecco, invece dello spazio, in bel <Textblock X> non sarebbe affatto male.
Riepilogando:
1) Apertuna veloce dei file grossi
2) Fissaggio dei vari metodi di ricerca
3) Migliore gestione delle table con salvaguardia da possibili errori
4) Velocità di reinserimento maggiore
5) Modifica al formato dei dump
6) Aggiunta del riconoscimento dei valori secondo base char, short, long, float, etc...
7) Cambio del nome del programma in Transhexual
La prima è facilmente fattibile. Basta riciclare l'idea di base dietro gli odierni editor esadecimali, ovvero userò un bel buffer per contenere i dati e altri eventuali buffer extra per sezioni di file modificate.
La seconda sarà un po' difficile, anche perché per implementare un buon metodo di ricerca bisognerà creare un bel codice sicuro al 100%. Spero di non doverlo appesantire troppo...
Tre, quattro e cinque sono dei punti decisamente interessanti. Stavo pensando di riscrivere quasi completamente il sistema di table per fare qualcosa di più serio. Mi spiego meglio: alcuni giochi usano particolari flag per identificare funzioni di gioco lanciate direttamente da script, esempio un ritardo sul testo, esecuzione di una musica di sottofondo o altro, per cui una semplice table creerebbe confusione nel caso in cui questi flag dovessero avere degli argomenti (es: byte 01XX, dove XX è la canzone da caricare. Se la canzone dovesse essere 00 e il byte di end verrebbe a coincidere, si otterrebbe un problema di equivoco nell'interpretazione). Praticamente più che semplici table sarebbero dei mini script da interpretare. Ammetto che la cosa non è facilissima da inserire, ma il risultato sarebbe davvero fantastico e praticissimo, soprattutto per chi si trova scomodo con gli attuali dump di Translhextion, come me. Per chi avesse idee su come scrivere questo formato, fate sapere. Sarebbe carino vedere le vostre esigenze anche in questo ambito per creare un formato fatto un po' da tutti.
La sei non è proprio nuovissima, visto che la vecchia versione più o meno presentava già questa caratteristica, anche se si limitava solo a Byte (char), Word (short) e Long, e in effetti non sevirebbe a molto inserire altri valori, ma alla fine non è nemmeno un grosso problema implementare, per cui vedrò cosa fare di questo punto.
La sette ovviamente è falsa. :°D
C'è questa richiesta però che non ho capito:
Citazione- inserimento byte con TBL, immediato (come fa Hex Workshop per le sue tabelle)
Mi spieghi esattamente cosa intendi? Non ho presente questo tipo di funzione, non esattamente almeno.
Anche questa è ambigua:
CitazioneE infine penso sarebbe molto carino un sistema di conteggio byte (per la lunghezza della frase) integrato e funzionale.
Intendi un conteggio sul numero di caratteri/larghezza in pixel per linea oppure un sistema per non sforare il numero massimo di caratteri? In entrambi i casi comunque non sarebbe difficile da inserire.
Per il resto dovrebbe essere tutto a posto. Stasera vedo di costruire almeno il vestitino al programma e di implementare qualcosa.
Significa che ora (almeno da quanto ho potuto vedere io... è passato tanto tempo dall'ultima volta che ho provato il programma), per inserire dei byte che fanno riferimento ad uno TBL bisogna ricorrere ad una barra che ti fa inserire prima lì i valori etc...
Il top sarebbe fare in modo da poter scrivere subito i caratteri nel programma, senza doverli mettere in questa nuova finestrella per l'inserimento.
Capito ora?
Per il conteggio io avevo pensato più ad un conteggio di lunghezza stringhe (o se vogliamo qualcosa riferito a tutto il file come "DimensioneFileModificato/DimensioneFileOriginale [Differenza]".
L'altra cosa mi sa più da utility esterna che qualcosa da inserire nell'editor a tutti i costi.
Poi, immaginando che il punto 7 sia la mia considerazione finale, se per te si tratta di una cavolata tanto meglio :)
Io mi ricordo che personalmente ci rimasi un po' male quando capìi che casino dovevo fare solo per far cambiare colore ad una label. :rolleyes:
Ehi, non vi dimenticate il conteggio byte su reinserimento da file, ogni volta mi scazza vedere se sovrascrive i pointer o altra roba. =\
Ps: il nuovo nome è carino, xD
Per le ricerche esistono tanti metodi e algoritmi di ricerca anche molto potenti (ora, non so quale algoritmo usi Translhextion) come l'albero binario di ricerca, etc, etc.
Su uno dei libri che ti ho prestato, questo argomento è ampliamente trattato, con inclusi i sorgenti di vari metodi di ricerca.
I libri del primo anno dovrebbero trattare sorting e ricerca, vero?
Ma come intendete sfruttare gli ABR? :blink:
Insomma... come ricerca sarà anche veloce (logN), ma analogamente alla ricerca dicotomica, non è possibile utilizzarla sempre.
L'ABR è costruito inserendo nella radice un valore, nel sotto albero di sinistra un valore minore della radice e in quello di destra un valore maggiore (e ciò vale per ogni sottoalbero visto come albero). Cosa pensate di utilizzare come "valore" per costruire l'albero? Inoltre bisogna tenere anche a mente che ci vuole un po' di tempo per la creazione dell'albero e che occupa anche memoria del sistema.
Cioè, sono daccordo anche io che ad esempio una ricerca tramite ABR sarebbe molto più veloce, ma non sono riuscito a capire come si possa implementare ciò per una ricerca in un editor esadecimale.
Essendo il contenuto di un editor esadecimale come quanto di più eterogeneo ci possa essere, secondo me la ricerca sequenziale è l'unica alternativa.
Se sapete come fare, sarei felice di essere smentito... mi piacerebbe impararne di più al riguardo :)
CitazioneCioè, sono daccordo anche io che ad esempio una ricerca tramite ABR sarebbe molto più veloce, ma non sono riuscito a capire come si possa implementare ciò per una ricerca in un editor esadecimale.
Proprio perché so quanto sono potenti e veloci l'ho proposto.
Non sono io a doverlo implementare :D
Ah, lol... ho capito :lol:
CitazioneSignifica che ora (almeno da quanto ho potuto vedere io... è passato tanto tempo dall'ultima volta che ho provato il programma), per inserire dei byte che fanno riferimento ad uno TBL bisogna ricorrere ad una barra che ti fa inserire prima lì i valori etc...
Il top sarebbe fare in modo da poter scrivere subito i caratteri nel programma, senza doverli mettere in questa nuova finestrella per l'inserimento.
Capito ora?
Sì, capita perfettamente stavolta. Il punto è che giochi con DTE/MTE non permetterebbero l'ottimizzazione del testo, ma comunque posso provare a fare un'alternativa, ovvero se vuoi questo fai questo, altrimenti usa la solita finestrella per l'ottimizzazione del testo. Così andrebbe bene?
CitazionePer il conteggio io avevo pensato più ad un conteggio di lunghezza stringhe (o se vogliamo qualcosa riferito a tutto il file come "DimensioneFileModificato/DimensioneFileOriginale [Differenza]".
L'altra cosa mi sa più da utility esterna che qualcosa da inserire nell'editor a tutti i costi.
Se ho capito bene dovrebbe essere un controllo sui banchi di testo, ovvero la possibilità di sapere in anticipo se il nuovo blocco occuperà tanto, più o meno del nuovo blocco. È così?
CitazionePoi, immaginando che il punto 7 sia la mia considerazione finale, se per te si tratta di una cavolata tanto meglio :)
Insomma, anche tu come Geo sei per il cambio di nome in Transhexual? :*
Vedo di lavorarci un po' stasera, e inizio a cercarmi un buon sistema di ricerca, almeno di tipo standard. Ho già in mente qualcosa, ma forse in questo caso sarebbe meglio basarsi su codice già testato e funzionante al 100%.
Sì, c'avevo pensato anche io... e bisognerebbe implementare un controllo successivo. Insomma... ora il prog lo fa quando si preme il pulsantino della finestrella... l'obiettivo è di farglielo fare dopo, controllando alcuni byte precedenti.
Secondo me è possibile farcela... ma bisogna studiarsela un attimo.
Non ho ben capito cosa hai capito te ( :lol: ), quello che ho pensato io è qualcosa di piuttosto semplice. Hai presente che nell'hex Workshop in basso è visualizzata la dimensione del file su cui si sta lavorando? Ecco, una cosa analoga qui... che visualizzi la dimensione del file su cui si sta lavorando, quella del file originale e che espliciti la differenza di byte tra uno e l'altro.
Poi è possibile riproporre un'altra cosa tramite qualche altra dialog (questa volta destinata a calcolare la differenza di lunghezza tra stringhe copiate, e non tutto il file).
La prima mi sa che non è proprio facilissima, soprattutto se si va a sovrascrivere. Comunque vedo di studiarmela per benino. Una soluzione sicuramente si trova.
La seconda l'abbiamo già commentata in chat, e si può fare senza problemi nella "ToolBox", ovvero la dialog volante stile Table Toolbar della 1.6.
A parte queste, avevo pensato di inserire un sistema di ripuntaggio, tramite script che definisca il formato dei puntatori, e anche un sistema di depuntaggio, ovvero estrazione del testo partendo dai puntatori, funzione utilissima nel caso in cui l'ordine dello script non dovesse seguire quella dei puntatori.
Dalle mie idee invece proviene quest'altra: progetti a lotti. In poche parole, si tratta di processi fissi, magari di reinserimento di testo o quel che sia, tutto eseguito automaticamente. Questa dovrebbe essere utile soprattutto quando si devono reinserire molti file di testo in tanti altri file binari e magari eseguire altre operazioni tipo ricalcolo dei puntatori. Insomma, dovrebbe dare qualche vantaggio.
Yuu-chan ha proposto anche di inserire un sistema di dump a scelta dell'utente dei vari banchi di testo in un unico file o in vari file txt enumerati progressivamente. Questa è interessante, soprattutto per chi non ha voglia di avere molti file in giro.
Il Saffo invece mi ha proposto l'uso multiplo di table, soprattutto per giochi che ne usano più di una. Questa credo la implementerò tramite la ToolBox, usando dei radio button (quei tasti a forma di cerchio con a fianco una scritta che permettono la scelta di una sola opzione), uno per ogni table. Mi pare sia la migliore per avere un accesso rapido a tutte le table in uso. Spero non appesantisca troppo il programma. :D
Ora mi manca solo qualche proposta sul nuovo formato di table per identificare i tag di un gioco. Con il Saffo prima se ne parlava, ma per il momento non abbiamo raggiunto nulla di totalmente concreto. Provate a buttare giù qualche esempio, dato che per ora non ho idea di come rendere la cosa.
Per ora dovrebbe essere tutto. Se avete altre idee, prego, scrivete pure. Meglio levarsi questi problemi in fase di progettazione che non in quella di espansione delle funzioni.
Colgo l'occasione per suggerire un imponente usodi hotkey. Soprattutto per certe cose sarebbe veramente funzionale. Una su tutte, lo switching tra le table.
Destinare ad esempio CTRL+F1, CTRL+F2, CTRL+F3 e CTRL+F4 per l'apertura di determinate TBL.
Otiima idea, è noioso usare il mouse per le funzioni che si usano spesso.
Tra le altre features possibili suggerirei di mettere un'opzione per creare direttamente la ptach ips della rom tradotta tramite comparazione, e, se è possbile, un analizzatore di patch ips (che magari ti dice in quali offset è stata fatta la modifica del testo e della grafica), credo che quest'ultima opzione possa risultare davvero molto utile, infatti molte rom tradotte in altre lingue (francese, russo, spagnolo) hanno buona parte della grafica tradotto, mentre per una eventuale patch italiana bisogna fare il lavoro da zero cercando gli indirizzi offset della grafica o quant'altro...
Non so se mi sono spiegato correttamente... spero di sì...
Ciao e buon lavoro.
Scarto quest'ultima, non avendo troppo a cuore il formato IPS (sinceramente preferisco altro per creare patch) e non vedendo molto cosa c'entri un'opzione del genere con un editor esadecimale per tradurre testo.
Vediamo di rianimare un po' questo topic con qualche parere esterno.
Guardare questa immagine:
(http://img193.echo.cx/img193/6539/trans1bp.gif)
Come potete vedere, la stringa caricata viene visualizzata secondo il codice ascii, mentre se andassi a caricare una table verrebbe cambiata secondo i valori di quest'ultima. L'idea sarebbe questa: vorreste visualizzare oltre ai valori in tabella anche il codice ascii? Ovvero ASCII -> TABLE. Potrebbe tornare utile in diverse occasioni, ad esempio quando vogliamo tenere una table caricata mentre cerchiamo qualcosa di non testuale.
Se a qualcuno sembra sensata o ha un'idea migliore a riguardo, faccia sapere.
PS: Negli ultimi giorni il programma ha cambiato nome, per cui niente più Translhextion 2.0 ma Translhextion .NET, dato che anche l'ambiente di sviluppo è cambiato (VC++ .NET 2003 con MFC).
Non ci pensavo, però in effetti come cosa può risultare utile.
A questo punto direi che sarebbe più sensato caricare una TBL invece della tabella ascii... tanto per quella basta caricare comunque una Table.
E cmq secondo me diventerebbe necessaria un'opzione per visualizzare solo una delle due tbl. Averne due in alcune occasioni può dare fastidio.
Approvo quanto proposto da Gemini.
Proprio ora, mi viene in mente una feature che potrebbe rivelarsi molto utile.
L'evidenziatore.
Intendo l'abilità di selezionare un qualsiasi testo all'interno del file aperto e di distinguerlo con un sfondo differente, come se fosse sottolineato con un evidenziatore. A che pro?
Ad esempio, per ricordare dei dati importanti (tipo quando si cercano i pointer), e si deve ripercorrere più e più volte un lungo file.
Se non è una cosa complicata, credo che possa servire (magari con la possibilità di impostare 2-3 colori differenti).
Beh, in translhextion c'erano i segnalibro, se non si può fare un evidenziatore magari mettere quelli.
Con l'evidenziatore si avrebbe la possibilità di segnalare un blocco di testo, con il segnalibro solo un offset, o erro?
CitazioneCon l'evidenziatore si avrebbe la possibilità di segnalare un blocco di testo, con il segnalibro solo un offset, o erro?
Alcuni bookmark permettono di selezionare due intervalli di indirizzi, per cui non ci vuole molto a rendere quel testo di colore diverso impiegando quella parte di tbl. Caratteristica aggiudicata.
CitazioneA questo punto direi che sarebbe più sensato caricare una TBL invece della tabella ascii... tanto per quella basta caricare comunque una Table.
Preferisco tenere l'ascii per il momento, almeno è abbastanza leggero in fase di caricamento e visualizzazione.
CitazioneE cmq secondo me diventerebbe necessaria un'opzione per visualizzare solo una delle due tbl. Averne due in alcune occasioni può dare fastidio.
C'è già qualcosa del genere, ma funziona con un numero più alto di table.
Io mi associo a tutte le proposte fatte e chiedo solo di scriverlo utilizzando wxwidgets o qualcosa di simile in modo da renderlo utilizzabile con linux/*bsd/OsX/windows
CitazioneIo mi associo a tutte le proposte fatte e chiedo solo di scriverlo utilizzando wxwidgets o qualcosa di simile in modo da renderlo utilizzabile con linux/*bsd/OsX/windows
Proposta bocciata. Questo progetto è stato pensato per funzionare solo con le MFC, e su Windows morirà senza possibilità di porting alcuna. Tra l'altro, questa volta non sarà un progetto open source.
Per i sistemi Unix/Linux Wine darà sicuramente una mano.
CitazioneTra l'altro, questa volta non sarà un progetto open source.
Il punto di forza di translhextion era proprio quello di essere software liberamente modificabile. [IMHO]Ampliarlo e chiuderlo sara' come darsi la zappa sui piedi...[/IMHO]
X brisma: Magari Wine su di un powerbook non aiuta, ma virtualpc sotto osx si ;)
Citazione[IMHO]Ampliarlo e chiuderlo sara' come darsi la zappa sui piedi...[/IMHO]
Preferisco un software chiuso e fatto bene che non uno aperto e con 100000 variazioni non standard (come l'odioso Linux).
CitazioneCitazione[IMHO]Ampliarlo e chiuderlo sara' come darsi la zappa sui piedi...[/IMHO]
Preferisco un software chiuso e fatto bene che non uno aperto e con 100000 variazioni non standard (come l'odioso Linux).
MMM hai mai sentito parlare dei modelli di sviluppo software
Cattedrale e Bazaar? non tutto il software opensource e' gestito come linux, prendi ad esempio i vari *BSD. (ma qui andiamo OT ;))
Tornando a translhextion, a quanto ho letto lo stai riscrivendo da zero. Perche' se fosse un fork credo dovresti accontentare le richieste della licenza dell'autore.
Citazione//Permission is hereby granted, free of charge, to any person obtaining a
//copy of this software and associated documentation files (the
//"Software"), to deal in the Software without restriction, including
//without limitation the rights to use, copy, modify, merge, publish,
//distribute, and/or sell copies of the Software, and to permit persons
//to whom the Software is furnished to do so
CitazioneMMM hai mai sentito parlare dei modelli di sviluppo software Cattedrale e Bazaar? non tutto il software opensource e' gestito come linux, prendi ad esempio i vari *BSD. (ma qui andiamo OT ;))
Ma Linux non faceva proprio parte della serie "Bazaar"? E comunque ripeto che non mi interessa l'open source, come d'altronde faccio da anni.
CitazioneTornando a translhextion, a quanto ho letto lo stai riscrivendo da zero. Perche' se fosse un fork credo dovresti accontentare le richieste della licenza dell'autore.
Prendo solo il nome e l'idea di base, il resto però ce lo sto mettendo io, per cui l'autore può aver scritto quello che gli pare.
CitazioneMa Linux non faceva proprio parte della serie "Bazaar"?
Appunto, sottolineavo il fatto che il modello di sviluppo OpenSource non e' per forza simile a quello di linux. Forse mi sono spiegato male ;)
CitazioneE comunque ripeto che non mi interessa l'open source, come d'altronde faccio da anni.
Libero di pensarla come vuoi.
CitazionePrendo solo il nome e l'idea di base, il resto però ce lo sto mettendo io, per cui l'autore può aver scritto quello che gli pare.
Allora tutto ok. Se riesci ad implementare tutte le features chieste sara' un ottimo editor. Buon lavoro ;)
CitazioneAllora tutto ok. Se riesci ad implementare tutte le features chieste sara' un ottimo editor. Buon lavoro ;)
L'idea di base infatti era proprio quella: ottenere un buon editor. Che poi non sia portabile su altri sistemi operativi, detto molto delicamente, STICA**I! :P
Non capisco tutto quest'accanimento per Linux...
Serve solo per fare i proxy e server "sicuri" sulla rete...
Per il resto per fare una cosa idiota da 5 sec di metti 1/2 ora, rincuorandosi che però è "sicuro"...Sì, è sicuro che lo mollo...
CitazioneNon capisco tutto quest'accanimento per Linux...
Ed io non capisco questo accanimento contro Linux :D
Scusate se riprendo l'OT ma vorrei dire anche la mia in proposito...
CitazioneServe solo per fare i proxy e server "sicuri" sulla rete...
Dipende, io sui miei server uso openBSD. Non ho mai provato ma credo che anche con Win si possano creare server "sicuri". Un server e' sicuro non in base al sistema operativo che utilizza, tutto dipende dall'admin che lo deve saper gestire.
CitazionePer il resto per fare una cosa idiota da 5 sec di metti 1/2 ora, rincuorandosi che però è "sicuro"...Sì, è sicuro che lo mollo...
Io uso linux sui miei desktop non solo per la sicurezza e la stabilita' ma soprattutto per la conformita' agli standard e per il fatto che e' un sistema operativo opensource molto ben documentato.
Sembra paradossale dover spiegare i vantaggi del software open in un forum di romhacking...
Per farvi un esempio pensate quanto sarebbe semplice tradurre roms di cui si conoscono i formati di compressione perche' ben documentati o di cui addirittura si hanno i sorgenti originali, in cui basta editare i testi e ricompilare il tutto. Quante rom tradotte avremmo???
Questo e' il vero motivo per cui ad esempio linux (dato che l'avete tirato in ballo) ha riscosso tutto questo successo, non l'affidabilita', la sicurezza (che da questo derivano) o il fatto che "fa figo" usare linux... ma proprio il fatto che sia liberamente modificabile e sopratutto trasparente
Questa e' la mia opinione in proposito, ci tenevo a sottolinearla dato che ho percepito uno strano alone di negativita' verso il pinguino, scusate ancora per lo sforamento... ;)
Torniamo IN TOPIC, per discussioni su Linux vi invito ad aprire un thread in separata sede.
CitazionePer farvi un esempio pensate quanto sarebbe semplice tradurre roms di cui si conoscono i formati di compressione perche' ben documentati o di cui addirittura si hanno i sorgenti originali, in cui basta editare i testi e ricompilare il tutto. Quante rom tradotte avremmo???
Personalmente io mi sentirei molto meno invogliato a tenere d'occhio questo "mondo". Insomma, se le cose sono già pronte si perde tutta la magia e tutto il divertimento. No... la cosa deve nascondere le sue insidie e le sue sorprese, altrimenti non c'è nemmeno gusto. Io mi annoierei a trovare solamente e subito un txt da tradurre e non comincerei nemmeno col progetto. E credo che ogni traduttore (o rom hacker, come lo chiamate voi, se volete proprio fare una distinzione) che abbia cominciato questo passatempo per sfida, la pensi come me.
Ed è anche per questo spirito di sfida che alcuni (o forse anche perchè è la moda del momento) si sono imparati uno o più linguaggi assembly. Perchè oltrepassando questa frontiera, la sfida diventa maggiore (e quindi più eccitante, stimolante, divertente ed appagante).
Esistono numerosi hack fatti ad alcune funzionalità di Windows, visto che non è opensource... ma non perchè è un tentativo di attaccare microsoft, ma proprio perchè si tratta di spirito di sfida. Linux ha tanti bei lati positivi, ma non può appagare nello stesso modo quello spirito di sfida che una persona può trovare in un sistema "chiuso e nascosto".
Dal mio punto di vista, Gemini ha tutti i diritti di pubblicare la sua applicazione compilata (anche se io, visto che si tratta di un progetto nuovo che non ha riferimenti con altri programmi, lo chiamerei con un altro nome). Ci possono essere un sacco di motivi validi per cui può decidere di non rilasciare i sorgenti. Il primo tra tutti (ed il più banale) è che siccome l'applicazione è sua, decide lui... anche se si trattasse di sfizio personale. Oppure siccome l'applicazione è sua, vuole che "rimanga sua", senza che altri ci mettano le mani senza che lui lo sappia. O ancora... può darsi che non sia fierissimo del codice che ha scritto (magari non è stilisticamente perfetto o si tratta di un cattivo codice) e che quindi preferisca tenere nascosta la cosa preferendo rilasciare solo un'applicazione che funziona lo stesso, invece dei sorgenti (che avrebbero rubato altro tempo per la messa a punto). Oppure si tratta di egoismo personale... o chissà cos'altro.
Di qualunque ragione si tratti, sono tutte legittime e io non mi sento di condannare questa scelta.
Inoltre non credo che si tratti di strani algoritmi o di codice particolare per cui sia veramente importante avere il sorgente a portata di mano. Secondo me una persona in grado di capire il codice di quel sorgente è una persona che saprebbe già rifarlo. Non credo tanto alla scusa del "guardare i sorgenti per imparare come fare". I sorgenti sono utili solo quando uno ha già un'idea di come sviluppare l'applicazione. Tanto per fare un esempio, basta prendere i sorgenti di alcuni programmi come Snes9x o EmulePlus. Una persona fa fatica a capirci se non ha anche altre basi. Nel caso di questo editor esadecimale io sono convinto che nel momento uno abbia le basi per capire il codice sorgente, sia già in grado in riproporlo in gran parte.
E se proprio una parte del programma rimane un mistero, o si chiede direttamente all'autore (che in genere, se l'applicazione non è commerciale, è sempre ben disposto nel dare dritte che possano aiutare gli altri), oppure si lavora di asm ;)
Edit by yuumeikai: Ma io parlo al vento?
Come va il progetto?
Sembra sia stato detto un po' tutto, personalmente mi troverei comodo se la barra che divide esa e binario fosse gestibile §(che si possa sostare ed allargare il campo del testo: l'esadecimale serve molto meno spesso del testo).
Proposte piu' fantasiose: un piccolo vocabolario multilanguage integrato (il Berlitz che usavo in passato pesa solo 700k), ed uno spazio per le note (dividendo in 4 la finestra ci entra tutto).
Con tutto questo potrei utilizzarlo a schermo intero, e non sempre in finestra!
Citazioneche si possa sostare ed allargare il campo del testo: l'esadecimale serve molto meno spesso del testo
Non servirebbe, c'è tantissimo spazio per il testo e l'esadecimale.
CitazioneProposte piu' fantasiose: un piccolo vocabolario multilanguage integrato
Inutile. Se vuoi usare un vocabolario basta estrarre tutto il testo su dump e lavorare lì.
Citazioneed uno spazio per le note
Questa sarebbe carina, anche se non avrei idea di come infilarcela nel programma.
Il guaio non è tanto come infilarci le note, ma come farle rimanere memorizzate. È ovvio che non possono venire memorizzate insieme al programma che si edita. Le soluzioni quindi sono due:
1) Creare un file esterno (tipo di progetto) per ogni file che si va ad editare, in cui memorizzare varie informazioni (al di là delle note) che possono essere molto interessanti e carine (come segnalibri a particolari offset, TBL da caricare automaticamente, impostazioni predefinite per un particolare file aperto, la posizione dell'offset in cui ci si trovava prima che si chiudesse il prog, e altre cose).
[es. IDA (che però supporta anche la gestione da un unico database)]
2) La seconda soluzione è memorizzare in un unico database (magari memorizzato nella stessa cartella dell'applicazione), tutte le informazioni sopra citate... quindi memorizzando anche il percorso del file che si sta modificando.
[es. ACDSee]
Entrambe possiedono vantaggi e svantaggi. Con la prima soluzione sicuramente c'è una maggiore flessibilità, visto che diventa possibile passarsi anche i file di progetto, e quindi usufruire anche di queste informazioni extra. C'è da dire che però in questo modo, da ogni file su cui si lavora viene generato un nuovo file (che probabilmente non sarà molto grosso in termini di dimensione) e quindi c'è la tendenza a "inquinare" il proprio PC con questi file.
La seconda scelta è sicuramente più "elegante" a prima vista, perchè non crea altri file sparsi per il PC, ma è più complessa da gestire. Inoltre diventa praticamente impossibile scambiarsi le informazioni memorizzate in questo modo (a meno di sostituire il proprio database con l'altro, in cui saranno memorizzate anche informazioni che non ci interessano e sicuramente ci impedirà di usufruire delle nostre informazioni che noi avevamo memorizzato.). Un'alternativa a questo metodo è quella di creare un'utilità che permetta di creare un file (tipo di patch) apposito per i dati relativi al file che si sta modificando. E ovviamente anche una funzione per caricare nel proprio database i dati nuovi contenuti in questo file.
Forse questa è la soluzione ottimale, che permetterebbe sicuramente di usufruire dei benefici di un file di progetto, senza essere troppo invadente (conservando tutto in un unico file che teoricamente non dovrebbe diventare troppo grande, data la natura delle informazioni da memorizzare), ma conservando allo stesso tempo una certa flessibilità. L'unico svantaggio è che si tratta della soluzione più complicata da implementare, e che richiede una certa analisi di ciò che si vuole memorizzare e come... Anche solo la scelta di limitare lo spazio per le note ad un numero di caratteri massimo o di lasciare illimitato lo spazio può presentare stravolgimenti di implementazione, dovendo abbandonare l'idea di un classico database per esempio, con un organizzazione sequenziale dei dati. In questo secondo caso ad esempio può diventare comodo l'utilizzo di un secondo file di indice, in cui vengono memorizzati i puntatori per i dati relativi ad ogni file. È ovvio che ad ogni modifica delle informazioni per ogni file (variando la lunghezza dello spazio occupato) diventa necessario anche ricalcolare tutti i puntatori relativi ai dati memorizzati dopo quelli del file che si è modificato.
Come si può notare (e questa è stata un analisi a freddo... possono benissimo esserci molte altre problematiche) i problemi da gestire ci sono e non sono nemmeno pochi. Poi sta a te decidere quanto ti vuoi impegnare per questa cosa o se, capito il mazzo che c'è da farsi, rinunciare a questa opportunità.
Se si decide di supportare la gestione di queste informazioni extra, consiglio comunque di comprimere i file (o il file) in qualche modo, per guadagnare spazio. Una compressione Zip usando la Zlib va benissimo (ed è gratuita). Al massimo gli dici di cambiare l'estensione con una più personalizzata.
Comunque decidi te.
a che punto è arrivato il programma?
Citazionea che punto è arrivato il programma?
Ero riuscito a ottenere una buona gestione dei file grossi, facendoli sembrare caricati totalmente in ram, però credo di aver ucciso il programma, tentando di cambiare delle cose per renderlo MDI (apertura multipla di documenti in parole povere). Ora si avvia, ma dà subito errori di frame e si richiude. Per il momento lo lascio com'è, poi lo riprenderò in tempi migliori. :P
CitazioneEro riuscito a ottenere una buona gestione dei file grossi, facendoli sembrare caricati totalmente in ram, però credo di aver ucciso il programma, tentando di cambiare delle cose per renderlo MDI (apertura multipla di documenti in parole povere). Ora si avvia, ma dà subito errori di frame e si richiude. Per il momento lo lascio com'è, poi lo riprenderò in tempi migliori. :P
Traduzione per i non capenti:
L'ha sminchiato e non ha più voglia di starci dietro a sistemarlo :P
capisco...
un giorno farò qualcosa in modo che le persone non usino più il thingy oppure il tranhexeltion (come cavolo si chiama)
Citazioneun giorno farò qualcosa in modo che le persone non usino più il thingy oppure il tranhexeltion (come cavolo si chiama)
Uomo di buona volontà...
CitazioneTraduzione per i non capenti:
L'ha sminchiato e non ha più voglia di starci dietro a sistemarlo :P
Tu sì che mi leggi nel pensiero. :* ... xD