In T5174#77238, @alcinos wrote:

For single track transitions, I already have ideas about how to implement that.

Example of clip snapping in Blender.

An example of how nested clips work in Blender.

This is an important one as well JB

This is important for the rotoscoping workflow...

Here is a report with some good suggestion to improve the details that make a big difference.

Here is a crash caused from attaching/detaching project/clip monitors.

In T2908#57521, @jessed wrote:

I suggest this little usability improvements if you don't mind:

Interesting thread on Flowblade's github...

Simon from AppImage has agreed to help packaging Kdenlive. We need someone to follow up in this.

Congrats on the succesful release!

The people over at Flowblade are thinking of developing an EDL feature to integrate better with Natron. Maybe we could join forces and propose an MLT module?

Probably the CMX 3600 standard.

One more thought... there isn't technically afaik alpha in video, right? So if you apply this fade to transparent on one track (with nothing under it) then it would fade to black?

Isn't that what dissolve kind of does? In which scenario would this be useful?

A nasty timeline corruption with video example.

Congrats JB! Most of the bugs are fixed.

Closing this for now...

I still need to do some design so just focus on content.

I have taken the content form the old site:
https://kdenlive.org/downloading-and-installing-kdenlive

Gonna close this since most content is there...

One more timeline corruption one:

In T3172#44750, @thediveo wrote:

Farid, this is one I would also like to see resolved! I often could work with reduced track hight just perfectly, but not without the track header controls. Track titles could be abbreviated, but I would really like to see a resizeable track header area (by dragging the divider between the header and the tracks).

This is probably an easy one nevertheless very useful.

Here go some suggestions for us to investigate:

What I usually do for quick tasks is use Inkscape; I define the page size to 1920x1080 (my render size), create the title template, export to png and then import it in Kdenlive.

@jessed The audience is very generic really everything from new comers trying to discover kdenlive to old users who would go to the site to keep up with news and stuff. I am going to do a showcase section soon to show some of the latest works done by the community as well as try to give more view to a tutorials section.

I changed the homepage based on your suggestions.

Frankly I worry about the titler and its features/bugs consuming too much time... I would rather not have it and worry less to handle more code/bugs. I would rather have a proper EDL export and use Blender or Natron for this kinds of tasks but I understand that it might be overkill for many people and see its worth. :)

@massimostella wrote in the other request:

I meant to merge this one with T1950 not the other way around. I didn't manage to undo it. Sorry.

As in SVG support?

Flatpak has just been officially released.

I have done some tests exporting an EDL list from Shotcut into Blender, note that the EDL-import-plugin might not work perfectly, here are some things I have noticed:

Was this discussed in Randa?

Just found a crash:

Do you know which standard does it use to do the EDL export?

It is 5.22 and kdenlive 16.04.1.

I might offer an encouragement on the features page: I would focus on the core strengths and features of Kdenlive itself before putting any affiliated technologies. If your target audience is video editors, film production studios, professionals, etc., then they're going to be interested in Kdenlive, first, and what IT can do. They need to see what makes it great. Flexible layout, advanced trim tools, timecode, multiple edits in a single project (sort of), GPU processing (once it's perfected -- HUGE feature), keyframe effects... you get the idea. I think that would have a bigger impact on viewers.

In T2937#39570, @massimostella wrote:

Hi.
What about of animated gifs which show in 2 seconds the features?

In T2327#39449, @thediveo wrote:

It's a start, but most people won't read that amount of text and start writing bug reports anyway. So, in my humble opinion, we need a short and concise intro that explains how to write a good Kdenlive(!) bug report.

All the other details are for those who want to make most of bugzilla. Most users won't bother reading all the stuff.

So it should simply say: How to write a good bug report, followed by only three or four important rules. For instance, along these lines:

• steps to reproduce: if the bug can be reproduced using only a few simple steps, this will often suffice. Please make sure that your list of steps is complete.
• minimal example: help the devs to reproduce your problem by attaching a minimal Kdenlive project. A minimal example consists only of the clips in project bin and timeline absolutely necessary. However, please don't attach video or image clips to your report unless explicitly asked to do so.
• stack trace: if Kdenlive crashes, please add a stack trace to your report. A good stack trace...

In T2327#39450, @jessed wrote:

In T2327#39365, @afarid wrote:

Now that the main structure is somewhat done I am starting to focus on content and I think we should start to focus on "Features" and then on "About".

Features

This page is to showcase Kdenlive so it should have straight to the point content and great screenshots. Have a look at some content of similar websites for to get an idea of when it is "good" and when it is "bad".

https://www.blender.org/features/
http://ardour.org/features.html
http://natron.fr/features/
https://shotcut.org/features/
http://jliljebl.github.io/flowblade/features.html
https://cinelerra-cv.org/five/Features5.pdf
http://cinelerra.org/2015/index.php/features/editing
https://inkscape.org/en/about/features/

I am thinking of first having the logos and respective links of the technologies kdenlive uses and then move on to describe the features and screenshots.

https://dev.kdenlive.org/features/

Farid, the website is looking awesome! Great start, sir! Your logo up at the top left, too.... it just works. :) It'll be great to see it become the new brand logo for Kdenlive when the time comes.

I might offer an encouragement on the features page: I would focus on the core strengths and features of Kdenlive itself before putting any affiliated technologies. If your target audience is video editors, film production studios, professionals, etc., then they're going to be interested in Kdenlive, first, and what IT can do. They need to see what makes it great. Flexible layout, advanced trim tools, timecode, multiple edits in a single project (sort of), GPU processing (once it's perfected -- HUGE feature), keyframe effects... you get the idea. I think that would have a bigger impact on viewers.

In T2327#39453, @jessed wrote:

Also, I just noticed this on the homepage. Right front and center, bold and big in your face, is the "Bugs" image and link. I cannot, CANNOT discourage this more. The fact that users will see "Bugs" right there from the get go is going to veer away any professional seriously interested, and deter a very valuable part of the video market. Bugs present flaws, weakness, and instability. It's great that you have a link for Bug Reports under the "Get Involved" at the footer on the bottom. Awesome place for it. It's out of the way, but it lets users know that the option is there without having to navigate tediously to find it.

If Kdenlive is going to gain rapport, and subsequently greater support, and even increase the chance for greater funding, it has to have a bold, stable, reliable, functional and useful presence. "Bugs" will kill any chance of that presence in once glance -- I promise you that. The only people that won't be extremely intimidated by this are developers, testers, and techno-junkies. If this is the target audience you're trying to reach with Kdenlive, then go for it. But, please, if you're looking to appeal to any professionals, don't put "Bugs" front and center on the home page.

Alright, I'm stepping off my soap box. :) Again, it's just a strong encouragement, with motives to drive Kdenlive towards greater success. No harm intended.

In T2327#39449, @thediveo wrote:

It's a start, but most people won't read that amount of text and start writing bug reports anyway. So, in my humble opinion, we need a short and concise intro that explains how to write a good Kdenlive(!) bug report.

All the other details are for those who want to make most of bugzilla. Most users won't bother reading all the stuff.

So it should simply say: How to write a good bug report, followed by only three or four important rules. For instance, along these lines:

• steps to reproduce: if the bug can be reproduced using only a few simple steps, this will often suffice. Please make sure that your list of steps is complete.
• minimal example: help the devs to reproduce your problem by attaching a minimal Kdenlive project. A minimal example consists only of the clips in project bin and timeline absolutely necessary. However, please don't attach video or image clips to your report unless explicitly asked to do so.
• stack trace: if Kdenlive crashes, please add a stack trace to your report. A good stack trace...

In T2327#39417, @thediveo wrote:

In T2327#39414, @afarid wrote:

I can't really test this but i think the theme framework already has some phone and tablet fallback modes...

I've just tested the dev.kdenlive.org link and the current design works on touch devices fine. As long as there are no drop-down menus and hover functionality, touch should always be fine.

I recently did a fresh install of archlinux and kdenlive didn't have icons in the interface... so i had to install oxygen-icons. There should be at least a guideline od dependencies for packagers so we can guarantee a similar experience across all distros.

In T2327#39416, @afarid wrote:

In T2327#39412, @thediveo wrote:

For the contact/help topic: we should explain to new users not to flood the bug tracker with distro-specific installation and packaging problems. Lately, we see many useless bug reports with highly specific system and distro combinations. Probably no dev is able to figure out what's wrong with all the broken Kdenlive distro packages out there.

The project maintains its own Ubuntu ppa and I assume this to be the reference if in doubt. For known installation woes I would assume to direct people first to an installation FAQ and then to the Kdenlive forum.

Users should understand that the bug tracking system is for reporting bugs as concise as possible with minimalized regression projects if possible.

There is also this which Sam wrote based on Kritaś

https://userbase.kde.org/User_talk:Cameralibre

Maybe it helps...

In T2327#39412, @thediveo wrote:

For the contact/help topic: we should explain to new users not to flood the bug tracker with distro-specific installation and packaging problems. Lately, we see many useless bug reports with highly specific system and distro combinations. Probably no dev is able to figure out what's wrong with all the broken Kdenlive distro packages out there.

The project maintains its own Ubuntu ppa and I assume this to be the reference if in doubt. For known installation woes I would assume to direct people first to an installation FAQ and then to the Kdenlive forum.

Users should understand that the bug tracking system is for reporting bugs as concise as possible with minimalized regression projects if possible.

In T2327#39400, @massimostella wrote:

Do we have already a text for the "Featuure" page?
I guess that before to create the screen shots we have to know what are the features we want to list on the page.
What are the most important and which are less important for creating images based on the text.

In T2327#39370, @thediveo wrote:

Just a minor note, don't know if this is really an issue for potential Kdenlive.org visitors: many web sites have menu navigation that still doesn't work with touch. So, visiting these sites is a pain when using a tablet (Android, iOS, Windows). Even KDE forums don't work correctly when visited using a touch display device.

Now that the main structure is somewhat done I am starting to focus on content and I think we should start to focus on "Features" and then on "About".

In T2908#38733, @massimostella wrote:

Hi, Afarid. :)
Just launch Kdenlive via terminal and copy what the prompt says.
I think that these informations could be useful for Jean-Baptiste.

PS: of course before to launch the application for testing it, remember to enable the gpu effects (Movit) in the Kdenlive settings. :)

I have a GeForce GTX 660 Ti, let me know what to do to test it.

We could definitely consider borrowing some code from Qtractor for the mixer:

In T2327#34067, @mardelle wrote:

Good news, I got an answer. So it looks like Wordpress requires more admin time, but they are ok to create us a Wordpress instance for kdenlive. I will now ask them to go for it and will let you know when it's ready!

great jb,

In T2327#33279, @obogdan wrote:

Has a ticket been made thowards the sysadmins? can you pleas link it here?

Support for .kra files has been added:

As soon as we get a reply from the kde sysadmin we can start development.