[kwin] [Bug 482142] drag in drop files in Google Chrome renders Chrome unusable
https://bugs.kde.org/show_bug.cgi?id=482142 --- Comment #51 from Hyuri --- To be clear, this was only fixed for Plasma 6+, not Plasma 5.27+, right? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 482142] drag in drop files in Google Chrome renders Chrome unusable
https://bugs.kde.org/show_bug.cgi?id=482142 Hyuri changed: What|Removed |Added CC||hyuri.pimen...@gmail.com --- Comment #6 from Hyuri --- This is happening in Plasma 5.27 as well (Kubuntu 23.10). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-frameworkintegration] [Bug 423669] Change OK/Cancel buttons order/layout to improve consistency with other software
https://bugs.kde.org/show_bug.cgi?id=423669 Hyuri changed: What|Removed |Added CC||hyuri.pimen...@gmail.com --- Comment #10 from Hyuri --- This small quality-of-life change would be perfect to feature in the Plasma 6 release ;) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 473684] Sequence lost 4 hours of edits
https://bugs.kde.org/show_bug.cgi?id=473684 Hyuri changed: What|Removed |Added Flags||timeline_corruption+ -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 473684] New: Sequence lost 4 hours of edits
https://bugs.kde.org/show_bug.cgi?id=473684 Bug ID: 473684 Summary: Sequence lost 4 hours of edits Classification: Applications Product: kdenlive Version: 23.04.3 Platform: Flatpak OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 161139 --> https://bugs.kde.org/attachment.cgi?id=161139=edit Project File SUMMARY I'm not sure what exactly what to report. I lost 4 hours of work. I duplicated a timeline and worked on it for 4 hours, closed the app, and when I opened it again, the sequence had been restored to the state when I first duplicated it, before I changed anything. The sequence in question is "CUT_ROUGH". It was originally duplicated from "SELECT_3", before I spent 4 hours working on it. I opened the project file in a text editor and noticed there are two "CUT_ROUGH" tractors. So it gives me a glimmer of hope that my edited sequence might be hidden there in the file somewhere. If anyone who knows how to navigate the project file could take a look in the file and see if there is indeed another sequence and it can be restored, that would really save me right now. STEPS TO REPRODUCE 1. Duplicate sequence 2. Work on duplicated sequence for 4 hours — save. 3. Close app, and re-open 4. See how the sequence is restored to a previous state and the work is lost. OBSERVED RESULT Sequence restored to a previous state. EXPECTED RESULT All the work I did in the sequence kept and save. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Pop!_OS 22.04 (available in About System) Gnome Version: 42.9 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 470005] Lift/Gamma/Gain bugs (slider resets color wheel & color jumps around)
https://bugs.kde.org/show_bug.cgi?id=470005 --- Comment #1 from Hyuri --- I found a bug in the tracker that is the same issue as BUG #1 but, in my case, I couldn't reproduce it by resetting the effect. It might be the same issue but only happening sometimes, under certain conditions in my case. https://bugs.kde.org/show_bug.cgi?id=448467 Video that shows what BUG #1 looks like: https://disk.yandex.ru/i/qO-fKzGbbGdXqQ -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 470005] New: Lift/Gamma/Gain bugs (slider resets color wheel & color jumps around)
https://bugs.kde.org/show_bug.cgi?id=470005 Bug ID: 470005 Summary: Lift/Gamma/Gain bugs (slider resets color wheel & color jumps around) Classification: Applications Product: kdenlive Version: 23.04.1 Platform: Flatpak OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Effects & Transitions Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- SUMMARY Hi! Firstly, thank you very much for the recent (23.04.1) fixes and improvements to the Lift/Gamma/Gain effect! It's a joy to use now! Only issue is: I'm still experiencing a bug (1) I was experiencing before, and found a new one (2). They seem related, so I bundled them together in this report, but let me know if I should break them down into individual reports. BUG #1 Sometimes the dot in the color wheel randomly jumps around when I move its slider up and down. The color changes randomly, accordingly. I tried to reproduce it again but it only happens sometimes. I don't know how to reproduce it. I guess simply using it for long enough, pasting the effect onto other clips, tweaking, adding other effects before and/or after, moving effects around, perhaps. I'm guessing it might have something to do with having one or — somehow — more than one of the RGB values highlighted and being changed at the same time as the slider when I scroll it. STEPS TO REPRODUCE BUG #1 I can't reliably reproduce it. All I did was: 1. Add a Lift/Gamma/Gain effect to a clip 2. Move the Gain's slider up and down using Ctrl + Scroll 3. You should see the dot in the color wheel jumping around to random points BUG #2 After shifting the colors (hue & saturation) in the color wheel, Ctrl + Scrolling or Shift + Scrolling the luma slider to zero (0.000) resets the color wheel. Happens to all three — Lift, Gamma or Gain. Resetting (Right Clicking) the Lift's slider resets its color wheel as well (because Lift's default is 0.000, while Gamma and Gain's defaults are 1.000). Doesn't happen when I bring the slider to zero by grabbing it with Left Click and moving it with the mouse. STEPS TO REPRODUCE BUG #2'S GAMMA OR GAIN ISSUE 1. Add Lift/Gamma/Gain effect to a clip 2. Shift the colors in the Gamma or Gain's color wheels 3. Using Ctrl + Scroll, lower the Gamma or Gain's luma slider all the way down to zero (0.000) 4. See how the color wheel has reset itself STEPS TO REPRODUCE BUG #2'S LIFT SLIDER SCROLL ISSUE 1. Add Lift/Gamma/Gain effect to a clip 2. Shift the colors in the Lift's color wheel 3. Move the Lift's luma slider up or down any amount 4. Shift + Scroll the Lift's luma slider to zero (0.) 5. See how the color wheel has reset itself STEPS TO REPRODUCE BUG #2'S LIFT SLIDER RESET ISSUE 1. Add Lift/Gamma/Gain effect to a clip 2. Shift the colors in the Lift's color wheel 3. Move the Lift's luma slider up or down any amount 4. Reset the Lift's slider by Right Clicking on it 5. See how the color wheel has reset itself as well OBSERVED RESULT BUG #2 The color wheel resets itself when you bring the luma slider to zero (0.000). The Lift's color wheel also resets itself when you reset the slider associated with it. The hue and saturation adjustments the user made are lost. EXPECTED RESULT BUG #2 The color wheel (hue and saturation) should not be affected by its associated luma slider. The luma adjustment should be decoupled from the hue and saturation adjustment so that we don't lose hue and saturation adjustments while changing luma. SOFTWARE/OS VERSIONS Linux / DE: Pop!_OS 22.04 / Gnome 42.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.19 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 469467] New: Move settings and preferences from ".local/share/kdenlive" to ".config/kdenlive"
https://bugs.kde.org/show_bug.cgi?id=469467 Bug ID: 469467 Summary: Move settings and preferences from ".local/share/kdenlive" to ".config/kdenlive" Classification: Applications Product: kdenlive Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Installation Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- SUMMARY Hi! I'd like to suggest moving settings and preferences from "~/.local/share/kdenlive" to "~/.config/kdenlive". Preferences such as shortcuts, export presets, effects presets, LUTs, titles, library, lumas[, and profiles?] — essentially, things that the user can customize and would like to take with them from system to system. >From what I've read, "~/.config" is the preferred place for preferences in the Linux world, analogous to "~/Library/Preferences" on macOS, and I've checked myself that most apps I have installed do indeed store their preferences in "~/.config", so it makes it much easier to backup preferences if they are all in one place. Does that make sense? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 467124] New: Shape Alpha (mask) effect's Image / Video Resource does not update when file changes on disk
https://bugs.kde.org/show_bug.cgi?id=467124 Bug ID: 467124 Summary: Shape Alpha (mask) effect's Image / Video Resource does not update when file changes on disk Classification: Applications Product: kdenlive Version: 22.12.2 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Effects & Transitions Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- SUMMARY The Shape Alpha (mask) effect's Image / Video Resource does not update when the file, such as a Glaxnimate .JSON animation, changes on disk. Selecting / Opening the file again doesn't update it either, and neither does clearing the path first and then selecting / opening the file. It only updates after I Reset the Shape Alpha (mask) effect and select the file again. STEPS TO REPRODUCE 1. Add a Shape Alpha (mask) effect to a video; 2. Select a media file, such as a Glaxnimate animation, in the Image / Video Resource field; 3. Play the video back to see the effect; 4. Make big changes to the media, such as modifying the animation in Glaxnimate — changing motion, timing etc. as desired — and save the file (same name, same path); 5. Back in Kdenlive, play the video back again and see how the Shape Alpha (mask) image / video resource never updates to the new version, it maintains the older version prior to modifying the media. OBSERVED RESULT Image / Video Resource is not updated when the file changes on disk. EXPECTED RESULT Image / Video Resource is updated when the file changes on disk. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Pop!_OS 21.10 (available in About System) KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 466548] New: Folder icon disappears in the lowest zoom level in Tree View in the Project Bin
https://bugs.kde.org/show_bug.cgi?id=466548 Bug ID: 466548 Summary: Folder icon disappears in the lowest zoom level in Tree View in the Project Bin Classification: Applications Product: kdenlive Version: git-master Platform: Appimage OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 156797 --> https://bugs.kde.org/attachment.cgi?id=156797=edit Video showing the folder icon disappearing in the lowest Tree View zoom level SUMMARY The folder icon disappears in the lowest zoom level in Tree View in the Project Bin. The same does not happen in Icon View. STEPS TO REPRODUCE 1. Change view type to Tree View; 2. Add a folder; 3. Zoom all the way out, to the lowest level; 4. See how the folder icon disappears. OBSERVED RESULT Folder icon disappears in the lowest zoom level. EXPECTED RESULT Folder icon should not disappear in the lowest zoom level. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gnome 40 & 42 (available in About System) KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION Happening in both 22.12.1 and kdenlive-master-506-linux-gcc-x86_64 build. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465205] New: Separate clip proxy enabling from proxy generating
https://bugs.kde.org/show_bug.cgi?id=465205 Bug ID: 465205 Summary: Separate clip proxy enabling from proxy generating Classification: Applications Product: kdenlive Version: 22.12.1 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 155904 --> https://bugs.kde.org/attachment.cgi?id=155904=edit Proxy options broken down and put into a proxy menu SUMMARY Right now, we only have one option when it comes to proxies in the clip right click menu in the project bin: "Proxy Clip". That option generates proxies if none exists but also serves as an enable/disable toggle. This adds confusion, especially when you are using external proxies, and even more if Kdenlive eventually gets more flexible external proxy handling in the future. I propose we separate these functions and put them into a "Proxy" sub-menu containing: Enable Proxy Create Proxy... Attach Proxy... What they do: Enable — A toggle that Enables/Disables any proxies attached to the clip, either existing external proxies or proxies created by Kdenlive itself (by the "Create Proxy..." option under it in the same sub-menu). This "Enable" option should be grayed out when no proxies are attached to clip. Create Proxy... — Generates a new proxy for the clip with proxy settings defined in the Project Settings. Basically what happens currently in Kdenlive when we toggle "Proxy Clip". Attach Proxy... — Attach/Link an existing proxy. Clicking it opens up a file browser that lets you select a video file to be used as proxy for this particular clip. (This would be a sub feature request here, as Kdenlive doesn't currently offer this option). (Question here: does mixing up different codecs have any downsides? If it does, then this file browser could restrict viewing/selecting only files that match the proxy settings defined in the Projects Settings. Otherwise, just let the user mix and match if they want, to allow flexibility and not put any unnecessary restrictions on any production pipeline). Conclusion: Breaking the enabling/generating of proxies into different options makes it much more clear when Kdenlive is enabling an existing proxy attached to the clip versus when Kdenlive is creating a new proxy. This is especially important with external proxies because you want to be confident that when you enable a proxy for a clip, Kdenlive is using the existing external proxy attached to the clip — that might have a LUT or other color adjustments applied or even timecode burnt-in — and not generating a new one. SOFTWARE/OS VERSIONS Linux: Pop!_OS 21.10 & Fedora 37 DE: GNOME 40 & 43 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION Concept image attached. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465138] Make external proxies more flexible
https://bugs.kde.org/show_bug.cgi?id=465138 --- Comment #3 from Hyuri --- (In reply to Hyuri from comment #2) > Also, if we are going to use external proxies that keep the original file > name, it would only make sense and be really useful to also have the proxies > Kdenlive generates also keep the original file name with additional suffix, > instead of the current random string of letters and numbers. > > Example: > - Original file: "CLIP_0001.mp4" > - Proxy generated by Kdenlive: "CLIP_0001_Proxy.mov" This format even provides compatibility with proxies generated for Premiere Pro. Premiere uses a "_Proxy" suffix for proxies, which would mean that proxies generated for Kdenlive could also be attached to Kdenlive projects. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465138] Make external proxies more flexible
https://bugs.kde.org/show_bug.cgi?id=465138 --- Comment #2 from Hyuri --- Also, if we are going to use external proxies that keep the original file name, it would only make sense and be really useful to also have the proxies Kdenlive generates also keep the original file name with additional suffix, instead of the current random string of letters and numbers. Example: - Original file: "CLIP_0001.mp4" - Proxy generated by Kdenlive: "CLIP_0001_Proxy.mov" -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465138] Make external proxies more flexible
https://bugs.kde.org/show_bug.cgi?id=465138 --- Comment #1 from Hyuri --- Reasons why it's useful to allow proxies generated outside of Kdenlive and be able to manually choose the proxies folder location: 1. Dedicated [open source] transcoding apps, such as Shutter Encoder and Hand Brake, offer a much simpler and specialized workflow to create proxies in a variety of edit-friendly formats; 2. These apps allow us to burn-in titles and timecode onto the proxies, make color and other image adjustments, apply LUTs, change other settings, affording us much more control over the proxies we generate; 3. Shutter Encoder, for example, has a "watch folder" feature, that lets you configure a folder to watch for new footage so that you can just drop a folder with new footage in there and Shutter Encoder automatically starts transcoding. We don't have to open Kdenlive, set up a new project, save it somewhere, import all the footage, and enable the proxy generation. Plus, proxy generation in Kdenlive has failed on me before with an .mkv source; 3. Sometimes we get proxies already generated from a production, so it doesn't make sense to re-generate them inside Kdenlive, we should be able to just link/attach the existing proxies (Premiere Pro behaves like this, as an example); 4. Project files, media files, and temporary files (proxies & cache) are usually placed in different drives, to optimize performance and maintenance. So I rarely want the proxies inside the project folder — except in small or personal projects edited in my own notebook; 5. When external apps like Shutter Encoder generates proxies, it keeps the original file name and gives you options to add a suffix (like "_Proxy") to all the files. This is really helpful to know which files are proxies and which files are not. The proxies Kdenlive generates are named a random string of characters and numbers, so it makes it very hard to manage and send them to other editors to re-link if needed (this last scenario will probably not happen now because Kdenlive isn't commonly used in the industry yet, but it might start happening as it matures and more people and production companies adopt it like happened with Blender). So, for those reasons, it's important to offer some flexibility when it comes to attaching and using external proxies. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465138] New: Make external proxies more flexible
https://bugs.kde.org/show_bug.cgi?id=465138 Bug ID: 465138 Summary: Make external proxies more flexible Classification: Applications Product: kdenlive Version: 22.12.1 Platform: Appimage OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 155856 --> https://bugs.kde.org/attachment.cgi?id=155856=edit Concept: New "Custom" option pointed by red arrow; separate suffix and extension pointed by yellow arrows SUMMARY 1. Add a "Custom" option to the External Proxy Clips, in Project Settings/Proxy, where we can manually change the parameters (paths, prefixes, suffixes, extensions); 2. Break the clip/proxy suffix field into two separate fields: "suffix" and "extension". The first excludes the file extension, the second only looks at the file extension. If the "extension" field is left empty, Kdenlive accepts all files of all supported extensions; 3. Option to set the proxy folder to any arbitrary folder, that can be an absolute path (this allows us to have the proxies folder located in external drives, for example, or media-only servers separate from the project folder root; Additional: 4. Change the clip/proxy paths from "relative to clip/proxy" to "relative to the project root folder". So, if the project root folder is "My Project" and it contains the folder "FOOTAGE" that itself contains folders "PROXIES" and "ORIGINALS", we could set the clip/proxy paths to "FOOTAGE/ORIGINALS" and "FOOTAGE/PROXIES", respectively. For this to work, I imagine it would be required for the Kdenlive project to note which folder is the project root; STEPS TO REPRODUCE 1. Open "Project Settings" 2. Click on the "Proxy" tab 3. Enable "External proxy clips" 4. Click on the drop-down menu containing the pre-existing external proxy profiles 5. Notice how we have no "Custom" option, and how we are not able to customize any of the existing profiles EXPECTED RESULT In the "External proxy clips" drop-down menu, we should have a "Custom" option that allows to customize the settings to our specific project needs. SOFTWARE/OS VERSIONS Linux: Pop!_OS 21.10 (available in About System) DE: GNOME 40 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463790] New: Changing a Transform Effect's "Composite" (blending mode) has no effect
https://bugs.kde.org/show_bug.cgi?id=463790 Bug ID: 463790 Summary: Changing a Transform Effect's "Composite" (blending mode) has no effect Classification: Applications Product: kdenlive Version: 22.12.0 Platform: Appimage OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: Effects & Transitions Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 154996 --> https://bugs.kde.org/attachment.cgi?id=154996=edit Changing Transform's blending modes on the top clip has no effect SUMMARY I often need to use the "Screen" or "Multiply" blending modes but changing a Transform Effect's "Composite" (blending mode) has no effect. So I always have to add a composite clip between the clips, choose the "Cairo Affine Blend" and then select "Screen" or other option within the Cairo Affine Blend. This has been happening since I started using Kdenlive. The blending modes in the Transform effect never worked, but it gets annoying having to add the extra "Composite" clip just to change the blending mode. STEPS TO REPRODUCE 1. Add two different clips to the timeline, each on a different track, one above the other 2. Add a "Transform" effect to the clip on top 3. Select the clip on top and change the "Composite" (blending mode) property of the "Transform" effect you just added, from "Alpha blend" (the default) to any other option — Screen, Multiply, Overlay, as examples 4. See how the blending mode of the video on top does not change at all OBSERVED RESULT Changing a Transform effect's "Composite" (blending mode) has no effect. EXPECTED RESULT Changing a Transform effect's "Composite" (blending mode) should change the blending mode of that clip / how that clip blends with everything that's under it. Basically the "Composite" (blending mode) in the Transform effect should work like the blending modes available in the "Cairo Affine Blend" option in the additional "Composite" clips. We shouldn't have to go through the extra hurdles of using and managing the additional "Composite" clip. SOFTWARE/OS VERSIONS Linux: Pop!_OS 21.10 (Gnome 40.4.0 under X11) KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463629] New: The widgets of some effects disappear after collapsing & expanding the effect
https://bugs.kde.org/show_bug.cgi?id=463629 Bug ID: 463629 Summary: The widgets of some effects disappear after collapsing & expanding the effect Classification: Applications Product: kdenlive Version: 22.12.0 Platform: Appimage OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Effects & Transitions Assignee: j...@kdenlive.org Reporter: hyuri.pimen...@gmail.com Target Milestone: --- Created attachment 154910 --> https://bugs.kde.org/attachment.cgi?id=154910=edit The Lift/gamma/gain effect after collapsing and expanding it back again SUMMARY The widgets of some effects (like the wheels of Lift/Gamma/Gain, and the slider of White Balance and White Balance (LMS Space), disappear after collapsing the effect and expanding it back again. It does *not* happen to all effects, only a handful, it seems. But I haven't tested all the effects, so I don't know which and how many are affected. The widgets are back if I do this: 1. Keep the effect expanded; 2. Add another effect to the clip or move any effect up/down in the stack. But it's only back until I collapse the effect again. STEPS TO REPRODUCE 1. Add effect (Lift/gamma/gain, for example) to a clip; 2. Collapse the effect, then expand it back again; 3. See how the Lift/Gamma/Gain color wheels are gone; (additional) 4. Add another (any) effect to the clip; 5. See how the color wheels are back in the Lift/gamma/gain effect; 6. Collapse the Lift/gamma/gain effect again; 7. See how the color wheels are gone again. OBSERVED RESULT After collapsing the effect and expanding it back again, the widgets, such as color wheels and sliders disappear from the effect. EXPECTED RESULT Collapsing & expanding an effect should never make its widgets, such as color wheels and sliders, disappear from the effect. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Pop!_OS 21.10 (GNOME 40.4.0 under X11) (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.100.0 (found in "About Kdenlive") Qt Version: 5.15.7 (found in "About Kdenlive") ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
