V1.6 Devlog ( ̶A̶p̶r̶i̶l̶-̶S̶e̶p̶t̶e̶m̶b̶e̶r̶ ̶2̶0̶2̶5̶ (paused and postponed)): input and output nodes, undo/redo and more

[KennedyRichard]

Warning

As for why this development round is paused and postponed, check this comment further below

Hello, everyone!

Nodezator development work posts like this one are meant...

• for me to present the next features/changes on which I intend to work for the next Nodezator version
• for you to suggest other features and give feedback on the ones I chose
• once we decide on the features/changes to be implemented, to work as a devlog to keep everyone updated on my work

Since I work in various projects, I publish a detailed work report each month or couple of months here: https://github.com/orgs/IndieSmiths/discussions/10

Previous development round

The previous development round for Nodezator (V1.6 Devlog (July-December 2024): input and output nodes, undo/redo and more) was the first ever to be paused midway. The reasons were explained in subsequent replies in that post, but I'd like to summarize them here for your convenience. It was due to a series of circumstances that required my immediate attention, mostly things of interest to the project and its members/followers. That is, although I didn't finish the work I was doing for Nodezator, I did manage to keep working on other areas of the Indie Smiths project and even submitted a few patches to Nodezator as well.

First, an experimental feature, socket proximity detection, got a lot of traction online: https://x.com/KennedyRichard/status/1823905562192449762 and https://fosstodon.org/@KennedyRichard/112963623039789844

This brought many new users to the community and since the feature was mostly complete when it was first presented, I temporarily shifted my attention to finishing and releasing it so everyone had access to it right away, specially since the feature is a substantial usability aid and was bringing new users.

Then unexpectedly I had to move to a new address and had problems with my work desk (had to replace its base). It took me 5 weeks to find a solution to this (ended up using trestles, which were effective and inexpensive).

During that time, I kept working on the Indie Smiths project, but since I only had access to a small makeshift desk, I couldn't fit my monitor and keyboard on it, only the laptop, and thus had to use the monitor and keyboard on my laptop instead.

Because of that, instead of coding inefficiently, I focused on content production and other administrative tasks of the project instead.

The project gained traction online again via this post on HackerNews.

Whenever the project get many visits in such circumstances, it requires some time to reply to people asking questions about the project. The increased traffic also led to more people using Nodezator and reporting bugs, that again required me to shift my attention from development to bug fixing. Back then I submitted two new Nodezator patches (1.5.2 and 1.5.3).

By then the year was almost finished and I had to make plans for the Indie Smiths project in 2025, which I posted here: https://github.com/orgs/IndieSmiths/discussions/6. After that I had the 15-days break I take at the turn of every year.

The rest of my work after I got back from my break at the beginning of January is detailed in my work reports.

Now let's finally get back to work on Nodezator. The next section details what I'm planning for this new development round.

Proposed features/changes

Despite the many changes the Indie Smiths project had these past few months, the features/tasks scheduled for the previous development round are still relevant/needed. Because of that, I selected them again for this new development round as well:

• Finish the SDD (software design document)
• Implement the missing system test cases
• Implement undo/redo in Nodezator
• Implement the input and output nodes in Nodezator (first step towards implementing subgraphs/group nodes)
• Implement the ability to drag data (files/text) into Nodezator (read about it here: Dragging and dropping data into Nodezator #39)
• Implement clipboard access (copying/pasting data)
• ... (possibly other small/QOL features)

Since in the post for the previous development round I explain the importance of each of theses features/tasks, I'll only summarize them here. I only add a few more points when summarizing the need for the input/output nodes.

In the following paragraphs I present brief explanations on each listed feature/change.

Once the SDD is finished, it will serve as a guide for further development rounds and help keep Nodezator's development on track.

Implementing the missing test cases for Nodezator's automated system testing is crucial to ensure Nodezator's stability and to help speed up development, since it completely removes the inordinate amount of time and effort required to test all the apps features after each change.

I think an undo/redo system is self-explanatory. It is a basic yet very useful feature that makes editing sessions much more convenient. Being able to drag data (text) and files (for instance, images) into Nodezator is useful and convenient as well, as is clipboard access.

Input and output nodes will likely take the most time due to required changes in the whole app to support the feature. A whole graph in Nodezator represents a Python function, which you can see when you export the graph to Python code. Currently, that exported function doesn't have parameters or a return value. That is, all data entering and leaving the graph does so via its nodes (which are functions/callables themselves). Once this feature is implemented, graphs will have entrances and exits, inputs and output.

This will open up new possibilities for the next development rounds. For instance, once the graphs have parameters/outputs, we'll be able to turn them into nodes themselves. That is, we'll use this feature to enable group nodes/subgraphs, making Nodezator even more powerful. I also own you all a more comprehensive write up on what exactly are input/output nodes and how they'll work. I won't give you an explicit date, but I intend to write it soon. I'll post a link to that written piece here once I publish it, likely as another discussion.

As always, during a development round I often use the opportunity to implement a few small features (possibly quality-of-life features), so keep that in mind as well. Like in the previous development round, I might try implementing a search bar for nodes and the ability to reorder subparameters by dragging them instead of having to click them with the mouse. We'll see.

On the ETA (estimated time of arrival)

Following our announcement regarding the IndieSmiths project in 2025 and following years, I'm working on a few projects at any time. Usually, I focus on a single one for a few weeks while briefly working on the others from time to time, then switch my focus for a few weeks to another project while working more briefly on the remaining ones, and so on. Often, I work a bit more in a project on a whim or when I achieve a particularly productive flow.

This allows me to progress slowly but steadily, and put in quite enough work and time to be able to implement and release new features, as can be seen in my work reporsts. However, as a result of working in different projects, it is even harder for me to accurately provide ETAs for features or the outcome of tasks/development rounds. This is compounded by the fact that we are an open-source project, unlike commercial projects that have budget and staff.

Even so, I'd still like to keep providing timelines for my deliveries. I'll just try to adjust the deadlines according to my experience over time. This will give me some motivation and acountability. The motivation will come from the fact that I'll have to keep such dates in mind when planning and executing my work. The accountability will come in the form of reporting back to members/followers of the project and users of its apps/games on my performance in regards to meeting the deadlines or not during the whole process (usually once every couple of weeks).

Without further ado, the ETA for those tasks/features for Nodezator 1.6 is

flowchart
    text[April-September 2025]

Loading

This is a rather extended deadline because it takes into account...

• the higher number of features/task
• a feature like input and output nodes require large changes in the whole repo rather than changes in specific subsystems
• as explained before, the inherent impossibility of providing accurate ETAs, so we account for possible difficulties
• I'm still experimenting with the right amount of time to work efficiently and deliver quality work

Also, as pointed out in the previous development round:

despite having to extend our deadlines multiples times in the past, there was never indication in our results nor in feedback by the community that the work made was lacking in quality [...] and "as always, all the work was performed with as much transparency as possible, either by sharing a local copy of my repositories online or by working directly on a dev/development branch (the approach I adopted recently), measures which enable people to closely inspect my work at any time.

On top of that, I've always been updating people regularly on my development work, except for a few occasions that arise from time to time when tasks from other areas of the project or outside the project take up time. For instance, in addition to work on Nodezator's development, I also develop the Bionic Blue game, produce content for both projects, help users online, etc. Even on those occasions, though, what decreased was the frequency of my updates, not the frequency of my work on the project, which remained constant.

Risk management

The input/output nodes feature require a lot of GUI work, which usually takes more time to fine tune than other kinds of features. This represents a moderate risk of having to extend our deadline.

Development work is already hard to accurately predict, but on top of that the tasks scheduled also include finishing Nodezator's software design document, which is technical writing work and comes with its own challenges, so it is yet another factor that can possibly result in a deadline extension.

Final observations

Now the only missing piece of content related to this planned work is the detailed description of the input and output nodes. However, as the planned work was already listed, people can already provide feedback on them if desired. As always, all feedback is welcome.

Don't hesitate to reach out to me if you need anything.

Have a nice week!

Peace

[KennedyRichard]

Hello, everyone,

As some of you may know, , I'm developing/maintaining 03 projects:

• Nodezator
• myappmaker
• Bionic Blue

I think this is about the maximum number of simultaneous projects one can work on sustainably and don't intend to add even a single more project. The game project, Bionic Blue, once finished in the future, will be replaced by another game project. Since I'll probably work regularly on myappmaker and Nodezator at least for a couple more decades (given the scope of such projects and how much I still want to improve and further develop them), I'll then always have 03 project in my hands all the time.

The only problem is how to plan, schedule and manage the work sustainably so the 03 projects are always progressing.

The game project only requires skills that I already master or at least have operational knowledge on, so I can work on it every day in 01 or 02 ~01 hour sessions without much planning/research (also, most of its systems are implemented already, and I'll likely work more often on content rather than code). As for Nodezator and myappmaker, they are much more complex projects that require more planning and research and, therefore, much more.

I thought I could schedule development rounds for Nodezator and myappmaker simultaneously and switch between them each month or few weeks, which is why is scheduled this development round for Nodezator from April to September and a development round for myappmaker from April to July.

However, as I said, those projects require a lot of time and attention, so I only managed to work mostly on myappmaker and only did small maintenance work on Nodezator (analysed and accepted a PR). This has nothing to do with skills, workflow, motivation or negligence. It is just that I'm a single developer working on multiple projects simultaneously.

Because of that, in order to ensure sustainable and effective progress of all projects (but mainly on Nodezator and myappmaker, since the game project is mostly figured out), as I already explained in the latest monthly work report, I'll only work in one development round at a time, each few months.

That is, I'll work a few months in myappmaker, then work a few months in Nodezator and so on.

Since myappmaker is in a more unfinished state in comparison to Nodezator, I'll finish its current development round, then start another new one for it, only this time around. After that, I'll keep switching between the projects each few months. This will likely be much more productive, because during my struggle to work on both projects and only managing to work mostly on myappmaker, I did achieve significant progress on myappmaker. Now that I'll be able to focus on only one of them at a time, I expect much more progress from both, each on its own time.

Because of all that, consider this development round for Nodezator paused and postponed until further notice. I'll probably only get back to my work on Nodezator in 4 to 5 months, I'm not sure. I intend to soon post a centralized post on IndieSmiths/discussions listing the next planned development rounds (both their dates and scheduled tasks), so everyone know when to expect things to progress in both projects. I don't know when, but I also intend to post roadmaps for both projects so people know about the next planned steps as well (and can share their opinions/feedback).

Thank you all for you attention and patience.

Peace