Language Selection

English French German Italian Portuguese Spanish

Collabora Office for Phones

Filed under
Android
LibO

SUSE was a foundational supporter of LibreOffice, and it was clear that smartphones were becoming a thing, and something needed to be done here. Also Apache OpenOffice was being used (without anything being contributed back) by AdrOpen Office - which looked like 'X on Android', so we needed a gap plugging solution, and fast.

Luckily a chunk of the necessary work: cross-compiling was dual-purpose. Getting to work was part of our plan inside SUSE to build our Windows LibreOffice with MINGW under SLES. That would give us a saner & more reliable, and repeatable build-system for our problem OS: Windows.

Of course we used that to target Android as well, you can see Tor's first commit. We had a very steep learning curve; imagine having to patch the ARM assembler of your system libraries to make STL work for example.

FOSDEM as always provided a huge impetus (checkout my slides) to deliver on the ambitious "On-line and in your pocket" thing. I have hazy visions of debugging late at night in a hotel room with Kendy to get our first working screenshot there:

Read more

Collabora Office Brings Power of LibreOffice to Android & iOS

  • Collabora Office Brings Power of LibreOffice to Android & iOS

    Dream of using LibreOffice on Android or iOS? if so, the release of Collabora Office will be of particular interest.

    Collabora Office is a free and open source office suite for Android and iOS. It is powered by LibreOffice and developed (in part) by open-source consultancy firm Collabora.

    But unlike previous ‘LibreOffice for Android’ style apps you may have seen this is a fully featured editing tool, not merely a document viewer.

    It also features a bespoke UI crafted specifically for editing documents on mobile devices, via fingers. The UI borrows from the Collabora Online interface.

    These features, along with other mobile-minded enhancements and power ups, make Collabora Office super useable on small screen sizes, and easy to use singlehandedly.

    The app also works entirely offline. With no cloud or online service features come enabled by default or are required to use any of the included features (though naturally there’s support for integrations with cloud storage services, including NextCloud, should you want it).

Collabora brings smooth editing to Android and iOS

  • Collabora brings smooth editing to Android and iOS

    Today we are releasing Collabora Office for Android and iOS which will allow you to edit documents directly on your phone or tablet, guaranteeing your privacy and putting you in full control of your data and documents. This release fully integrates the iOS and Android apps into our Collabora Office product family. They are now a supported part of our business suite and come with every Collabora Office Enterprise subscription. Take a look: it’s a great app: feature rich, providing smooth editing, a polished user experience and lots of design goodness.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Games: Newer Windows Games On Wine, Steam on Chrome OS and Soldat's Source Code

  • A New Kernel Patch Is Being Discussed That's Needed For Newer Windows Games On Wine

    Newer Windows games/applications are making use of system call instructions from the application code without resorting to the WinAPI and that is breaking Wine emulation support. A Linux kernel patch is now being worked on for addressing this issue in the form of system call isolation based on memory areas while having a smaller performance hit than alternatives. With newer Windows software executing system call instructions without going through the Windows API, Wine isn't able to intercept and emulate those system calls and thus breaking the support. Wine can't really rework its handling of every system call as that would thrash the performance. So a Linux kernel-based solution is being sorted out.

  • Cloud FTW: Steam on Chrome OS may not look like we thought

    Back in January, word got out that Google and Valve were collaborating to bring some form of native Steam client to Chrome OS. Director of Product Management Kan Liu told Android Police that the project would leverage Crostini, aka Linux on Chrome OS. Because I spend a good portion of my days tinkering with Linux on my Chromebook, I hastily presumed that Steam would be delivered in some sort of Chrome OS-optimized Linux package. While that could still be a possibility, it appears that Valve may look to the Clouds in Steam’s next evolution.

  • Soldat source code released and a story of how it all started

KDE Development: Adriaan de Groot and New GSoC Students

  • Timezones, yes please

    One of the bits of Calamares that I think is most terrible is the timezone selector. So I was very happy to read Volker’s ideas about timezone-mapping. Calamares is a universal Linux installer, used by some dozens of Linux distro’s. It is built as a framework, customizable by downstreams to their liking. This is basically a service to the small-distro Linux community, and PRs are very welcome .. but I digress. Part of installation is picking a timezone to put the system in. Calamares offers a map, and you click on it, and it picks a likely location, and off you go. The technology used is simple: there’s a PNG for each timezone (this sounds familiar). The user clicks on the PNG of the world map, and the mouse coordinates are mapped to a location (longitude and latitude), the location is mapped to a zone offset that gets mapped to a timezone image, and the image is drawn.

  • The Community Bonding Period Ends

    It has been almost a month, since the commencement of community bonding period and the phase was mostly good. I spent most of my time lurking over the IRC in passive reconnaissance mode, force of habit I mostly speak less and I know it is not a good one especially being part of an open-source community. I used to attend all the meetings and tried to get accustomed with the workflow of the community and got to know about everything hot and spicy that is taking place whether it is Krita finally on android or new contributors working on some bugs.

  • KDE Conference India 2020: A very late post

    KDE India Conference 2020 was successfully organized in Maharaja Agrasen Institute of Technology. It was a three-day event, from Jan 17 to Jan 19. There were talks about Libre, Open Source Software and how software is developed using C++ and the Qt Framework. Hands-on workshops were also organized on C++, Qt and QML which gave attendees a good start on how to start their journey with C++ and Qt Framework. The conference was able to educate 200+ attendees throughout the conference. Refreshments were provided to all present for the conference on all 3 days. Every day of the conference concluded with dinner at various good places in Delhi with all the speakers, organizers and volunteers.

  • About me, who am I?

    I am Shubham, a final year undergraduate student, pursuing B.E(Bachelor of Engineering) at BMS Institute of Technology and Management, Bangalore, India. I am an open source enthusiast and developer, mostly working with C++ with Qt framework. I also have decent knowledge of C, Java, Python, bash scripting, git and I love developing under linux environment. Previously I was selected as one of many GSoC students to be mentored by this amazing organization, which is KDE. This year also, I applied again to KDE as a student and was fortunate enough to get selected. I will be developing for Cantor project. Apart from coding, in my spare time I go for Cricket or Volleyball to keep myself refreshed.

  • Integrated Documentation in Cantor

    Cantor is an application that lets user use their favourite mathematicalapplications from within a nicely KDE-integrated worksheet interface. It offers assistant dialogs for common tasks and allows users to share their worksheets withothers. Cantor is one of many KDE educational projects. It supports a variety of backends, be it Maxima, Octave, Python, R and many more and that too packed in a single intuitive GUI. The current version of Cantor does not have support for viewing backend's documentation inside the application itself. For example, to view Maxima’s documentation or help, the application provides an external link pointing to the Maxima’s official documentation page which is opened in a fresh browser window. This has the obvious drawback of requiring an active internet connectivity.

The Linux Kernel Deprecates The 80 Character Line Coding Style

The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit". The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be as enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals but with today's high resolution displays the terminal sizes are often larger though some preferring the default in order to allow more terminals to be displayed simultaneously on their nice displays. Read more Original from Torvalds:

  • clean up kernel_{read,write} & friends v2
    Not necessarily.
    
    Excessive line breaks are BAD. They cause real and every-day problems.
    
    They cause problems for things like "grep" both in the patterns and in
    the output, since grep (and a lot of other very basic unix utilities)
    is fundamentally line-based.
    
    So the fact is, many of us have long long since skipped the whole
    "80-column terminal" model, for the same reason that we have many more
    lines than 25 lines visible at a time.
    
    And honestly, I don't want to see patches that make the kernel reading
    experience worse for me and likely for the vast majority of people,
    based on the argument that some odd people have small terminal
    windows.
    
    If you or Christoph have 80 character lines, you'll get possibly ugly
    wrapped output. Tough. That's _your_ choice. Your hardware limitations
    shouldn't be a pain for the rest of us.
    
    Longer lines are fundamentally useful. My monitor is not only a lot
    wider than it is tall, my fonts are universally narrower than they are
    tall. Long lines are natural.
    
    When I tile my terminal windows on my display, I can have 6 terminals
    visible at one time, and that's because I have them three wide. And I
    could still fit 80% of a fourth one side-by-side.
    
    And guess what? That's with my default "100x50" terminal window (go to
    your gnome terminal settings, you'll find that the 80x25 thing is just
    an initial default that you can change), not with some 80x25 one. And
    that's with a font that has anti-aliasing and isn't some pixelated
    mess.
    
    And most of my terminals actually end up being dragged wider and
    taller than that. I checked, and my main one is 142x76 characters
    right now, because it turns out that wider (and taller) terminals are
    useful not just for source code.
    
    Have you looked at "ps ax" output lately? Or used "top"? Or done "git
    diff --stat" or any number of things where it turns out that 80x25 is
    really really limiting, and is simply NO LONGER RELEVANT to most of
    us.
    
    So no. I do not care about somebody with a 80x25 terminal window
    getting line wrapping.
    
    For exactly the same reason I find it completely irrelevant if
    somebody says that their kernel compile takes 10 hours because they
    are doing kernel development on a Raspberry PI with 4GB of RAM.
    
    People with restrictive hardware shouldn't make it more inconvenient
    for people who have better resources. Yes, we'll accommodate things to
    within reasonable limits. But no, 80-column terminals in 2020 isn't
    "reasonable" any more as far as I'm concerned. People commonly used
    132-column terminals even back in the 80's, for chrissake, don't try
    to make 80 columns some immovable standard.
    
    If you choose to use a 80-column terminal, you can live with the line
    wrapping. It's just that simple.
    
    And longer lines are simply useful. Part of that is that we aren't
    programming in the 80's any more, and our source code is fundamentally
    wider as a result.
    
    Yes, local iteration variables are still called 'i', because more
    context just isn't helpful for some anonymous counter. Being concise
    is still a good thing, and overly verbose names are not inherently
    better.
    
    But still - it's entirely reasonable to have variable names that are
    10-15 characters and it makes the code more legible. Writing things
    out instead of using abbreviations etc.
    
    And yes, we do use wide tabs, because that makes indentation something
    you can visually see in the structure at a glance and on a
    whole-function basis, rather than something you have to try to
    visually "line up" things for or count spaces.
    
    So we have lots of fairly fundamental issues that fairly easily make
    for longer lines in many circumstances.
    
    And yes, we do line breaks at some point. But there really isn't any
    reason to make that point be 80 columns any more.
    
                      Linus
    

today's howtos