Looking for ideas on your next Gemini project?
Antefacto
this gemlog has been in gestation for at least three month from the date it has been published
This idea is born from the following post on Station:
I found myself, always more, taking notes and ideas in GemText; I would write emails too if only we had a Gemini Email Client. Even though I'd had loved having more "lines" I think we got a good compromise. The composition for lines helps you to create a peculiar style giving a nice rhythm to the paragraphs, I really love it!
I think if I would have a software that allows me to taking notes and ideas in a Gemini fashion, and if I could link together these notes as the good old time of the hyper-texts, and moreover if I could eventually export such ideas in Gemini pages; plain text documents; or even plain text email; this will surely become my preferred software for writing anything.
"YNGP"
I am not a coder therefore what I am going to do here isn't related with coding. I am here more to inspire any person looking for an exciting project related to Gemini! Since I am not going to program anything I will give to this project the code name: "YNGP": which stands for "Your Next Gemini Project". If this project would ever have an author, this person has the right to appoint the name and nobody else.
What I am going to write here is about:
- defining the scope;
- defining the behavior;
- defining the layout;
- defining what shouldn't do;
- evaluating possible extensions;
- defining menus;
- wire-frame concept proof;
- anything that isn't related with the above points.
If you want create a TUI or GUI application, I am not really interested in these details, even though this project is well suited to work on a TUI environment; but let me clarify one simple thing:
- any major changes in its behavior, or goals, will make this project something totally different from "YNGP", it might be better or worse, but it will be another project.
Anyone is free to follow the direction that considers more appropriate, but remember there is only one variation that match "YNGP".
The scope
Gemini is a cool project and even though as tech revolution has been embraced mostly by tech people, not all the people involved are Computer Scientists or Professional IT! I am not a tech savvy by any means, for instance I deleted (because a pebcak) the first version of this Gemlog that had a better and more inspired introduction than this current one…
There are plenty of editors to write a Gemini text document — my favorite one is Micro the editor — however there isn't a single software specifically made for one thing: creating Gemini documents!
As a proud capsuler I'd like to have a "YNGP" that is designed to natively understand GemText, this will render each line just right and it will be able to follow internal and external links, and when it is needed this will export each logs into a Gemini page.
I believe that nurturing a capsule shouldn't be a methodical nor a sequential task, therefore this "YNGP" should be a useful tool able to handle several (gem)logs at the same time; for instance you should be able to interconnect them, and you should always be able to trace them back and forth. Every time you create a log it will persist until you don't detach it from the editor, however logs won't be deleted. Deleting a detached log is something that should be made manually.
The scope of "YNGP" is to keep the state of your thoughts alive, you create a log and you start writing whatever you want: your next gemlog, your notes, the Christmas list, you name it! You can connect each log through internal links as you please. You can then writing but you can also reading, I envision this "YNGP" to be somehow modal, thus you can change its status anytime you decide to switch in reading or in editing mode, this should happen seamlessly.
Someone may argue that a "YNGP" to write and interconnect logs should be more powerful and not limited by GemText, but we all recognize the Gemini values therefore we embrace them at the maximum stake!
The behavior
Being methodical doesn't mean being necessarily organized, so far I have plenty of GMI files waiting to be issued, their number constantly is increasing since I have a lot of ideas against very little spare time available. My Gemini working folder is becoming increasingly messy and this won't help me to issue all my unfinished gemlogs faster.
By the other hand I'd like to pin more ideas anytime one comes out, since I don't have a specific "YNGP" for this, my working folder continues to becomes more, and more, messy and confused. I really need this "YNGP"!
In "YNGP" the main area is the log area, this is ready to unleash your creativity, however you have to trigger it, therefore the very first line of each log is reserved. Once you create the first line your log will be automatically saved and it will be alive!
Difference between floating logs and projects
"YNGP" should offer to the authors the opportunity to work freely, but also to handle an entire capsule (even more capsules); thus I distinguish between:
- floating logs: logs that don't belong to any project;
- and projects: wherein logs depend by a given root and all the internal links are relative the project's root!
Said that, it is important to implement a method to import an existing capsule into "YNGP".
Publishing, exporting and detaching
I decided that I don't want dedicate time to save any logs, you don't save your logs, your logs live along you, your logs are persistent however they can be exported or published and eventually detached.
- Publishing — it is mainly related with (capsule) projects, every time that you update a log or create a new one and they are ready to be issued you publish them! Those will be exported as GMI files in your local or remote folder. It is important then "YNGP" is able to distinguish between logs that haven't changed, logs that are updated and logs that just created.
- Exporting — this operation allows to export a log, whether is a floating or a project one, as any other plain format such as .txt, .log, .csv, etc. Exporting a log does not detach it.
- Detaching — is used to remove a log from "YNGP"; detached logs cannot be exported as GMI files; and you can detach a log from projects as well. When you detach a log a prompt will ask you if you want also exporting it (as plain text), detached logs aren't deleted from your drive and can be reattached if you do not manually erase them.
Explaining the first line
The first line thus is used by "YNGP" to assign a name — that you can change anytime — and to assign logs to a project. The information to the first line will used to find or display each log or project.
Since a project represents a capsule you can't assign the same name to different projects.
The first line is divided in three parts:
- the very first part defines which project the log belongs to; the project is interrupted by the colon's symbol (:);
- the second part is the name of the log which is separate by the third part by a single comma (,);
- the third part is anything that comes after the comma and it is separated by a space (␣); the third section is reserved to assign tags;
below the specific examples: floating log and project log:
:Title of the log, tag1 tag2 tag3 etc...
the colon can be omitted when a log does not belong to any project, but "YNGP" should then add it, when missing, at any boot.
Projec name: Title of the log, tag1 tag2 tag3 etc...
The first line must be case insensitive!
Links
Links are vital to make connections, each internal links is clickable when in reading mode, external links won't work and will be insensitive while still in reading mode. "YNGP" should be able to create relational logs where your ideas are constantly connected as it was a spider net. "YNGP" should be able to display internal links automatically or when invoked by a specific command.
The temptation to create an alternative tag lines is hard, for instance we could use <== to distinguish from internal and external links but this would be a dangerous slope and we don't really want this. It is important to clarify that only the internal links work in reading mode, therefore "YNGP" should distinguish between internal and external links.
Inside a project the internal links can't escape outside to the given root, as a matter of fact a project is an entire capsule's replica; in reading mode external links are insensitive.
Lines behavior
Since "YNGP" is an editor to write content, the text is automatically wrapped into multiple lines to visually create paragraphs, however this is annoying when is time to write verbatim text; it would be cool if "YNGP" could be able to not wrap the text's portion that is in between these two special lines "```" & "```" that are assigned to make unformatted text; in a "ncurses" environment an alternative window might be invoked to edit the verbatim separately, while in the regular view the verbatim lines must be truncated to respect the viewport.
Recap the scope & behavior
These are the points I wrote about so far:
- main area is reserved the to logs
- logs are never saved manually
- logs can be published, exported and detached
- Only logs inside a project can be published (as GMI)
- The first line of each log is reserved and uses this scheme:
Project "facultative":title log, Tag1 Tag2 Tag3
- When is created log is stored indeterminately
- log area is modal, it can be switched from editing to reading/browsing
- Lines are always wrapped but verbatim lines are not
- project is an entire capsule's replica
Layout
This section explains the layout and will provide wire-frame images as examples.
Main Area
I already wrote about the main area but I haven't specified yet that logs are opened as tabs, the amount of tabs visible depends by the size of the viewport, while you can reorganize the tabs the way you want, at every restarting of "YNGP" tabs must be rearranged in a reverse chronological orders, showing as first tabs the last logs you worked on.
Each tab's log should remember the position of the cursor at any session.
Between the tabs bar and and log area there is the history navigation bar, this is crucial because you can create new empty logs but you can create also child logs, the latter are related with the parents, if a log is a child the first line after the tags must shown a label like:
children of ...
This is not editable, it is a reminder to keep the track of where the log was coming from. This function is useful to create interconnected map, or living documentation, although when a full log-family is exported should be provided also navigation links, even though is quite likely to happen those links are going to be modified with the right URI. When "YNGP" is switched in navigation mode the history bar is clickable and browsable allowing to jump on any place.
Inside a project the navigation bar becomes the representation of capsule's root and it will display this way:
~/root/dir 2/dir 3/...
Aside the lateral edges of the main area there are two columns.
Left Column a.k.a. "the manager column"
The left column is used to manage anything related with the log in terms of availability and chrono-history; by default the left column shows only the title lines; the second tab is dedicated to the active projects; an additional third tab may show also the list of all the documents published or simply detached.
Right Column a.k.a. "the navigation column"
The right column shows anything that is related with browsing a log, by default it shows the internal structure of log, ergo it shows all the lines not only the title taglines. The second tab is dedicated to the internal links the active log is connected to, this way you can always visualize where the current document is going to. Since the right column shows the interconnections then it shows also the three tags — sometimes called cloudtags — and under each tags you created you can read which logs is relative to.
When the current log belong to a project then the right column shows the root tree!
What shouldn't happen
The first argument I'd like to clarify is "YNGP" is not a software to make code, and therefore there shouldn't be any support for any kind of other coding languages. However it may be reasonable adding support for highlighting the verbatim code (```) and reserving the first block to recall the language in use, for instance:
``` type:python
␣␣I do
␣␣␣␣not know
␣␣␣␣␣␣anything
␣␣␣␣about;
␣␣python
```
"␣ <— this means a blank space"
Someone might find the project interesting and would like to add support for Markdown, while you can do whatever you want just remember this is THE case where "YNGP" is not anymore the "YNGP" but something completely different.
The use of "YNGP" should be rational but and the same intuitive for anyone, it should use the most common paradigm like for instance:
- key combination
- expected functionality
- easy to understand
In one word the "YNGP" must be smooth, smooth as the silk! Wherever you see there is a blocking area it means something is going the wrong direction and must be analyzed, addressed and fixed; for instance should be avoided:
- convoluted mechanisms
- complicated key combination
- obscure commands
For me a good design paradigm to follow for instance is:
- everything must be only two click away
Avoiding recursive, and nested, options or functionality must be a priority.
At anytime of your activities such as writing, taking notes, writing snippets you must be always able to understand where you are in the document, as well as in the flow of your mind-map or project's root: if you feel lost, or you are unable to understand where you are at any given moment, this is a design flaw that must — as any other — be analyzed, addressed and fixed.
Possible extensions
- IT would be cool if "YNGP" would have an approach that can separate the core from the UI, in order to allow different approaches and let anyone developing the UI that loves the most (GUI, TUI, WebUI, etc.).
- Support for a Gopher-like approach to the writing style is surely interesting, although Gemini exists specifically to overcome many Gopher shortcomings.
- An integration with SSH, RSYNC or RCLONE and anything in between, would be another feature that many would appreciate almost certainly.
- Editing Gemini page on the fly would be something pretty useful although really outside the scope.
- Using "YNGP" to draft email and then passing it to a client would be somehow cool but extremely outside the scope.
- Making "YNGP" expandable with plugins in order to convert it something else, is cool but in contrast with the Gemini philosophy: «less is more».
The last point: «less is more» should always be the beacon, and the paradigm to follow, although mostly it depends by your comparative point: "YNGP" won't be a Gemini client therefore must do more, however compared with other similar projects should do less, while preserves all the essential functionality you would expecting from an editor.
Defining the menus
Any software that is respected has menus and functionality, this looks pretty trivial till you have to figuring out them. Since I do not use any similar software, now I am struggling a bit to imagine them, but I think I should be able to individuate the fundamentals ones:
Main menu
------------------------------------------------------------------------------------------------
| file | edit | document | view | options | help |
-----------------------------------------------------------------------------------------------|
| import | copy | glyphs/emojis | show line numbers | change theme | help |
| export | cut | lower case | show white space | language | commands |
| detach | paste | UPPER CASE | show paragraph marks | check spelling | wiki |
| info | find | Sentence case | show line endings |----------------| about |
| quit | replace | Title Case | show "YNGP"bar | ------------
----------| date | quote/unquote | show panels |
-----------| order alphabetically |-----------------------
| order numerically |
| add link |
| lines count |
| words count |
------------------------
Wire-frame concept proofs
I prepared some wire-frame mock-ups and has been a precious lesson since it taught me that designing a GUI is nothing trivial, and during the yeras I pressed a lot of developers asking for this and for that thinking it was pretty easy for them…
I am sincerely sorry about that… 🙏
I am not sure you are going to like the look and feel but I would like to try some new effects available in Inkscape 1.2, anyway I can put simply plain graphic if are difficult to understand, please let me know! 🙏
Hitting my limits
This pebcak delirium is almost reaching its end because I have already finished all my shots and I don't have any ideas on how to move from the theory to the practice. My effort has been like designing a car drafting exclusively the shape but without any knowledge on how to wire the various components as well as to assemble the mechanics.
Software is complex as well as any other complex thing, therefore there is something you can see (the UI) and something that is hidden instead! I don't know what is supposed to be hidden therefore I can't recommend any particular language suitable for this project, I can't recommend how to store the data internally, I can't recommend if using a database or a plain document.
I apology for such delusional section but my intention was only to inspire anyone who was looking for some idea. Apparently people with lesser knowledge about a complicated topic tend to be more imaginative because they aren't afraid by the difficulties — that actually they don't know or underestimate — but nonetheless such naive imagination may stimulate a person with the knowledge to approach a project with reinvigorate spirit and let him observe the problem from a different perspective that shows more benefits than the issues.
Wrapping this up
It would be fantastic if Santa Claus would inspired some fellow Geminauts/Capsulers to find this idea interesting and worth to pursue! I can guarantee that, by my side, I will use it daily since using GemText is fun and easy.
The Holidays season is already gone maybe it can be for the next one... 🎄
For comments or suggestion write me at: