Editing Screencast

In this older post I described how to record a screencast in Linux.

However, you will very likely need to do some post processing with the recording, like removing the unneeded parts at the beginnig or the end, cropping the image or adding an empty frame at the end so it is obvious when the animation restarts.

And for that we can use Gimp editor which is usually pre-installed in the major Linux distributions.

Gimp

Gimp is designed for editing static images but with some workarounds it can edit animations as well. Simply open your *.gif animation file created in the recording session in Gimp.

Every frame in the animation is loaded as a separate image layer. This looks a bit strange at first sight but I guess this was the only way how to add animation support into a static image editor.

The animation is played from the bottom layer to the top.

The Initial Step

The very first step you should do after opening the animation image is to unoptimize it. To store the animation efficiently the GIF files usually store only the changes between the frames. Usually only very small part of the image changes and it does not make sense to repeat the unchanges parts in every frame and wasting space.

However, this makes editing more difficult as each frame (layer) only contains the changes, you cannot see what will be actually displayed on the screen and editing is almost impossible.

Fortunately Gimp can expand the diff frames to full images, simply use the Filters ➞ Animation ➞ Unoptimize menu. It will create a new image with full frames, you can close the original image now.

Displaying Separate Frames

As already mentioned, each frame is loaded into a separate layer. If you want to see a frame you need to select only that frame otherwise the later frames (the layers above) will cover it.

Press Shift and click the eye icon in the layer window to display only that frame.

Cutting the Animation

If you need to remove some frames at the begining or the end then simply remove the not needed layers from the image.

Select the layer and press the trash bin icon in the left bottom corner in the layer .

Changing the Timing

As you have probably already noticed the layer names contain special tags at the end like (180ms)(replace). These tags specify the animation properties of the frame.

The first value in the parenthesis defines how long is this frame displayed before displaying the next frame. The second value defines how the frame should be displayed.

Cropping the Image Area

If you need to crop the image area e.g. because you recorded a bit larger area you can simply select the area with the rectangle selection tool and use Image ➞ Crop to Selection to crop all layers.

Adding Empty Frame

Select the top layer and select New Layer from the mouse context menu (right-click) or press the button in the left bottom corner of the layer window.

Do not forget to include the animation properties at the end of the layer name.

Preview

You can preview the current state using Filters ➞ Animation ➞ Playback menu. Exporting the final animation is not trivial so you should check the final animation before exporting it.

Exporting the Final Animation

At first you need to optimize the animation again. Use Filters ➞ Animation ➞ Optimize (GIF) menu to remove the repeating parts of images. This is basically the opposite process to the initial unoptimize step.

Then we can finally export the animation to a GIF file. Use File ➞ Export as … menu item, then write the target file name. Do not forget to set the .gif suffix.

The most important step here is check the As animation option which is by default unchecked. Then press Export and that’s it!

The result could look like this:

Final Words

At the very end check the file size before uploading to web. The animation should be rather small, usually less than 500kB. Do not use several megabytes large files, that is probably too much (esp. for mobile devices).

As I briefly mentioned a few weeks ago on my G+ page, the plan is for the 4.9 Linux kernel release to be the next “Long Term Supported” (LTS) kernel.

Last year, at the Linux Kernel Summit, we discussed just how to pick the LTS kernel. Many years ago, we tried to let everyone know ahead of time what the kernel version would be, but that caused a lot of problems as people threw crud in there that really wasn’t ready to be merged, just to make it easier for their “day job”. That was many years ago, and people insist they aren’t going to do this again, so let’s see what happens.

Go 1.7 was released earlier this month, and the thing I’m most excited about is the incorporation of the context package into the Go standard library. Previously it lived in the golang.org/x/net/context package.

With the move, other packages within the standard library can now use it. The net package’s Dialer and os/exec package’s Command can now utilize contexts for easy cancelation. More on this can be found in the Go 1.7 release notes.

Go 1.7 also brings contexts to the net/http package’s Request type for both HTTP clients and servers. Last year I wrote a post about using context.Context with http.Handler when it lived outside the standard library, but Go 1.7 makes things much simpler and thankfully renders all of the approaches from that post obsolete.

A quick recap

I suggest reading my original post for more background, but one of the main uses of context.Context is to pass around request-scoped data. Things like request IDs, authenticated user information, and other data useful for handlers and middleware to examine in the scope of a single HTTP request.

In that post I examined three different approaches for incorporating context into requests. Since contexts are now attached to http.Request values, this is no longer necessary. As long as you’re willing to require at least Go 1.7, it’s now possible to use the standard http.Handler interface and common middleware patterns with context.Context!

The new approach

Recall that the http.Handler interface is defined as:

type Handler interface {
        ServeHTTP(ResponseWriter, *Request)
}

Go 1.7 adds new context-related methods on the *http.Request type.

func (r *Request) Context() context.Context
func (r *Request) WithContext(ctx context.Context) *Request

The Context method returns the current context associated with the request. The WithContext method creates a new Request value with the provided context.

Suppose we want each request to have an associated ID, pulling it from the X-Request-ID HTTP header if present, and generating it if not. We might implement the context functions like this:

type key int
const requestIDKey key = 0

func newContextWithRequestID(ctx context.Context, req *http.Request) context.Context {
    reqID := req.Header.Get("X-Request-ID")
    if reqID == "" {
        reqID = generateRandomID()
    }

    return context.WithValue(ctx, requestIDKey, reqID)
}

func requestIDFromContext(ctx context.Context) string {
    return ctx.Value(requestIDKey).(string)
}

We can implement middleware that derives a new context with a request ID, create a new Request value from it, and pass it onto the next handler in the chain.

func middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
        ctx := newContextWithRequestID(req.Context(), req)
        next.ServeHTTP(rw, req.WithContext(ctx))
    })
}

The final handler and any middleware lower in the chain have access to all the previously request-scoped data set in middleware above it.

func handler(rw http.ResponseWriter, req *http.Request) {
    reqID := requestIDFromContext(req.Context())
    fmt.Fprintf(rw, "Hello request ID %v\n", reqID)
}

And that’s it! It’s no longer necessary to implement custom context handlers, adapters to standard http.Handler implementations, or hackily wrap http.ResponseWriter. Everything you need is in the standard library, and right there on the *http.Request type.

GSoC comes to an end, so it is time to write a last post about it.

The project

Let’s summarize what I did. You can also see it on Github: https://github.com/openSUSE/osem/commits?author=Ana06

I explained in my last post about the project that I had already changed completely the public schedule of OSEM. Since then I have mainly focused on the admin schedule, the place where the schedule is created. Now it is also possible to have several schedules in the backend before deciding which of them to use. So there is a list of schedules and a switch in every schedule to set that schedule as the selected one. I’ve also changed the appearance and functionality of the admin schedule. This is how it used to look like:

And this is how it looks like now:

As you can see I have integrated it in the admin interface. I’ve used bootstrap while doing so and I have also changed the way events are loaded and scheduled.

I’ve also introduced a Save button, as previously the schedule was saved instantly when dropping and event in a new cell. After clicking Save the page is reload and it is rendered a message to inform that the schedule was correctly saved or the reasons why it was not correctly saved. Another problem I’ve solved is that it was possible to schedule an event at the same time than other event, so things like that could happen:

I’ve also made the schedule times changeable. Previously the schedule started at 9:00 and ended at 20:00 and it was impossible to schedule an event outside this hours range.

Apart from the admin schedule I also add the feature to allow users to have their own schedule by having favourite events:

Nishanth GSoC project interfered few times with mine. It was something great as he pointed out some bugs in my project and I also helped him with the tags in the schedule:

There are some of the things I mentioned that hadn’t been merged yet as they are still being reviewed.

Challenges

I found a little bit tiresome understanding the javascript code previously used for the admin schedule and then changing it almost completely several times. But every time I changed that code I liked it more so it was worthwhile.

Displaying the tags in the schedule properly was not as easy as it seemed at the beginning: osem#1082 and osem#1125. Founding a way to make links inside other link work and to do it with ctrl+click was another little challenge as you can see here: osem#1132 and osem#1134.

Overall experience

Working in an Open Source Project has been much better than I expected (and I had very high expectations ). During the last three months I’ve learnt many things, had really fun and made friends. I would like to thank this amazing summer to all mentors (specially my mentors Christian and Henne) and to the openSUSE community. I also want to thank the TSP program for giving me the chance to attend openSUSE Conference, which was an incredible experience.

I will continue working on Open Source projects and of course I will continue working on OSEM. I also encourage all students reading to apply to GSoC next year and to do it at openSUSE.