Initial bulk upload

This commit is contained in:
Kishpa 2025-08-04 13:25:16 +02:00
parent 4eb2120594
commit b58efe5543
4 changed files with 538 additions and 80 deletions

373
FILEID.TXT Normal file
View File

@ -0,0 +1,373 @@
FILEID.TXT v1.9 by Richard Holler [CIS 73567,1547]
Last Revision 05/17/94
This text file was prepared at the request of the ASP (Association of
Shareware Professionals), but the information contained in it may be of
value to any shareware author.
FILE_ID.DIZ INFORMATION
-----------------------
Basically, the FILE_ID.DIZ file is a straight ASCII text file, distributed
inside your distribution archive file along with your program files, which
contains a description of your program. This file will be used by most BBS
(Bulletin Board System) softwares for the online file description of your
file. We recommend that the FILE_ID.DIZ file be used in all of your
distribution archives.
This text file contains a description of the FILE_ID.DIZ file, as well as a
description of the recommended distribution archive format.
WHY SHOULD YOU USE FILE_ID.DIZ?
-------------------------------
The use of this file will insure that the online description of your
program will be in your own words (and who better to describe your program
than yourself?), and that it will remain the same no matter how many
different people upload your file to various BBS systems.
As more and more BBS software makes use of this file, you can be assured
that your own description will replace such online descriptions as "Cool
Program" or "OK utility, but needs better ..."
Please note that the ASP Hub Network, the Author Direct FDN (File
Distribution Network), and the majority of other electronic distribution
services *REQUIRE* that a valid FILE_ID.DIZ file be contained in your
submitted distribution archive. If your file doesn't contain a valid
FILE_ID.DIZ file, then it simply won't be distributed by these services.
Furthermore, most BBS sysops will not accept uploads of files which do not
contain a valid FILE_ID.DIZ file, so you automatically lose out on that
distribution as well.
DESCRIPTION:
------------
FILE_ID.DIZ was created by Clark Development for use with their PCBDescribe
utility, as a means for shareware authors to provide descriptions for their
products, and thus so that BBS callers can upload the file(s) without
having to manually type in a file description.
As long as an author creates and includes a FILE_ID.DIZ file in their
distribution fileset, the text from that file will be used for the online
description (in most cases) rather than anything typed in by the uploader.
It also ensures that the online description is always the same regardless
of the number of different BBS systems the file is posted on. It has since
been accepted by the BBS industry more-or-less as the "standard" file
description source. (The extension of "DIZ" actually stands for
"Description In Zip").
NOTE: The FILE_ID.DIZ file *MUST* be named exactly that, and *NOT*
something like <filename>.DIZ. It will *ONLY* be used if it is named
FILE_ID.DIZ!
The FILE_ID.DIZ file is nothing more than a straight ASCII text file which
contains the full description of the archived file containing it. It is
used by most popular BBS software to describe your program, rather than
using the description supplied by the person that uploaded your file. It
should be placed *INSIDE* your distribution archive file. The FILE_ID.DIZ
file is defined by its creators (Clark Development) as being created by the
program author, and *NOT* the end user who is trying to upload the program.
The BBS software will "look" inside the archive file. If a FILE_ID.DIZ file
is found, it will replace any existing online file description with the
text contained in FILE_ID.DIZ. It is an excellent method for making sure
that your program files are described the way that "you" want them
described. Even sysops who's software can't automatically make use of the
FILE_ID.DIZ file have found it to be an excellent source for their manually
added file descriptions.
STRUCTURE:
----------
The file consists of straight ASCII text, up to 10 lines of text, each line
being no more than 45 characters long. It should *NOT* contain any blank
lines, any form of centering or formatting, or any Hi-ASCII or ANSI
characters. (i.e. it should ONLY contain alpha & numeric characters).
We recommended that it consist of 5 basic parts:
1. the proper name of your program
2. the version number
3. the "ASP" identifier (optional, for ASP members)
4. the description separator
4. the description
All of the above parts should be separated by a single "space".
PROGRAM NAME: To set it apart from the rest, it is recommended that you use
ALL CAPS for the program name.
VERSION NUMBER: The version number should be in the form of "v12.34".
ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
identifying mark be added after the version number, to identify your
product as an ASP-authored product.
DESCRIPTION SEPARATOR: To separate the actual description text, insert a
simple "-" (dash/minus) character after the ASP identifier (or version
number, if not using the ASP identifier), and in front of the description
text.
DESCRIPTION: You should attempt to FULLY describe your product, including
its most important functions and features. Be sure to include anything
which will separate your program from it's competition, and make the BBS
user want to download your file. Also try to include any hardware or
software requirements that your product may have.
You should try to use the first 2 lines of the text to give a basic
description of your program. This is helpful for sysops who's BBS software
limits them to less than 10 lines, 45 characters. Sysops who are limited to
using shorter descriptions can simply use the 1st two lines and truncate
the rest. Thus, you can basically still supply your own description for BBS
software which does not actually utilize the FILE_ID.DIZ feature.
The remaining lines of text can be used to elaborate on the programs
features, enhancements from the prior version, information concerning
multi-file sets. Please note that older versions of some BBS software can
only use 8 lines of text. It is advisable that you create your FILE_ID.DIZ
file so that the file can be truncated to various line lengths without
destroying it's usefulness.
EXAMPLE
-------
MY PROGRAM v1.23 <ASP> - A program which will
do anything for anybody. Will run in only 2k
of memory. Can be run from the command line,
or installed as a TSR. Completely menu-
driven. Version 1.23 reduces the previous 4k
memory requirements, and adds an enhanced
graphical user interface. Also, MY PROGRAM
now contains Windows and DESQview support.
Coming soon - an OS/2 version.
From Do-It-All Software, Inc. $15.00
MULTIPLE DISK INFO
------------------
Please note that if your distribution archive requires multiple archive
files, you should create a separate, specific FILE_ID.DIZ file for each
archive. This can be utilized to describe the various contents of each
archive, and to identify each disk in the set. For example, the FILE_ID.DIZ
file for disk #1 could contain:
"MY PROGRAM v1.23 <ASP> Program Executable
Files - Disk 1 of 2"
[followed by detailed description text]
while the FILE_ID.DIZ file for disk #2 could contain:
"MY PROGRAM v1.23 <ASP> Documentation Files -
Disk 2 of 2"
[followed by more detailed description text]
Optionally, you could also create a "complete" FILE_ID.DIZ file for the
first disk, which would fully describe the program in detail, and identify
it as Disk 1 of x. Then, for each remaining file in the set, simply include
the Program Name, version number, ASP identifier, and the disk number (i.e.
"MY PROGRAM v1.23 <ASP> Disk 2 of x").
ADDITIONAL INFO
---------------
Please don't be tempted to use fancy graphic or ANSI sequences in the
FILE_ID.DIZ file, as most BBS software will not allow this, and will render
your FILE_ID.DIZ file useless. Also, don't be tempted to simply copy your
program description file to FILE_ID.DIZ. Attempting to "format" your
FILE_ID.DIZ file (i.e line centering, right & left justification, etc) will
also cause unexpected results, especially for BBS software which re-formats
descriptions to other than 10line/45char.
Fred Hill <ASP> has written a freeware utility which interactively creates
a valid FILE_ID.DIZ file. The file is called DIZGEN.ZIP, and is included
with this distribution archive. I highly recommend that you use this
utility for creating your FILE_ID.DIZ files.
<*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
The following is a recommendation for the structure and contents of
distribution archives prepared for use on BBS systems.
DISTRIBUTION DISK RECOMMENDATIONS
---------------------------------
The following are recommendations for preparing your program files for
distribution to Bulletin Board Systems (BBSs) via the ASP's distribution
services, as well as other methods.
Two varieties of program files are defined here:
1) Program files which utilize an "install" utility and self-extracting
program archives (later referred to as "Author-Installed Programs").
2) Programs files which do not use install utilities or self-extracting
archives (later referred to as "User-Installed Programs").
AUTHOR-INSTALLED PROGRAMS:
--------------------------
These programs require a bit more work from the author, but will eliminate
many user mistakes, especially in programs which require complicated
setups.
Most "installation" utility programs will make use of program files which
have been "archived" into Self-Extracting (SFX) archives. We will attempt
to define which files should be contained in the Self-Extracting archives,
and which files should not.
1. Files which should be contained in the self-extracting program file
archive:
a. All program-specific executable files.
b. Any required configuration and/or data files required by the
program.
c. Program documentation files. Optionally, these may be left
outside of the self-extracting archive, in order to allow
them to be viewed/read by the various archive viewing utlities.
d. Any other program-specific files that are required for the
operation of the program.
2. The files described above should be compiled into a self-extracting
archive file, which will then be extracted by the install utility.
NOTE: the author is required to abide by any distribution requirements
specified by the archive utility author, and to obtain any required
distribution rights necessary. Please check to see if distribution rights
are required for your archive utility choice.
3. Files which should NOT be contained in the self-extracting program file
archive:
a. The install utility itself (obviously).
b. The FILE_ID.DIZ file. (described in detail in the section
preceding this one)
c. Any distribution/information files, such as VENDOR.TXT,
SYSOP.TXT, etc.
d. Any description or information file, such as DESCRIBE.TXT.
e. A user file (such as README.1ST), which should explain how
to use the install utility, what the user should expect
during the installation, and any preparation that the user
should make prior to the installation. This file might also
contain a brief description of your program, in case the user
is able to read the documentation files in the distribution
archive prior to downloading (many BBS systems offer this
ability to the user).
4. The actual distribution archive file (described below) should then
contain the install utility, the self-extracting program archive, and the
files described in #3 above.
USER-INSTALLED PROGRAMS:
------------------------
This type of distribution archive is much simpler than the Author-Installed
variety. It should simply be an archive file, containing all of the files
for the program described above.
Since this type of program requires the user to do all of the installation
manually, it should contain very specific and detailed information
regarding the installation requirements (such as INSTALL.TXT).
THE DISTRIBUTION ARCHIVE FILE:
------------------------------
The actual distribution archive file should merely be an archive file
containing the files described above. For BBS distribution, this archive
should be of the standard archive format, and -NOT- a self-extracting
archive. Many sysops will not allow self-extracting archives, and most BBS
software will not allow self-extracting archives to be uploaded.
There are many popular archive utilities available, such as PKZIP, LHA,
LHARC, ARJ, etc. Most BBS systems are capable of handling archives in
virtually any format. However, you should be aware that most BBS systems
will convert your archive format to the format of choice by the sysop. By
following the methods described above, this conversion process should not
affect your program, or any self-extracting files which are contained
within your distribution archive file.
You should also retain the default archive file extension defined by the
archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH", etc.
Changing the file extension may cause the BBS software to delete your file
because it doesn't recognize the format.
For the actual filename for your distribution archive, it is recommended
that the program filename be limited to 6 characters to represent the
program's name (i.e. MYPROG could represent "My Program"). This should be
followed by 2 numeric digits which will represent the version number of
your release. Even if this is your initial release it should include the
version number in the filename (i.e. MYPROG10.ZIP would indicate the
program called "My Program" version 1.0).
Please note that CompuServe limits filenames to only 6 characters. By
limiting the file "name" to 6 characters, you will easily be able to rename
the archive for CompuServe uploading by simply removing the 2-digit version
identifier, to make the file compatible with CompuServe libraries.
By including the 2-digit version number in the archive filename, it will be
very easy for both the user and the sysop (and yourself) to identify older
versions of your program.
MULTIPLE DISTRIBUTION ARCHIVES
------------------------------
At one time, it was recommended that your final distribution archive not be
larger than 350k, so that it would fit on a single 360k floppy disk and
still leave room for any distribution files necessary for Disk Vendors.
(i.e. Disk Vendors will often include their own GO.BAT file, or other
various small files to help their customers install the software). This
limitation is slowly falling by the wayside as more and more computer
systems have 3.5" floppy disk drives as standard.
If your program is large enough to require more than one distribution
archive, it is recommended that your filename be limited to 5 characters
rather than 6 as described above. Following the 5-character name should be
the same 2-digit version number. Then, append a single "letter" to identify
the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading to
CompuServe, these filenames may then be shortened to 6 characters by
removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP). However,
for CompuServe it is recommended that you simply create a single
distibution file, and eliminate the multi-part file set.
If your program requires multiple distribution archives, -BE SURE- to
create separate FILE_ID.DIZ files for each distribution archive. Also, each
FILE_ID.DIZ file should contain disk number information pertaining to each
individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.).
THE DISTRIBUTION DISK
---------------------
It is recommended that your distribution disk simply contain a ZIPd version
of your product. However, If you choose to supply "unarchived" files on a
distribution disk for Disk Vendor use, it is _VERY_ important that you
specify in your documentation a suggested archive filename, so that BBS
sysops can create archived files with the proper author-specified
filenames. This information should be contained in your SYSOP.TXT (or
VENDOR.TXT) file. If you don't supply a suggested archive file name, the
sysops will be forced to create the name themselves, thus you may end up
with thousands of versions of your products on BBS systems all over the
world, but all with different filenames.
Please note that the ASP Hub Network, and nearly every other electronic
distribution service *REQUIRE* that your files be submitted as an archived
file, using the ZIP format. Also note that many BBS sysops will not go to
the trouble of ZIPing your unarchived files for you. If you don't supply
them with an archived distribution version of your product, it might not
get distributed by BBSs.
If you supply your own disk labels, it is recommended that the ASP logo, or
at least the initials "ASP" be included on the label, so that anyone can
immediately identify your disk as an ASP member's software.
SUMMARY
-------
Your distribution disk should now be ready to submit to the various BBSs,
distribution services, and Disk Vendors.
You may choose to create a separate distribution disk for use by BBSs and
Disk Vendors. However, if you follow the above steps in preparing your
distribution archive file, a separate "Disk Vendor" disk is probably not
necessary. The majority of disk vendors will be able to accept your
distribution file/disk if it is prepared in the above described format.


86
LICENSE
View File

@ -1,79 +1,7 @@
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License.
"The Library" refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.
An "Application" is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
A "Combined Work" is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the "Linked Version".
The "Minimal Corresponding Source" for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.
The "Corresponding Application Code" for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.
GNU GENERAL PUBLIC LICENSE GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007 Version 3, 29 June 2007
Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/> Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
@ -280,25 +208,25 @@ If you develop a new program, and you want it to be of the greatest possible use
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
gui-diz-editor diz-generator
Copyright (C) 2025 eotb Copyright (C) 2024 eotb
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail. Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:
gui-diz-editor Copyright (C) 2025 eotb diz-generator Copyright (C) 2024 eotb
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>. You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <https://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <https://www.gnu.org/philosophy/why-not-lgpl.html>.

View File

@ -1,2 +1,61 @@
# gui-diz-editor # Editor DIZ
## Situació
En el meu dia a dia com a `SysOp` d'un `BBS`, necessito informar el contingut dels fitxers que poso a disposició dels meus usuaris a les diferents àrees de fitxers.
Per a tal efecte es va crear fa molts anys el format `file_id.diz`[^1], àmpliament reconegut i establert com a estàndard, amb una especificació tècnica [^2] ben definida.
Per tant, cada fitxer en la meva base de fitxers hauria de tenir inclòs un fitxer de tipus `file_id.diz` descrivint el seu contingut.
I aquests fitxers `file_id.diz`s'han de crear i editar.
## Problema
Hi ha disponibles infinitats d'editors de text, de tota mena i tecnologia, però cap d'específic per a tractar aquest tipus de fitxers. Dels pocs que hi ha, o són de tipus privatiu, o només funcionen en entorns `MS Windows`.
Pel que fa als editors generalistes, no permeten -o no he sabut trobar-ho- establir un format d'edició que preservi les dues grans condicions dels fitxers `file_id.diz`: un màxim de 10 línies, i un màxim de 45 caràcters per línia.
## Solució
Necessitava un editor multiplataforma, de codi obert, que permetés crear i editar els fitxers de tipus `file_id.diz`, que respectés els condicionants del seu format, i que fos usable i intuïtiu per al `SysOp` que el fes servir.
Per tant, he desenvolupat un *script* en `python`, que dona resposta a tots aquests requeriments. Donades les meves limitacions com a desenvolupador, m'he basat en la llibreria estàndard `tkinter`[^3] per a proveir una interfície gràfica -simple però efectiva- que doni aquesta usabilitat i funcionalitat.
Aquest *script* permet:
- Arrencar un `GUI` amb font monoespai per a visibilitzar uniformement les línies.
- Accedir a un panell d'exploració de fitxers navegable.
- Obrir, desar, visualitzar i editar textos de 10 línies i 45 caràcters per línia.
- Un comptador per línia amb els caràcters escrits en temps real sobre els 45 permesos.
- Línies independents entre sí, de manera que es pugui editar un text lliurement[^4].
- Tractar aquests textos com a `file_id.diz` o `elnomquesigui.diz`.
- Executar-se en qualsevol plataforma que diposi de `Python`, la biblioteca estàndard `tkinter` (i s'entén que un *Entorn d'Escriptori*[^5]).
## Execució
Des de l'intèrpret de comandes:
```bash
python diz-editor-py
```
o en funció del vostre entorn:
```bash
python3 diz-editor-py
```
`<EOF>`
[^1]: https://en.wikipedia.org/wiki/FILE_ID.DIZ
[^2]: En aquest mateix repositori: [FILEID.TXT](https://shipyard.thefreebay.net/eotb/gui-diz-editor/src/branch/main/FILEID.TXT "FILE_ID.DIZ Specification v1.9 by Richard Holler")
[^3]: https://docs.python.org/3/library/tkinter.html
[^4]: Tot i que no es recomana, aprofitar les línies per fer [Art ASCII](https://ca.wikipedia.org/wiki/Art_ASCII "Viquipèdia").
[^5]: https://ca.wikipedia.org/wiki/Entorn_d%27escriptori

98
diz-editor.py Normal file
View File

@ -0,0 +1,98 @@
import tkinter as tk
from tkinter import filedialog, messagebox
import os
class DIZEditorApp:
def __init__(self, root):
self.root = root
self.root.title("DIZ Editor")
self.root.geometry("600x400")
self.filepath = None
# Fuente monoespaciada
self.monospace_font = ("Courier", 10)
# Text editing frame
self.text_frame = tk.Frame(self.root)
self.text_frame.pack(fill=tk.BOTH, expand=True)
self.text_vars = []
self.text_entries = []
self.char_counts = []
for i in range(10):
frame = tk.Frame(self.text_frame)
frame.pack(fill=tk.X)
text_var = tk.StringVar()
text_entry = tk.Entry(frame, textvariable=text_var, width=45, font=self.monospace_font)
text_entry.pack(side=tk.LEFT, fill=tk.X, expand=True)
char_count = tk.Label(frame, text="0/45")
char_count.pack(side=tk.RIGHT)
text_var.trace_add('write', self.update_char_count(text_var, char_count))
self.text_vars.append(text_var)
self.text_entries.append(text_entry)
self.char_counts.append(char_count)
# File explorer frame
self.file_frame = tk.Frame(self.root)
self.file_frame.pack(fill=tk.X)
self.file_label = tk.Label(self.file_frame, text="No file selected")
self.file_label.pack(side=tk.LEFT)
self.open_button = tk.Button(self.file_frame, text="Open", command=self.open_file)
self.open_button.pack(side=tk.LEFT)
self.save_button = tk.Button(self.file_frame, text="Save", command=self.save_file)
self.save_button.pack(side=tk.LEFT)
self.save_as_button = tk.Button(self.file_frame, text="Save As", command=self.save_as_file)
self.save_as_button.pack(side=tk.LEFT)
self.exit_button = tk.Button(self.file_frame, text="Exit", command=self.exit_app)
self.exit_button.pack(side=tk.RIGHT)
def update_char_count(self, text_var, char_count):
def callback(*args):
text = text_var.get()
if len(text) > 45:
text_var.set(text[:45])
char_count.config(text=f"{len(text)}/45")
return callback
def open_file(self):
filepath = filedialog.askopenfilename(filetypes=[("DIZ files", "*.diz")])
if filepath:
with open(filepath, 'r') as file:
lines = file.readlines()
for i in range(min(10, len(lines))):
self.text_vars[i].set(lines[i].strip())
for i in range(len(lines), 10):
self.text_vars[i].set('')
self.filepath = filepath
self.file_label.config(text=os.path.basename(filepath))
def save_file(self):
if self.filepath:
self.write_to_file(self.filepath)
else:
self.save_as_file()
def save_as_file(self):
filepath = filedialog.asksaveasfilename(defaultextension=".diz", filetypes=[("DIZ files", "*.diz")])
if filepath:
self.write_to_file(filepath)
self.filepath = filepath
self.file_label.config(text=os.path.basename(filepath))
def write_to_file(self, filepath):
with open(filepath, 'w') as file:
for text_var in self.text_vars:
file.write(text_var.get() + '\n')
def exit_app(self):
self.root.quit()
if __name__ == "__main__":
root = tk.Tk()
app = DIZEditorApp(root)
root.mainloop()