Attracted by virtual constructs

April 2, 2016

Plasma Weather widget: code template available to add your favorite weather data provider

Filed under: KDE,Plasma — by frinring @ 9:08 pm

Quick recap

Plasma 5.6 has finally seen the return of the Plasma Add-ons Weather widget, which had been missing the port from Plasma4.
Next, the Weather widget does not talk to any weather data providers directly, instead it talks to a weather dataengine (currently part of the Plasma Workspace module), to query for any weather stations matching the entered location search string when configuring the widget and to subscribe to the data feed for a given weather station from a given weather data provider.
That weather dataengine itself again also does not talk directly to any weather data providers. Instead it relies on an extendable set of sub-dataengines, one per weather data provider. So-called “ion”s.

Currently there are only 3 ions part of Plasma: wetter.com (private company running wetter.com), envcan (Environment Canada, by Government of Canada), noaa (USA’s National Oceanic and Atmospheric Administration). That is not enough, right.

Get quickly started with a working template

Time to add an ion for your favourite weather data provider. An ion can be independently developed by everyone, no need to do this in the plasma-workspace module (though it would be great if your ion ends up there once it is working, so it can be shared more easily).

To allow you a quick start with your own ion development, for the next version of the Plasma, 5.7, a code template (in the kapptemplate format, as supported by KAppTemplate or KDevelop) has been added. So when installing the development packages for Plasma Workspace (e.g. “plasma5-workspace-devel”), there should be also a “Plasma Weather Ion Dataengine” code template available, in the “KDE/Plasma Dataengine” folder.

Until Plasma 5.7 is released, download a snapshot of the ion code template. This snapshot also works with Plasma 5.6. You will need to have the development packages for Plasma Workspace installed, so the “plasma/weather/ion.h” header is available.
To use the template with KDevelop, select in the menu “Project”/”New From Template…” and click the button “Load Template From File” to add the template to the list. Then select the template and follow the dialog.
To use it with KAppTemplate, you need to manually install the file in “/usr/share/kdevappwizard/templates/” and (for KAppTemplate before Applications 16.04) also add a dummy PNG file to “/usr/share/kdevappwizard/template_previews/“, with the same base name as the template, “ion-dataengine.png“.
If the template does not work for you (please tell in the comments if), download this sample ion zip file, made from the template and the name “trueweather”, and start from that.

Follow the “README” in the sources and learn how to build, install and test your ion dataengine, e.g. how to query it via the Weather dataengine with the Plasma Engine Explorer:
trueweather ion dataengine in Plasma Engine Explorer

Learn more details about the Plasma Weather dataengine system in the last blog post.

Do not hesitate to ask for help on the #plasma irc channel and the plasma-devel mailinglist.

March 24, 2016

Plasma Weather widget: add your favorite weather data provider

Filed under: KDE,Plasma — by frinring @ 12:25 pm

So Plasma 5.6 has seen the revival of the Weather widget that is part of KDE Plasma Add-ons module (revival as in: ported from Plasma4 API to Plasma5 API).
(And even got the interesting honour to be mentioned as the selling item in the headline of a Plasma 5.6 release news article by a bigger German IT news site, oh well:) )

This revival was concentrating for 5.6 to restore the widget in its old state, without any bugs. But that’s not where things are to end now…

And you, yes, you, are invited and even called in to help with improving the widget, and especially for connecting to more weather data providers, incl. your favourite one.

For a start, let’s list the current plans for the Weather widget when looking at the next Plasma release, 5.7:

  • Overhaul of look (IN PROGRESS)
  • Breeze-style weather state icons (IN PROGRESS)
  • also temperature displayed in compact widget variant, like on panel (TODO)
  • support for more weather data providers (YOUR? TODO)
  • privacy control which weather data providers are queried on finding weather stations (YOUR? TODO)

Overhaul of widget look

The KDE meta sprint at CERN (of groups WikiToLearn, Plasma, VDG, techbase wiki cleanup) at begin of this March, where I mainly went for techbase wiki cleanup work, of course was a great occasion to also work face-to-face with Plasma developers and VDG members on issues around the Weather widget, and so we did. Marco helped me to learn more about Plasma5 technologies which resulted in some small bugs fixed in the widget still in time for Plasma 5.6 release.
Ken presented me the drafts for the look & design and the config of the weather widget that he had prepared before the sprint, which we then discussed. Some proposals for the config could already be applied in time for Plasma 5.6 release (those without need for changed UI texts, to not mess the work of the translators). The rest of it, especially the new look & layout of the widget, is soon going to be transferred from our minds, the notes and the photos taken from the sketches on the whiteboard at CERN into real code.

Breeze-style weather state icons

Ken also did a Breeze style set of the currently used weather state icons. While touching the icons, a few icon naming issues are going to be handled as well (e.g. resolving inconsistent naming pattern or deviation from the weather state icon names actually defined in the XDG icon naming spec (see Table 12. Standard Status Icons). Should soon be done as well.

Temperature display in compact widget variant

One thing that has been missing also from the old version of the Weather widget is the display of the current temperature in the compact widget variant, where now only the current weather condition is shown (e.g. when on the panel). While some weather data providers (like wetter.com) do not provide that detail, so there is nothing to display, others do, and often it is pretty nice to know (clear sky can happen with temperatures of any kind, so it’s good information about if and then what kind of jacket to put on before stepping outside). First code is drafted.

Now, finally the things were you can improve things for yourself and others:

Supporting more weather data providers

The Weather widget does not talk to any weather data providers directly. Instead it talks to a weather dataengine (currently part of the Plasma Workspace module), to query for any weather stations matching the entered location search string when configuring the widget and to subscribe to the data feed for a given weather station from a given weather data provider.
That weather dataengine itself again also does not talk directly to any weather data providers. Instead it relies on an extendable set of sub-dataengines, one per weather data provider.

The idea here is to have by the one weather dataengine an abstraction layer (he, after all this is KDE software😉 ) which maps all weather data services into a generic one, so any UI, like the Weather widget, only needs to talk one language to whoever delivers the data.
Which works, more or less. Because of course there are quite some weather data specifications out there, what else did we expect😛 And possibly the spec interpretations also vary as usual.

((You might think: “Well, screw that over, there is only one user of the weather dataengine, so integrate that directly into the Weather widget!”
While that might be true right now, it does not need to stay this way. There are ideas like showing the weather forecast also with the days in Plasma calendar widgets. Having a KRunner plugin to quickly request weather in some place. Or having a wallpaper updater reflecting the current weather by showing matching images, yes, not everyone has the joy to work close to a window, enjoy if you do. And also alternative weather widgets with another UI, remember also the WeatherStation widget in kdeplasma-addons (still waiting for someone to port it), which focussed on details of the current weather state. These kind of usages might prefer a normalized model of weather data as well, instead of needing custom code for each and any provider again. Actually long-term such a model would be interesting outside of Plasma spheres, e.g. for any calendaring apps, for a plugin for Marble-based apps showing weather states over a map or whatever other fancy uses there can be. Feel free to share ideas in the comments, to improve motivation for creating such a Plasma-independent lib!))

While I only took over kind of maintainership in the last weeks, so did not design the current system myself, I still think it’s a good approach, having in mind reusable UIs and relative independence from any given weather data providers. So for now I do not plan to dump that, simply lacking a more promising alternative.

So, given you are still reading this and thus showing me and yourself your interest:) let’s have a closer look:

The sub-dataengines for the different weather data providers have been named “ion”s. On the code level they are subclasses of a class IonInterface, which itself is a subclass of Plasma::DataEngine.
See here for the header defining IonInterface: https://quickgit.kde.org/?p=plasma-workspace.git&a=blob&f=dataengines%2Fweather%2Fions%2Fion.h

This header and the respective lib libweather_ion are public and should be installed with the devel packages of Plasma Workspace. Which means you should be able to develop your custom ion as 3rd-party developer without the need to checkout the plasma-workspace repository and develop it in there.

Plasma 5.6 itself installs three such ions:

  • wetter.com: adapter to service of the private company running wetter.com
  • envcan: adapter to service of Environment Canada, by Government of Canada
  • noaa: adapter to service of USA’s National Oceanic and Atmospheric Administration

Find their sources here: https://quickgit.kde.org/?p=plasma-workspace.git&a=tree&f=dataengines%2Fweather%2Fions

In that source folder you will also spot a bbcukmet ion, for the BBC weather service. While being ported to build and install at least with Plasma5, the service API of BBC as used by the code seems to have been either changed or even removed. So that ion is currently disabled from the build (uncomment the #add_subdirectory(bbcukmet) to readd it to the build). Investigations welcome.
Update: There are patches for the Plasma4 version of the bbcukmet ion to make it work again with current BBC service API. See below in the comments for detailed info. Should be easy work and a chance to contribute also for beginners.
Update2: Those patches have been used to restore the bbcukmet ion, it will be part of Plasma 5.6.2 and later. Still would be good to have someone look closer at it, there is room for improvements.

Another old ion which though already got removed during the revival was a more fun one: there used to be a Debian “weather” service (random related blog post), which reported the status of Debian-based distros by number of working packages as weather reports, and this ion connected to them. But the service died some years ago, so the ion was just dead code now (find the unported code in versions of “Plasma 5.5” and before)

Talking about funny weather reports: why not write an ion for the CI system Jenkins, e.g. with build.kde.org, which while perhaps not being able to give forecasts at least reports the current build state, with builds mapped to stations. After all the short report for a build uses the weather metaphor, see https://build.kde.org/:)

For more serious weather data provider ions again, as you surely know or can guess, there are many more public & private weather data providers than those 3 currently supported. And they not only may have a better coverage of your local area, but might also provide more data or more suited ones.

Please also see the proposal for using “weather data from the open data initiatives” in a comment on the first blog post on the Weather widget.

It would be great to have a larger selection of weather data providers supported in Plasma 5.7. So while having your ion as 3rd-party plugin somewhere else is fine, consider maintaining it inside one of the Plasma repositories, either with the existing ions in the repo plasma-workspace or as part of addons in the repo kdeplasma-addons. This should ensure more users and also more co-developers.

Do a good check of the licenses for using the data services of the weather data providers. Especially public ones should be fine given their purpose, but if in doubt after reading the details, ask the providers.

Privacy control

One issue in the old and current Weather widget code is that when searching for a weather station suiting the users desire, as expressed by the location search string, all currently installed ions are queried. Which of course is a problem from a privacy point of view. And will be worse the more ions there will be.

So there needs to be a way to limit the scope of ions that would be queried. Given that dataengines by design should be used by all kind of dataengine consumers, a Weather widget-only solution might be only a short jump here. There are very possibly other Plasma modules talking to remote services as well, like geolocation services. And ideally one is able to control system-wide (so even beyond Plasma scope) which remote services are allowed and which not.

Until such a global solution exists a Weather widget-only solution is better than nothing surely. Still, it needs to be designed UI-wise, so a job to be picked up by someone:)

Getting started with your own ion

So while I am currently impeded these days from hacking, among other things by waiting for new development-capable hardware being delivered (disadvantage of small towns: need to use an online shop for special hardware desires, and there latency unit is days, not minutes, especially bad when wrong stuff is delivered and then also holidays get into the game. Looking on the bright side of life, my old hardware only broke right after the CERN sprint, not before:) )…
… Do not hesitate to look into things already. I would have liked to provide a KAppTemplate-package with an ion sample in this post already, so you could experiment right away. But perhaps you are experienced enough to get a new ion working by looking at the existing ones. If not, in a few weeks hopefully there should be a template, so watch out.
Update: There is now such a template, see this blog post.

And do not hesitate to ask for support on #plasma on irc or on the Plasma mailinglist, I received lots of help there with the Weather widget porting, so you should when trying to write an ion:)

March 8, 2016

Selecting text in the Calligra-powered Okular plugin for ODT, DOC, DOCX & WPD

Filed under: Calligra,KDE — by frinring @ 12:38 am

Traveling 8+ hours on the train all the way through Germany to Geneva in Switzerland, where CERN is located (its area spreading across the border to France actually), the place of the WikiToLearn-Plasma-VDG-TechbaseOverhaul meeting, was also a good chance to first spend some time again on a sprint-unrelated, but still KDE-related item, which is adding support for text selection to the Calligra-powered Okular plugin for text documents.

With some first satisfying prototyping results, where selection highlight is rendered at the correct positions and the correct chars being copied:
Calligra Okular plugin first text selection support

Polishing this up is left for the trip back home on Sunday. Looks promising so far, you hopefully soon will be able to select text from your DOCX, DOC, WPD and ODT files you view in Okular using the plugins from Calligra (once both Okular based on KF5/Qt5 and Calligra 3.0 are released, TBD).

One thing learned on the train: forcing your SchuKo-style power plug into the Swiss train’s on-board Swiss-style power socket might work (SchuKo connectors have a slightly bigger diameter), yes.
But: it takes some time to get it out again, without destroying the socket, so it is best started to be done some time before the switch-trains-here station is reached, not only a few seconds, which has one run the risk of not getting out in time. Or having to leave the power supply behind, better to be avoided as well:)

TechBase Wiki Overhaul at CERN

Filed under: KDE — by frinring @ 12:38 am

KDE’s techbase wiki, “the primary place for technical information about KDE targeted at developers, ISVs and sysadmins”, has been gone lost a little during the transition of KDE software to KF5 and Plasma5.
An unsatisfying situation, so a few people including me decided to use the opportunity of the scheduled KDE contributor meeting at Europe’s CERN this second week of March, originally for WikiToLearn, Plasma & VDG, to also meet up for preparing and starting an overhaul of techbase. And there we are already!

It’s great to be here at CERN, a place where Europe feels like the good old late last century Europe. It is exciting to be in an environment where people work together for the good and for more knowledge, and with such excellence. Very inspiring.

A nice sideeffect of doing this big sprint here at CERN is that it also means getting a few talks delivered about the CERN and its activities. Where one can learn that a flying mosquito or big fastfood items are suitable quantification units when it comes to explaining what gets accelerated in the underground here and how:)

Once this morning we all had been introduced to our host and the location as well as us to ourselves, the different KDE teams, and our each goals at the sprint, we spread out into the IdeaSquare building and grouped again in the in-door containers or in-door bus decks (“Ceci n’est pas un bus” only by definition, even if it looks, smells and feels like a real 1960 London double-decker bus, that was also said to have been driven all the way from London straight into the building by one of the employees) to start our work.
We TechBase overhaulers got a good run so far, starting with revisiting the purpose of TechBase, collecting issues with the current content on TechBase (or not on it) and sketched first solutions that would help to fix or prevent those issues. And discussed with Plasma and WikiToLearn people about that a little.
No content was touched so far. Soon more about it.

When in the evening the daily recap was done, it seemed all groups had made some good progress today.

Having a rather stiff northern culture as background, it is heart-warming to experience lots of Italian students from the WikiToLearn project occupying and running the kitchen here in the IdeaSquare building for creating lunch and dinner for everyone and vigorously celebrating the joy of food (with ingredients bought right behind the border in the less expensive supermarket in France, small is this continent). One of the terms to be learned is “abbiocco”, left without direct word matches in the northern languages present, interesting.

With the Plasma and VDG people present, somewhen the next days they and me will also take advantage of that and work a little together on both improving the revived Plasma5 AddOns Weather widget and also getting Breeze-style icons for it:)

This meeting at CERN is not only made possible by our hosts here at CERN, but also by you, the donators to the KDE e.V., which is forwarding your financial support also to us all who have come here, to cover parts of travel and accomodation.
If you haven’t already, consider joining the donators. Click the banner for more info:
cernbanner-wtl

March 2, 2016

Will the Addons Weather widget be revived for Plasma 5.6?

Filed under: KDE,Plasma — by frinring @ 5:47 pm

If you are deep in coding mode and cannot afford to turn your head or even your eyes to look through the window at outside to check the current weather… or if you are deep down below ground plumbing at your black hole farming machine and now preparing your way home and are unsure whether to put on a rain jacket or the sunglasses… what is there to help you? A widget on your computer telling you about the weather, right.

Plasma5 so far was missing the port of the weather widgets which were part of the Plasma Addons package with the older Plasma. While there are nice Plasma5 weather widgets on kde-apps.org (1, 2) I wanted the weather widget back I was used to.

Time for “Scratch your itch!”. Starting myself with no clue about Plasma dataengines and also about the new Plasma5 QML-centric widget technology, there was enough material to be found and samples to copy from to port the old weather widget code over to the new Plasma5 world. Also was there great support by the Plasma developers (special thanks to Kai-Uwe and Marco) who quickly helped out with questions, gave good review or the next day fixed bugs elsewhere I hit on the way.

This week there was the feature freeze for Plasma 5.6, and of course it would be nice to share this widget already with everybody again. Did we make it in time?

Teaser: Yes:)

Addons Weather widget showing forecast for Geneva and Lisbon

Seems its time for rain jacket in Geneva, while sunglasses are okay in Lisbon:)

There is one bigger issue currently known: sometimes after configuring a new weatherstation to be used, there is no instant data update, so the widget will be blank. This blank widget should heal itself on the next weather report update interval (or on the next Plasma restart). Hopefully we soon find the reason to fix this.

There is still the Weatherstation widget left in Plasma Addons, waiting for a port as well (nothing I am interested in, so no itch to scratch here). Feel encouraged to give it a go to port it yourself and become the happy maintainer of a Plasma5 widget as well:)

January 25, 2016

New Year Calligra Words Sprint

Filed under: Calligra,KDE — by frinring @ 12:54 pm

When the streets are covered with snow and ice in many parts of Europe, it’s a good time to sit inside in front of our computers and to improve that software we are sharing here with each other.
With the porting of the apps, plugins & libs part of Calligra to Qt5/KF5 roughly done towards the end of 2015, it is now also a good time to work on features again.

Given a few Calligra developers interested in improving the text-handling modules, we looked into doing a developer meeting (a.k.a. “sprint”) on that quickly, and given January being a good candidate for snow and ice on the streets, we scheduled it for the 4th week-end of January, so the one that just passed.
In the end it was just three of us who could make it, but small can be also better:)

A big share of time of the sprint was invested into spreading knowledge about the current text-layout system by its architect Camilla, by explaining and discussing the current design and code.
To apply, test and enhance the learned things about the layout system, we started to draft and to implement support for the concept of text sections (as in OpenDocument Format’s <text:section>) to the system.

While talking about the text-layout system and the data structures, we also looked into the Calligra plugins for the document viewer Okular (learn more about the plugins). We checked and fixed a little the current calculation of the positions of headings for the table of contents. And drafted how to use the layout structure data for the calculation of characters positions on a given page, to finally implement support for text selections and hyperlinks with the plugins.

And with OpenDocument Format engaged people around, we also chatted about ODF-related things a little. E.g. that having a central database where all errors & artifacts injected into ODF files by the known ODF producer software is collected. Because with some N-number of ODF producer software all M-number of ODF consumer software need to each write support for possibly dealing with broken files from all N ODF producer software, and need to know what to care for and how. It might be nice to perhaps just have a single broken-ODF-file-fixup software one could use, so one’s ODF consumer software can simply expect sane ODF files.
While mentioning ODF here: consider visiting Jos’ talks at FOSDEM upcoming week-end, “The Future of OpenDocument (ODF)” and “Eternal Plugfest”.

It happened that due to a date mixup the Krita developer community did a small sprint at the same place at the same time. Which worked out nicely not only for the social parts of the sprint, which we all did together. Also during the working times often we were sitting mixed in the same rooms.
It was also an occasion to learn more about Krita’s OpenGL-based rendering, which could be an inspiration for a new generation of Calligra’s shape rendering system (which I personally am thinking about).

These are the sheets with explanations that I take home with me, next to the digital and mental notes:
WordsSprintJan2016SheetsOnTheDesk

(One day hopefully we finally will do such sketches not on real paper, but on virtual sheets, using Calligra + Krita modules :)) ).

It was a very productive and enjoyable week-end, in a wonderful atmosphere, I am happy we did this meeting.

Thanks a lot to Boudewijn and Irina for being the great hosts to our Calligra Words sprint and for giving us the free accomodation in their home, incl. breakfast, drinks and more, in a family-like way.

This sprint was also enabled by the supporters of KDE e.V., thanks to them to make it financially possible for us Calligra developers to meet up for face2face talking and working.
If you, dear reader, want to do your little contribution to the future of KDE software as well, consider to Join The Game as a supporter of KDE via the KDE e.V. !

November 25, 2015

Marble Maps forking for SailfishOS

Filed under: KDE,Marble,SailfishOS — by frinring @ 7:39 pm

Marble, the swiss army knife for maps and globes, developed in the KDE community, this year has got an app variant added that is concentrating on maps and that is designed for today’s typical mobile devices with touch UI, called Marble Maps. It currently is in Beta state. Read “Announcing Marble Maps for Android Open Beta” for more info.

At this year’s Randa meeting for a few days I joined the people working on having KDE software run on Android. After all there are gazillions of such systems out there, and it only makes sense to have existing FLOS software, such as KDE ones, also run there, as a matter of dealing with realities. With the developers of Marble, KAlgebra and GCompris around, some experience could be shared, and I compiled what I learned into a small Hello KWorld example.

As a Marble fanboy, Marble Maps was my obvious toy project here when learning more about building Qt5-based software for Android. I had no Android device available, but a Jolla phone with SailfishOS. That one also has support for running Android apps, so I still could use it to test my self-built Marble Maps Android packages.

Now, it felt strange to run a Qt5-based application via Android emulation layer on an OS like SailfishOS which itself is using Qt5 and then some usual “Linux” software stack/middleware. Should it not simply run directly there?

So last week finally I gave it a try to build and to run Marble Maps natively on SailfishOS. And was presented with a problem: SailfishOS in the latest version is (still) at Qt 5.2 (with QML upgraded to 5.3 it seems) and, more important, has no QtQuick Controls. Which are used in Marble Maps for all controls. At least all the Marble C++ code was building fine after 2 small fixes, so that part was looking promising.

An option might have been to build a custom version of QtQuick Controls. But that somehow smelled like problems waiting. And I also was tempted to try to do some native UX to gather more experience with QtQuick and the SailfishOS ideas. So I forked the Marble Maps code and started to write a SailfishOS variant, using its Silica UI components. The code for Marble Maps is mainly the UI layer one, written in QML, with the actual business logic nicely in the shared Marble libs and components, so it is not that much logic which is duplicated here. Still it is not “Write once and run everywhere”. It’s up for discussion how much native multi-platform apps should go. For now I will play more with it.

Right now Marble Maps for SailfishOS almost has all current features of the “normal” Marble Maps implemented, modulo some small bugs:

Marble Maps on SailfishOS: Editing a route Marble Maps on SailfishOS: Adding a new point to a route

These days sadly many people hearing “marble” and “sailfishos” might rather think of “tombstone”, bad timing here. But until that OS is pushing up the water lilies I will play more with it, after all I can use the code on a working device of mine.

If you want to use the code on a device of yours, find first RPMs on build.merproject.org and the code in branch “sfos” in my Marble repo clone clones/marble/kossebau/marble on the KDE git servers, see src/apps/marble-maps-sailfishos/ for the app code. Once it’s stable enough the code will be proposed for inclusion in the official Marble repo.
(Update: when installing the RPM on the Jolla phone, make sure you have “qt5-qtscript” installed, pkcon install qt5-qtscript in the terminal should get you there.)

Also looking forward to see the “normal” Marble Maps and other Marble-based apps soon on Plasma Mobile hopefully.
And anyone looking into an Ubuntu Touch version? Would that work with stock Marble Maps, thanks to QtQuick Controls, or would more native UX be needed there as well?

November 21, 2015

Your input, please: naming of action icons (tables, vectorpaths, animation, text, …)

Filed under: Calligra,KDE — by frinring @ 10:14 am

Developing an application where you use or need icons for actions around tables, vectorpaths, animations, text formatting? Looking forward to use Breeze-styled icons, shared with other applications? Then please read on, this is especially for you:

The Breeze iconset currently gets further icons, as needed by the different Calligra apps and plugins. And that are many icons.

Given these icons are then in the public namespace (without any Calligra-specific prefix) and ideally also can be reused by any apps, we need to ensure there are no icon name collisions and also that semantics in the naming are properly done. The XDG Icon Naming Specification currently is leaving a lot of room and surely one day can also get more feedback by the names we start to use here.

Please have a look at the overview of proposed icon names:
https://community.kde.org/Calligra/Icons/3.0
(shows also old custom icons used in Calligra and old custom names).

And then please tell (e.g. by commenting on this post or by replying to the email on ML kde-devel ) where you see chances for improvements. The quicker you comment, the better, because this is WIP and might soon create facts.

While there are naming proposals already for most icons, there are a few in need for any naming proposal at all. So listing them here explicitely once again (see details in the overview page):

  • borderpainter
  • black
  • highlight
  • special_paste

Andreas from the VDG has already started to do and commit first such icons in Breeze style to the repo of Breeze icons, see links below to get an idea what is coming up.
There have been done already quite some Breeze-style icons for LibreOffice. Just, LibreOffice for legacy reason has their own internal icon naming and resource system, so the Breeze icons as created for LibreOffice are not in the normal Breeze iconset and not following the XDG Icon Naming Specification. But by that there is some iconic language existing and SVG code to reuse. Still, this is a big amount of work to be done, so we Calligra developers are very happy that Andreas has started to tackle this!

Initial commits:
Calligra escape directions
Calligra connection line types
Calligra path editing related icons
Calligra Borders for multiple cells icons
Adde dmissing action icons to icons-dark

PS: Anyone a good idea how to embed external SVG files in Community Wiki pages? Using link as plain text only works with PNG files (and once the url ends with “.png”), but not SVG ones.

October 24, 2015

Karbon 3 Alpha: also pure Qt5/KF5 now

Filed under: Calligra,KDE — by frinring @ 12:03 am

On the road to a Calligra with no more need of the porting util KDELibs4Support another milestone has been passed: Karbon now also is based purely on Qt5 and KF5.

Karbon 3 Alpha without KDELibs4Support library

As with the other ported Calligra apps, some small glitches here and there and then the old bugs. Well, work in progress:)

You might have discovered on the screenshot that the Stencil box is shown, which in Calligra versions 2.x and before was exclusive to Calligra Flow. Adding stencils for flow diagrams and other things can be also useful in presentations or text documents, so the Stencil box will be made generally available in Calligra 3. It still needs to be thought about how to perhaps merge it with the general Shape box, that is left for later for now and surely something to work on with the VDG.
Calligra Flow itself has not seen any porting efforts so far, as the plan is to rewrite it using Karbon components, given that Calligra Flow handles the same document type as Karbon, rich vector graphic documents. The main difference has been that Karbon only supports single-page documents, while Calligra Flow also supports multiple pages. And both UIs have been targetting different use cases.
The idea and goal here is the same as with e.g. Calligra Words and Calligra Author: reusing components while providing optimized UI for the different usecases.

For now though we are still in the porting phase: get rid of “KDELibs4Support” completely, fix any regressions and then some bugs, also get all unit tests to pass again. So no dreaming about future features yet, first we need a real base for that.
There are still 21 matches in 16 CMakeLists.txt files on “KDELibs4Support” in Calligra’s codebase, sigh… Calligra Sheets, Calligra Plan and Calligra Gemini are still awaiting their final port. So time to get back to the KDevelop window…😉

October 11, 2015

Calligra Stage 3 Alpha: next pure Qt5/KF5 one

Filed under: Calligra,KDE — by frinring @ 1:01 am

Earlier this week we could report that Calligra Words 3 has joined the club of pure Qt5/KF5 apps, now we can say the same about Calligra Stage 3 Alpha:

Calligra Stage 3 Alpha without KDELibs4Support library

As with Words and the other Calligra apps, Stage of course has seen a few regressions due to the porting, which will be need to be ironed out in the next phase, together with the existing old bugs. Where you are invited to join our efforts!

And quite some code still left which depends on the util KDELibs4Support library (47 matches in all Calligra CMakeLists.txt files). So expect some more success reports about porting away from it😉

In other pure-ness news, we made a decision that was hard to do, but which seems most pragmatic and which has now also reached a milestone: Krita has been split off into a git repository of its own, on its way to become a project pure on its own, outside Calligra.
git clone git://anongit.kde.org/krita
is how you can get Krita code now. The “master” branch of Calligra contains no more Krita code since a few days already. The current 2.9 version will still be maintained and released from the Calligra repo as part of Calligra 2.9, only Krita 3.0 will be the first on its own, and Calligra 3.0 the first without Krita.

This was not done lightheartedly, after all the years in which Krita and the other Calligra apps have been developed together, sharing the same libraries and many plugins and gaining a lot by the resulting synergy. Now with the success of Krita many new developers have joined its development, which is great by itself. Just, most of them are interested in a painting app, but less or not in the other Calligra apps or the abstract middleware for document-content apps, as there is with the Calligra libs. Also with more developers now hacking on Krita only than the rest of Calligra together, enhancing the Calligra libs together was often not possible due to missing time by the other app maintainers, which resulted in more and more Krita-side-only additions to the shared libs. Which made things a lot more complicated for everyone, outweighing any synergy.

All the libs and plugins shared so far have been forked by Krita and are being reduced now to the max. We already made sure Krita 3 and Calligra 3 apps can be nicely co-installed without clashes. We could also see a last synergy: all the Qt5/KF5 porting work on the shared code was done when it was still shared:)
Will be a hard time for developers working on both projects in the beginning due to a lot of code being similar, but no longer the same, but we will manage.

For me this means also that a feature I had on my TODO list will be harder to achieve, with all the brush-engine code from Krita no longer inside the Calligra repo: supporting sketching and scribbling in all kind of documents by pen input, using the great brushes from Krita for better looking strokes etc. But well, I first have to get to this entry in my long TODO list anyway before I think more about it😉

Next Page »

The Toni Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.