future of cinGG UI?
I've been away for a while dealing with family stuff but I noted that the last AppImage of the traditional UI cinGG is from august and more recently the app has a Qt interface. I hope we are not seeing a switch from the traditional UI semantics, without continuing the power user functionality that existed for so long. For a long time I considered that a UI based on a popular toolset was a good idea but abandonned that goal after looking at how heavily the old UI was embedded into the code. Qt was an obvious choice. So don't get me wrong, I congratulate the author's update, but would like to point out a few issues that should be addressed. * The traditional UI accepted immediate mode commands entered from the keybord. While possible in Qt, it seems that operational mode is not active in the current Qt version. When I type (q) on the timeline I want to see the "quit" dialog. Likewise, <shift>R should immediately pop up the render dialog. * I understand the current popular "wayland" position that apps should each be managed by a single top level window and that somehow IPC between windows is a "cough cough" security bug...but! The workflow of content creation in a single window UI is greatly crippled by cramming everything in a single top level window. I contend that each major function: timeline, compositor, and asset-management should have their own independent top level window. I use a dual monitor configuration and need to be able to place function windows on independent monitors to space things out. * color themes need to be better considered. The default theme is fine, but when you introduce a popup like the global settings over top of the full screen app window, the content gets lost in the haze. I'd contend that popups should use a different background color so their content becomes more ovbious. * the new Qt UI is polished and very pretty. PLEASE, don't favor pretty fluff over power user functionality though. having to click a series of pulldown menus to reach a frequently used function is unpleasant. Sometimes keyboard commands are "better" than point and click. * a bug that seems to be prevalent in cinGG is that upon opening a clip, the default timeline doesn't fully render the audio tracks, but only for about half of the visible clip. The full rendering doesn't take place unless I zoom in or out on the timeline time range. Truth is that I am impressed with the Qt UI, but we need to maintain a aire of power user friendliness so that productivity doesn't take a backseat to asthetics. I've always maintained that WYSIWYG is a bad concept and I prefer, "you aksed for it, you got it!" For now I'm hoping the traditional UI app continues to be the main dev branch and receives ALL fixes and enhancements for the foreseeable future. On a final note I recently pulled down the full git repo and tried to do a default build (use cinGG 3rd party libs) but the "build install" fails with a recurve out of memory error when trying to install certain plugins: I think ladspa stuff? -Rob
Hi Rob, welcome back, and thank you for this careful mail. Your concerns are fair, so let me go through them one by one. First the big picture. The Qt6 version is not a new program. We took the existing Cinelerra-GG code over one to one: the editing engine, the EDL, the plugins and the render paths are the code you know. Qt6 replaces the drawing layer underneath and adds native panels on top. The goal is not a prettier but weaker Cinelerra, it is the opposite. The old UI limited us in many places, and a lot of professional features we wanted were simply not possible with it. With Qt6 they are within reach, and we plan many of them. The traditional version is not going away. It continues to be maintained, and fixes in the shared engine benefit both versions. The new professional features are developed in the Qt6 version. What you see today is an alpha. Not everything is ported yet, so some things you rely on may still be missing or behave differently. That is exactly where reports like yours help us. Keyboard. Every command now runs through one command table, about 300 commands, nearly all on their keys from the traditional UI. Settings > Keyboard Shortcuts... shows them on a drawn keyboard, and you can put any command on any key. Your two examples: In the last days we also brought back the remaining keys of the old main window. The alpha AppImage of 27 October does not have them yet, the next one will. * Quit is on Ctrl+Q in the Qt6 version at the moment, not on Q. You can put it back on Q in Keyboard Shortcuts. * Shift+R still triggers Render..., but it opens the Deliver page (render settings, presets and the render queue on one page) instead of the old dialog. Windows on two monitors. The timeline is the main window. Every other panel (Viewer, Compositor, Resources, Effect Inspector and so on) is a dock that you can tear off into its own top-level window: drag its title bar out of the main window, or double-click it. Then put it on your second monitor. Window > Save Layout... keeps the arrangement, and Ctrl+Shift+F1 to F6 bring a saved layout back. Popups over the main window. Good point, I have noted it. Dialogs should stand out more clearly from the window behind them. A screenshot of the case you mean would help. Pretty versus power. Agreed, and that is why the keys came first. Another step in that direction is in the works: a remote control through which scripts and AI assistants can drive Cinelerra, every command and every effect, each step undoable. It is not in an AppImage yet. Audio tracks drawn only half way. To reproduce it I need a few details: was it the traditional AppImage from August or the Qt6 alpha (and which date), what kind of clip (container, codec, length, number of audio channels), and at which point the waveform stops. Build. Please tell me which repository you cloned (the traditional git or the Qt6 one), the commands you ran, your distribution and compiler, and the last 50 lines of the output. If it was the Qt6 repository built with CMake: CMake has a recursion limit that the Qt6 deployment helpers can hit, and running cmake with -DCMAKE_MAXIMUM_RECURSION_DEPTH=5000 is worth a try. And please keep the list coming. Which power-user workflows do you use every day? Those are the ones we want to make sure the new version does at least as well. Cheers Sam Am 28.10.26 um 17:45 schrieb Rob Prowel via Cin:
I've been away for a while dealing with family stuff but I noted that the last AppImage of the traditional UI cinGG is from august and more recently the app has a Qt interface. I hope we are not seeing a switch from the traditional UI semantics, without continuing the power user functionality that existed for so long.
For a long time I considered that a UI based on a popular toolset was a good idea but abandonned that goal after looking at how heavily the old UI was embedded into the code. Qt was an obvious choice.
So don't get me wrong, I congratulate the author's update, but would like to point out a few issues that should be addressed.
* The traditional UI accepted immediate mode commands entered from the keybord. While possible in Qt, it seems that operational mode is not active in the current Qt version. When I type (q) on the timeline I want to see the "quit" dialog. Likewise, <shift>R should immediately pop up the render dialog.
* I understand the current popular "wayland" position that apps should each be managed by a single top level window and that somehow IPC between windows is a "cough cough" security bug...but! The workflow of content creation in a single window UI is greatly crippled by cramming everything in a single top level window. I contend that each major function: timeline, compositor, and asset-management should have their own independent top level window. I use a dual monitor configuration and need to be able to place function windows on independent monitors to space things out.
* color themes need to be better considered. The default theme is fine, but when you introduce a popup like the global settings over top of the full screen app window, the content gets lost in the haze. I'd contend that popups should use a different background color so their content becomes more ovbious.
* the new Qt UI is polished and very pretty. PLEASE, don't favor pretty fluff over power user functionality though. having to click a series of pulldown menus to reach a frequently used function is unpleasant. Sometimes keyboard commands are "better" than point and click.
* a bug that seems to be prevalent in cinGG is that upon opening a clip, the default timeline doesn't fully render the audio tracks, but only for about half of the visible clip. The full rendering doesn't take place unless I zoom in or out on the timeline time range.
Truth is that I am impressed with the Qt UI, but we need to maintain a aire of power user friendliness so that productivity doesn't take a backseat to asthetics. I've always maintained that WYSIWYG is a bad concept and I prefer, "you aksed for it, you got it!"
For now I'm hoping the traditional UI app continues to be the main dev branch and receives ALL fixes and enhancements for the foreseeable future.
On a final note I recently pulled down the full git repo and tried to do a default build (use cinGG 3rd party libs) but the "build install" fails with a recurve out of memory error when trying to install certain plugins: I think ladspa stuff?
-Rob
_______________________________________________ Cin mailing list --cin@lists.cinelerra-gg.org To unsubscribe send an email tocin-leave@lists.cinelerra-gg.org
On 10/28/26 1:26 PM, Sam via Cin wrote:
Hi Rob,
welcome back, and thank you for this careful mail. Your concerns are fair, so let me go through them one by one.
What you see today is an alpha. Not everything is ported yet, so some things you rely on may still be missing or behave differently. That is exactly where reports like yours help us.
using appimage (CinGG-qt6-alpha-20261027-anylinux-x86_64.AppImage)
Windows on two monitors. The timeline is the main window. Every other panel (Viewer, Compositor, Resources, Effect Inspector and so on) is a dock that you can tear off into its own top-level window: drag its title bar out of the main window, or double-click it. Then put it on your second monitor. Window > Save Layout... keeps the arrangement, and Ctrl+Shift+F1 to F6 bring a saved layout back.
As long as the Qt MDI interface is used and floating windows are "children" of the timeline window I think it will be problematic for me. Upon testing I can only "move" a floating window once (when I pull it out of the timeline window) then afterwards it only responds to resize events. Also, child floating windows are not allowed to be "behind" the main timeline window which makes it too easy to accidentally merge the floater back into the timeline panel and screw up the timeline layout panel. I really do prefer separate/independent X11 windows for each function. using openbox, xorg, and nvidia-570.207 driver. in twinview config when I'm editing content, and xaphod config any other time
Pretty versus power. Agreed, and that is why the keys came first. Another step in that direction is in the works: a remote control through which scripts and AI assistants can drive Cinelerra, every command and every effect, each step undoable. It is not in an AppImage yet.
You had me until you mentioned AI. Long passionate anti-AI rant, so I'll digress. re - color scheme: just bring up the global configuration screen over top of the main app MDI panel and it's pretty obvious that something needs to be done to make the popup more distinguishable from the background.
Audio tracks drawn only half way. To reproduce it I need a few details: was it the traditional AppImage from August or the Qt6 alpha (and which date), what kind of clip (container, codec, length, number of audio channels), and at which point the waveform stops.
It happens with pretty much every media clip I load, upon first load. Once the thumbs exist in .bcast5 directory the clip loads properly upon subequent tries. If I delete the indexes and thumbs then it burps again. I've tried with both you-tube content (av1/opus/matroska) and with h264/aac content. Latest august (traditional UI) cingg does not suffer the problem, just the Qt appimage I tried listed above.
Build. Please tell me which repository you cloned (the traditional git or the Qt6 one), the commands you ran, your distribution and compiler, and the last 50 lines of the output. If it was the Qt6 repository built with CMake: CMake has a recursion limit that the Qt6 deployment helpers can hit, and running cmake with -DCMAKE_MAXIMUM_RECURSION_DEPTH=5000 is worth a try. origin is: https://git.cinelerra-gg.org/goodguy/cinelerra.git
last pulled commit (HEAD) was: commit 3a30a189bfda351205615618fc2b206901bb6934 (HEAD -> master, origin/master, origin/HEAD) Author: Good Guy <good1.2guy@gmail.com> Date: Tue Oct 20 10:59:07 2026 -0600 Credit FFmpeg team and Andrew for patches for FFmpeg 9.0.2 generated standard configure program and ran with all defaults uses traditional gmake debian13: gcc 14.2.0-19 no output available because I deleted all artifacts and "git clean" on local repo after failure. build ran correctly. It was the install to /usr/local that barfed.
Hi Rob, thank you for testing again and for the precise details. They were enough to find the causes. Here is where each point stands. The fixes are done and will be in the next alpha AppImage. The one from 27 October has none of them yet. Floating windows that move only once. I found one cause. A floating panel had a 12 px resize border along its top edge, and its title bar is 29 px high. Grabbing the upper part of the title started a resize instead of a move. The border at the top is now 4 px, the corners keep 12 px. I reproduced it under openbox 3.6.1: before, a drag 8 px below the top edge resized the window, now it moves it. "Only once" itself I could not reproduce, three drags in a row moved the window in both versions. I also cannot test TwinView or separate X screens here. If it still happens with the next AppImage, please tell me where on the title bar you grab it. Independent windows. There is a new setting under Settings > Preferences
Appearance > Floating panels. "Stay above the main window" is the default and keeps the current behaviour. With "Separate windows" every floating panel is a window of its own, which the main window can cover, for example on your second monitor. The setting applies at once. In this mode the window manager moves the panel like any other window, and letting it go over the main window no longer docks it back, so your layout stays as it is. To dock a panel again, double-click its title.
Popups over the main window. Done. Every dialog now has a slightly lighter surface than the panels behind it and draws a thin frame of its own, so it stands out even without a compositor shadow. I checked the Preferences and ten other dialogs under openbox with the dark Onyx theme. Audio tracks drawn only half way. Found and fixed, and your description was the key. On first load the timeline drew the waveform from the audio index while the index was still being built, and kept that half-finished picture. Nothing told the timeline when the index was complete. That is why the second load was fine. Now a waveform drawn from an unfinished index is only provisional and is drawn again when the index is done. With the index deleted, the old version drew 82 to 93 of 578 columns of a test clip on first load, the new one all 578. AI. Fair enough, no debate from my side. Just so you know where things stand: the Qt6 port is built with an AI coding assistant, Claude Code, and every commit says so. With a team as small as ours the port would not have been possible otherwise. I see it as a tool, as Linus Torvalds does, who now uses Claude Code for kernel work too (https://www.phoronix.com/news/Linus-Torvalds-Claude-Code). I completely understand if you want nothing to do with it. The traditional version is still maintained, and fixes in the shared engine benefit both versions. Inside Cinelerra nothing of it is forced on you. The remote control is off unless you switch it on yourself (Settings > Preferences > Interface
Remote control), and it is a local socket, not a network port. Transcription uses a Whisper model, by default locally on your machine, and only runs when you choose Transcribe... yourself. Only its optional cloud engine sends audio to a service, and only with your own API key.
Build. Thanks, that helps. You built the traditional repository (goodguy/cinelerra.git at 3a30a189), not the Qt6 one, and only make install failed. Without its output I cannot say why. If you try again, make install 2>&1 | tee install.log keeps the output, and the last 50 lines are enough. One question already: did make install run as root or with sudo? Once the next AppImage is out, I would be glad to hear whether the separate windows work for your two monitors. Sam Am 28.10.26 um 23:23 schrieb Rob Prowel via Cin:
On 10/28/26 1:26 PM, Sam via Cin wrote:
Hi Rob,
welcome back, and thank you for this careful mail. Your concerns are fair, so let me go through them one by one.
What you see today is an alpha. Not everything is ported yet, so some things you rely on may still be missing or behave differently. That is exactly where reports like yours help us.
using appimage (CinGG-qt6-alpha-20261027-anylinux-x86_64.AppImage)
Windows on two monitors. The timeline is the main window. Every other panel (Viewer, Compositor, Resources, Effect Inspector and so on) is a dock that you can tear off into its own top-level window: drag its title bar out of the main window, or double-click it. Then put it on your second monitor. Window > Save Layout... keeps the arrangement, and Ctrl+Shift+F1 to F6 bring a saved layout back.
As long as the Qt MDI interface is used and floating windows are "children" of the timeline window I think it will be problematic for me. Upon testing I can only "move" a floating window once (when I pull it out of the timeline window) then afterwards it only responds to resize events. Also, child floating windows are not allowed to be "behind" the main timeline window which makes it too easy to accidentally merge the floater back into the timeline panel and screw up the timeline layout panel. I really do prefer separate/independent X11 windows for each function.
using openbox, xorg, and nvidia-570.207 driver. in twinview config when I'm editing content, and xaphod config any other time
Pretty versus power. Agreed, and that is why the keys came first. Another step in that direction is in the works: a remote control through which scripts and AI assistants can drive Cinelerra, every command and every effect, each step undoable. It is not in an AppImage yet.
You had me until you mentioned AI. Long passionate anti-AI rant, so I'll digress.
re - color scheme: just bring up the global configuration screen over top of the main app MDI panel and it's pretty obvious that something needs to be done to make the popup more distinguishable from the background.
Audio tracks drawn only half way. To reproduce it I need a few details: was it the traditional AppImage from August or the Qt6 alpha (and which date), what kind of clip (container, codec, length, number of audio channels), and at which point the waveform stops.
It happens with pretty much every media clip I load, upon first load. Once the thumbs exist in .bcast5 directory the clip loads properly upon subequent tries. If I delete the indexes and thumbs then it burps again. I've tried with both you-tube content (av1/opus/matroska) and with h264/aac content.
Latest august (traditional UI) cingg does not suffer the problem, just the Qt appimage I tried listed above.
Build. Please tell me which repository you cloned (the traditional git or the Qt6 one), the commands you ran, your distribution and compiler, and the last 50 lines of the output. If it was the Qt6 repository built with CMake: CMake has a recursion limit that the Qt6 deployment helpers can hit, and running cmake with -DCMAKE_MAXIMUM_RECURSION_DEPTH=5000 is worth a try. origin is: https://git.cinelerra-gg.org/goodguy/cinelerra.git
last pulled commit (HEAD) was: commit 3a30a189bfda351205615618fc2b206901bb6934 (HEAD -> master, origin/master, origin/HEAD) Author: Good Guy <good1.2guy@gmail.com> Date: Tue Oct 20 10:59:07 2026 -0600
Credit FFmpeg team and Andrew for patches for FFmpeg 9.0.2
generated standard configure program and ran with all defaults uses traditional gmake debian13: gcc 14.2.0-19
no output available because I deleted all artifacts and "git clean" on local repo after failure. build ran correctly. It was the install to /usr/local that barfed.
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
Rob, Let me also assure you that the current CinGG version is here to stay for as long as possible. But the QT6 version is a much needed update for modernization and to be more relevant for the upcoming generations who have learned the technology on better/faster computers with different expectations. For example, everyone these days uses Ctrl-z to undo their change whereas the default original in CinGG was just z (Ctrl-z was added later upon request) and Ctrl-q is expected as the shortcut for quit whereas the original CinGG just uses q. In addition, in case you never noticed this, an "alternative" shortcuts AppImage is available because there is no way to redefine keys in the original CinGG and this has been quite detrimental to many users; with the QT6 version, defining keys to suit the user will be possible. Also, the current CinGG intends to continue to work even on 32-bit and older Operating Systems, like Ubuntu 16, whereas QT6 is intended to work on the current latest version of operating systems. There will be a CinGG release on October 31 which includes the latest FFmpeg version 9 - although vaapi render formats will not be working yet. I will try to refer to the original CinGG as "classic cinelerra" and QT6 as "qt6 cinelerra". On Wed, Oct 28, 2026 at 10:45 AM Rob Prowel via Cin < cin@lists.cinelerra-gg.org> wrote:
I've been away for a while dealing with family stuff but I noted that the last AppImage of the traditional UI cinGG is from august and more recently the app has a Qt interface. I hope we are not seeing a switch from the traditional UI semantics, without continuing the power user functionality that existed for so long.
For a long time I considered that a UI based on a popular toolset was a good idea but abandonned that goal after looking at how heavily the old UI was embedded into the code. Qt was an obvious choice.
So don't get me wrong, I congratulate the author's update, but would like to point out a few issues that should be addressed.
* The traditional UI accepted immediate mode commands entered from the keybord. While possible in Qt, it seems that operational mode is not active in the current Qt version. When I type (q) on the timeline I want to see the "quit" dialog. Likewise, <shift>R should immediately pop up the render dialog.
* I understand the current popular "wayland" position that apps should each be managed by a single top level window and that somehow IPC between windows is a "cough cough" security bug...but! The workflow of content creation in a single window UI is greatly crippled by cramming everything in a single top level window. I contend that each major function: timeline, compositor, and asset-management should have their own independent top level window. I use a dual monitor configuration and need to be able to place function windows on independent monitors to space things out.
* color themes need to be better considered. The default theme is fine, but when you introduce a popup like the global settings over top of the full screen app window, the content gets lost in the haze. I'd contend that popups should use a different background color so their content becomes more ovbious.
* the new Qt UI is polished and very pretty. PLEASE, don't favor pretty fluff over power user functionality though. having to click a series of pulldown menus to reach a frequently used function is unpleasant. Sometimes keyboard commands are "better" than point and click.
* a bug that seems to be prevalent in cinGG is that upon opening a clip, the default timeline doesn't fully render the audio tracks, but only for about half of the visible clip. The full rendering doesn't take place unless I zoom in or out on the timeline time range.
Truth is that I am impressed with the Qt UI, but we need to maintain a aire of power user friendliness so that productivity doesn't take a backseat to asthetics. I've always maintained that WYSIWYG is a bad concept and I prefer, "you aksed for it, you got it!"
For now I'm hoping the traditional UI app continues to be the main dev branch and receives ALL fixes and enhancements for the foreseeable future.
On a final note I recently pulled down the full git repo and tried to do a default build (use cinGG 3rd party libs) but the "build install" fails with a recurve out of memory error when trying to install certain plugins: I think ladspa stuff?
-Rob
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Wed, 28 Oct 2026 12:45:31 -0400 Rob Prowel via Cin <cin@lists.cinelerra-gg.org> wrote:
* I understand the current popular "wayland" position that apps should each be managed by a single top level window and that somehow IPC between windows is a "cough cough" security bug...
Hi, that is a misconception. Wayland does not in any way mandate or recommend single-window application architecture. Perhaps this misconception stems from multi-process applications. There is no problem with a single process having as many windows as it wants. However, Wayland does intend to isolate different Wayland IPC connections from each other, and two processes simply cannot share one Wayland connection. Hence processes (not windows) get isolated from each other by default. Thanks, pq
participants (4)
-
Pekka Paalanen -
Phyllis Smith -
Rob Prowel -
Sam