Command Wiki: Backend Development

 All Posts Tagged: Command Wiki 

The elephant in the room is the plan for backend development.

This is a strange question in the real world, because I don't know how invested I am personally going to be in this project. I tend to write the ideal situation, but in reality could actually fall back quite a bit, to the closest thing I can do at a given time.

Of course falling back to different technologies is terrible, because it does not create an application that could serve as a foundation towards the more ideal one.

Single Language

Of course, the aspect of this application being native to Linux removes the necessity for resorting to a web platform. Web platforms are primarily rational in situations where you want your application to be cross-platform.

• Zig and GTK
• C and GTK
• C++ and Qt
• Swift and . . . ?
• Nim and . . . ?
• Rust and Iced
• Python and Dear PyGui / Qt / GTK

I wanted to use a forward looking language and toolkit for this. My preference was Swift and GTK, or Rust and Iced. Neither of these combos are as far along as I had hoped to start something like this. Neither are Zig and GTK.

Rust and Iced

Rust is made for projects that would have been done in C++ and C.  These projects are better off without garbage collection, because they are very performance critical. This means they are for deep systems programming, and heavy duty applications, like multimedia applications.

I do not think a systems language is necessary for this application. It could be satisfied with a garbage collected language.

Rust has no equivalent GUI tool kit to Qt.

Additionally, the added oddity of Rust, due to its specific security paradigm makes it unnecessarily weird to learn for this context.

Despite all of this, Rust is interesting for the sake of learning Rust, and for the sake of using it on a Rust-based system as well as Linux. An application specifically centered around Redox and Cosmic might have been good, and I will still have to keep an eye on Iced to see if it makes more sense than I thought. A lot of Iced applications have a very cool look to them - almost like python's Dear PyGUI. It is genuinely a very good aesthetic for this application in my opinion.

Swift and GTK

The oddity of Rust is what makes Swift a very compelling alternative. Swift has always been centered around applications. It is like a C++ alternative, minus being a C alternative, and its safety paradigm gets out of the developers way compared to Rust, while still being better than regular garbage collection of other languages.

Swift is very mature, but not on Linux. In my opinion, it is one of the most common sense languages to focus on for Linux and open source, and prettymuch THE MOST clear language to build up on Linux right now. At present, the portion of its libraries that are pure Swift code cross over to Linux. Swift needs heavy compatibility with a GUI Linux toolkit. 

I do not know if I would prefer to use GTK or Qt. I have not looked into the specifics of licensing for these tools with Swift, but I think it would be ok as individuals have tried to create some tools here and there. These types of community bindings and tools are generally very spotty in terms of completion, stability, and longterm support for any of these languages.

Swift uses the Apache 2 license. I am not sure the specifics of it, but I am pretty sure it's compatible with Linux, as Apache has been the premier Linux web server.

C++ and Qt

It is possible that I could consider C++ and Qt. C++ is still a very valuable skill, and if I were going to learn Zig at some point, then it would be cool to have some solid C++ under my belt. It would be very cool to be able to use Zig to augment C++ projects. C++ is supposedly moving to 20 in the near future.

I do hate the idea of starting a new project in a language that people are trying to move away from, but it would make some sense.

A lot of my favorite applications just so happen to be written in C++.

C and GTK

On a similar note to C++, the same thing goes for C, except I am not particularly familiar with applications written in C - just the Linux kernel. I'm sure there are a lot, but I know none of them by name. It is a useful language for sure, and it might be good to learn in conjunction with Zig at some point.

C is for GTK, and so the desire to use native GTK would be the main driver behind going with C.

Zig and GTK

Zig just isn't ready, and I am not sure that it ever will be. For a while I really thought Zig's pace was going to pick up, and it would accelerate to maturity, but it is not ready for this kind of project. I am all for learning Zig for the sake of learning it, but that is not what this is.

Zig has philosophies about staying very simple and minimal. Zig is kind of like Rust, in that it is very much a systems language with no garbage collection. So, what is the point of forcing such a language into a desktop application that probably does not have that kind of performance profile.

Yes, it has been done with Ghostty. I have even thought: what if I could use Ghostty code in my application that has a terminal in it? But I am not sure that is enough. I will keep an eye out.

Geany IDE

It is kind of a harebrained idea, but I have literally thought of starting with Geany as a base for the application.

Geany is a really solid text editor with a couple IDE features, written in C++. It has terminal capabilities as well as a plugin system.

From a step back, the appealing thing about Geany is that:

• the non-unique features are done.
• nothing sounds worse than having to develop these features from scratch, only to find yourself to be 25% done over 5 years, just to have another text editor and terminal.
• The development environment and context are ready to go to hit the ground running:
1. from experimental development
2. to actually contributing real things to Geany
1. bug fixes
2. plugins
3. features
3. into a proper fork of Geany
• development becomes about the interesting stuff
• unique markup interpreter
• application database
• tagging/classification system
• table interface
• linking features
• all the rest
• generally learning C++, which seems to build a path:
1. Learn C
2. Learn C++ and GTK
3. Learn Zig and Rust to integrate and compare

If it is possible, I could develop the whole project as massive Geany plugins, but I have my doubts about this approach.

Geany's philosophy is to take a very minimal approach to GTK+ usage, and I think it would get in the way of what I am trying to do. The application has a system for adding and removing any of the buttons of the toolbar, or removing the toolbar altogether which is good.

The problems are likely to occur in terms of how easily the existing code can integrate these kinds of large feature shifts.

NW.js

• Node.js
• Javascript / Typescript
• Rust
• WebAssembly 

NW.js has the ability to integrate with the commandline, and the operating system, and systems languages. It is a Chrome-engine-based web platform, but these points constitute a few advantages over some web based platforms for creating a native application.

NW.js With / Without Tiddlywiki

Tiddlywiki has Tiddly Desktop programmed in NW.js. This could serve as a starting point.

In terms of personal project feasibility, the most feasible (and biggest compromise on the whole idea) is actually to go with NW.js and Tiddlywiki.

The rest is about trying to figure out security holes for Tiddlywiki to get NW.js to exert manipulations over Tiddlywiki.

NW.js With / Without Rust

NW.js has the ability to mix with a systems language, like Rust.

All-in-all, Rust is a good idyllic and mature language to learn. If there's any WebAssembly that would be used for a native desktop application, then that would be cool to learn as well.

WebAssembly might be useful to run the application across Linux architectures. Then again, maybe not? I don't fully understand the scope of WebAssembly. 

I never liked the idea of mixing so many technologies together, but on the other hand, that might actually make it the most educational project I could do. (The ideal version of the project remains either way.)

Tauri

Tauri means Rust and Javascript/Typescript, and maybe even WASM, but probably not WASM.

This could possibly be a better option than NW.js, except that Tiddly Desktop is already using NW.js, and so there is some riding on that.

I take a look at Tauri every now and then.

Anyway, if I were to be considering doing NW.js, without Tiddlywiki, then the Tauri option becomes a close comparison, and a more serious consideration.

It is primarily a consideration if I want to go with new tools, and use a web front-end, but do not want to use Tiddly Desktop.

Python Backend

Another option that has made me recoil, but might actually be quite practical is a Python backend.

I wish there was a mature Python replacement, but there isn't. I wish Python was fast, but actually what do I know anyway. It might be more than enough for this purpose? Maybe one of the C compilation options would make it something else. Maybe it could compile to Zig?

Being a desktop application, the pressure is off for this application to be extremely fast. But every time I see an application written in a fast language, I swear I can tell the difference just by using it.

Being a wiki application that might be database intensive, I have no idea what to make of the Python speed issue. It could be completely negligible, with a modern GUI toolkit and modern hardware.

Ease of Use is a Big Plus

Python means that even after all these high level markup abstractions, that the backend too, is even written in a very easy language. This could be very good for plugins and contributions from a community.

If it's easy for me and others to develop, then you have to ask how bad the speed issue could really be. I am afraid that as features start to build, then speed will become an issue later on, after it is too late to change course.

Ecosystem 

Python has a wide array of choices for . . . virtually everything. It has fantastic scripting capabilities, data capabilities, and Linux GUI compatibility. It's the first language after C to be compatible with GTK, and it is the first language after C++ to be compatible with Qt.

Zim Wiki

Zim is a cross platform desktop notes application written in python. It is not a web-based application, but it can export to a basic html format.

Zim has more capabilities than is immediately apparent, but it definitely lacks some features compared to what I am thinking of. It is perhaps possible to get significantly closer than it is now, through a combination of plugins and independent scripts.

With such a basic starting point, the prospect begs the question of why you do not simply start building a separate application.

Lacking Features

• Embed text documents
• maybe a plugin could do this
• A quality editor
• just use a different editor
• or create a massive plugin? . . . maybe
• Fully linking wiki with widgets
• much more critical than the other missing features
• perhaps a plugin could fix it?
• Perhaps an entire bash-based system could accomplish similar functionality
• would be different in workflow
• would require hacky UX/UI
• what is the point? . . . 
• getting a headstart on development
• Zim community familiarity

Terminal Use

Instead of incorporating a terminal, Zim has the ability to run basic scripts, and include some Zim environment variables. However this mild scripting ability is primarily intended for reading and manipulating the wiki text itself.

Zim's scripting capability could perhaps massively compensate for all of Tiddlywiki's built-in filter syntax and widget syntax etc. This could make a lot of sense with a custom plugin.

OS Integration

Zim's features do open up some possibilities in terms of scripting and the filesystem. Especially with a few custom plugins, this could potentially become a big deal.

File Attachments

Zim has the ability to take files from the operating system, and copy them to Zim's attachments directory. They function as attachments, in that the files are not the originals. This could potentially be altered by creating a custom script that creates a link instead of copying the file. (haven't tried it)

Open With . . .

Zim allows you to create OS application runners for attachments and general launching.

Zim's Uses

Zim feels good for a different set of use cases. It can be very good for quick note taking. It is a good change from many of the note taking applications. It can be good for running quick scripts. I wish there was a way to put buttons inline with the text.

Zim has this thing where it is very simple, but it reaches outside itself to able to do a few things. But it needs a few more important features to make the intended functionalities more effective.