I want to be able to double click on a .gozen file and it starts the editor, and skip the startup screen.

Not certain how to accomplish this yet

Use google forms and it's API to make it easy for people to submit bugs from within the application.
I guess I could have a link to my website where a bug submitting form exists, would be the quickest and easiest solution.

This could be an option of the top bar editor icon submenu and a command in the command bar.

FFMPEG is needed for nearly all complicated functionalities inside of GoZen and will be responsible for following items:

• Thumbnails;
• Loading/Importing videos;
• Displaying frames;
• Rendering;

This would provide us with codec support for nearly all video files.

The way to integrate ffmpeg is being tried by using GDExtensions and C#, we will use whatever works first.

Still need a settings menu which has to be accessible from the project manager and main UI.

For the settings menu to be finished, we need to check these boxes:

• Have a UI;
• Setting categories;
• Cache controls; (empty/view cache, see how much MB is being taken)
• Shortcut settings;

Not necessary for now as Module system is not finished yet:

• Community Module Garden integration;
• Custom Module Settings should be displayed as well;

Change the startup image to the gozen logo with the Godot logo. This is a note to myself so I won't forget to do this.

Project Manager and the way data is saved will change a bit because of the new project structure. No more working with a data class and data will be directly stored inside of the Project Manager auto load itself.

Problems or limitations

Just as the title says, it should hide the project settings button until a project has been opened however.

Feature to solve the problem

Fix the top bar to include these changes.

Other informations

No response

Problems or limitations

While I'm not particularly attached to this project (in fact, I learned about it lurking in godot's subreddit) or have anything against it, but I noticed that for translations you use csv files (which it seems that you store in yaml that later will be packed to several csv files...) instead of gettext system (that Godot introduced support for in Godot 4) which will probably suit much better, especially in future when there will be much more strings and more different languages.

Feature to solve the problem

Since gettext specifically was born for dealing with translations, there not much reasons to not using it.

It is standardized (much more then some csv file) especially when it come to features such as pluralization or documentation or anything related to translations. And beside features, standardization means that there already exist great tools to deal with gettext, for example, poeditor.

It's much easier to translate using gettext from translator viewpoint. You can easily create new locales from interface of software such as poedit with much easy, specify rules for pluralization (which is done mostly automatically for you by software, but you still provide your own), see outdated or changed or new string (once you will generate new pot file, translator can merge it with their po file so everything that outdated or changed will be automatically considered "fuzzy" so translator will see them without you, developer, being involved in this process), have support for translation memory (very useful feature that you won't get much editing some csv files using text editors) and just in general you have much better experience.
And, also, translators can leave translation specific comments in their file (yet another great feature of gettext), so next translator can see why previous translator might used that wording or translated something in that way, etc.

From your pov of developer with Godot it's also very easy. You just add resources that need to be translated to pot generation in project settings (resources such as scripts, scenes, etc) and then click "Generate POT" once in while when you want your translators to update their translations.
(And, translations itself for your game stored in source, that gettext collects from there and compile pot file from it that translators will use later.)
You can even provide context to your translations (2nd argument in tr and 3rd in tr_n functions) that will be used to distinguish same strings for different context, and also will be used to neatly sort list of string in po file, so translator will have much better time translating your stuff.
Also, gettext has support for special comments system that will be addressed directly to translators (TRANSLATORS:), but as of now, godot doesn't implemented it sadly. I opened proposal for it godotengine/godot-proposals#8555, so it might be added in near/far future.

Other informations

TLDR: use gettext for translation support of your program, not csv. Since you only starting, it might be much easier to move to gettext. Here godot docs about: https://docs.godotengine.org/en/stable/tutorials/i18n/localization_using_gettext.html (if you have questions about gettext, I might answer them, since I kinda already familiar with it in terms of user|translator and as developer.)

I'm talking about all of this because I kinda translator myself. In my profile you can found several fork of repos (mostly GTK software) that I translated (Mostly in Ukrainian language, but sometimes also Russian alongside) that also uses gettext. And let me tell you: gettext is just much-much-much better then some csv/json/whatever-system-and-format, especially when you translate and maintain translations for several projects. gettext + Poeditor just makes translator's life so easy, which in return will provide you with better translations.

TLDR2: Please, consider moving to gettext instead of this yaml to csv stuff.

The 'File Explorer' module uses the default Godot file explorer. This should be changed to a custom file explorer with the option for saving certain folders (bookmarks).

Things to note:

• We should have the default folders of each operating system easily accesible;
• Bookmarks are a must;
• Bookmarks need to become part of the FileExplorerInterface for other module creators to use;
• Must use the default theme; (Default theme at this point is still a work in progress)
• Must only have the necessary stuff.

We need to keep the base version of GoZen light, minimalistic looking and simple to use. So whoever wants to have a go at making this file explorer, please take this in mind. It can look and feel like any other file explorer.

Edit:
I've added this to the project page for GoZen.
The TO-DO's for this to be finished are:

• UI;
• Zen-mode UI;
• Save previous location which was accessed;
• Be able to create folders;
• Be functional as a file explorer basically;

The reason why I am implementing my own solution is as a learning experience and it gives people who want to make their own file explorer module easier. Feel free to create a module which uses the systems file explorer, or even the Godot file explorer. I have some plans on making it worth it to have our own made File Explorer, but those benefits will show later.

My intention is to make it when you open the file explorer when intending to add files to your project, that you have a split view of your system files and your project files. In the project files will also be the folder for adding global accessible files (Files which you can access from all your projects).

This will be the way for officially approved modules to be shown inside of the editor and made available to download directly from the editor.

This will contain both modules, effects and transitions.

More info for this feature coming as soon as I finish some other stuff.

We need a build system which we can set the version correctly, compile to GDExtension for all operating systems, build all projects and bind them into OS specific bundles.

New settings menu will have to be made to align with the new settings manager. This may involve some changes which will probably have to be made in the settings manager. However those changes should stick to a minimum.

Point of this is just to create a way to change settings which would be sufficient enough for the first Alpha version of GoZen

Top bar is almost finished but still needs a little amount of work:

• Hide project settings button on startup;
• Add tooltips;

The start menu is getting a complete make-over to make it more modular and cleaner looking.

Progress done on the start menu:

• Became a floating window with transparent rounded corners;
• Became a separate Godot project;

The reason for making it into a separate Godot project was for multiple reasons, first of all UI/look based reasons. I wanted it to become a floating window with a clean look of rounded corners. Because you can not make the main window itself invisible and having to deal with changing resolutions of the project together with disabling and setting different window properties proved to be difficult, I found that making the startup manager into it's own element to be a good change. Also, having transparency on for your window has a performance impact, so the having it as a separate project eliminates that problem.

Another change and probably be the biggest reason is to keep the code and project clean and simple. Now we can more easily implement the opening of video files by double clicking the project file as it does not first need to go through the start menu, it could directly be opened through the editor itself. Project path would be given as an argument and for new projects it's basically giving the project screen size as an argument. If no arguments are given it will default to standard 1080p video project size.

Render menu will need a couple of items to be checked of before this can be closed:

• UI;
• Zen-mode UI;
• Basic render presets;
• Advanced render controls;
• Local rendering should be working; (This needs FFMPEG)

This is related to the codec support request in issue: #21

The settings manager needs some changes and some checking so I can close that part of my to-do list before the first alpha gets released.

Right now we are having a basic version checker which uses a json file. I'd like to improve the whole versioning system in some way that it more easily displays when you are in a dev build, a test build, or an official release.

Not certain how to properly achieve this in a clean and effecient way yet, but I'll be working on it when I have the time, this is not a priority for now but should be in place for Version 1.0.0.

Note to myself to decrease the complexity and simplfy the logo.

Roadmap for GoZen

Alpha

Everything which needs to be done before the alpha can be released.

To Do's:

• [GDExtension] Render profile (basic version);
• [GDExtension] Renderer (basic version);
• [GDExtension] Video class (importing audio + seeking/getting video frames);
• [Timeline] Clips data structure;
• [Timeline] Clips saving/loading;
• [Timeline] Clip cutting;
• [Timeline] Clip moving;
• [Timeline] Clip resizing;
• [Timeline] Clip grouping;
• [Timeline] Clip moving (in same track + multi track);
• [Timeline] Make the play-head work;
• [Timeline] Display time positions on top;
• [Timeline] Audio thumbnails;
• [Project View] Display what the play-head is on;
• [Project View] Basic playback controls;
• [Effects] Basic audio volume effect;
• [Effects] Basic fade;
• [Effects] Basic transforms (position, scale, size, rotation);
• [Effects] Give files basic effects by default;
• [Effects] In effects panel display both file effects and clip effects;
• [Renderer] Have render export video frames from timeline;
• [Renderer] Have render export audio data from timeline;
• [Renderer] Basic render presets;
• [Renderer] Option to render specific area of timeline;
• [Settings] Move away from ConfigFile (performance limitations);

Beta

Everything which needs to be done before the beta can be released.

To Do's:

• [Build system] Have an automated build system working;
• [Effects] Have effect times to have more dynamic effects;
• [Transitions] Create a basic transition which can be applied to timeline;
• [Shortcut handler] Have the shortcut handler set up;
• [Core] Have undo and redo working correctly;
• [Subtitle layout] Have a working subtitle handler layout;
• [Dialog manager] Have a custom dialog window for opening/selecting/saving files;
• [Project View] Display audio meter;

First release

Everything which needs to be done before GoZen can finally be released.

To Do's:

• [Core] No crashes;
• [Core] All alpha+beta bugs fixed;
• [Build system] Working Linux build;
• [Build system] Linux installer;
• [Build system] Add to pacman? (not certain how easy or if possible at all);
• [Build system] Working Windows build;
• [Build system] Windows installer;
• [Module garden] Have the module garden basics setup;
• [Project manager] GoZen "bundles" for exporting projects;

Not completed

I'll keep adding stuff to this list as time goes on, this will be the document I use personally to keep track of my progress and to easily find things I can work on next.

The media pool is another important aspect of the editor (previously called files view).

TO-DO's:

• UI;
• Zen-mode UI;
• Showing files; (colors, texts, videos, audio)
• Have folder structure;
• Global files; (files which are available in any project)
• File thumbnails;
• Buttons to create colors and texts;

The default editor screen still has some work and won't be finished very early on because of following to-do's:

• UI;
• Zen-mode UI;
• Default positions for modules;
• Possibility to change module locations;
• Way to add completely custom module types to the editor layout;
• Tabs + Containers;
• Save system to save changes + split offsets;
• Hide empty tabs;

Design plans are inside of the /assets/design folder of the project

Version or branch

ec8bfe1

Operating system

Windows

Bug behaviour

Unable to drag the window (or press anything) while the command bar is enabled.

Expected behaviour

I should be able to drag the window when it is enabled.

Steps to reproduce

1. Open the command bar (using /)
2. Try dragging the window (you can't)

Other informations

I think the command bar should be hidden when the user presses something else. (And maybe add a semi-transparent background to indicate you can't press other things)

Just to have a very basic layout version of where to put each thing. I'm stepping away from the previous plans of having multiple fields where things can be dragged as it was making things overly complicated to work with for now.

When implementing modules again, I'll look into making the big layout again with multiple slots of where to put each screen element.

(X are module spots)
X - Project view - X
X - Timeline - X

More complex design would add a left and right column:
X - X - Project view - X - X
X - X - Timeline - X - X

Goes hand in hand with #67

We need colour files to test the timeline and media pool, but have no way of creating them.

My idea is to have a setting for a duration and a default color which is part of "media pool". Creating a new color for will give you that default color with the default set duration, double clicking will open the "file" in the effects view where you can eventually change the color with a color picker.

Possible addition would be to let the user store a certain amount of colors

Main window has some items/features which need changing because of the new overall structure of the GoZen project. These changes to the main window part can be achieved within a day or so

Version or branch

0.0.1-Alpha

Operating system

Linux

Bug behaviour

Can not drag the window around because it was made borderless.

Expected behaviour

Being and to drag it

Steps to reproduce

.

Other informations

No response

Discussed in https://github.com/voylin/GoZen/discussions/8

How would a command paletta improve use-ability:

• Time-saving: Quick way of doing actions;
• Convenient: If you can't find how to do something, you can search for it;
• Customize-ability: People can create their own commands to do certain things quicker;

How to implement:
Should be some kind of bar overlay in which can be typed. When hovering over commands a description should popup somewhere (not certain about how this would work yet).

This could go together with a possible 'Zen mode' in which all possibly not needed buttons are completely hidden and the main way of controlling things in the editor is by keyboard using the command palette.

Edit:
This got added to the Github project for GoZen. The command bar still needs some polishing and fixing:

• Use arrow keys to select command;
• Make UI more readable;

Add an option to select the desired codec used to save the video as.
E.g:

match codec:
    "MPEG2":
        var command = [
  'ffmpeg', '-y',  # Overwrite output file if it already exists
  '-f', 'image2pipe',  # Input format: image sequence
  '-r', str(25),  # Frame rate
  '-i', '-',  # Read input from pipe
  '-c:v', mpeg2',  # VP9 video codec
  '-b:v', '1M',  # Video bitrate
  '-pix_fmt', 'yuv444p',  # Pixel format - default: yuv420p
  '-f', 'webm',  # Output format: WebM
  'output_video.webm'  # Output file path
]
        

You could even add and option for AV1 encoding which many editors don't support yet. You could see what encoders the hardware supports via ffmpeg -encoders (source:https://ffmpeg.org/ffmpeg-codecs.html#Encoders)

Similar to normal settings menu, but with the project specific settings.

• UI;
• Making the settings work and save on change;

Mainly a not so I remember to implement this. Right now rendering happens by sending the images to a python server running locally on the pc. But by sending the files, project data and timeline data, it would be possible to create servers which render out the footage.

Ways tht rendering can work:

• locally
• half remote
• fully remote

Future plan could also be too edit over fully over the web.

Again, mainly a note for myself but this could also show people done future feature for the editor.

The Startup module is nearly finished, couple of boxes still need to be checked of:

• Recent projects; (File Explorer needs to work first)
• Settings should be accessible from startup screen;

Problems or limitations

the project open in 1080p screen so its not usable in any smaller screens and you have to support these screens because this is one of the soul purpose of a "lightweight-bare minimum" video editor it should work on an old laptop... old hardware in generals

Feature to solve the problem

make it easy to resize and open smaller than the monitor, I'm not sure but this thing built in godot

Other informations

No response

The default project manager which we have now works, but needs more improvements to actually be useful to use. Features like the sorting have to be improved a little so it can go both ways.

Things to note:

• Don't over complicate it (Keep visuals minimalistic and clean/simple);
• Must use the default theme (Default theme at this point is still a work in progress).

I have already created a base version, it has some bugs, especially when importing new projects, sometimes importing certain projects twice for some reason. As of now it works and this is good enough to be in the first milestone release.

Edit: This is added to the Version 0.0.1 milestone as it is bugy and needs fixing/re-work anyway before we can release the first version of GoZen

hey!

if you're planning to make this project free for people to tinker with and share around, consider choosing a license for the program. otherwise, anything you don't explicitly allow in a license is proihibited by default, so you might wanna include something if you want to allow.

my personal bias is that, you're doing a new thing that a lot of people will benefit from, specially if you're intending to focus on having it in a small file size in the end, and Godot can also export to the web, so the AGPL (v3 and later) would be an awesome fit compared to the standard GPLv3, because on top of it implementing copyleft, it also has a case for giving the same rights to people interacting with the program over the internet (complements Godot projects being usable on the web).

Lichess is a project under this license, requiring anyone who publicly hosts their own version of the website to also distribute the code, while Godot itself is more permissive under the MIT license, but that is if you're willing to allow for components or whole derivatives of your project to be shared as proprietary / with restricted source and execution.

pick and choose what you think fits best in the project, but remember these aren't the only ones. do your research ^^'