Here’s one of the reasons why I’m not exactly in a hurry to learn C. When you ask me to read through C code, this is what happens:
No jokes. Even after simplifying and compacting the code, it’s still such a pain for me to navigate through C that I actually felt the need to output the code onto thin slices of dead plants and stick them to a wall. This piece of code that I wanted to understand for a long time suddenly became clear after a few hours of analysis with a blue “thinkpad” and ballpoint pen:
What was this code for, you ask? Making the toolbar hide nicely in fullscreen mode. Thus 400 lines of compacted C code to analyze from Gedit (nearly 700 if you don’t compact and just search code related to the fullscreen toolbar) became 50 lines of Python code in Pitivi.
Okay, the fullscreen toolbar is not the only thing I’ve been up to lately. While cleaning up code or looking at old bug reports, I fixed some little details, such as filtering out unknown/irrelevant file types from the file chooser dialog when importing clips:
A combobox (defaults to “Supported file formats”) allows you to change the strictness of the filtering. The same is true of the “missing clips” file chooser. By default, we now show only files with the same extension as the one you’re looking for:
I also made it error out if you don’t provide the requested replacement clips, with a new error dialog to explain accordingly:
This is better than being stuck inside an infinite asynchronous loop, trust me. There are also some new error dialogs (everyone loves those) to catch some silly corner cases, such as trying to save in a read-only directory (because GTK doesn’t do it for us):
…And even crazier scenarios, including someone explicitely bypassing the file extension filters to try to load a movie file as if it was a project file:
It’s the little details that count. You can’t make something too bullet-proof.
I also progressively reworked the pitivi git environment/build script to make it smarter and friendlier. Not only does it allow you to continue where you interrupted the checkouts/builds, but it has a built-in debugging duck:
“What, that’s it? Don’t you have more exciting stuff to show?”
Well, it turns out that Pitivi itself is pretty much ready*, it’s in very good shape. What’s preventing a release is the need for GNonLin (and after that, GES) to be fixed, and there’s nothing I can personally do about that (except testing and mentoring interested contributors). So if reading and writing C does not require you to stick pieces of dead plants onto walls, come talk to us!
*: except if we embark on the project of refactoring and porting the whole timeline UI to Clutter… Oh, and we need someone to fix undo & redo after that… And expand our test suite… And improve our title editor UI… And update the user manual/documentation…
Comments
13 responses to “Autohiding fullscreen toolbar, error dialogs and file format filtering3 min read”
Great post, had a fun time reading it!
Keep up the great work, I am looking forward to a release that rocks!
Hi,
First of all, THANKS a lot indeed.
You really rock (I really admire your work) 🙂
It would be magnificent to have the new Title editor UI included in the next upcoming major release.
Most of all because this is a very “basic” feature for a video editor…
Unfortunately, I am not a developer and I can’t help in this area 🙁
Anyway, thanks again indeed for making Pitivi better and better
Very nice, thank you for your hard work 🙂
But i was quite dsiappointed to read that PiTiVi doesn’t support partial projects, which means that for a projet with lots of file and work, if only one is missing we’re not able to go back to work ?!!!! Tragic !
@antistress: It never did 🙂 it will, when someone implements https://bugzilla.gnome.org/show_bug.cgi?id=609136
Fun post, thanks! It’s worth spending some time to find a really good code *reading* environment. We are so writing-focussed in the programming world, which is a shame. You don’t write a great piece of literature without having to read a lot of good stuff first. Personally, I find a mixture of Vim (my preferred editor), ctags, vim’s support for navigating around using ctags, and a version control system (even for code with no history… being able to start carving stuff up or adding comments and quickly find them thanks to the VCS is a real godsend) the best way to learn my way around C programs. There’s a great book called “Code Reading: The Open Source Perspective” with lots of stuff in it about the importance of reading code and tools and techniques: http://www.spinellis.gr/codereading/
learning C is definitely worth it. If you know C can faster learn C++, Java, PHP and #.net, they all start with a common C notation for begin- end, loops, function calls and so on.
And now you know how I feel when looking at Python code. :p
Only that I need to draw graphs of which function calls which with what type of object. Duck typing…
i had a dream : PiTiVi was ready in the same time that GStreamer 1.2 (which should bring hardware acceleration in december)…
http://gstreamer.freedesktop.org/wiki/ReleasePlanning/RoadMap
If someone opens a movie instead of a project, what it _should_ do is make a new project with that movie added to source list already. That’s clearly what they want to do.
@Karl: not necessarily. What if the user already has an existing project running? It could get messier too: eventually it will be possible to import projects to be used as clips in a timeline…
@Nekohayo I will try to work on the documentation again. I just have to finish my college applications. You could probably get a lot of contributions from google code in.
I think the problem why you need to print out code could well be not the C language but rather that there is no decent IDE with good code navigation features available. People who are comfortable with Eclipse JDT or Netbeans (for example) know what I mean. And no, neither emacs, vim, gedit with a ton of plugins nor Anjuata qualify as a decent IDE.
And btw: your blog design’s header takes more than half of my screen, so that I can barely read the first headline. Usability for the win!
Mike said:
> there is no decent IDE with good code navigation features available.
and
> And no, neither emacs, vim, gedit with a ton of plugins nor Anjuata qualify as a decent IDE.
I’ve never found an IDE (D for Development) that was easier to use for code navigation/reading (rather than *writing*) than Vim + Ctags. All the great features IDEs bring to table take *writing* code up a level; but they’ve done very little for reading IMHO.