View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001019KdenliveUser Interfacepublic2009-07-07 12:472010-09-14 23:22
Assigned ToGranjow 
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version0.7.5 
Target VersionFixed in Version 
Summary0001019: Text clip usability is very primitive
DescriptionThe generated text clips' dialogs are very primitive, and require manual work via "templates". That solution is not exactly visual. Check out Vegas' "text generated media" dialog to see how it's done.
TagsNo tags attached.
Build/Install Method3rd party package
Attached Files

- Relationships
parent of 0001211closedGranjow Titler: Better z-index handling 

-  Notes
Granjow (developer)
2009-07-07 13:17

Could you please be more precise? Perhaps attach a screenshot or a link? I don't know how many devs own Vegas or even have the possibility to install it (I know, there is a demo version, but you need to register and you need to have Windows).

Eugenia (reporter)
2009-07-07 13:26

You just need Windows, you don't have to register to download/install the trial version. I just uploaded here the Vegas screenshots of the Text Dialog to see how they do it.
Granjow (developer)
2009-07-07 13:57

And what is the problem now exactly?

Positioning text in the Titler is possible too, also centering.

Or did I miss something?

Eugenia (reporter)
2009-07-07 22:09

Yes, you missed 4 screenshots full of features that don't all exist on your app, AND, the ones that exist, they are NOT as easy to use as the dialogs shown.
xzhayon (developer)
2009-07-08 01:08

this was (shortly) discussed on the list: markus "kamikazow" suggested to integrate the koffice text kpart, which is a solution i really like. perhaps, we could use it if koffice is found installed (not really sure this can be done on runtime, but for sure it can be done on buildtime), otherwise we can switch back to the plain text editor we have (improved a bit)

oh, i will add: what about using the karbon or krita kpart instead of the kword one? it would be awesome

we have to investigate on this
Eugenia (reporter)
2009-07-08 01:13

I personally do not use KOffice, I use Gnome on Ubuntu. KDEnLive is the _only_ KDE app I have installed. I am simply not interested in the rest of KDE and its baggage. If you are going to implement this, do it right. Take the time, and either fork the specific code from KOffice and use it specifically on KDEnLive, or don't bother. You see, down the line you _will_ need to modify specific stuff in a way that using another app's kpart won't work for your needs. Think more ahead of the road rather than a quick fix.

Also, don't forget the keyframing support for it, also shown in the shots. ;)
jmpoure (developer)
2009-07-08 01:52
edited on: 2009-07-08 01:54

Dear Eugenia,

I had to remove your screenshots. The European law and most law systems do not allow this kind of process.
For example, you will not find screenshots of Photoshop on a Gimp forum!

On the converse, you can draw what you want, but without reference to a particular product.

Sorry to interact lately in this post, but we cannot accept screenshots from a Company X product with logo and the idea that Kdenlive could simply "copy" it.

I will not discuss this issue, sorry.

Eugenia (reporter)
2009-07-08 01:55

Nobody said anything about copying it as is, you can always innovate on it. But as I told you earlier in the other bug report, without having used at least FPC, Vegas and Premiere yourselves for a number of years, as users, you can't expect to get KDEnlive right out of the bat. You need the experience of what's out there already, and improve on it. It's just impossible to create something as complex as a video editor without having video editing experience yourselves using popular tools.
Eugenia (reporter)
2009-07-08 01:56
edited on: 2009-07-08 01:57

So sure, don't let the screenshots up, I agree with that law actually. But your team needs to setup a PC somewhere, install Windows and Mac, download the trial versions of these apps and use them. Don't tell anyone about it if you can't. But you certainly need the knowledge of what's out there already. You currently going blind.

xzhayon (developer)
2009-07-08 02:02

i don't see it as a quick fix: koffice has some great kparts which i would love to use with kdenlive; being able to draw scalable graphics with karbon (which i personally prefer over inkscape) could be a nice feature. this doesn't mean we're going to put the koffice code in kdenlive: we're not developing a text editing suite. if we're gonna make it on our own, we'll just make the current titler evolve

anyway, the whole kpart topic is just an idea, i don't even know how to use them at the moment, and i'll have no time until the end of the year (stability comes first), so if no other developer is willing to look into this, we'll have to wait
also, i'm not speaking for the whole team: someone else could think the opposite

about keyframing: i think i've seen the code for simple start -> end animations, so it shouldn't be so far
jmpoure (developer)
2009-07-08 02:13

I agree we should reuse code whenever possible.

This is an organization issue.

It is probably interesting for people of other projects to see their work reused. The best is to find very active projects with nice people willing to collaborate.

The best would be to contact koffice team and ask them their advice.
Eugenia (reporter)
2009-07-08 02:19

Reuse code, but in this case it's not how it should work. To make a video editor powerful and stable, you need control over it. Adding dependencies to libs that many of us are not interested into, is not going to make your acceptability easier.

You can always "reuse" that code, if it's the code you want, by forking it and adapting it to your needs exactly. This way, you won't have to wait for KOffice to implement a new feature, should you need it. You just do it yourselves.

I have the same opinion about ffmpeg btw. Depending on the system-installed ffmpeg to encode/decode streams is a mistake. You will never be stable enough if you just work with random implementations of ffmpeg. You need to fork it, because you need a pipeline that's known to you. Otherwise, bug reporting will be hell for you. Either that, or you need to put YOUR people working on the official ffmpeg version (which I doubt they will be given any decision power, since the guy behind ffmpeg is pretty restrictive about what he wants in his app).

I wouldn't say any of that if you were making a KDE app for KDE users only, but KDEnLive is the only somewhat usable video editor right now on Linux, so you will have Gnome users too using it. Don't make their pain more than it has to be. And for stability reasons, control as much of the code as you can. Being "open" is all good and daddy for simpler apps, but for something like a video editor, or a web browser, you need control over it.
jmpoure (developer)
2009-07-08 02:34
edited on: 2009-07-08 02:34

This is an organization issue.

The advantage of FFmpeg is that they fix bugs within hours or days. Their community is very active. We cannot recompile everything. It would mean reading patches and additions. What a work! The power of GNU/Linux is to resuse libs. We cannot change the rules.

All this is a question of team, ability to develop fast and fix bugs.

Take the example of MLT: it is a different project. But: Dan is fixing bugs ASAP, answers questions and develops new features in his free time. Before, Kdenlive relied on another video engine but it was crappy for "human" reasons.

Find the right persons and developers. If Koffice developpers are nice and collaborative, then ask them to participate. Otherwize, stay away.

Eugenia (reporter)
2009-07-08 02:58

Yeah, I guess this is where we differ. I believe that in order to create a serious video editor that doesn't crash left and right as KDEnLive does right now, you need to OWN the pipeline. You need to put resources onto shaping a version of ffmpeg that works for your needs exactly as it must, and occasionally updating it with newer support from the official tree.

You on the other side, you believe that you somehow have to play with the unwritten rules of the Linux community and "reuse code".

As I said above, I don't disagree that reusing code is a good thing. But not all problems have the same solution. This specific problem, that linking to arbitrary and random implementations of a library that is SO important to your app, is NOT the right engineering decision to make.

I understand that you don't have 100 engineers working for you. But maybe you should recruit some. Give them candy to sway them in. Because if you can't get the decoding right, and your app still crashes out of the blue during playback, you don't have a video editor. You have a toy.

It's your decision, you're the boss.
jmpoure (developer)
2009-07-08 08:38

I am not the boss. Shaping FFmpeg would require a huge energy, as it is one of the most active projects in free software. Development goes too fast and by the time we would addess a fix, it would already be in FFmeg mailing list. Better Mpeg2-ts/H264 will soon be addressed. Then VDPAU will be used. It is a lot of work and it is mainly done in FFmpeg, then MLT, then Kdenlive. We cannot change the process.
Eugenia (reporter)
2009-07-08 08:46

Maybe then you can change how you use ffmpeg. For example, create a separate process to talk to ffmpeg, and make sure that when ffmpeg or that process dies, it doesn't take kdenlive down with it.
Granjow (developer)
2009-07-21 10:26

Back on topic, okay?

Where do titles require too much manual work? Or what exactly is bad?
j-b-m (administrator)
2009-07-21 10:49

I have also been thinking about the titler these days. Marco is just working on an MLT producer for titles based on QGraphicsView. That means we could probably introduce animation in our titler. However, I think it would be a mistake to turn the titler into a full animation designer.

My opinion is that for advanced animated titles, users should use a program like inkscape. Hopefully, in the not too far future, inkscape should be able to produce animations (on their roadmap for next release), that could be loaded directly in Kdenlive.

So now, what would be really useful for a basic titler? Scroll & zoom of the title itself will be added soon. What other feature do you think is important?
Granjow (developer)
2009-08-08 16:35

0000643 perhaps? If I understand correctly this could be done now?
jmpoure (developer)
2009-10-06 08:01

Eugenia, we never look at commercial products.
raps (reporter)
2009-10-10 01:09

I just realised that the version 0.7.6 has all the basics I wish.
It is maybe only lacking of two buttons, to put an element on the background and the foreground.

After that, I don't think that adding features is the good way. Animations can be done easier in the timeline.

To create complex title patterns we have to use an external editor.
There are two possibilities: a vectorial one or a bitmap one.
Better is a vectorial one, because we are susceptible to export our videos in merely resolutions (DVD / website / ...).

So a good feature would be the possibility to import vectorial documents.
Eventually add an item in the menu to add a clip allowing to open a (vectorial) editor of our choice (or from a list).
Granjow (developer)
2009-10-10 08:30

Move to foreground/background is already possible with the z-index field. Not obvious enough? (We could add a tool tip or so)
xzhayon (developer)
2009-10-10 12:50

mh, i find the idea of the z-buttons a good idea: why not replacing the input field with the buttons (set lower, move down, move up, set upper)? it's more intuitive
raps (reporter)
2009-10-11 13:41

I would use the z-index to increase / decrease the layer of 1 unit.
And the buttons to put it in foreground (max z) and background (min z) with only one clic.
The z-index info is not so bad, although such info is not displayed in common text processors (MS Word or writer). They have only foreground / background buttons and I find it enough - but I'm only a lambda user.
ddennedy (developer)
2009-10-12 02:17

This is a feature enhancement request, not a bug.
Granjow (developer)
2009-10-13 09:19

I opened a new report about the z-index. Ok?
Granjow (developer)
2009-12-01 14:40

fyi, have been working on z-index handling 0001211 (feel free to test :))
LeHomard (developer)
2010-06-18 12:30

I there actually a specific feature request here ?

I feel this report should be closed, and maybe some more specific one could be opened. This just looks like "make titler better", which doesn't really help.
ddennedy (developer)
2010-06-18 19:24

Yes, agreed. please close it due to lack of precision. We do not need bug reports just to remind us that our shit stinks.
Eugenia (reporter)
2010-06-18 20:18

I basically need the following, in a single window (with tabs ?):
The text, font, italics, bold, underline, size, alignment. Placement in the framing, so we make sure we are not outside of the safe zone. Text color, background color (if not transparent), tracking and scaling of text, Outline (feather, width) and Shadow of text (feather, X/Y offset). And all this, adjustable with keyframing.
LeHomard (developer)
2010-06-19 10:58

Right, I'll probably close this bug report and open one for a list of features that aren't yet implemented (I'll have to check first, I don't use the titler very often...), and a seperate one for keyframability (if the word actually exists)
Granjow (developer)
2010-07-07 16:34

Yes -- please let's close this bug and @Eugenia please open new feature requests for each feature.
Granjow (developer)
2010-07-24 21:13

Closing now.

- Issue History
Date Modified Username Field Change
2009-07-07 12:47 Eugenia New Issue
2009-07-07 12:47 Eugenia Build/Install Method => 3rd party package
2009-07-07 13:17 Granjow Note Added: 0003612
2009-07-07 13:25 Eugenia File Added: text-dialog.jpg
2009-07-07 13:26 Eugenia Note Added: 0003613
2009-07-07 13:57 Granjow Note Added: 0003618
2009-07-07 22:09 Eugenia Note Added: 0003627
2009-07-08 01:08 xzhayon Note Added: 0003632
2009-07-08 01:08 xzhayon Status new => feedback
2009-07-08 01:13 Eugenia Note Added: 0003634
2009-07-08 01:49 jmpoure File Deleted: text-dialog.jpg
2009-07-08 01:52 jmpoure Note Added: 0003635
2009-07-08 01:53 jmpoure Note Edited: 0003635 View Revisions
2009-07-08 01:54 jmpoure Note Edited: 0003635 View Revisions
2009-07-08 01:55 Eugenia Note Added: 0003636
2009-07-08 01:56 Eugenia Note Added: 0003637
2009-07-08 01:57 Eugenia Note Edited: 0003637 View Revisions
2009-07-08 02:02 xzhayon Note Added: 0003638
2009-07-08 02:13 jmpoure Note Added: 0003639
2009-07-08 02:19 Eugenia Note Added: 0003640
2009-07-08 02:34 jmpoure Note Added: 0003641
2009-07-08 02:34 jmpoure Note Edited: 0003641 View Revisions
2009-07-08 02:58 Eugenia Note Added: 0003644
2009-07-08 08:38 jmpoure Note Added: 0003645
2009-07-08 08:46 Eugenia Note Added: 0003646
2009-07-21 10:26 Granjow Note Added: 0003699
2009-07-21 10:49 j-b-m Note Added: 0003700
2009-08-08 16:35 Granjow Note Added: 0003778
2009-10-06 08:01 jmpoure Note Added: 0004078
2009-10-10 01:09 raps Note Added: 0004097
2009-10-10 08:30 Granjow Note Added: 0004101
2009-10-10 12:50 xzhayon Note Added: 0004103
2009-10-10 12:51 xzhayon Target Version => future version
2009-10-11 13:41 raps Note Added: 0004109
2009-10-12 02:17 ddennedy Note Added: 0004119
2009-10-12 02:17 ddennedy Severity major => feature
2009-10-13 09:18 Granjow Relationship added parent of 0001211
2009-10-13 09:19 Granjow Note Added: 0004153
2009-12-01 14:40 Granjow Note Added: 0004396
2010-06-18 12:30 LeHomard Note Added: 0005291
2010-06-18 19:24 ddennedy Note Added: 0005293
2010-06-18 20:18 Eugenia Note Added: 0005294
2010-06-18 20:18 Eugenia Status feedback => new
2010-06-19 10:58 LeHomard Note Added: 0005295
2010-07-07 16:34 Granjow Note Added: 0005346
2010-07-07 16:34 Granjow Assigned To => Granjow
2010-07-07 16:34 Granjow Status new => feedback
2010-07-24 21:13 Granjow Note Added: 0005402
2010-07-24 21:13 Granjow Status feedback => resolved
2010-07-24 21:13 Granjow Resolution open => no change required
2010-09-14 23:22 ttill Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker