The Document Foundation Planet

 

May 28, 2015

Official TDF Blog

The Document Foundation announces LibreOffice Viewer for Android

Berlin, May 28, 2015 – LibreOffice, the best free office suite on the desktop, is available on Android as a native application for viewing ODF documents. The app can be installed from Google Play Store at http://tdf.io/androidviewer. Direct download of the APK and download from other app stores will be made available at http://www.libreoffice.org/download/android-viewer.

LibreOffice Viewer also offers basic editing capabilities, like modifying words in existing paragraphs and changing font styles such as bold and italics.

Editing is still an experimental feature which has to be enabled separately in the settings, and is not stable enough for mission critical tasks. It will be enhanced to a fully fledged editing solution in the future, with the help of our steadily growing developer community. The editing features provided in the current release have been developed thanks to donations to The Document Foundation.

Feedback and bug reports are very welcome, to help developers improve the quality of the application on its way to a fully-fledged editor. Users are invited to report problems, using the bug tracker and attaching files that have triggered the issue at https://bugs.documentfoundation.org.

LibreOffice Viewer is using the same engine as LibreOffice for Windows, OS X and Linux. This, combined with a new front-end based on Firefox for Android, reads documents similarly to LibreOffice on the desktop.

LibreOffice Viewer has been developed by Collabora and Igalia, backed by Smoose, with contributions from Google Summer of Code students, together with The Document Foundation and the LibreOffice community. SUSE has provided a key foundation of cross platform support, and Mozilla Corporation several core components.

by italovignoli at May 28, 2015 11:24 AM

Michael Meeks

2015-05-28 Thursday.

  • Up early; mail chew; call with Niall, admin; CRM bits, filed holiday; signed up for OIN.

May 28, 2015 11:18 AM

May 27, 2015

Michael Meeks

2015-05-27 Wednesday.

  • Day off - up late, into Cambridge; wandered around the Fitzwilliam Museum a bit with the babes, interesting place. Lunch in the courtyard outside in the sun. Back to the office for a partner call, then a customer call; picked by by a homebound family; TDF board call. Worked late.

May 27, 2015 09:00 PM

>Marius Popa Adrian

RIP Robert Pacurar

Monday  I looked in the mirror in the morning and i saw death into my eyes reflected into the mirror for glimpse of a second , I couldn't belive that this is the end but yes my eyes were darker than usual and i told to myself that that day something is gonna happen to me , Then i went to work and saw a car with a "Be aware of bikers" bumper sticker and i wondered why people would put something

by Adrian Marius Popa (noreply@blogger.com) at May 27, 2015 07:45 PM

#gsoc2015 for libreoffice update #2 - update firebird to 2.5.4 , osx builds ok

I have updated firebird 2.5.4 patch also with osx patches refactored (now is building ok on osx) https://drive.google.com/file/d/0BwmDDYc8dMVzRllXM0pMYWRhWlpiOGRZSDNmMkxfekV2QlI0/view?usp=sharing I still need to clean the cygwin msvc patch (work in progress) it fais on cygwin on these lines 2 out of 10 hunks FAILED -- saving rejects to file configure.in.rej [build CHK] cppu

by Adrian Marius Popa (noreply@blogger.com) at May 27, 2015 03:22 PM

#gsoc2015 for libreoffice update #1 - update firebird to 2.5.4

Jenkins tells us libo master fails to build on MacOS and MS Windows, in the firebird compilation. These two will be merged into one request: https://gerrit.libreoffice.org/#/c/15026/ Patch is applied upstream http://tracker.firebirdsql.org/browse/CORE-4475 https://gerrit.libreoffice.org/#/c/15029/ Also external/firebird/firebird-icu.patch is already applied upstream in 2.5.4 (it's an examples

by Adrian Marius Popa (noreply@blogger.com) at May 27, 2015 03:21 PM

User Prompt

Libreoffice Human Interface Guidelines: The second step

lo_logoAlmost a month has passed and it’s time for an update. The Libreoffice UX team finished two more guidelines that are introduced in this posting. The interesting point is not what the guidelines constitutes in detail but the impact of the previously defined articfacts. Because we introduced two primary personas for whose Libreoffice is being developed we need to address this fact as well in every design and workflow decision. And of course the guidelines have to reflect the duality likewise.

Menu bar

The menu bar provides access to all functions using submenus or cascading menus to structure the content. Users like the Libreoffice persona Eve refer frequently to the menu bar, especially when they are seeking a function for which they know of no other interface. Ensuring that menus are well organized, are worded clearly, and behave correctly is crucial to the user’s ability to explore and access the functionality of the application.

Learn more about menu bars at Libreoffice HIG: Menu bar.

Tool bar

A tool bar is a graphical presentation of commands optimized for fast access. Typically, a tool bar contains buttons that correspond to items in an application’s menu, providing direct access to application’s most frequently used functions for both novice users such as Benjamin who relies on this preselection and experts like Eve. A good menu bar is a comprehensive catalog of all the available top-level commands, whereas a good tool bar gives quick, convenient access to frequently used commands.

Learn more about tool bars at Libreoffice HIG: Tool bar.

Next Steps

The human interface guidelines basically intends to optimize UX decisions. It aim is to improve the experience for the users by making application interfaces more intuitive, learnable, and consistent. This posting is a life sign and should make our progress transparent, on the one hand, but is also an indicator what impact two primary persona have on the definition of a consistent user experience.

The next steps include guidelines on context menus, sidebars, and dialog layout. We will keep you updated. And as always we are interested in your feedback.

by Heiko Tietze at May 27, 2015 01:51 PM

Official TDF Blog

LibreOffice Conference Sponsorship Packages

The LibreOffice Conference 2015 will be hosted by the city of Aarhus, the second largest in Denmark, from September 23 to September 25. The event gathers developers, designers, localizers, documenters, supporters, marketers and users of the leading free office suite, to get an update about the project and learn about its future.

Companies are invited to support the event – joining Collabora, Magenta and RedHat, who have already confirmed their sponsoring – according to the package that best suits their needs. Pre-configured packages are available on the conference website at http://conference.libreoffice.org/2015/sponsorship/.

Supporters benefit from a number of activities before LibreOffice Conference, including the logo and a company description on the website, a media announcement of their participation, and a mention during the opening session. They are also given the opportunity to host a session.

Sponsors logos will be featured on conference banners and publicity materials in the various conference rooms, and materials will be included in the official LibreOffice Conference registration bag.

The conference is organised by the not-for-profit “Foreningen Dansk LibreOffice Konference 2015″. Please get in touch with them at conference@libreoffice.org to sign up for a sponsorship package.

by italovignoli at May 27, 2015 07:53 AM

May 26, 2015

Michael Meeks

2015-05-26 Tuesday.

  • Mail chew; pushed a few patches; Linux Format Column; customer call, chat with Niall, team call; more hackery.

May 26, 2015 09:00 PM

Andras Timar

Exporting custom shapes to DrawingML – Part 2

On LibreOffice Cambridge Hackfest and the days after it I hacked on exporting custom shapes to DrawingML. (The “Part 2″ in title indicates that there is a Part 1, the work I did on FOSDEM Hackfest, earlier this year.)

It was drawn to my attention, that my commits caused “regression” in the sense that the wrong export became even worse in some cases (e.g. tdf#90338). I was also aware of some imperfections.

Screenshots worth a thousand words, so here is the result of my recent work.

BEFORE Shapes saved to DOCX format and reopened in Writer.

BEFORE
Shapes saved to DOCX format and reopened in Writer.

AFTER Shapes saved to DOCX format and reopened in Writer.

AFTER
Shapes saved to DOCX format and reopened in Writer.

by timar at May 26, 2015 06:11 PM

Björn Michaelsen

Death or Glory vs. Continuous Integration

But I believe in this and it’s been tested by research
— The Clash, Death and Glory

Thanks to Norbert’s efforts, the LibreOffice project now has a Jenkins setup that not only gives us visibility on how healthy our master branch is, with the results being reported to the ESC regularly: In addition it allows everyone easily testing commits and branches on all major LibreOffice platforms (Linux, OS X, Windows) just by uploading a change to gerrit. Doing so is really easy once you are set up:

./logerrit submit                      # a little helper script in our repo
git push logerrit HEAD:refs/for/master # alternative: plain old git
git review                             # alternative: needs to install the git-review addon

Each of the above commands alone send your work for review and testbuilding to gerrit. The last one needs an additional setup, that is however really helpful and worth it for people working with gerrit from the command-line regulary.

So, what if you have a branch that you want to testbuild? Well, just pushing the branch to gerrit as suggested above still works: gerrit then will create a change for every commit, mark them as depending on each other and testbuild every commit. This is great for a small branch of a handful of commits, but will be annoying and somewhat wasteful for a branch with more than 10-15 commits. In the latter case you might not want a manual review for each commit and also not occupy our builders for each of them. So what’s the alternative, if you have a branch ${mybranch} and want to at least test the final commit to build fine everywhere?

git checkout -b ${mybranch}-ci ${mybranch} # switch to branch ${mybranch}-ci
git rebase -i remotes/logerrit/master      # rebase the branch on master interactively

Now your favourite editor comes up showing the commits of the branch. As your favourite editor will be vim, you can then type:

:2,$s/^pick/s/ | x

To squash all the commits of the branch into one commit. Then do:

git checkout -                                   # go back to whatever branch we where on before
git push logerrit ${mybranch}-ci:refs/for/master # push squashed branch to gerrit for testbuilding
git branch -D ${mybranch}-ci                     # optional: delete squashed branch locally

Now only wait for the builder on Jenkins to report back. This allowed me to find out that our compiler on OS X didnt think of this new struct as a POD-type, while our compilers on Linux and Windows where fine with it (see: “Why does C++ require a user-provided default constructor to default-construct a const object?” for the gory details). Testbuilding on gerrit allowed me to fix this before pushing something broken on a platform to master, which would have spoiled the nifty ability to test your commit before pushing for everyone else: Duly testing your commit on gerrit only to find that the master you build upon was broken by someone else on some platform is not fun.

The above allows you to ensure the end of your branch builds fine on all platforms. But what about the intermediate commits and our test-suites? Well, you can test that each and every commit passes tests quite easily locally:

git rebase -i remotes/logerrit/master --exec 'make check'

This rebases your branch on master (even if its already up to date) and builds and runs all the tests on each commit along the way. In case there is a test breakage, git stops and lets you fix things (just like with traditional troubles on rebases like changes not applying cleanly).

Note: gerrit will close the squashed branch change if you push the branch to master: The squashed commit message ends with the Change-Id of the final commit of the branch. So once that commit is pushed, the gerrit closes the review for the squashed change.

Another note: If the above git commands are too verbose for you (they are for me), consider using gitsh and aliases. Combined they help quite a lot in reducing redundant typing when working with git.


by bmichaelsen at May 26, 2015 08:39 AM

Miklos Vajna

LibreOffice Cambridge Hackfest

https://lh3.googleusercontent.com/-dGY38VD7z0M/VWNqvkXDLwI/AAAAAAAAFlE/8yurKsu0NcA/s400/

The first ever UK LibreOffice Hackfest took place in the city of Cambridge on May 21st to 23rd (Thursday → Saturday), kindly hosted by Collabora.

My starter idea was to fix tdf#90315, i.e. to support both nested tables and multiple columns with the proper spacing in between them in the RTF import. For comparison, here is how this looked in LibreOffice 3.4:

https://lh3.googleusercontent.com/-KX9Z8y1ojYc/VWNzgg1gQeI/AAAAAAAAFlk/TRwfvnklEOI/s400/

The table borders looked OK due to correct column spacing, but the nested table is missing. Then here is the LibreOffice 4.4 state:

https://lh3.googleusercontent.com/-wz4OZdsYf5I/VWNzgu5OhUI/AAAAAAAAFlg/CG37pRlGggY/s400/

Nested table is OK, but the table borders are strange due to incorrect column spacing. Finally here is how it looks like now, when the import result is correct:

https://lh3.googleusercontent.com/-Zul_8xTSOkA/VWNzguGZf-I/AAAAAAAAFlY/L88WkfCpL1E/s400/

Other than this, here is a list of other topics I hacked on:

After fixing two more less interesting regressions, now it seems we’re down to 0 for the regressions having RTF in their summary, which is promising. :-)

I few pictures I took while punting and a panorama is available, too.

May 26, 2015 07:07 AM

May 25, 2015

Michael Meeks

2015-05-25 Monday.

  • Up lateish; off to Bruce & Anne's for a Warren End party. Good to meet up with Sue, Clive & boys; as well as lots of neighbours. Hacked in the car on the way back.

May 25, 2015 09:00 PM

Charles Schulz

Software Commons vs. Product

One regular reader of this blog contacted me a few days ago to share a few suggestions and some concerns about the LibreOffice project. I did not agree with many of the points he was making, but a few of them made sense. I’d like to discuss the main one, because I think there is no clear cut answer about it even inside the LibreOffice project.

The matter at hand was that this reader felt that we could not really accomplish much in the way of a quality product if we were to continue to function as a community. Should we either “dump” our community, if it were even possible, or should we as project turn the tables and radically change the way we work? LibreOffice_external_logo_200px

If such questions seem outrageous, they tend to highlight what many people in the I.T. and even elsewhere think: Free & Open Source Software projects should deliver great products, but unfortunately, they seldom do. There are several problems with this assertion, the first one being that contrary to popular belief even inside FOSS communities FOSS projects do not produce nor develop products. Products are created by companies and they are complete and finite constructs. Online communities on the other hand, produce commons: software or media commons most of the time. A product does not come out by sheer will: it comes with warranties and a professional support structure that must exist and be operational, for consumers or professionals. LibreOffice, Firefox, Linux distributions, VLC, the Gimp, Emacs, etc. are software commons. They may do their job really well, they may be very innovative, but they cannot be products. What could be a product is a company providing support and services on a software. In this case, it wouldn’t be a product as much as a service, but you see my point: the offer itself would be the service and the software commons themselves would not be sold; only the added value can be monetized.

I frequently see this mistake being made even inside FOSS communities. Sometimes this stems from volunteers who want to help by promoting the software and as such they will think of what should be done in terms of “marketing”. But irrespective of the fact that “marketing” has changed a lot since the good old “4Ps” and the “explain what your product does to your client”, you cannot market software commons like you would with a product; you would create wrong expectations and disappointing users.

I do believe however that some of this misunderstanding arises out of frustration that a project is not headed to where we think it should, or that the software has not added the feature XYZ yet. Yet frustration is of little use to a project if you don’t try to change things from within. Obviously, not everyone has time to contribute nor is able to develop features. But does it mean that FOSS communities develop less innovative software than their proprietary counterparts?

Not at all. But it is important to remember that:

  1. Proprietary software products are different from Free and Open Source software, which is by definition software commons.
  2. Any glance at the IT industry would prove otherwise, but expectations vary from one sector to the other, especially when it comes to software everyone uses. That’s the case with LibreOffice, and people will mistake innovation with changing the interface all of a sudden for no seemingly understandable reason (case in point: the Ribbon user interface). Being a “user oriented software” has its blessings. And its curses.
  3. Communities are not companies. Individuals, commercial, academic and governmental entities coming together to produce software commons is very different from someone selling products or service for his own benefit or the one of shareholders. You may think one is more effective than the other, but in terms of how you can influence each of them, the verdict is clear: communities are the right venues to involve any interested party to contribute. That is not usually the logic with regular businesses.

So where does it leave us? I think it is important to remind ourselves what it is that we want. I do wish LibreOffice could get even more patches and features in, improve its quality. I do not believe that getting rid of our community of contributors is a right price to pay for such an expected outcome. True enough, the Document Foundation can invest resources to “get things done” and ensure certain tasks are performed in a timely fashion, to the extent our existing contributors would not be able to do it. But here lies the limit of the distinction: knowing when to rely on service providers and when to rely on our community. The answers are not always easy to come up with.

by Charles at May 25, 2015 02:03 PM

Official TDF Blog

Behind the scenes at TDF: Certification Project, an update

Italo Vignoli is one of the founders of The Document Foundation, and has been a member of the first Steering Committee and then of the first Board of Directors until 2014. He has been active in marketing since the launch of the project, and has created the LibreOffice certification project from scratch. He is a member of the staff, in charge of certification and now also of marketing and public relations.

2015 is another year packed with exciting projects and ideas around LibreOffice and The Document Foundation, so we want to continue our behind-the-scenes series, to share achievements with our community and our generous donours, to whom we’d like to express our sincerest gratitude and thanks for their incredible and wonderful support and their invaluable contributions!

The LibreOffice Certification Project has seen a number of improvements since January, when we have had the first session at FOSDEM.

First, we have added Edmund Laugasson from Estonia and Carlos Rodriguez from Spain, who have gone through the peer-to-peer review process in early May, to the list of certified TDF members.

We have also leveraged the experience of the review sessions to improve the process, in order to make it more dependable for the future. Thanks to several contributions from Sophie Gautier, Lothar Becker and Thomas Krumbein, we have a hugely improved questions & answers document which will help reviewers to keep a high level of consistency between sessions.

In the future, we can easily keep track of the questions which have been asked to each candidate, to check – for instance – if weaknesses have been addressed since the previous review.

Also, we have introduced a face-to-face (via videoconferencing) meeting with Sophie and myself before the peer-to-peer review session, to meet the candidate in a more relaxed way and discuss informally about his certification related activities.

This meeting is not included in the existing review protocol (published online) but will be introduced in the new version released in June, which will become effective for the next peer-to-peer review session.

In June, most documents published on the certification website will be updated, based on the experience gained so far. In addition, other documents will be published, to improve the governance of the process.

Last, but not least, we are working at the first training session for third parties applying for certification.

The training has two objectives:

  • first, to teach candidates free software and related licenses, TDF governance, LibreOffice development and quality assurance,
  • second, meet the candidates face-to-face, and discuss their motivations to get LibreOffice certification.

LibreOffice certification is on its way to become a solid foundation for the ecosystem. The objective is to make it easier for certified professional to get rewarded for their competence, and for the value they can add to migration and training projects.

by italovignoli at May 25, 2015 08:00 AM

Matteo Campanelli

Text Chaining in Draw - Work Plan

Text Chaining = Text Sharing

In my last post I described what I thought were necessary properties of an implementation of text chaining. The following seems to be a natural consequence of those observations: given a chain of boxes, we need that editing in each of them is global to the whole text in the chain. We do not only need that changes in one single text box propagate through the other boxes, but also that any type of selection (and most other user actions) is extended to the text in the whole chain. For example, if the user presses Ctrl-a in any of the boxes in the chain we expect to see the text in all the boxes to be selected (instead of a "local" behavior that selects only the portions in the box in focus).

A Timeline

With this perspective in mind, here is an attempt for a plan of attack:

  • Week 1 (from May 25 to My 29): Experimenting. My goal is to have a pointer that moves seamlessly though boxes as if it were just the same box.
  • Weeks 2 & 3 (from June 1 to June 12):Make boxes share the whole text (paragraph-wise). We should have that behavior as selection should be global to boxes in the chain (adding and removing text? Maybe, that might be more complicated though). Also, we expect to have this with boxes having chunks of the global text that are whole paragraphs (since this seems simpler than more fine grained breaks).
  • Week 4 (from June 15 to June 19): Integrate overflow check and automatic transfer of text (paragraph-wise). We want editing in one box to propagate in real time in the others. Since overflow detection code from last year seems quite solid it might be feasibe to almost use it as it is. Breaks are still at level of paragraphs at this stage.
  • Weeks 5 & 6 (from June 22 to July 3): Make breaks occur at word level instead of paragraph level.

The week starting July 5 can then be used for cleaning up the code to integrate it in master andfix other problems that can show on the way. If this schedule holds, this leaves several weeks to work on hyphenation in the last part of this GSoC.

by matteocam at May 25, 2015 05:37 AM

Text Chaining in Draw - Drafting specifications

In this post I will describe some ideas on what we expect from chained text in Draw giving a high-level, pseudo code specification of it.
See my last post here for an overview of the problem.

It was all wrong

In my last post I described some of the necessary changes we wanted to get in the project this year. One of the main problems was that now text is moved only after the user exits from editing mode and the current implementation is only sensitive to edits occurring in the first box in the chain (if you delete content in a box in the middle of a chain, nothing is going to happen in the others).
In that post, however, I don't describe precisely enough what we want from a future implementation.

The expected behavior

The behavior we expect from chaining text in Draw is the same we have in Writer already implemented now: when user edits text (adding text, removing text, changing formatting and font size or whatever) in any of the boxes in the chain the implementation should:

  • restructure the whole text in the chain, i.e. redistribute appropriately the text among the boxes (I will call this process "spreading");
  • position the editing pointer at the right updated spot (e.g. if the user pasted some text overflowing in a next box the pointer should be in the latter at the end of the pasted text).

A high-level functional view of spreading

Currently I have no clue of how the mechanism above should be implemented in editeng, svx and the other modules responsible for text dynamics in LO Draw. If we wanted to idealize the process and LO internals, I would now like to propose the "only" two components we may need to achieve the result above. Notice that, for the time being, we want to understand the issue of what before even touching the problem of how, so I will make little or no consideration of efficiency or compatibility with existing architecture whatsoever. The description is in some kind of statically typed pseudolanguage, none of the data types I use refer to real data types in LO code.

The Spreader

Suppose the we have some text T0 already distributed, err... spread, among boxes in a logical chain of text boxes [b_1, b_2..., b_n]. Suppose now that the user edits it (e.g. pasting some content in the middle of it) and we get a new text T through the chain; consider T as the concatenation of the content of all the boxes. Assume that text objects T0 and T contain also information about formatting of the text, the box space it requires for fitting, paragraph breaks, etc... At the same time assume that each box object b_i contains info on their respective sizes.

<figure class="figure-code code">
Vector<Texts> spreadText(TextBoxChain Bxs, WholeText T)
{
  /*
  Given in input chain of boxes Bxs = [b_1, b_2,...b_n] and text T
  should return a vector of texts [t_1, t_2,... t_n] such that
  1) t_1, t_2 ...t_n give T if "concatenated" together
  2) each t_i fits inside box b_i
  */
}
</figure>

I hope the intuition behind the function spreadText is clear enough. The function that spreads the text does what you expect from it: assigns portions of the text to some box so that all fit within the box (let us assume that there is enough space for the whole content for now). Ideally, such a function could be used in the middle of the formatting loop somwehere in ImpEditEngine:

<figure class="figure-code code">
... // new editing has occurred yielding text T

newTexts = spreadText(Bxs, T)
// Replace T with newTexts
...
</figure>

It is an open question how plausible it is the code we'll write will actually look like that.

Moving the pointer

After spreading the text among the boxes we need to figure out where the editing pointer is now located. For example, suppose the pointer is at the bottom of the first box - say the tenth word in the paragraph - and the user now copies and paste two more words inside it making the text overflow. From a global perspective, the pointer is at the end of the pasted text (after the twelveth word) but where we want the pointer now is in the second box at the end of the first (or second, depending on where overflow occurs) box. Thus we need to be able to map from a "global" position to a "local" position in a specific box and one function like the one below can come handy. (Note for the attentive reader: as far as I remember, in editeng positions are not measured in "words", so take that just for sake of example)

<figure class="figure-code code">
Pair<TextBox, TextPos> global2localPos(TextBoxChain Bxs, WholeText T, TextPos globPos)
{
  /*
  Return a pair (b_j, locPos) such that if
  [t_1, t_2,... t_n] = spreadText([b_1, b_2,...b_n], T)
  then globPos in T corresponds to locPos in t_j.
  */
}
</figure>

One building block from the other

It seems intuitive to me that the spreading function as described above can be implemented (inefficiently) using global2localPos:

<figure class="figure-code code">
Vector<Texts> spreadText(TextBoxChain Bxs, WholeText T)
{
  foreach word w in T:
        posOfWrd = getStartPos(w,T)
        (bx4w, _) = global2localPos(Bxs, T, posOfWrd) // Haskell-like pattern syntax (we ignore _)
    // Assign w to bx4w
}
</figure>

So are all problems solved?

Obviously not. There are still a million questions to be answered (and as many to be asked), among which:

  • what would "WholeText" and "Text" look like in editeng? We need to work at the level of words but many classes in editeng might work at the level of paragraphs.
  • as a related question to the previous one: Can we break and recombine paragraph objects easily?
  • Do we have all the information on sizes of text and boxes readily accessible somewhere in the code?

by matteocam at May 25, 2015 01:52 AM

May 24, 2015

Michael Meeks

2015-05-24 Sunday.

  • Up late; read news, watched fascinating SpaceX GPU compute talk. J. and babes home in the afternoon; nasty cellulitis infected bite in leg - hmm. Out to Histon Baptist church for an afternoon service; pizza; bed early.

May 24, 2015 09:00 PM

Andreas Mantke

New LibreOffice Extensions Site Theming

I’m currently working on fixing some HTML validation issues in the development of the new LibreOffice extensions and templates site. Alongside I started with a new design from scratch. Therefor I created a new Diazo theme inside my local Plone development environment, that strips the full stack of Plone stylesheets and reset the styles of HTML tags. The output is like in my first screenshot:

newextensionssitewwithoutcss

I’ll add some styles to the Diazo theme in the next days, thus it will get reformatted and really usable (something like in the follwing screenshot).

newextensionssitewwithcss

If you want to join me in this process and you have good knowledge in HTML and CSS and webdevelopment in general, please send a mail to the LibreOffice website list: website@global.libreoffice.org

by andreasma at May 24, 2015 08:34 PM

May 21, 2015

Official TDF Blog

First LibreOffice 5.0 Bug Hunting Session starts Tomorrow

Berlin, May 21, 2015 – The first LibreOffice 5.0 Bug Hunting Session starts tomorrow at 08AM UTC, to catch bugs and regressions on the first beta of the software, available from this link: http://dev-builds.libreoffice.org/pre-releases/. The session will last until May 24, 2015.

On those dates, mentors will be available from 08AM UTC to 10PM UTC to help less experienced volunteers to triage bugs, on the QA IRC channel and via email on the QA mailing list.

Those who cannot join during the bug hunting session are always welcome to help chasing bugs and regressions when they have time. There will be a second bug hunting session in June, to test LibreOffice 5.0 Release Candidate 1.

More detailed information on the bug hunting session are available here: https://wiki.documentfoundation.org/BugHunting_Session_5.0.0.0.

LibreOffice 5.0 will be released at the end of July 2015.

by italovignoli at May 21, 2015 02:11 PM

May 20, 2015

Official TDF Blog

Behind the scenes at TDF: Localization and Native-Language Projects

Sophie Gautier has been a member of the OpenOffice.org project since its beginning, and then a founding member of The Document Foundation and LibreOffice. She is extremely active in the Francophone and international community, and is a staff member of The Document Foundation. She takes care of the French translation of LibreOffice (interface and help), is a member of LibreOffice certification committee and is a leading member of the quality assurance project.

2015 is more than ever a year packed with exciting projects and ideas around LibreOffice and The Document Foundation, so we want to continue our behind-the-scenes series, to share achievements with our community and our generous donours, to whom we’d like to express our sincerest gratitude and thanks for their incredible and wonderful support and their invaluable contributions!

The localization team has been very busy translating for the 4.4.x version, a lot of dialogues have been modified, so thousands of strings were touched, moved and need to be translated and validated again.

The L10N team had an important discussion on the workflow and the current workload due to changes on the sources, whether they are needed or purely cosmetic, which resulted in several decisions. The first is that the teams willing to work on master will have a new Pootle project reflecting the changes done there. It will be merged once a month and the template will be updated in Pootle accordingly. This allows us to check the strings much earlier and revert eventually unneeded changes. The teams wishing to work at the branch levels will still be able to do so.

To be able to reach out to developers more quickly and get a better communication between the teams, I attend and report the L10N activities and needs to the Engineering Steering Committee, by attending the weekly calls. For example, the request to have a mechanism that handles the localization of the templates will be provided for 4.5 and strings will be uploaded on Pootle.

The migration to the new Pootle version is going on. We are closely working with the Pootle team to get this done smoothly and to have the whole set of features the L10N team needs. The Deckard addendum will be the next step.

A cross work between the documentation and translation projects has been brought up by Milos Sramek from the Slovak community. They have developed a whole workflow to translate the user guides and to maintain them. After some tests in different languages, we have decided to use it for the whole project and document it on the wiki. This is handled via the OmegaT Project feature and we use the LibreOffice GitHub repository to manage revisions in the .ODT file, which turned out to be really time saving and reducing errors – even if the first work is important, it allows afterwards to only handle modifications needed by new LibreOffice versions. If you are willing to use this workflow for your own translation projects, even if it’s another LibreOffice writing, don’t hesitate to contact us either on the documentation or the L10N list.

Some new languages added to Pootle during the first quarter are: Guarani, Nahualt, Tigrinya, Pashto and a new contributor who will work on Tatar, which was stalled for the moment. Welcome to all of them, keep up the good work, guys!

It is a bit early, but let’s already talk about what L10N and NLPs wanted to discuss during the LibreOffice Conference. I am very happy to see that we will have a large group representing the teams this year! :) If you are active in the L10N or NLPs groups and wish to attend, don’t hesitate to come back to me via e-mail and have a look also at the conference website. We will have workshops, discussions and presentations sharing our experiences, difficulties, tips & tricks, but the most importan,t we will be altogether in the same room :-) If you can’t attend, don’t feel sad, we will try to organize a hangout and an IRC chat as well.

TDF has also been a supporter of the Document Freedom Day, an event that will be followed by several groups all over the world. I’ll report about it next quarter. The Brazilian team has launched the 15th edition of its magazine. The Japanese team is, as always, organizing several events, trainings and mentoring during this quarter. Don’t forget to have a look at our calendar to follow the activities and perhaps meet a team exhibiting near your place.

by italovignoli at May 20, 2015 07:22 PM

>Marius Popa Adrian

Timo T gameplay video no #2

We have worked some more on our game, still have some work to do, but we do hope that we'll have a demo in a week or 2 (fingers crossed)... Until then enjoy the new video... We will gladly reply to each of you that comes with Feedback, questions and suggestions. Who knows maybe You'll give us some great ideas! http://www.indiedb.com/games/timo-t/videos/timo-t-gameplay-21

by Adrian Marius Popa (noreply@blogger.com) at May 20, 2015 06:14 AM

May 18, 2015

>Marius Popa Adrian

Firebird PHP Web Admin with Bootstrap 3.x

Here is one screenshot with new Firebird Web Admin interface Compare with previous version

by Adrian Marius Popa (noreply@blogger.com) at May 18, 2015 08:24 AM

Miklos Vajna

Protocols Plugfest Europe 2015

(via plugfestcon)

Last week I went to Zaragoza to give a talk on how LibreOffice handles interoperability at Protocols Plugfest Europe 2015 on Tuesday. Although I was told this conference is a successor of the previous Zentyal Summit (and I were not there) the conference seemed well-attended — proof above. :-)

Jacobo also gave a LibreOffice-related talk on Wednesday.

On the same day, there were some explicit spare time, so I took the opportunity to walk in the historical parts of the city, see my photos and a panorama if that kind of pictures are of your interest. FWIW, Hotel Sauce has free wifi in the rooms, that’s kind of impressing for a two-star category. ;-)

As usual, thanks Collabora for sponsoring this travel!

May 18, 2015 05:54 AM

May 16, 2015

Caolán McNamara

crash testing, 1 import failure

moggi described here our crash testing infrastructure. Basically we have a document horde mostly populated through get-bugzilla-attachments-by-mimetype which downloads all the attachments from our bugzilla (and a whole bunch of other bugzillas) that are in formats which LibreOffice can open. We then import the lot of them with the above testing harness looking for crashes and aborts. A new report tends to appear every 1-3 days.

These documents are filed in bugzillas. In many cases they were filed specifically because they were causing some sort of trouble for someone, so there are a lot of hostile documents in there.

We currently have 76221 documents in the horde, the most recent run reports one, one single solitary failure (an assert in a .doc about invalid positioning of a cross-reference bookmark in a document with change-tracking enabled).

Here's a graph over time of our failure rate. Where failure is either a straight forward crash, or a triggered assert. The builds are dbgutil, extra-debugging, extra-checking, assert-enabled, exception-specification-enabled builds.


You get temporary local peaks every now and then when either a new assert is added or someone introduces a bug. We have two purposes here, immediate regression discovery and historic bug removal.

We also have export crash testing, where the numbers aren't as shiny yet, but are on an equivalent downward trend. More on that in a while when we figure out how to fix this final import stinker.

by Caolán McNamara (noreply@blogger.com) at May 16, 2015 08:01 PM

Matteo Campanelli

A Prototype for Dynamic Text Flow - An Overview

In this post I describe part of my project for GSoC 2014: automatic flow of text from one box to another in Draw/Impress. I outline some of the current features and limitations and describe future developments.

An Overview of Dynamic Text Flow

Imagine having a text box containing too much content for its size. In some documents it is not possible or convenient to solve the problem resizing the box or the font. In these situations we may want the overflowing text to move to some other area in the document, such as another text box logically linked to the overflowing one.

To have a concrete idea of the kind of behavior we expect, look at the following screenshots from one of the latest versions of the prototype (written during GSoC 2014).
When the user enters too much text for a single box this is automatically distributed among the others until it fits (or until there are no more boxes to fill). Notice that (currently) the text is redistribited paragraph-wise: each box receives as many paragraphs as it can contain - in this case one per box. Also notice that the rightmost box in the second screenshot is filled because the second and third paragraphs, once moved from the leftmost box, do not fit completely in the central text box; thus chaining occurs recursively.

While the user is still editing the content is shown as overflowing.

The text distributes itself automatically after editing.

A more desirable behavior: beyond the tiranny of paragraphs and "editing mode"

The screenshots above give an idea of what the current prototype does, let us now look at some of possible improvements. There are two major flaws in the current implementation:

  • text cannot be broken at arbitrary locations, only at the end of paragraphs;
  • user has to stop editing to see results.

We would like that text could be automatically moved anywhere between two words, not only between paragraphs. Also we would like such "automatic transfer" to occur seamlessly in real time (Writer, for example, implements such behavior), not only after editing is done. This is a serious problem both because it reduces the WYIWYG-ness for the user (who has to stop and check her results every once in a while) and because it complicates the design of the feature increasing the number of questions to be answered; all these questions hardly have a sensible answer from a UX point of view: should the whole text appear only in the first box (as it is the case now)? If yes, then shouldn't the next logical boxes be special and should not be editable?

The main goal of my GSoC 2015 project is to achieve the two properties above. As a starting point on deciding how to build them, I will now get back to the current implementation describing what it does under the hood.

Current prototype: a skeleton

The following is a overall scheme of how the current implementation works. The reader will notice how the general idea is extremely simple.

When user is editing: keep track of whether (and at which paragraph) the text exceeds the box size.

When user is done with editing: when creating "non-edit-mode" text of the box, if overflows occurred:

  • "cut" the overflowing paragraphs from text in current box;
  • set the overflowing paragraphs as text in the next logical box and recursively call checks on overflows.

Conclusions

The current prototype for text chaining should be modified to handle between-words breaks and real-time modifications. Going in this direction will require abandoning a good part of code written last year (or at least the approach outlined above).
Next steps:

  • finding out how to test for overflow by words only; currently complete paragraphs are used to test for overflowing content.
  • finding out how to possibly modify content of text boxes in real time; current code depends completely on the user exiting editing mode.

by matteocam at May 16, 2015 04:00 PM

May 15, 2015

Caolán McNamara

gtk3 native theming menubar

After something of a struggle I appear to have the right gtk3 menubar theming combination for the selected item now after image...

before image...

by Caolán McNamara (noreply@blogger.com) at May 15, 2015 04:29 PM

May 14, 2015

Caolán McNamara

more gtk3 theming

Continuing on the Gtk3 theming work. Now got the combobox and editbox rendering and sizes correct along with new gtk3-alike focus rectangles. Here's the after...
Here's the before of what the gtk3 effort looked like in 4-4
Here's the equivalent 4-4 gtk2 effort. Note that now in the above gtk3 theming we have a single focus rectangle for the full combobox rather than a focus rectangle around the non-button part of the widget and that, as in a normal gtk3 combobox, the background isn't set to blue when selected. I always hated that out of character blue listbox/combobox selection color. So certain elements of the gtk3 theming now slightly surpass the gtk2 one which is nice. Though clearly the spinbuttons are still effectively imaginary ones as they look nothing like the native gtk3 ones.

I also fixed (for both gtk2 and gtk3) that notorious checkbox issue where unchecking a checkbox would leave a portion of the check still drawn outside the checkbox rectangle.

by Caolán McNamara (noreply@blogger.com) at May 14, 2015 07:56 PM

May 13, 2015

Joel Madero

MSO 2013 Template Interop Project

Hi All,

Ever wanted to get involved with LibreOffice but not sure how? Well – here’s a nice easy way to do just that.

Goal: Improve interoperability with MSO 2013 templates

What is Needed:

  1. Microsoft Office 2013
  2. Daily build of LibreOffice (dev-builds.libreoffice.org/daily/master/)

Instructions: https://docs.google.com/document/d/1Vdf5qkGg9H6V6IXJ9zK2P7xDOaSkriEwylgAIDV1_Mw/edit?usp=sharing

Organization: https://drive.google.com/folderview?id=0B5S-XtOUGGH5fnVCME91X3BfX08zWGswOWNjaUl2RVE4UE1MYXFLVFAxLTRvSjdjWm9lU1E&usp=sharing

Reporting Identified Bugs: 

  1. Create account at http://bugs.libreoffice.org/
  2. Click on File a bug;
  3. Select LibreOffice;
  4. Component = Calc, everything else leave as is;
  5. For bug comment:
    1. Provide clear and enumerated steps on how to reproduce;
    2. Upload pdf of what the file should look like;
    3. Make sure to include your operating system and version of LibreOffice

Example of Good Bug Report: https://bugs.documentfoundation.org/show_bug.cgi?id=91267

This is a really easy way to contribute back to the community and an area that will lead to substantial improvements in the project. Contact me:

  • Leave a comment on the blog;
  • Email me;
  • Find me in our chat: http://webchat.freenode.net/?channels=libreoffice-qa

by joelmadero at May 13, 2015 08:05 PM

May 11, 2015

Jacobo Aragunde Pérez

Speaking at Protocols Plugfest 2015

In a couple of hours, I will go to the airport and head for Zaragoza, where I’m taking part of the Protocols Plugfest 2015 happening this week.

Protocols Plugfest 2015 logo

Igalia will contribute a speech about LibreOffice interoperability with ECM solutions, specially SharePoint, through the CMIS protocol.

See you there!

EDIT: The plugfest is over! Thanks to everyone attending. By the way, I couldn’t help doing some changes to the slides the night before the talk; I’ve updated the link above.

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

by Jacobo Aragunde Pérez at May 11, 2015 08:03 AM

May 07, 2015

Collabora Community

Spread the word: LibreOffice Hackfest Cambridge

Two weeks today on May 21st LibreOffice enthusiasts from around the world will converge on Cambridge for the first ever UK Hackfest. Hosted at Collabora’s headquarter offices, engineers, designers, translators, and first-time contributors will work together on the world’s most popular Open Source office suite over a three day sprint.

The Cambridge Beer Festival

The Cambridge Beer Festival coincides with the LibreOffice Hackfest

Use the printable poster below to tell your colleagues and classmates about the event, and encourage them to participate. Hackfests are the perfect opportunity to get familiar with LibreOffice for the first time — expert engineers will be happy to help you get started and solve problems together. High resolution A5 size PDF and PNG files are available, as well as editable Gimp source files.

Poster advertising the Cambridge Hackfest

Poster advertising the Cambridge Hackfest

Full details of travel, accommodation, programme, and more can be found on the dedicated Document Foundation Wiki page. See you in Cambridge!

by Sam Tuke at May 07, 2015 11:26 AM

May 06, 2015

Collabora Community

LibreOffice, Collabora, and Partners at openSUSE Conference and Kolab Summit

Last weekend over a hundred Linux experts and contributors gathered in The Hague for the annual openSUSE conference. Collabora’s Michael Meeks presented the latest developments in LibreOffice, including a live demo of the cutting edge document editing features in LibreOffice for Android, and an introduction to the backend architecture of LibreOffice online.

Attendees at openSUSE Conference 2015

Attendees at openSUSE Conference 2015

Michael Meeks presenting in the Hague

Michael Meeks presenting in the Hague

Between talks on subjects such as community building, power management, and cloud infrastructure, Document Foundation Committee Member and Collabora partner Cor Nouws offered information and advice to attendees from his conference booth, and shared infographics and promotional materials. As a leading member of the Document Foundation’s Dutch Team, and Director of local LibreOffice training and services firm Nou&Off, Cor was ideally placed to field the crowd’s questions.

Booth with Cor Nouws

Booth with Cor Nouws

The event was run jointly for the first time this year, sharing a venue with the inaugural Kolab Summit. Hosted by Kolab, an Open Source Groupware application, the two days of talks ran parallel with the openSUSE Conference, and Michael contributed his second talk of the weekend titled “Producing business: driving development of LibreOffice-from-Collabora”. A video of Michael’s talk is being prepared and should be available in the next few weeks.

by Sam Tuke at May 06, 2015 01:52 PM

May 05, 2015

Caolán McNamara

new area fill toolbar dropdown

The GSOC 2014 Color Selector is in LibreOffice 4.4, but it's not used for the "area fill" dropdown in impress or draw. So I spent a little time today for LibreOffice 5.0 to hack things up so that instead of using the old color drop down list for that we now have the new color selector in the toolbar instead. Gives access to custom colors, multiple palettes, and recently used colors all in one place.
LibreOffice 5.0
And here's the old one for reference, I've backported the above change to Fedora 22's 4.4.X to address some in-house vented frustration at selecting colors in impress.
LibreOffice 4.4


by Caolán McNamara (noreply@blogger.com) at May 05, 2015 07:46 PM

May 03, 2015

Miklos Vajna

MathType import in the RTF and DOCX filter

TL;DR: Import of old-style (pre-2010 for RTF, pre-2007 for DOCX) math equations embedded into text documents should be now imported as editable embedded math objects.

Longer version: if you want to embed math equations into RTF or DOCX files, you have two choices. The older approach is to embed a MathType OLE object into the file, the newer one is a native OOXML markup, which has an RTF markup equivalent as well. Handling of the later has been implemented by Luboš Luňák for DOCX a long time ago, and I contributed the RTF equivalent almost 3 years ago.

What remains is the handling of the older version, the embedded OLE object. Previously only the replacement graphic was imported, so regardless of the Tools → Options → Load / Save → Microsoft Office → MathType to Math checkbox, the result was never editable.

Here is how it looks like now:

https://lh3.googleusercontent.com/-V3SqO3Rz88s/VUZvFcBNMPI/AAAAAAAAFb4/QARDYqQVQGY/s0/

Given that the RTF and the DOCX importers share lots of code in the writerfilter/ module, I implemented the same for the DOCX import at the same time, too. The interesting challenge was that writerfilter wants an XFilter implementation for the embedded object if it is to be handled internally by LibreOffice, but the MathType filter (originally created to handle math objects inside binary DOC files) didn’t have one. Once I implemented such a filter wrapper, the rest wasn’t too hard.

Here are test documents if you want to try it yourself. You’ll need a 5.0 daily build for that, though. ;-)

If I’m at describing features new in LibreOffice Writer 5.0 file filters, here are a few more:

And a number of bugfixes for the RTF filter:

  • tdf#86182 better RTL paragraph handling

  • tdf#80708 related to the improved old-style Writer table export handling work

  • tdf#90421 hyperlink export tweak

Do these sound interesting? Look at what others did for LibreOffice 5.0 on the TDF wiki, even if it’s far from complete, as the 5.0 branch is not yet created. :-)

May 03, 2015 07:15 PM

Andreas Mantke

Further Work on the new LibreOffice Extensions-Template Site

I worked a bit more on the search feature for the new LibreOffice extensions and templates website. I added text indexing features to some more form fields of projects. After updating the test  website with my git commits running buildout I had to clear and rebuild the catalog of the website. It’s possible to search for strings now within the form now.

There are some todos left to move to the new website, e.g. a new website theme based on the Diazo theming framework.

by andreasma at May 03, 2015 04:26 PM

May 01, 2015

Charles Schulz

Numbers & Names

When the Document Foundation announced its release policy, few people besides IT professionals understood why we were telling people about two distinct stable branches for LibreOffice. The truth is, not only do many FOSS projects share this kind of release policy, but software vendors producing proprietary software often have very much the same kind of release structure. At the beginning of the LibreOffice project, you had to pay attention to which branch each new release was belonging to. It wasn’t unclear as you could look it up on our wiki, but it wasn’t something that could be found right away for anyone in a hurry or lacking enough self-confidence to search for the right information in the right place.LibreOffice_external_logo_200px

The Marketing Team at that time came up with the idea to add to the existing numbering schemes a name or an attribute so that each branch would be immediately identified. We first came up with “Stable” and “Fresh”, then we arrived to our present situation with “Still” and “Fresh”. It may be useful to add that besides these the stable releases of each of these two branches, there are release candidates for each releases, as well as betas and nightly builds for anyone to grab, run and test.

LibreOffice started with the 3.3 release; it then added micro releases with a third number next to the first two digits. As time went forward, so did the releases: 3.4.0, 3.4.1, 3.5.0, 3.5.1, onwards to the 3.6 branch, the last one to carry the number 3 as its major release number, and to the 4.0 and the 4.x.x based releases. This summer we will be releasing the 5.0, and you will hear a lot more about the changes and improvements that are being put into it. But when you think about it, we started our version numbering exactly based on the one of OpenOffice.org . In 2010, it meant something technically and something for the community and more broadly the users of OpenOffice.org and LibreOffice. Fast forward to 2015: does anybody really know what a “4.3” release mean? What message does this numbering scheme convey?

10947544804_f573450e48_zIt may be time to consider other numbering schemes, keeping in mind that these wouldn’t affect either the name of each branch, nor would it change anything to the actual release policy. But what scheme? Do wo use the year and the month? Do we start off with a completely new set of numbers with a coherent meaning? Do we blend the year and a series (like Ubuntu)? Or do we make it very simple to the point of being confusingly simple and only use one number that would change with each release (like Fedora) ?

Numbering schemes may seem utterly useless especially when the two branches of LibreOffice tend to be advertised even more than the version numbers. But let’s not forget that these numbers describe a technical reality, not just a chronological one. The 4.3.7 comes last in the 4.3 series; it is also the one that has received the most patches in these series; its younger counterpart, currently in Fresh branch, is the 4.4.2 offer just the same level of bugfixes and patches, but has other, more recent improvements and features the 4.3.7 simply do not offer.

This question is not a petty one; it is rather important, but should also convey meaning for as many people as possible. This is only the beginning of the discussion; and I know neither its outcome nor its end. Be it as it may, it is going to be at the same time probably exhausting and exciting at the same time: in these matters, it is hard to be completely right or wrong.

photo by Andy Maguire, “Numbers”.

by Charles at May 01, 2015 01:59 PM

April 30, 2015

User Prompt

Libreoffice Human Interface Guidelines: First steps

The work on usability and design is often seen as some kind of anarchistic creativity: some people receive divine inspiration out of the blue and read tea leaves to decide how features have to be implemented. But that’s not true. Both the creative work on visual design as well as the composition of an effective and efficient user interface is hard work based on axioms. Those fundamentals are “written in stone” by Human Interface Guidelines (HIG) with the objective to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.

lo_logoThe Libreoffice project identifies with Mozilla’s generic UI principles and refers to Gnome as its guideline for controls. Furthermore, some rough ideas were collected on the whitepages. At this point we want to restart HIG.

All usability work starts with artifacts that guides through decisions. Those artifacts consist first of all of the vision which describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Next artifact (or rather usability method) is the persona. It represent the average user, ideally based on empirical data, and provides thereby a common understanding among the design and development team. Last but not least we want to state a user experience manifesto that prioritize UI principles.


 Vision

LibreOffice on Desktop UX goal: Simple for beginners and powerful for experts.

  • Novices can start to work with LO without the need to read a manual
  • In every situation the user is confronted with only a few options – but can get all on demand
  • Experts will have access to all functionality
  • Full access keeps usability first but might need some training

Persona

Primary (Beginner)

CC0 Public Domain http://pixabay.com/en/laugh-boy-young-people-young-pink-412038/

Primary persona Benjamin

Benjamin is a 17 year old boy who goes to secondary school. He just started to do his home work with LibreOffice since it has been required by his school. As a beginner he expects to write text and to create presentations as on paper. He doesn’t know about themes, styles, templates, and formatting. He knows how to browse internet, play games, and use tablet & phone. He hates to do home work and to work with a desktop PC. His goal in general is to do stuff as fast as possible, accuracy is not his major concern. To solve problems he neither would read documentation nor use an trial and error approach. Things that cannot be done immediately and out of the box will not be done at all.

Primary (Expert)

CC SA http://en.wikipedia.org/wiki/Lupita_Nyong'o

Primary persona Eve

Eve is 34 years old, single, vegetarian, pacifist, and open-minded in technology in general. She works as an executive secretary in an NGO for animal rights. She studied economics and sociology. During her studies she used Open Source, and understood the attitude & community culture. Her duty is to summarize and publish studies, to request and write reviews, and doing the accounting. Cooperation is an important aspect of her work.

Secondary (Admin)

http://commons.wikimedia.org/wiki/File:US_Navy_020614-N-0552D-001_SPAWAR_award_winning_employee.jpg

Secondary persona Adrian

Adrian is 40 years, married, two children, living in the suburbs, with a technical college education having a BA in computer science. He works as an IT expert at a company that has transferred from Microsoft Office to Libreoffice. He is responsible to keep the system running including all networking (printers, storage, backups), to provide all workstations with templates for corporate identity, and to install updates. He evaluates early versions, works with the QA team, and files bugs. Personally, he doesn’t use Libreoffice on a daily basis.

UX Manifesto

The ISO 9241-110 defines seven principles for usable interaction design:

  • Self-descriptiveness (the dialog should make it clear what the user should do next)
  • Suitability (the dialog should be suitable for the user’s task and skill level)
  • Controllability (the user should be able to control the pace and sequence of the interaction)
  • Familiarity (the dialog should be consistent with user’s expectations)
  • Learnability (the dialog should support learning)
  • Individualization (the dialog should be able to be customized by users)
  • Robustness (the dialog should be forgiving)

Libreoffice focuses on:

  • Simplicity by default with full functionality on demand
    Every processing has two ways of access: a very simple way with the core features only and an advanced way with all features
  • Consistency over Efficiency
    Users should feel familiar with all tools rather than having specialized apps.
  • Usability over Graphical Design
    Form follows function, Libreoffice respects the OS theming.

In general,

  • Follow general design principles (https://wiki.documentfoundation.org/Design/Principles)

Next steps

Of course nothing is written in stone. We explicitly ask you to comment. Can you identify yourself with the vision? Do you agree with the personas? Finally it would be great if you make use of the artifacts. For instance, arguing pro or con a new feature is much easier when you refer to Benjamin or Eve because of the empathic abstraction from yourself.

The next steps for the design team are to add guidelines for controls and pattern. Of course the HIG should be the first place to go not only for usability experts but also developers, and the localization and documentation team should also be interested in consistency.

by Heiko Tietze at April 30, 2015 09:57 AM

April 22, 2015

Collabora Community

Interview with Jennifer Liebel and Tobias Madl from Munich

Last summer, German students Jenny and Tobias started a work placement organised and funded by the City of Munich. One of the most famous Linux deployments in the world, Munich began switching to Free Software across its desktop and server infrastructure in 2003, and completed the process ten years later. LibreOffice is included on all desktop computers, and the City manages its own development of the application, including training students on placements.

Tobias and Jenny talked with Sam Tuke about how they sped up LibreOffice significantly by reorganising its internal task management, with the help of their Mentor Michael Meeks, and the LibreOffice community. This work is a foundational technology for future improvements to our rendering model, converting it from immediate to deferred (ie. idle) rendering, which is necessary to get smooth double-buffered rendering without flicker. It’s great to see the investment from Munich improving the LibreOffice user experience for all.

Tobias and Jenny - students in Munich

Tobias and Jenny – students in Munich


About Jenny

  • Name: Jennifer Liebel
  • Web nicknames: jeyli
  • Nationality: German
  • Location: Munich Germany
  • Blog: Google+
  • Hobbies: personal fitness

About Tobias

  • Name: Tobias Madl
  • Web nicknames: tobaem
  • Nationality: German
  • Location: Neufahrn bei Freising, Germany
  • Blog: Google+
  • Hobbies: sword fighting, bouldering, fire fighting

When was your first LibreOffice contribution?
In August 2014, while completing a work placement with the City of Munich (Landeshauptstadt München), we started working on some LibreOffice ‘Easy Hacks‘; translating German comments into English, and working on automated quality checks with CppUnit tests. Around 20,000 city-owned computers run Linux, and LibreOffice comes pre-installed with the Limux distribution of Linux that they use. In our work placement we had the choice of what to work on, and we chose LibreOffice.
For the next seven months we worked on LibreOffice consistently.
Had you used LibreOffice before that?
Yes we were using it at University for coursework and presentations. It has all the features we need. Later on, Tobias presented his talk at FOSDEM using LibreOffice Impress.
When we began our Computer Science studies we started using Linux because it made software development easier. We chose Linux Mint, and as LibreOffice came bundled with it, we started using it.
How do you explain LibreOffice to others?
It’s an awesome alternative to Microsoft Office and if people don’t want to waste their money, they should definitely try it.
Do your fellow students use LibreOffice too?
Yes, many. Maybe even most of them. Mainly it’s used for presentations and text documents. Students here don’t get provided with a copy of Microsoft Office like at some universities, and many use LibreOffice instead. A few use Latex. Students here use LibreOffice on all operating systems.
What was your initial experience of contributing to LibreOffice like?
It was exciting and challenging: we were using new tools for the first time, like the Gerrit review platform for managing LibreOffice code contributions. Getting used to these tools was a lot of fun.
How did you choose what part of LibreOffice to work on?
We were members of a group of five students whose placement focused on LibreOffice. We worked on different parts. We were both lucky enough to be invited to the LibreOffice Conference in Bern, where we met Michael Meeks who works for the Document Foundation and Collabora. It was a fantastic event, and he proposed tasks that we could work on, and became our mentor.
One of the hardest options proposed was improving LibreOffice’s "main loop". This loop executes the most important actions that LibreOffice needs to start up and run itself, including loading macros, generating previews, updating menus, and more. It sounded demanding, and we both wanted to learn as much as possible, so we chose that.
Together we went through every single timer used in this loop, and invented a new task scheduling system, which manages the loop more efficiently. The list of tasks in the loop is huge; we wrote them up in documentation of our work on the Document Foundation Wiki. We planned and developed the new scheduler together to prioritise important tasks and drop some which were unnecessary.
Optimizing the main loop has been a huge and interesting task. We’ve learned a great deal, and are still improving the quality of our code.
How did you make decisions and distribute the work?
‘Scrum’ is an agile software development methodology that we used to organise our work. We had regular stand-up meetings, did paired programming (especially for harder tasks), and generally worked in the same space for easier communication.
Michael was in England, while we were in Germany, so we had video calls and communicated via email.
What was it like to be mentored?
Working with Michael was demanding but awesome, great to meet and get to know him. He’s very motivated! We had a few communication issues because of distance, and time available, but he was very helpful. He reviewed our code, gave us tips and direction, he spent a lot of time with us on our project.
Did you communicate with other LibreOffice community members?
Markus Mohrhard and Jan "Kendy" Holesovsky helped us a lot when we were starting out with setting up our working environment, and teaching us how to debug code efficiently with the GDB debugging tool.
Building LibreOffice binaries from source code on our own machines was easy thanks to the great documentation, but building a good development environment with the right Vim editor plugins was harder. We went to a LibreOffice/Debian Hackfest and were shown how to do it in person, which was really useful. Kendy also explained the purpose of other LibreOffice libraries that we didn’t understand which clarified things a lot.
Every day we were in the #LibreOffice IRC Chat channel talking with Kendy, Markus, Thorsten Behrens, Stephan Bergmann, Noel Grandin, and others. We had an opportunity for lots of chatting with nice people online, and then met many of them at the FOSDEM conference.
Caolán McNamara was also reviewing our work at the end of our placement, and we were very happy there was someone looking over our code because it was our first time merging code using Git for version control. We’d also like to thank Miklos Vajna, Michael Stahl, Tor Lillqvist, and Bjoern Michaelsen for helping us and reviewing our work.
Once we started chatting with people we felt accepted as part of the LibreOffice community. We were just some students, but people made time to help us.
Had you contributed to Free Software before your work on LibreOffice?
No, this was our first project, but we are thinking about contributing to other projects, maybe the Kodi home theatre application.
What aspect of LibreOffice do you like the most?
Clearly the friendly and open community, which supported us a lot. We had great fun with them.
What the one thing you’d like to change about LibreOffice?
Improve OpenGL support (hello Michael Jaumann, Stefan Weiberg 😉 ).
Michael Jaumann, a close friend of ours, developed OpenGL support for LibreOffice Impress. It was really awesome to get to know how that worked. We’re developing OpenGL shaders in another part of our Computer Science course, and we love it. It’s got so much potential. There are still some issues with implementing full-scale support in LibreOffice due to its use of some older APIs; it’ll be great when those are fixed.
What will you do after your studies?
Jenny: As part of our course commitment, we have to work for the City of Munich for three years after our degree. The City has a large IT department catering for most of its own technical needs, including software and hardware development, and sub-departments dedicated to Java applications, network infrastructure, and custom development workgroups. Our work placement was with the Linux Desktop branch, which caters to the many thousands of City staff using Linux in Munich and the region.
I’m not sure; I’ll probably stay in Munich. Let’s see after three years!
Tobias: I’m definitely interested in software development, but also in information security and embedded development. I’d like to work in a company in one of those fields, or even better a mixture from all of them, but I’m not sure if something like that exists.
Both: You can read more technical details about our work in the Document Foundation Wiki report.

by Sam Tuke at April 22, 2015 05:00 PM

April 21, 2015

Collabora Community

LibreOffice for Android: prototype editor preview

Contents

  1. Suite improvements
  2. Under the hood
  3. Reaching out
  4. Joining in

A continuous effort

Since January, Collabora’s engineers have been working on the next generation of LibreOffice for Android: a fully functional mobile office suite, running natively, ready to edit rich documents. Thanks to Document Foundation sponsorship, we’ve spent the last three months working intensively towards this vision. Today we’re delighted to present a new prototype with spreadsheet, slideshow, and text editing built-in.

Writer: formatting text

Writer: formatting text

Calc: selecting cells

Calc: selecting cells

Suite improvements

Like LibreOffice Desktop, LibreOffice for Android has separate components for different types of task. On Android, we include Writer, Calc, Draw, and Impress.

All components of the the prototype benefit from the following features:

  • Text editing with on-screen keyboard
  • Simple text formatting with bold, italic, underline and strikethrough
  • Text selection by touching and holding part of a section of text (aka ‘long push’)
  • Easy resizing of shapes and images by tapping them to select, then dragging one of eight directional handles and releasing
  • High quality rendering of a wide range of filetypes, including Open Document Format, OOXML, and MS Office file formats (both binary and rich text format)
  • One tap access to the on-screen keyboard for quickly switching between viewing and editing mode
  • Smooth scrolling between pages

In addition to these, each component has its own distinct features.

Writer

  • Document saving support, updating the originally opened file by default
  • Support for movable embedded images, drawings, and shapes

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="469" src="https://www.youtube.com/embed/3mkN8i85vrU?feature=oembed" width="625"></iframe>

Calc

  • Touch-triggered selections of table and spreadsheet cells flows across columns, rows, and pages with the drag of a finger.
  • The “parts” sidebar switches between spreadsheets within the document

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="469" src="https://www.youtube.com/embed/fWGMW1V8WYA?feature=oembed" width="625"></iframe>

Draw

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="469" src="https://www.youtube.com/embed/U7TbP9CSS90?feature=oembed" width="625"></iframe>

Impress

  • The “parts” sidebar shows a scrollable overview of all slides
  • User interface interaction and overlays are now far more accurate

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="469" src="https://www.youtube.com/embed/xdphYds9fYU?feature=oembed" width="625"></iframe>

Under the hood

Powerful internals

The editor consists of two parts: LibreOffice core compiled for the Android platform, and a Java component that is responsible for the user interface. They interact with each other via LibreOfficeKit — a thin C++ library that allows any application to access LibreOffice’s powerful internals via a consistent interface.

All three parts (LibreOffice core, LibreOfficeKit, and the Android interface) have been extended to enable them to handle user-specified selections, cursor placement and movement, and commands like loading a document and applying formatting. The signals we’ve implemented make way for other LibreOffice-powered applications to support editing too.

Input and interface accuracy

  • Highlighted text selections can include table contents, allowing for formatting of contents of multiple document sections simultaneously. Previously selections used different internal identification systems and had to be selected separately.
  • All Impress interaction data has been ported to TWIPs — or ‘twentieth of an inch points’, from millimetre based measurements, resulting in much finer internal measurements, and improvements to display and selection for all versions of the application.

Impress: slide overview in sidebar

Impress: slide overview in sidebar

Impress: more accurate selection via TWIPs

Impress: more accurate selection via TWIPs

Performance

More efficient rendering of documents tiles: those relating to non-visible areas are deprioritised and rendered in the background without blocking the initial page view from loading. The result: faster loading of documents for the user and more efficient use of the mobile device’s resources.

Documentation

  • We’ve added extensive javadoc/doxygen comments to pre-existing and updated methods
  • We’ve included javadoc/doxygen comments for all new classes and methods

Performance: non-visible pages deprioritised

Performance: non-visible pages deprioritised

Writer: cross-page text selection

Writer: cross-page text selection

Reaching out

On the rare occasion that our engineers hands haven’t been busy under LibreOffice’s hood, they’ve been writing up their work in blogs and demonstrating it at conferences.

Joining in

This is the start of a journey that you can be part of — get involved with any number of ongoing LibreOffice activities, including LibreOffice for Android documentation, demonstration, and development.

  • Unstable daily builds can be found here
  • A user introduction is available on the Document Foundation Wiki
  • A developer introduction is also available
  • Report any problems you find to the bug tracker, and attach any documents related to the issue so developers can investigate

To complete this prototype preview we’d like to again thank The Document Foundation for making the work possible, and remind you that, as a charitable foundation, donations power their work. Support the foundation by donating via their website.

by Sam Tuke at April 21, 2015 03:24 PM