Skip to main content
  1. Planet
  2. Global
  3. Page 869

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

LibreOffice Visio Import Filter: 20 years of drawings opened in your favourite office suite

It is true that the support of the most used Microsoft Visio file formats in LibreOffice will celebrate 1 year next February. And I will gladly have a birthday talk with any of you who will be freezing in Brussels during the next FOSDEM 2013. Nonetheless, even though libvisio was in development for several months already, the Visio story was far from finished when we released that day. As I already mentioned in another blogpost concerning reverse-engineering of file formats, assessment of a conversion quality in this kind of cases is illusory before real users get to stress-test it with real-life documents.
Since the first release of our filter in LibreOffice 3.5.0, we were improving it thanks to bug reports from our users. It is a big thank you that I would like to say to all those that took the bother to submit reports in our bugzilla. Without you, guys, this filter would be only a moot exercise.
But wait... Do I write this blog now only to thank the people who contributed to the current quality of the filter? Yes to a big extent! Nevertheless, I know that the distinguished readers of this blog would like to have some news. And, yes, we have some news.
The libvisio library underwent heavy re-factoring as we started to understand more and more details about the underlying file-format.
  1. A particular bug report about files imported as empty pages provided us with a document structure that we did never see before. This resulted in a more generic parser and unification on the way we parse master shapes and visible pages.
  2. This re-factoring in its turn allowed us to extend our file-format coverage to all earlier binary Visio file-format versions. We now support all binary Visio documents starting from Visio 1 (released in 1992).
  3. Extending the support to earlier file-format versions allowed us to better understand the development of the file-format, to find more information that we did not parse before, and improve the conversion quality for other binary versions too.
  4. Another re-factoring came with our work to support the XML-based Visio file-formats, namely the "XML Drawing" also known as *.vdx; and the Microsoft Visio 2013 new file-format, known as *.vsdx.
So the news is that LibreOffice 4.0.0 will be able to open ALL Visio files starting from Visio 1 (release in 1992) until Microsoft Visio 2013 (released just some weeks ago).
And since the readers of this blog are more interested in pictures than in pointless words, here come some candies for your eyes:
File opened in Visio 1.0   The same file opened in LibreOffice 4.0.0 beta1
File in Visio 1.0   File in LibreOffice 4.0.0 beta1

VSDX File opened in Microsoft Visio 2013   The same file opened in LibreOffice 4.0.0 beta1
VSDX File in Microsoft Visio 2013   File in LibreOffice 4.0.0 beta1
So, download the LibreOffice 4.0.0 beta1 and help us testing the new big release. We are interested in bug reports that help us to improve our quality. And for those that would love to support us with donations, just click here:
Donate for LibreOffice
Mastodon

the avatar of Andrew Wafaa
the avatar of Andrew Wafaa

ARMing A Virtual World

There is now real hardware from ARM’s partners that offers the ability to leverage hardware virtualisation, in a similar fashion to Intel and AMD. So far three devices are shipping to the general public – the new Series 3 Chromebook, the Nexus 10 and the Arndale board. They all have one key factor in common, the Samsung Exynos5 SoC. This fine piece of silicon is a member of the Cortex-A15 family which introduces the required virtualisation extensions.

the avatar of Raymond Wooninck
the avatar of Raymond Wooninck

brBoard Elections: openSUSE Release Strategy

As also indicated on my Board Election Platform page (http://en.opensuse.org/openSUSE:Board_election_2012_platform_rwooninck), one of the topics that I would like to change is the strategy plan/release goals for the upcoming openSUSE releases.

The issue as seen by me. 

Currently the strategy plan for the distribution is seen from the outside as handled only by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

My proposal on how to improve the process
The strategy process can be improved in two areas. The first area is the simpler one, where we should utilize wiki pages to describe the goals set for the next release. Similar to what the KDE organization is doing. On the main wiki page, the teams can list their plans on what they want to achieve or improve in the next openSUSE release. The team could create detailed wiki pages behind those goals and track the progress on the main wiki page. Major changes within the distribution should always have a detailed page where the change is described in more detail and also indicating how it would impact other areas and/or the user.

The second area is how to get to the right strategy plan for the next openSUSE release. We have openFATE where users are registering their requests for changes, but I see no real official follow-up on this. There are quite some discussions per requests, but in the end it is not clear if a request is being implemented or not. Also the requester will never know exactly in which openSUSE release his request might get implemented. Especially in this area a bigger change is required. In a kind of strategy round the outstanding openFATE requests should be evaluated and classified. Classification could be consisting out of:  “Next Release”, “Future Release”, “Rejected”, “Info required”. Those classified as “Next Release” will be implemented in the upcoming openSUSE release. Those classified as “Future Release” have been accepted, but due to several reason, they can not be implemented in the upcoming release. Similar approached are also being followed by the other distributions.
a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

4.10 Beta 2 packages available for openSUSE

The KDE community has just released Beta 2 of the upcoming 4.10 release of the Development Platform, Workspaces, and Applications. Of course, distributions are providing binary packages for the adventurous… and how could the green distro be left out?

In fact, it is not. Beta 2 packages were uploaded and built in the KDE:Distro:Factory repository. Updated packages have also been submitted to the development version of openSUSE (Factory) as the ultimate goal is having 4.10 in openSUSE 12.3.

Before attempting to install them, be aware that:

  • This release is mostly aimed at contributors and testers to ensure that the final version is as polished as possible

  • You should expect bugs of all forms and kinds

  • It is not officially supported by openSUSE

If you understand all of the above, add KDE:Distro:Factory from YaST or zypper (see the link above; in case of zypper, use zypper ar -f <linktorepo> <reponame>), then trigger an upgrade using your method of choice (in the case of zypper, zypper dup --from <reponame>; don’t forget the --from!).

In case you find something that is not working and you are not sure, try posting your impressions in this special area at the KDE Community Forums, and afterwards file a bug on bugs.kde.org (as detailed as possible). Feel free to report packaging errors (not bugs in the software) on the opensuse-kde mailing list or on IRC (#opensuse-kde on Freenode).

Happy testing!

the avatar of Andres Silva
the avatar of Andres Silva

New Plasma Theme

Hello everyone

I have been working on a plasma theme for some weeks now and I think I am at a point where the plasma theme idea is understood and I would like to get some feedback. Obviously this theme is still considered in early stages, but I think it works well enough for testing.

I hope you like it.
If you would like to help me with it, find me at #opensuse-artwork

Thank you

https://www.dropbox.com/s/zd661zz69x389f7/Pure.zip



the avatar of Raymond Wooninck
the avatar of Raymond Wooninck

Let the openSUSE Board campaign begin.

This afternoon the official start of the Campaign week for the openSUSE board was given. In total there are 8 candidates with all good credentials. 

I would like to kick-off my campaign with the following: 

Introduction and Biography 
Most of you will know me as tittiatcoke, but my real name is Raymond Wooninck, 47 years young, holding a Dutch nationality and since 2001 living with my wife and 2 children in Vienna, Austria. 
Professional live
I have been working since 1990 in the IT area. Started out as an Application Manager and climbed up to departmental manager to SAP Technical Consultant. In 2001 I moved to Austria to start working for the second largest Coca-Cola bottler in the world and to support them during the implement of the SAP system. Now 11 years and diverse positions later, I have been assigned to the function of Application Portfolio Manager within the Strategy & Architecture department. While shaping this new role, I found quite some interesting similarities with the role of the openSUSE board as I see it. 
Unix and I
I had my experience with running Minix, SCO Unix and Linux (since kernel v0.12). Got into the distributions and played around with Red Hat, Mandrake and SuSE, but always came back to the SuSE distro. Shortly after that the openSUSE OBS opened (2009) the possibility to create your own packages, I started packaging a couple of KDE utilities and this brought me an invitation to push them to an official KDE repository and to start working together with the openSUSE KDE team (Many thanks to Dirk Mueller and Stephan Binner (Beineri) for that). 
openSUSE work
After my first experiences with the openSUSE OBS, I got more and more involved. Since end 2009 I took the maintainership for the Google opensource browser Chromium. Tried my luck with the integration of Plymouth (bootsplash) into the openSUSE Distro and got rewarded by having Plymouth as the default bootsplash in openSUSE 12.2. Due to reassignments within the official SuSE/openSUSE teams, I became one of the main maintainers of the KDE repositories and am currently maintaining these repo’s together with a great team. One of the last major activities was to ensure that both the Gnome and KDE desktops would function based on the new systemd-logind session manager and remove the ConsoleKit dependency. This work was done in cooperation with the Gnome team, which was another proof that within openSUSE both teams can work together and make great things happen. 

My view
In my view, there is need for improvement in the areas of user-friendliness (including not only use itself, but easiness of adoption, development, and so on) and access to information. Currently the strategy plan for the distribution is seen from outside as handled inly by developers or people working with the development version. Although this is not wrong, it ultimately leads to a lack of communication on why certain decisions were taken, or why defaults were changed, and so on. Of course the discussion appear in the open, like in mailing lists, but other forms of communication, like a wiki page describing the goals set for the next release, including the rationale for the changes, is missing. Ultimately this leads to confusions among end-users, and even among contributors, as endless discussions appear often on the mailing lists.

Role of the board
At the moment the board is hardly visible. Everybody knows that it is there, but we hear or see only very little of it. Also other candidates have already indicated this. 
In my view, the board should become more active in a number of areas. The most profound one being to set the goals/strategy for the next openSUSE release. This is can be easily done by creating the wiki-pages outlines above where based on the openFATE requests, the feature plan is shown. If this is done early enough, our users would have the opportunity to react on it and to increase the usability of the next release. 
Another area is the interaction with the community and to stimulate its members. With the changing role of the openSUSE boosters, some of the major projects (KDE, Gnome, etc) are now 100% depending on community members. This on itself is already a big change and to find enough community members to help out. Together with the new “rules” being setup regarding packaging, patching, etc, it becomes almost impossible to find new people as that people are volunteering for tasks, seeing what is involved and what rules to follow and they disappear. The openSUSE board should take here a more active role in promoting the active participation and rewarding the work that is being done by the community. 
A third area is the involvement of the board in the discussions on the mailing-lists on topics that concerns part of the strategies or decisions around the openSUSE release/distro. Discussion why a certain item was changed or not changes is now done between users and the responsible maintainer. The maintainer currently defends his position and community members are jumping in on either side. I believe that with a different setup of defining the strategy for the next release, the number of these type of discussions should go down. But in the case they still occur the board should intervene and indicate what the agreed/aligned strategy was regarding the topic. This should move the discussion away from a technical point to a strategic discussion. 

Why you should vote for me?
I believe that my strengths lies in my professional background where I am dealing with Application Strategies, Usability, Accessibility every day. Together with my willpower to bring things to an end, would be very beneficial for the board. I believe that I have proven my strengths in the past with my work on the openSUSE KDE desktop experience, the Chromium web browser as part of the standard openSUSE distribution and the integration of plymouth. 

Aims/Goals
If elected to the board
* I will strive to define, align and implement a new strategy process for the openSUSE releases together with the other board members
* I will try to find ways in which the openSUSE board can establish a better communication with its community
Regarding the KDE team
* I will continue to support the team in the best way I can
* I will strive and drive the team to make the best openSUSE KDE desktop experience ever

the avatar of Vincent Untz
the avatar of Vincent Untz

JDLL and Mini-DebConf Paris 2012

During the last two week-ends, I went to two different events. That's part of my end-of-year sprint where I travel too much: SUSEcon and openSUSE Summit in September, OpenStack Summit and openSUSE Conference in October (oops, didn't find time to write about these events), two weeks vacation in Thailand in October/November (yes, we enjoyed the time there!), one week of team meeting in Prague right now, and two other trips to Paris during those few months... Crazy planning!

I attended these events with my advocate hat to deliver GNOME-related talks (and also to chat with people a bit about openSUSE, and of course to meet good friends of mine ;-)). I feel there's a big need on GNOME's side to communicate more and clarify our direction and opinions, and on top of that, there's a lot of mis-informed statements around that people blindly trust and that need to be debunked. My talks were simply part of my local contribution towards that goal. And apparently, that's something that seems to be most welcome!

JDLL 2012

The Journées du Logiciel Libre (or JDLL) is an event that occurs every year in Lyon. Lyon being close to home, it's an event I can attend quite easily and this is not something I can complain about ;-) We did have some great people at the event this year, including a french-turned-british-turned-french-again guy.

When I got asked to give a talk about GNOME this year, I wasn't sure I would have anything really interesting to tell, so I suggested an interactive session around the recent hot topics in GNOME (you know, GNOME OS, systemd, fallback mode, etc.). In the end, even though I had many slides ready, we simply discussed the questions that were raised by the audience, and I believe that this session proved to be very useful for the attendees. So a good experience, and a format I'll likely use again.

I also had the opportunity to play a bit with Firefox OS. I've been following the project for quite some time but never took time to really try it, so I was really glad to be able to take a long look at it. There's still some work to do, and, hrm, well, that was visible ;-) I managed to crash things without even trying to be nasty. I hope it will take off, though: there's a need for an alternative closer to our ideals.

Mini-DebConf Paris 2012

The Debian France team organized a Mini-DebConf in Paris, and I was invited for a slot. I chose to talk about GNOME vs downstreams, and discuss the love/hate relationship we have, and how the future direction can be good/bad for different downstreams. The idea was simply to get out some information out about what GNOME is doing, and to clarify where the project is heading, as this has some pretty big impact on our downstream friends. Obviously not everything is perfect in GNOME but I feel that the project is, overall, doing okay as an upstream. (I'm kind of sad to discover an ABI breakage in glib after I told to Stefano and Lucas that we were not breaking ABI in our platform; oh well).

This Mini-DebConf was a pleasant surprise, as there were quite a number of attendees, and the whole event went quite smoothly (well, at least for the day I was there). It was also interesting to hear about the different opinions with regards to the Debian release cycle (got some pretty good food for thoughts), and I enjoyed Sylvestre's talk about making Debian compiler agnostic. The event had many other great talks — definitely an event I'd recommend attending, even to non-Debian people.

the avatar of Andres Silva
the avatar of Andres Silva

As we work on the next release of openSUSE.

As we work on the next release of openSUSE. We would like to invite
our community to participate with ideas to guide our design team in
choosing artwork for openSUSE 12.3.

Right now, there are some ideas coming through. As designers, it is
important to find ideas, words, or concepts that can help guide our
thoughts into choosing artwork for 12.3. Please provide us with a max
of 3 design "thoughts," for example

1. Simplicity
2. Clarity
3. Light

Choose any 3 of these that can help describe our thought process.

If in doubt of what's appropriate to suggest, and not deviate too much
from our current styling guidelines, refer to

http://en.opensuse.org/openSUSE:Artwork_guidelines


Thank you

Andy (anditosan)

PS: In case you have not seen yet, please swing by our flickr page.
Our contributors have been hard at work taking pictures and making
images that can do for a good wallpaper.
the avatar of Flavio Castelli
the avatar of Flavio Castelli

qjson 0.8.1 released

Just a quick information, QJson 0.8.1 has been released. This release ensure API and ABI compatibility with version 0.7.1.

The previous 0.8.0 release broke ABI compatibility without changing the SOVERSION.

Toward QJson 1.0.0

I’m not entirely happy with some parts of QJson’s API. I addressed these issues inside of the 1_0_0 branch.

I would appreciate to hear your opinion before merging this branch into master and releasing QJson 1.0.0.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

jappix needs php-mbstring and will fail on SLES11

jappix is a fine piece of xmpp (jabber) based community building software.
Sadly, its installer needs php-mbstring (for SLES 11 SP2, this is php5-mbstring or php53-mbstring depending on your php choice). Sadly, it hides any error messages before requiring this crucial library. You will never know until you investigate closely.

Or as some person on the web paraphrased in German: was meinst du mit testsuite?
Software should not behave that way. Test suites and installers like jappix’ setup.php should know how to handle missing dependencies and show them to users.

Debian is not affected. By luck or purpose, debian ships mbstring with the basic php package.