Welcome CSS Grid Layout

Posted in Blink, CSS Grid Layout, English, Planet, WebKit on March 13th, 2014 by Manuel Rego Casasnovas – 3 Comments

Igalia has been working in the implementation of CSS Grid Layout since past year (more below). This year I’ve had the chance to join the team and help to move forward this great spec.

State of the Art

Maybe, you’ve never heard before about CSS Grid Layout, but for sure you know part of the history of design in the web platform.

  • In the beginning people tried to make cool designs using <table> tag. Which completely breaks the separation between content (HTML) and presentation (CSS), apart from the ugly code and poor results achieved with this approach.
  • Then people started to use <div> for everything, floating blocks here and there. This might cause a terrible mess when trying to do flexible layouts that will adapt themselves to the screen size.
  • Now lots of CSS frameworks are emerging (960 Grid, Blueprint, Bootstrap, Foundation, Skeleton, …). They allow to create responsive designs (very useful in the mobile era) most of them based on the grid concept. The problem is that each framework has its own syntax and lots of CSS code in order to provide the expected behavior.

To solve all these issues W3C has defined a new powerful and flexible spec that will make web designer’s life happier.

CSS Grid Layout

“allows authors to easily define complex, responsive 2-dimensional layouts”

By Tab Atkins Jr. (Google) at CSS WG Blog.

CSS Grid Layout provides a mechanism to divide the available space in rows and columns with a set of predictable sizing behaviors. It defines a set of grid areas where designers can precisely place the elements of a web page.

CSS Grid Layout example

CSS Grid Layout example

The Grid Layout spec can be used to intelligently reflow elements within a web page optimizing locations and sizes, depending on the device where the page is rendered in, creating responsive designs.


So, let’s imagine that you have the following HTML and you want to layout it like in the picture above:

<div class="grid">
    <div class="title">Title</div>
    <div class="menu">Menu</div>
    <div class="main">Main</div>
    <div class="footer">Footer</div>

This will be the CSS syntax required to do the magic:

.grid {
    display: grid;
    grid-template-columns: 200px 1fr;
    grid-template-rows: 100px 1fr auto;
.title { grid-column: 1; grid-row: 1; }
.menu { grid-column: 1; grid-row: 2 / span 2; }
.main { grid-column: 2; grid-row: 1 / span 2; }
.footer { grid-column: 2; grid-row: 3; }


  • display: grid: Defines a grid container.
  • grid-template-columns and grid-template-rows: Specify the track breadths.
  • grid-column and grid-row: Determine a grid item’s size and location within the grid.

Flexible tracks (the ones defined with 1fr in the previous example) will grow or shrink and automatically adapt themselves to the viewport size. This allows to create very customized grids, defining flexible breadths depending on the contents or the available space.

We’ve created a repository with some examples and demos, feel free to play with them to get a better understanding of the spec capabilities:


Implementation status

Despite of being a Working Draft (WD) spec, implementations are appearing in the main web engines:

  • IE/Trident first shipped an implementation in IE10.
  • Google started an implementation in WebKit by the end of 2011. Igalia has been working on this implementation since mid-2013, collaborating with Google in Chromium/Blink and maintaining an up-to-date implementation in Safari/WebKit.
  • Mozilla started working on an implementation in Firefox/Gecko this year.


Finally, we’d like to thank Bloomberg for sponsoring our work around CSS Grid Layout on Blink and Webkit, together with the implementation of ECMAScript 6 (ES6) features in V8 and SpiderMonkey JavaScript engines.

Igalia & Bloomberg logos

Igalia and Bloomberg working together to build a better web

As a related note, my mates Juanjo and Xavi were talking about CSS Grid Layout and CSS Regions in the last Mobile World Congress at Barcelona as part of the W3C booth. Check the slides in case you missed it (demos and videos of this post are extracted from them).

Igalia will keep working hard to evolve the implementation of CSS Grid Layout spec both in Blink and WebKit. We’ll try to keep you informed about our progress, stay tuned!

Performance of selection with CSS Regions in WebKit and Blink (Part II – perf profiler)

Posted in Blink, CSS Regions, English, Planet, WebKit on January 29th, 2014 by Manuel Rego Casasnovas – 1 Comment

After the initial post introducing this topic and describing the Performance Tests (perftests), now is time to explain how to analyze the performance issues with a profiler in order to improve the code.

“Manual” measurements

First of all, you can think of doing some measurements in the source code trying to find the possible bottle necks in an application. For example you could use the following lines inside WebKit/Blink in order to measure the time required to execute a given function:
timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
printf("%lld.%.9ld\n", (long long)ts.tv_sec, ts.tv_nsec);
// Call to the function you want to measure.
timespec ts2;
clock_gettime(CLOCK_REALTIME, &ts2);
printf("%lld.%.9ld\n", (long long)ts2.tv_sec, ts2.tv_nsec);
printf("Diff: %lld.%.9ld\n", (long long)ts2.tv_sec - ts.tv_sec, ts2.tv_nsec - ts.tv_nsec);

Actually this is a pretty bad idea for a number of reasons:

  • Checking directly times with printf() is wrong as you are adding I/O that will spoil the measurements.
  • You have to modify the source code for every statement you want to measure, this can be really hard in large projects like WebKit/Blink.
  • There are better tools out there, called profilers, explicitly designed for this very same purpose, let’s use them.

Using perf profiler

In this case we are going to talk about how to use perf in a GNU/Linux environment to analyze the performance of the WebKitGTK+ port. You could follow the next steps:

  • Install it. It depends on your distro, but it should be simple. For example in Debian: apt-get install linux-tools
  • Run perf record to get the data. This will create a file called perf.data. Here you have different options:
    • Call directly the application, it will follow the children processes, so it works properly in WebKit2 architecture with multiple processes: perf record -g <app>
    • Connect perf to an already existing process, for example to the WebProcess: perf record -p <process-pid> -g
  • Use perf report to analyze the data gathered by perf record. Simply use the following command (where -i <file-name> is optional as by default it reads perf.data file): perf report -i <file-name>

About how to collect the data, in WebKitGTK+ you have the alternative to generate the perf data files while running the perftests. Just adding some arguments to run-perf-tests script: Tools/Scripts/run-perf-tests --platform=gtk --debug --profile

Which will create a file called test.data under WebKitBuild/Debug/layout-test-results/ folder.

Analyze profile session

perf report provides you the list of methods that have been running for more time, with the percentage of how many time was spent in each of them. Then you can get the full backtraces from the different places the method is called and know how many times it was invoked from each trace.

Let's use a concrete example to illustrate it. This is a perf report output got from the WebProcess doing a big selection in a page with CSS Regions:

- 6.26% lt-WebKitWebPro libwebkit2gtk-3.0.so.25.5.0 [.] WebCore::LayoutUnit::rawValue() const
- WebCore::LayoutUnit::rawValue() const
- 33.10% WebCore::operator+(WebCore::LayoutUnit const&, WebCore::LayoutUnit const&)
- 39.54% WebCore::LayoutRect::maxX() const
- 83.75% WebCore::LayoutRect::intersect(WebCore::LayoutRect const&)
- 98.69% WebCore::RenderRegion::repaintFlowThreadContentRectangle(WebCore::LayoutRect const&, bool, WebCore::LayoutRect const&, WebCore::LayoutRect const&, WebCore::LayoutPoint const&) const
WebCore::RenderRegion::repaintFlowThreadContent(WebCore::LayoutRect const&, bool) const
WebCore::RenderFlowThread::repaintRectangleInRegions(WebCore::LayoutRect const&, bool) const
- WebCore::RenderObject::repaintUsingContainer(WebCore::RenderLayerModelObject const*, WebCore::IntRect const&, bool) const
- 75.49% WebCore::RenderSelectionInfo::repaint()
WebCore::RenderView::setSelection(WebCore::RenderObject*, int, WebCore::RenderObject*, int, WebCore::RenderView::SelectionRepaintMode)

As you can see, 6.26% of the time is spent in LayoutUnit::rawValue() method, this is used in lots of places. 33.10% of the time it's called from WebCore::operator+() which is also quite generic. We should keep going deeper in the call-graph till we reach some methods that are interesting in our particular case.

In this case, the selection starts in RenderView::setSelection(), so we should investigate further the methods called from there. Of course, in order to do that you need to have some understanding of the code where you're moving or you'll end up completely lost.

Improve source code

Thanks to this data I realized that in each RenderSelectionInfo::repaint() it's used the RenderObject::containerForRepaint(). Which most times returns the parent RenderNamedFlowThread for all its children in the render tree.

This causes that for every element under RenderNamedFlowThread the method RenderFlowThread::repaintRectangleInRegions() is called. Taking a look to this method it has a loop over all the regions forcing a repaint. This means that if you have 1000 regions, even if you're just selecting in one of them, a repaint in the rest of regions is executed.

So, I've provided a patch that repaints only the affected regions, it means around 12%, 18% and 73% improvement in Layout/RegionsSelection.html, Layout/RegionsSelectAllMixedContent.html and Layout/RegionsExtendingSelectionMixedContent.html perftest respectively.

Doing tests with more regions using this example we got the following results:

Regions Without patch (ms) With patch (ms) Improvement
100 923 338 63%
150 2712 727 73%
200 5952 1285 78%
500 81731 7868 90%

As expected, results are better as we increase the number of regions.


This was just one specific example in order to explain how to use the available tools, trying to provide the required context to understand them properly.

For sure, there's still plenty of work to be done in order to improve the performance of selection with CSS Regions. Nonetheless, we still have to settle a final implementation for the selection in CSS Regions before going on with the optimization efforts, as it was explained in my previous post we're on the way to fix it.

This work has been done inside the collaboration between Adobe and Igalia around CSS Regions.

In Igalia we have a great experience in performance optimization for CSS standards like CSS Flexible Box Layout, CSS Grid Layout and CSS Regions. Please don't hesitate to contact us if you need some help around these topics.

Approach to fix selection with CSS Regions (WebKitGTK+ hackfest late wrap-up)

Posted in Blink, CSS Regions, English, Planet, WebKit on January 23rd, 2014 by Manuel Rego Casasnovas – 1 Comment

As you probably know if you have been following this blog, we’ve been working for a while in selection interaction with CSS Regions inside a collaboration between Adobe and Igalia.

First of all, let’s contextualize this post.

WebKitGTK+ Hackfest 2013

Back in December it was organized the 5th WebKitGTK+ Hackfest at Igalia offices in A Coruña (Spain). During that week Mihnea, Javi and myself were working together trying to find a good solution for selection in CSS Regions.

As Javi has already explained in his last post, our initial implementation to fix the issues of selection in documents with CSS Regions was discarded due to several problems.

At that point, the main goal was to find an approach that will make selection in CSS Regions spec compliant and might be validated by the editing experts in order to get it integrated upstream.

Current problem

According to editing spec selection is DOM based. If you select some stuff in a page with CSS Regions, the content is retrieved properly from the DOM tree. In a selection retrieved content and highlighted content should match. However, this is not happening with CSS Regions.

CSS Regions introduces a divergence between DOM and render trees. In CSS Regions some nodes of the DOM tree (called content nodes, the ones that have -flow-into property) are moved from the “regular” render tree (under RenderHTML) to the RenderFlowThread (a sibling of RenderHTML).

During the selection we have a start and end positions in the DOM tree that are mapped into positions in the render tree. Selection algorithms traverse the render tree from start to end, which has some issues with CSS Regions in several situations. Let’s use the following diagram to explain some of them.

Diagram showing DOM and render trees together with visual display of a CSS Regions example

Diagram showing DOM and render trees together with visual display of a CSS Regions example

Let’s imagine we perform a selection from content-1 to content-2.

  • DOM selection: Returns the following nodes: content-1, source-1 and content-2.
  • Render tree selection: We start and end the selection outside the flow thread. However, source-1 which is selected in the DOM tree is under the RenderFlowThread and it's not processed by the algorithm while traversing the render tree from start to end. Thus, it's not highlighted.
  • Issue: source-1 is not highlighted.
Example of current and expected behaviors for selection in CSS Regions

Example of current and expected behaviors for selection in CSS Regions


After some discussion and lots of diagrams representing the DOM and render trees on paper, we came up with 2 ideas:

  • Subtrees approach: The idea is to split the render tree in subtrees calculating the start and end positions of the selection for each of them. Then it will use current selection methods to perform the selection inside each subtree.
  • DOM order approach: In this case we would use DOM order to traverse the render tree. Also when looking for the container of a node, we will follow the DOM tree too if it's a content node.
Handwritten diagrams representing DOM and render trees

Handwritten diagrams representing DOM and render trees

During the hackfest we implemented 2 quick prototypes to check if previous ideas would solve the problems. In both cases results were satisfactory.

However, DOM order idea seems more complicated as some elements in the DOM tree might not be present in the render tree. On top of that, we should review carefully the different methods involved in the selection and modify how they traverse the tree (or look for their container) in some cases. This would imply several changes in the more complex parts of the selection code.

On a first sight the subtrees approach is more promising as it looks simpler and cleaner. After talking with Ryosuke Niwa and David Hyatt on IRC it was confirmed as the preferred approach and likely valid to be integrated into WebKit. In addition, it seems that more performance optimizations could be done with this approach. So, let's explain deeply how this solution would work.

Subtrees approach

All selection algorithms are thought to work in a single render tree under RenderView. Actually, RenderHTML is the top element of the render tree where selection state is set (see RenderBoxModelObject::setSelectionState()).

Inside this render tree the start object is always before than the end object. But that's not always true in the case of CSS Regions, as you can see in the diagram above. For example, if you start selection inside the source-1 element (depending on its position inside the DOM tree) start position could be under the RenderFlowThread and end under the RenderHTML.

So, this solution will split the render tree in subtrees where the root objects would be:

  • On one hand, the RenderHTML (for the "regular" render tree).
  • On the other hand, all the RenderFlowThreads (there will be 1 per flow thread in the page).

Then the total number of subtrees we'll be 1 (the RenderHTML subtree) + number of flow threads.

For each subtree we'll calculate the start and end positions (start will be always before end). And then we'll call selection algorithms for each subtree using that positions.

In the previous example we'll have 2 subtrees:

  • RenderHTML subtree.
  • RenderFlowThread (flow-1) subtree.

Let's calculate start and end positions for each subtree taking into account the example above:

  • RenderHTML subtree:
    • start: content-1, offset: start offset set by user's selection.
    • end: content-2, offset: end offset set by user's selection.
  • RenderFlowThread (flow-1) subtree:
    • start: source-1, offset: start of source-1 object.
    • end: source-1, offset: end of source-1 object.
Subtrees approach DOM and render trees selection example

Subtrees approach DOM and render trees selection example

Using these subtrees RenderView::setSelection() method will be called for each of them. Subtree's root object will need to store information about start and end positions (together with their offsets).


This is an important milestone for the work we have been doing lately, and it allows us to have a clear path to make progress on this field and eventually fixing the selection in CSS Regions.

Of course, there's still quite a lot of work to do. We'll improve current prototype to convert it in a real patch to be uploaded at WebKit's bugzilla and got it integrated after the review iterations. Then, as usual, we'll try to get integrated into Blink too.

Finally, thanks to The GNOME Foundation and Igalia for sponsoring the WebKitGTK+ Hackfest, and also to Mihnea for attending and helping us to move this topic forward sharing his experience on the CSS Regions standard.

Exciting times ahead, stay tuned! Happy hacking. :-)

Sponsored by GNOME Foundation logo

Igalia logo

Performance of selection with CSS Regions in WebKit and Blink (Part I – Perftests)

Posted in Blink, CSS Regions, English, Planet, WebKit on December 10th, 2013 by Manuel Rego Casasnovas – 1 Comment

In a nutshell, CSS Regions are a new W3C specification that allows next generation responsive design in the web platform (you can read this article for a nice introduction). Adobe WebPlatform team is doing a great job leading the implementation of this standard and we at Igalia are joining efforts to contribute to the challenge.

Selection’s performance plays an important role in the collaboration between Adobe and Igalia around CSS Regions. This is the first of a series of articles on how to fix performance issues in WebKit/Blink using the selection in regions use case as example.

Example of selection performance in a document with and without CSS Regions in WebKitGTK+

Example of selection performance in a document with and without CSS Regions in WebKitGTK+

We’ve been checking the performance of selection in regular pages compared to pages using CSS Regions. We created some examples (that you can try by yourselves) and they clearly show that the selection with regions is pretty slower as you can see in the picture. On the one hand this was expected due to complexity of CSS Regions, on the other hand we wanted to take a deeper look and see how it can be improved.

First of all we need objective numbers in order to show that the new patches improve (or not) the performance. For this purpose WebKit and Blink provide a mechanism called Performance Tests (perftests). Perftests measure the time required to run them and also the memory they consume. The idea is to create a baseline with these values and spot performance regressions in new revisions (see some nice charts generated from them).

On a low level note, perftests are simply HTML files which generally use a JavaScript object called PerfTestRunner which provides different utility functions, you can find them under PerformanceTests/ folder (both in WebKit and Blink). In addition you can run them using Tools/Scripts/run-perf-tests script.

Running Layout/RegionsSelection.html perftest directly in WebKitGTK+ MiniBrowser

Running Layout/RegionsSelection.html perftest directly in WebKitGTK+ MiniBrowser

There were already some CSS Regions perftests (see PerfTestRunner/Layout/ directory) but none of them about selection. So we decided to create a new perftest for selection in CSS Regions. The new test has 100 regions and it selects text from the first region to the last one passing through the rest of regions. That way we’re somehow simulating the interaction of a selection done by a real user. The test is called RegionsSelection.html and it’s available in WebKit and Blink.

Note: CSS Regions perftests are still skipped by default because of the fact that regions performance is an ongoing development. They’ll be enabled in the future once it’s possible to create a baseline.

Just to let you know how it looks like when you use the script, below you can see the results of running the perftest in WebKitGTK+ (using r160082):
$ Tools/Scripts/run-perf-tests --platform=gtk -2 Layout/RegionsSelection.html
Running 1 tests
Running Layout/RegionsSelection.html (1 of 1)
DESCRIPTION: Testing selection with 100 regions. Select text from first region to last one passing through all the regions.
RESULT Layout: RegionsSelection: Time= 987.760100001 ms
median= 990.745000017 ms, stdev= 8.95593764346 ms, min= 978.406000009 ms, max= 1013.26800004 ms
RESULT Layout: RegionsSelection: JSHeap= 173468.6 bytes
median= 173957.0 bytes, stdev= 1973.74275506 bytes, min= 169707.0 bytes, max= 174869.0 bytes
RESULT Layout: RegionsSelection: Malloc= 1593350.4 bytes
median= 1591104.0 bytes, stdev= 15450.5740939 bytes, min= 1567544.0 bytes, max= 1622624.0 bytes
Finished: 31.423325 s

Finally, once we have a perftest that provides objective numbers, we can start using a profiler and extract some data that helps us modify the code in order to improve the performance. We’ll talk about that in the next post. Stay tuned if you don’t want to miss what Igalia is doing related to CSS Regions.

Improving tests coverage for selection with CSS Regions in WebKit and Blink

Posted in Blink, CSS Regions, English, Planet, WebKit on November 6th, 2013 by Manuel Rego Casasnovas – Be the first to comment

It’s been almost a year since my previous post in this blog, I think this deserves an explanation. This year I’ve been working intensively in web internals as part of Igalia’s browsers team. Besides other stuff, I’ve been working in WebKitGTK+ port and its new WebKit2 API, contributing some patches into Epiphany (GNOME Web Browser) and lately working in the CSS Regions implementation in WebKit (where I’m already a committer :-D) and Blink as part of the collaboration between Adobe and Igalia.

Inside this collaboration, our main goal is to fix the selection issues in documents using CSS Regions. You can read more information about it on Javi Fernández’s post. As explained there we have cooked some examples highlighting different issues with selection in CSS Regions.

Despite of having more than 35,000 tests in WebKit, there were almost no tests checking the selection in CSS Regions. Thus, we’ve been creating different layout tests that you can find under LayoutTests/fast/regions/selection/ folder in WebKit‘s and Blink‘s source trees.

Example of layout test for selection in CSS Regions using vertical-rl writing mode

Example of layout test for selection in CSS Regions using vertical-rl writing mode

Most of them are reftests, which means that we have two HTML files that should render the very same result. Specifically in this case we usually compare the result of the selection content and highlighted text in CSS Regions with the result of a crafted HTML page using absolute positions. Moreover, we try to do the tests in a way that you can check them manually directly opening the HTML file a browser. Besides, we’ve created tests for different writing modes like horizontal-bt, vertical-lr and vertical-rl.

At this point we have a good tests coverage that should be enough as base to prevent breakages in the selection with CSS Regions. Anyway, it’s clear that more tests will come in the future as soon as implementation advances and some issues get fixed. You can follow the work we’ve been doing on this meta-bug.

Just for the record, here you have the full list of WebKit bugs and Blink issues related to this task:

Finally, I’d like to thank Igalia for giving me the chance to get involved in browsers development, working in the implementation of last specifications is a challenging but very heartwarming task. Let’s keep working hard to improve the web experience!

LibrePlan: Adapt planning according to timesheets

Posted in English, Java, LibrePlan, Planet on November 28th, 2012 by Manuel Rego Casasnovas – Be the first to comment

During the last weeks I’ve been working in a new feature for LibrePlan that allows to update the project plan using the data from the timesheets.

Let’s use an example in order to explain the new functionality better.

Imagine that you have scheduled a task to be done during week 45, however the timesheets reporting hours to that task are in week 47. This means that you’re not fulfilling the plan and you have a delay of 2 weeks in that task. Besides, maybe that task has dependencies with other tasks, so this delay also means that other tasks are going to be delayed.

Some questions:

  • How could you check that information in LibrePlan?
  • How could you update the current plan?

In order to solve these problems a new feature has been developed. The final implementation includes different things which will be explained below.

  • Mark a task as finished from the timesheets

    In the timesheets UI (both in standard and personal timesheets) you’ll have the option to mark if a task is finished or not. You can only mark a task as finished once, but the task end date will be taken from the last timesheet reporting hours over that task. Then, when you use the new button to adapt the planning, a new 100% progress of type timesheets will be set for the task, which means that the task has been finished.

    Pop-up to mark task as finished in personal timesheets

    Pop-up to mark task as finished in personal timesheets

  • New marks in reported hours bar

    If you use the button Show/Hide reported hours, you’ll see the pink bars in the Gantt representing the hours reported in the timesheets compared with the planned (or estimated) hours. Now, together with that information you’ll also see two square brackets, that represent the first and last date in which there’re reported hours in the timesheets.

    Gantt showing marks with information from timesheets

    Gantt showing marks with information from timesheets

    As you can see in the picture most of the tasks started more or less when it was planned. However, we can detect some issues:

    • Draft task is delayed 2 weeks, which makes Template task to be delayed too.
    • Shopping cart task was started in the planned date, however it’s taking more time than expected.
  • Adapt planning button

    There is a new button (close to Reassign) in the project Gantt view that will allow you to adapt your current planning with the information extracted from the timesheets. This will allow you to modify your planning as people report hours in the timesheets.

    Planning adapted according timesheets data

    Planning adapted according timesheets data

    Once the planning has been adapted according to timesheets data, you’ll see the actual status of your project. Moreover, you’ll have the possibility to know which tasks are finished. In the example the finished tasks are only: Draft, Product management and Shopping cart.

    With all this information you’ll be able to modify the future planning in order to finish the project in the expected date (maybe allocating more resources, reducing some tasks, …).

Summarizing, we think that this is a nice addition that could be helpful to our users in order to manage better their projects. It’ll be available in the upcoming version 1.3.2 (you can already test it in the unstable environment) and, as usual, we’ll be really glad to receive your feedback about it. If you want to know more, you can review the analysis and implementation notes at LibrePlan wiki.

Finally, we’d like to publicly thanks to SOMABE for sponsoring this development. As you probably know Igalia offers this kind of customizations and other services around LibrePLan, don’t hesitate to contact us.

First LibrePlan Hackfest

Posted in English, Java, LibrePlan, Planet on November 9th, 2012 by Manuel Rego Casasnovas – Be the first to comment

Yesterday, we arranged the first LibrePlan hackfest at Igalia headquarters in A Coruña.

Blackboard with the brainstorming

Blackboard with the brainstorming of LibrePlan hackfest

First of all, we started with a brainstorming where each of us provided his own ideas about how to improve the project. We ended up with a plan for the day defined by a quite big list of topics:

  • Right-click in the left menu of the project planning perspective.
  • Make projects list sortable in the main Gantt view.
  • Filter by name in projects and tasks view.
  • Implement dependencies with lag.
  • Avoid to leave the project perspectives without being warned if you have not saved the project.
  • Review some bugs that were pending from some time ago and need some discussion.
  • Give some love to help.
  • Create a new project status called “pre-sales”.
  • Add a milestone from WBS view.
  • Add dependencies from WBS view.
  • Copy/move tasks.
  • Copy projects.
  • Allow to modify LDAP/DB property in users edition.
  • Review and update Fedora hacking instructions.
  • Review some usability improvements.
  • Mobile application for bound resources.

And as you can read below the outcome was pretty good.

Jacobo and Óscar at LibrePlan hackfest

Jacobo and Óscar at LibrePlan hackfest

Jacobo was the first one finishing a task, he updates Fedora hacking instructions and also fix some issues preventing to compile LibrePlan with OpenJDK 7.

Javi and Jeroen were talking about different issues around LibrePlan, from the new LibrePlan customization for the audiovisual sector, to the last events where we’ve had some talks about LibrePlan (like Libre Software World Conference and T-Dose). They also discussed about the community, the future of the project and many other things.

Óscar and me started to review some bugs that have some special complexity and discussed the possible solutions. Óscar worked out a patch for bug #1413 and we also took a look to #1320, #1265 and #1553.

Loren began with the protect upper menu task, in order to prevent users to lose changes when they forget to use the save button. We really think that our users will appreciate this as you won’t have to worry about it anymore as Loren and Óscar finally managed to fix it. :-D

LibrePlan mobile app screenshots

LibrePlan mobile app screenshots

During the afternoon, after a nice lunch, we carried on with the hackfest.

I kept working in a small mobile application for bound users. The purpose of the app is to allow bound users query their assigned and report worked hours via the personal timesheets. The first part is almost ready and you can already see the list of assigned tasks to a bound resource in your phone.

Jeroen was working a little bit in the help in order to give it a new refreshing look.

Jacobo also did the task regarding to edit if a user is a LDAP or database user. And at the end of the day he was working in some usability improvements regarding how to set properly the focus while working in the WBS.

Loren began an approach to include the right-click on the project/task name avoiding the need to use the box in the Gantt to enter a project or allocate a task.

Javi, Jeroen and Loren at LibrePlan hackfest

Javi, Jeroen and Loren at LibrePlan hackfest

Javi was working in his patches to show the load of the resources to be assigned in the allocation pop-up. He also discussed some stuff with Óscar in order to improve the current implementation.

Jeroen, Loren and me were debating the possible project status in LibrePlan. Finally we included two new status “pre-sales” and “on hold” and also renamed the one related with subcontracted projects to “outsourced”. So the final list of project status is: pre-sales, offered, outsourced, accepted, started, on hold, finished, canceled and stored.

Finally, I’d like to specially thank Jeroen and Óscar for coming to the hackfest and contributing with their ideas and experience. And also to Igalia for sponsoring it. On the other hand, it was a pity that some people couldn’t attend in the last minute.

It was a really nice day, and we hope to repeat this experience in the future, you’ll enjoy the result of this day in the next LibrePlan versions!

Group picture of LibrePlan hackfest

Group picture of LibrePlan hackfest

You guys rock! Happy hacking :-)

LibrePlan: New Project Status Report

Posted in English, Java, LibrePlan, Planet on October 31st, 2012 by Manuel Rego Casasnovas – 1 Comment

Lately we‘ve been working in a new report in LibrePlan. The report is called Project Status Report and the first part of the report (related to hours) is already available in LibrePlan 1.3.1, however in the next version some additions over this report will be included.

The main goal of this report is to have a printable version of the project task tree (WBS) summarizing some important information regarding 2 aspects:

  • Hours: For each task in a project it will show the 3 type of hours we have in LibrePlan:
    • Estimated: The ones filled in the WBS tree.
    • Planned: The allocated hours, they are configured in the task allocation. They can be the same or not than Estimated hours as you can change it while doing the planning.
    • Imputed: The hours devoted to a task by the workers. Introduced in the timesheets (work reports). If the number of Imputed hours is bigger than Planned hours, then it’ll be shown an exclamation mark and the number will appear in red.
  • Money cost: Apart from the hours information in the new version will be included information about the money cost:
    • Budget: Estimated budget in the WBS.
    • Hours cost: Cost calculated depending on resources cost categories and the Imputed hours.
    • Expenses cost: Cost imputed via expenses sheets.
    • Total cost: Addition of 2 previous costs (Hours + Expenses). It’ll also show a mark if it’s bigger than Budget.
Project Status Report example

Project Status Report example

Apart from the new columns, the new version will also allow to filter the report by labels and/or criteria and the project filter will be optional. This will return the information of all the tasks related with the labels and/or criteria in all your projects. We think that this is a nice addition in order that you analyze where are you having troubles, for example, comparing Project managers with Developers.

Project Status Report filter by criterion "Project Manager"

Project Status Report filter by criterion "Project Manager"

Project Status Report filter by criterion "Developer"

Project Status Report filter by criterion "Developer"

We hope you enjoy the new report and the latest changes, we’ll be really glad to receive your feedback about it ;-)

SergasApp 0.1.1

Posted in Galego, PhoneGap, SergasApp on September 14th, 2012 by Manuel Rego Casasnovas – 2 Comments

SergasApp foi publicada en Abril deste mesmo ano e acaba de superar as 2000 descargas no market de Android (Google Play). Antes de nada, moitas gracias a todos pola boa acollida.

Debido a un bug de PhoneGap en Android 4.1 Jelly Bean veño de publicar unha nova versión da aplicación. O problema era que a aplicación pechábase cando un usuario introducía o número “7″ nalgún campo. O erro foi correxido na versión 2.0.0 de PhoneGap, polo que SergasApp agora emprega esa versión.

A parte desta corrección a nova versión inclúe as seguintes novidades:

  • Agora inclúese a información sobre o tipo de cita tanto durante o proceso de solicitude como na consulta das mesmas.
  • Por defecto, selecciónase o primeiro día e hora libres á hora de solicitar unha consulta.
  • En Android engadiuse un novo botón que permite pechar a aplicación.

Espero disfrutedes da nova versión que podedes descargar dende a páxina web da aplicación ou o market de Android (Google Play) ;-)

PhoneGap at Master on Free Software

Posted in English, MSWL, PhoneGap, Planet on August 4th, 2012 by Manuel Rego Casasnovas – Be the first to comment

Like in the past 3 years, this year I’ve been teaching some lessons of the web module inside the Master on Free Software organized organized by Igalia and URJC.

Apart from some classes about Java, this time I’ve given a workshop about PhoneGap (now renamed to Apache Cordova). If you don’t know it yet, maybe you want to take a look if you’re interested in web development (HTML + CSS + JavaScript) for mobile platforms.

The workshop tried to give an overview of this framework and during the class we developed a simple feed reader as example app. The main technologies used (apart from PhoneGap) were: jQuery (to manipulate the DOM), jQuery Mobile (for the UI) and jFeed (to read the RSS/Atom feed). You can find the slides of my presentation below and if you follow them you should be able to develop the example too ;-)

Finally, maybe you don’t know it yet, but some months ago I developed a small mobile application using PhoneGap. The app is called SergasApp and it allows request medical appointments for the Galician Healthcare Service. As usual, it’s free software and you can find the source code in GitHub if you’re interested in review another example app developed with PhoneGap.