I've used ngrx/store and ngrx/effects for a while, and like the pattern. The new version has been released, and here are some of the changes I had to make in my code.

Pre v4 you built your reducers as follows, passing an object with

stateslice: reducerfunction.

const productionReducer = combineReducers(reducers);
export function reducers(state: any, action: any) {
    return productionReducer(state, action);}

StoreModule.forRoot(reducer),

export interface Action {
  type: string;
}

import {Action} from "@ngrx/store";

import {PrintItem} from "../../../models/print.model";


export const ADD_TO_QUEUE = '[Printing] Add to queue';

export const REMOVE_FROM_QUEUE = '[Printing] Remove from queue';

export const MARK_STATUS = '[Printing] mark status';

export class Print implements Action {
    type = ADD_TO_QUEUE;    

constructor(public payload: PrintItem) {}
}

export class PrintDone implements Action {
    type = REMOVE_FROM_QUEUE;    

constructor(public payload: PrintItem) {}
}

export class PrintStatus implements Action {
    type = MARK_STATUS;    

constructor(public payload: PrintItem) {}
}

export type Actions
    = Print
    | PrintStatus
    | PrintDone;

import {PrintState} from "../../../models/print.model";import {ActionReducer} from "@ngrx/store";import * as printingActionTypes from "../actions/printing.actions";

export type Action = printingActionTypes.Actions;
const initialState: PrintState = {
    queue: []
};
export const reducer: ActionReducer = (

    state = initialState, action: Action) => {
    switch (action.type) {

....

In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community, have better supported software on users systems and allow for better quality at the same time.

Where we are going

Traditional model of software deployment

• It’s not unusual that software installed on a “supported” Linux system is outdated and not at all supported upstream anymore on the day it reaches the user. Worse, policies employed by distributions (or more generally, operating system vendors) will prevent some software packages from ever getting an update other than the most critical security fix within the whole support cycle.
• Software out in the wild with its problems isn’t supported upstream, bug reports reaching the upstream developers are often invalid and have been fixed in newer versions, or users are asked to test the latest version, which most of the time isn’t available for their OS — this makes it harder to address problems with the software and it’s frustrating for both, users and developers.
• Even if bugs are fixed in a timely fashion, the likelihood of users of traditional distributions actually receiving these updates without manually installing them is small, especially if users are not aware of it.
• Packaging software for a variety of different distributions is a huge waste of time. While this can be automated to some extent, it’s still less than ideal as work is duplicated, packaging bugs do happen simply because distribution packagers do not fully understand how a specific piece of software is built and best deployed (there’s a wide variety of software after all) and software stacks aren’t often well-aligned. (More on that later!)
• Support cycles differ, leading to two problems:
• Distros need to guarantee support for software they didn’t produce
• Developers are not sure how much value there is in shipping a release and subsequent bugfix releases, since it takes usually at least months until many users upgrade their OS and receive the new version.
• Related to that, it can take a long time until a user confirms a bug fix.
• There is only a small number of distributions who can package every single piece of useful software available. This essentially limits the user’s choice because his niche distro of choice may simply not have all needed software available.

The value of downstreams

One argument that has been made is that downstreams do important work, too. An example for that legal or licensing problems are often found during reviews at SUSE, one of KDE’s downstream partners. These are often fed back to KDE’s developers where the problems can be fixed and be made part of upstream. This doesn’t have to change at all, in fact, with a quicker deployment process, we’re actually able to ship these fixes quicker to users. Likewise, QA that currently happens downstream should actually shift more to upstream so fixes get integrated and deployed quicker.

One big problem that we are currently facing is the variety of software stacks our downstreams use. An example that often bites us is that Linux distributions are combining applications with different versions of Qt. This is not only problematic on desktop form-factors, but has been a significant problem on mobile as well. Running an application against the same version of Qt that developers developed or tested it against means fewer bugs due to a smaller matrix of software stacks, resulting in less user-visible bugs.

In short: We’d be better off if work happening downstream happens more upstream, anyway.

Upstream as software distributor

Software directly from its source

Linux distributors supply a base system, but most of the UI layers, so the user-visible parts come from downstream KDE (or other vendors, but let’s assume KDE for now). The user gets to run a stable base that boots a system that supports all his hardware and gets updated according to the user’s flavor, but the apps and relevant libraries come from upstream KDE, are maintained, tested and deployed from there. For many of the applications, the middle-man is cut out.

This leads to

• vastly reduced packaging efforts of distros as apps are only packaged once, not once per distro.
• much, much shorter delays until a bug fix reaches the user
• stacks that are carefully put together by those that know the apps’ requirements best

Granted, for a large part of the user’s system that stays relatively static, the current way of using packaged software works just fine. What I’m talking about are the bits and pieces that the users relies on for her productivity, the apps that are fast moving, where fixes are more critical to the user’s productivity, or simply where the user wants to stay more up to date.

Containerization allows systemic improvements

In practice, this can be done by making containerized applications more easily available to the users. Discover, Plasma’s software center, can allow the user to install software directly supplied by KDE and allow to keep it up to date. Users can pick where to get software from, but distros can make smart choices for users as well. Leaner distros could even entirely rely on KDE (or other upstreams) shipping applications and fully concentrate on the base system and advancing that part.

Luckily, containerization technologies now allow us to rethink how we supply users with our software and provide opportunities to let native apps on Linux systems catch up with much shorter deployment cycles and less variety in the stack, resulting in higher quality software on our users’ systems.

Hey Community!

Long time no see, huh? Yes, I neglected my blog and as such didn't post anything since Akademy 2014... Interestingly this is the last one where my dear Paul Adams held a famous talk. Talk he is referring to in his latest piece. Since his blog aggregation to Planet KDE is broken, I thought it would be a good idea to relay it on my own blog to give it more exposure. It is reproduced below, if you want to read it in its original form, click through the title.

Paul, the mic is yours now!

Retired From KDE, by Paul Adams

Many of you reading this are probably already aware, long-time maintainer of glibc Roland McGrath has recently retired from maintaining that project. Inspired by his words, I wanted to say a few things about why I no longer contribute to KDE; a project I “retired” from some time ago now.

Recently two very good friends of mine, both long-term KDE contributors, inquired if I was going to be attending this year’s Akademy (the annual KDE conference). Neither were particularly surprised when I said I wasn’t.

I was surprised that they asked.

Getting Into KDE

My first experiences of KDE were many moons ago; sometime in the very early 00s I guess. I had installed Linux on an old machine and was not particularly enjoying the desktop experience.

There wasn’t a desktop.

I cannot remember which distro this was. It had come off some magazine’s cover CD. There was X. And the tiling window manager which allowed me to fill my screen with x-term. This, for a long time, was just how I got stuff done. Emacs, Mutt, Lynx and some weird terminal-based MP3 player were my jam.

Some time later I was reading another magazine (Linux Format?) and it had a review of a recent beta of KDE 2. The sources were included on the cover CD. KDE looked kinda nice. Less boxy and purple than the only other *nix desktop I had seen, CDE. Until I finished my undergraduate degree KDE was my go-to desktop.

Getting Deeper

For a while I had reverted to using a tiling window manager and a screenful of x-term. This was just a convenient way for me to get through my PhD and my day job.

During my PhD I was studying Free Software community productivity metrics. I was also working on research into software quality funded by the European Commission. KDE eV (the governance body¹ for KDE) was also taking part in that project. At this time KDE was almost ready to release KDE 4. It was an exciting time to get involved.

So I installed whatever the Debian stable KDE desktop (3.102193393392393²) of the time and really enjoyed the experience. Having rediscovered my love for KDE and having met some of the active community, I dived in deeper.

KDE became high on my list of projects to study during my PhD. The community was going through major changes: not only was KDE 4 on its way in, but KDE SVN was on its way out.

Gitting Ready For Change

Around 2006 I discovered Ade de Groot’s tool for visualising contributions to SVN; it was part of the English Breakfast Network³. His version of this tool utilised Python’s SVN bindings to read the repo data. Git instinct told me this tool would work faster if it parsed SVN logs rather than read the repo data through a library. I turned out to be right and this was a formative moment in my career.

I created a generic SVN log parser for use by this visualisation tool and used the same parser for other purposes; mostly other visualisations and data plotting. The ultimate aim was to expose to the KDE community what we could learn about social interactions within the community from, arguably, its most important communication tool: the version control system.

KDE SVN was⁴ truly enormous. It was pretty much the largest SVN repo in the wild. One very large central repo which represented the entire body of KDE code/artefacts. Around this time the strains of using such a repo with such a huge (and growing) community were prompting discussion about distributed VCS.

These were remarkably mature and structured discussions. Git was, by no means, a foregone conclusion. Other distributed VCS were given headroom and this was the first (and, basically, last) time I played with Mercurial and Bazaar. The discussions were, for the most part, very technical. I raised my voice to talk about the potential social impacts of switching from SVN to distributed VCS. Any distributed VCS.

Joining KDE eV

I spoke at Akademy and other KDE events (including the KDE 4 launch at the Googleplex) about the research I was doing; either my PhD or the EC-funded stuff. I blogged. I dented⁵. My work was positively received and gearheads would actively reach out to me for more-detailed analysis of their corner of KDE.

I was encouraged to join KDE eV and I did. Given that I had made precisely 0 code contributions⁶ to KDE this, to me, felt like an achievement.

Since day one of my involvement, KDE eV had somewhat of an identity crisis. It was really not 100% clear what it did… but anyone who had been involved with KDE for more than 6 months was highly encouraged to join. Before long it had become bloated; lots of members contributing almost nothing and the few people wanting to do something not getting enough support to do it.

KDE has switched to Git and the social changes were a-happenin’. The KDE project was starting to lose its social cohesion. Post KDE 4.0-release blues, the switch to GIT and a lack of care from KDE eV all contributed here. Other things, too. No one thing started the KDE community’s cohesion degradation. But we felt it. We even went though a rebranding… KDE was not a desktop project, it had become a suite of projects and the desktop was just one of them.

KDE had evolved and I had not.

Cohesion Degredation?

One of the metrics I worked on during my PhD was a simple use of graph theory to measure how well-connected a community is. The contribution I made here was intriguing: as project get bigger they become less cohesive, but through careful community management, luck and clever structure, KDE avoided this.

The last time I properly attended Akademy (the KDE community conference) was back in 2014. I’d been frustrated for some time with my inability to drive home the message that the switch to GIT had o be managed properly. I’d been frustrated that nobody seemed to have noticed that my warnings were coming true.

So I gave a talk that year.

Deep down, I knew this was my last public outing on behalf of KDE. It was. After my talk a lot of people came up to discuss the mic I had just dropped. But as the days and weeks passed after the event, the message disappeared. And so did I.

So Why Are You Telling Us This Now?

This year’s KDE conference starts tomorrow. Two of my all-time best buddy KDE community members reached out to see if I was turning up.

They knew I wasn’t.

While we briefly reminisced by email, one of them pointed out that my talk from 2014 had recently come up in conversation on a KDE mailing list. That, 3 years later, the talk was being used as part of a great discussion about change in the project.

I’m really not sure what my emotion about that was. But, I did not feel compelled to join the discussion. I did not feel a need to remind people about what I was trying to achieve all that time ago. Nope. Instead, I went and pushed some changes to a core plan I had been working on for Habitat, the new home for my free time.

The Thanks

To all my friends in KDE:

Enjoy Akademy. Enjoy the opportunity to do some navel gazing. Enjoy the food, the drinks, the sun. Hack. Break shit and put it back together again. Remind yourselves of why KDE is special. Remind yourselves of why it is important. Very important.

I thank you all for the time we spent together.

We were all part of the solution.

Footnotes

• otherwise throw away no feature branches needed when:
• focused team
• effort predictability

experiments and collaboration implies quantum effect branches

in any case lifetime upper bound

I planned on writing about the Present extension this week, but I’ll postpone this since I’m currently strongly absorbed into finding the last rough edges of a first patch I can show off. I then hope to get some feedback on this from other developers in the xorg-devel mailing list.

Another reason is that I stalled my work on the Present extension for now and try to get first my Xwayland code working. My mentor Daniel recommended that to me since the approach I pursued in my work on Present might be more difficult than I first assessed. At least it is something similar to what other way more experienced developers than myself tried in the past and weren’t able to do according to Daniel. My idea was to make Present flip per CRTC only, but this would clash with Pixmaps being linked to the whole screen only. There are no Pixmaps only for CRTCs in X.

On the other hand when accepting the restriction of only being able to flip one window at a time my code already works quite good. The flipping is smooth and at least in a short test also improved the frame rate. But the main problem I had and still to some degree have, is that stopping the flipping can fail. The reason seems to be that the Present extension sets always the Screen Pixmap on flips. But when I test my work with KWin, it drives Xwayland in rootless mode, i.e. without a Screen Pixmap and only the Window Pixmaps. I’m currently looking into how to circumvent this in Xwayland. I think it’s possible, but I need to look very carefully on how to change the process in order to not forget necessary cleanups on the flipped Pixmaps. I hope though that I’m able to solve these issues already this weekend and then get some feedback on the xorg-devel mailing list.

As always you can find my latest work on my working branch on GitHub.

It's with all the joy in my heart that I share with you this amazing notice: AtCore was officially moved today to KDE Extragear by my favorite sysadmin Ben Cooksley after more than a month on KDE Review. This is the first huge milestone that we achieve on this 11 months of team work made [...]

This release includes all the feature-enhancements the Linux version has received (frameworks announcements for 5.36.0)

– Actually working spell-checking.
– Possibility to switch interface language.

EDIT: Adding an extra fall-back UI language does not wok properly yet.

Kate in Sweedish

Grab it now at download.kde.org:  Kate-setup-17.04.3-KF5.36-32bit or Kate-setup-17.04.3-KF5.36-64bit

When I released Brooklyn v0.1 complaints arose from the fact that it is written in Java.
A lot of criticisms come from users that probably wrote Java code when it was born.
The language is constantly changing and I decided to use Java 8 as the primary language for Brooklyn.
I'm writing this blog post because while I was learning new features I realized that there is an enormous difference between studying something and applying what you have studied in a practical scenario.
I'll keep writing posts like that, and I want to write much more if I receive a good feedback!

Avoid null pointer exceptions
Imagine that you've a Bot interface with a method sendMessage and three classes that implements that: IrcBot, TelegramBot and RocketChatBot.
sendMessage returns a string which contains the messageId returned from the bot; the main problem is that there are bots like IrcBot which can send messages to IRC, but the protocol doesn't support messages identification.

What should you do? The first thing you can come to your mind is to return a null:

public interface Bot {
 String sendMessage(...);
}

public final class TelegramBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return msgId;
 }
}

public final class IrcBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return null;
 }
}

public interface Bot {
 Optional<String> sendMessage(...);
}

public final class TelegramBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return Optional.of(msgId);
 }
}

public final class IrcBot implements Bot {
 @Override
 public String sendMessage(...) {
  // Message is sent here

  return Optional.empty();
 }
}

if(result.isPresent()) {
 String msgId = result.get();
 System.out.println(msgId);
}

Optional<File> file;
File fileNull = x.getFile();
if(null == fileNull)
 file = Optional.empty();
else
 file = Optional.of(fileNull);

Time to fly off to the sun to meet KDE friends old and new and plan out the next year of freedom fighting. See you in Almería!

by

I completed the Oware two player mode as described in my previous blog post GSoC-First month analysis. This month was the time for the single player mode. So well it started well, I implemented the alpha beta pruning for the AI mode.

The levels are structured in the following way:

1. For the initial levels the AI is random which sows randomly from its houses. But if the computer gets in a bad position or is losing badly then it switches to AI mode. A maxDiff is maintained for each level, for example level 1 has maxDiff = 20, level 2 has maxDiff = 15 and so on. So as soon as the computer/AI is behind the player by maxDiff it switches to AI mode.
2. For the last levels there is no random selection so basically maxDiff = 0.

I also had been working on the animation of seeds which involves movement of the seeds from one house to another. It still has some issues left involving the animation being triggered at each step.

There are also some changes in my GSoC plan. I thought of working on computer activity after oware earlier when I made my proposal but with discussions with my mentors we came to a conclusion that musical activities are more important for a child. So I would be working on musical activities now which includes play piano and note names activity which were started in the branch Play piano and were earlier to be done in my last month. My aim would be to complete both these activities.

I planned to go to Akademy this week and meet everyone but well my visa got refused :( I will try to be a part next year and I hope I get the chance of meeting everyone (especially my mentors soon). I will cover more about the musical activities and my progress in my next blog post :)

I’m currently in my final preparations for this year’s Akademy.

For people unaware of this conference, it is the annual conference of KDE contributors.

We tend to have a few dozen of high quality talks on various topics ranging from art and community building, to hard-core Qt and C++ talks.

This year, I’m going to have two talks. One on (obviously :) ) functional programming in C++, and one on C++17 and 20. The later one will be a bit self-serving because I’d like us to raise the compiler requirements for our software so that we could enjoy working in KDE even more.

The only thing more important than talks is the period after where the different teams within KDE meet-up to discuss the future plans. While we do it all the time on IRC and on the mailing lists, having face-to-face meetings is irreplaceable.

If you are near Almeria, join us – the conference is free for attendance!

Hi everyone!
As the title of this blog post suggests, the first evaluation has been successfully passed, the project accomplishing all the proposed goals. Thus, let me present you the progress I’ve done for the first evaluation.

• The very first thing I’ve took care was allowing multiple-instrument visualization framework, by modifying the old core architecture of Minuet. Instead of the one and only keyboard instrument, Minuet is now providing an instrument tab bar, enabling the end user select the desired instrument. The tab bar is currently loading the instrument within the first tab as default. After I’ve discussed with my mentor, Sandro, I decided to keep the piano keyboard as the default instrument contained by the first tab. In order to keep all the functionalities available and a simple architecture at the same time, I’ve created an InstrumentView wrapper above all the instruments. Its methods are called by the core ExerciseView, calling in turn the methods that each instrument should implement.

• After changing the Minuet’s core in order to provide a multi-instrument framework, I started refactoring the piano keyboard view as a separate plug-in. Basically, for Minuet, a plug-in is nothing more than a bunch of QML files and a simple JSON file parsed in order to learn about the QML files’ location and load them dynamically in the instrument tab bar.

The next goal was to install each instrument separately as a plug-in, besides all other Minuet’s plug-ins. Like any other KDE application, Minuet, keeps its data files into /usr/share/ file-system directory. Thus, this was the place where our plug-ins had to be installed; actually, the exact path is /usr/share/minuet/plugins/. Installing a plug-in is simply done by using a CMakeLists.txt file telling the build system where the plug-in files should be installed.

Plug-ins are loaded as follows: firstly Minuet searches for plug-ins location and if the search succeeds, it will iterate through each instrument’s JSON file, building a QJsonArray containing the plugin name and path. This QJsonArray is passed to the InstrumentView, setting the contents of the Instrument Tab Bar. Having all the tabs ready, the TabBar will just wait for a tab to be selected and a QML file to be loaded.

• Having the multiple instruments framework and piano plug-in ready, the next step was to test and analyze the code for possible technical issues or bugs. Also, a general clean-up was required before submitting the code for the review and first Google Summer of Code evaluation.

These are the achievements I’ve met for the first evaluation. Let’s discuss now about the current progress for the next evaluation:

• I wrote a proper and comprehensive documentation for the piano plug-in, enabling anyone to create his/her own instruments plug-ins and loading them dynamically into Minuet.
• I started implementing a new instrument from scratch. As I am very passionate about guitar, I chose to integrate it into Minuet’s instruments suite. Thus, I have already designed the visuals for the Guitar plug-in and added it into Minuet’s instrument tab bar. Now, I need to link the GUI to the core, work on the guitar’s specifics and make the plug-in fully functional.

In conclusion, GSoC proves to be a great experience thus far, being a pleasure to work on a project focused mainly on a subject I’m in love with: music. For further cool news, stay tuned!

A lot of implementation changes were introduced

• Selection highlights depends upon the items selected in the model.
  • Previously, the selection higlights toggled when the SelectionButton for an image was clicked
  • Now the higlighted images are shown according to the items selected and stored in the selection model
    
    
• Completely removed baloo dependency
  
  
• For “By Folder” filter KIO based model is used for folder representation of images.
  • It shows the mixed images and folders in the AlbumView.
  • It shows the images in hierarchical structure, as they are represented in the memory. Just like a file manager would represent, but just the images and folders.
    
    
    
    
• Adds a new ImageListModel
  • This model would just store the image list irrespective of whether they are from ImageLocationModel or ImageTimeModel.
  • This made the representation of images in the GridView and the ImageViewer a lot more easier
    
    
• Better implementation of ImageViewer done by Marco Martin
  • Better animations for ImageViewer to appear and disappear.
  • Pinch zoom for the single Image appearing in the ImageViewer.
  • Zoom animations for the images in ImageViewer. Zoom on double clicking the image as well as on Ctrl + wheel action
    
    

    Normal Image
    
    Zoom on Double Click
    
    Ctrl + wheel Zoom
    
    

• Automatic updation of the currentIndex for the GridView if the index changes in the ImageViewer.
  
  
• Makes the thumbnailer code common to all the models.
  • Faster loading of thumbnails for the GridView.
    
    
• Totally removed the old code base qml implementation.
  
  
• Adds KDirNotify and KDirWatch to support live updates of the data in the time and location collections as well.
  • We don’t need to add KDirNotify and KDirWatch to the ImageFolderModel since it subclasses KDirModel which already takes care of the changes.
  • KDirWatch uses the concept of singleton object ie we can use just a single instance of the KDirWatch class for the entire application.
    
    
• Makes the enums common for all the models.
  
  
• i18n’z all the text elements.
  
  
• Creates a different SortModel for the ImageViewer to apply sort as well as the filter to show just the images.
  
  
• Adds contextualActions to the AlbumView.
  • For now three actions are added Select all, Deselect all and Delete selections.
  • These actions can just be applied on the images and not on the collections or folders.
    
    
• Selectively loads desktop and mobile user interface depending upon whether the environment variable QT_QUICK_CONTROLS_MOBILE is set or not.
  
  
  • There is just single difference between mobile UI and desktop UI, that is of the contextualActions. For desktop version these appear on the toolbar and for mobile version these appear in the contextDrawer.
  • Rest of the changes are handled brilliantly by the Kirigami.
    
    

    Desktop UI
    
    Mobile UI

• Adds a selection mode for mobiles that is activated on pressAndHold.
  
  

  On PressAndHold

• Opens a specific image via the commandline.
  • That allows us to open the image from the file manager also.
  • It takes you directly to the single image in the ImageViewer
  • It also pushes the intermediate folders into the pageStack(that contains AlbumView) starting from the standard Pictures location to the folder containing the image, for the “By Folder” filter.
  • If the image is not in the Pictures location then it just pushes the folder into the pageStack(that contains AlbumView).
  • Though this is not perfect yet. The problem is that the SortModel(QSortFilterProxyModel) in the ImageViewer is populating in pieces that is first when the sourceModel for the model in ImageViewer is set to specific ImageFolderModel with empty data (I think) and then again the rowsInserted signal is emitted and the model is populated again and thus making the rowCount to double of the actual number of images, which then makes the currentIndex in the ImageViewer invalid(-1) at the beginning and hence the navigation starts from the first image in the list instead of the selected image. Searching for the alternatives :)
    
    
• PS: The background shown in the application is theme dependent. This is Breeze-dark theme

In my last post, I talked about adding a grid layout to the activity. The inspiration of this layout was to remove the trial and error method of selecting (x,y) positions of a node and to implement a more efficient method of positioning the nodes. Along with that, the distance between two generations and nodes could also be maintained in a homogeneous manner, keeping the layout similar throughout the activity.

As it also turned out, the grid layout along with knowing the width and height of the node also helped in accurately positioning the edges, the effect of which will be shown in a few before-after screenshots later in this post

Implementation

Vertically, the screen is divided into three equal parts (representing three generations), represented as:

readonly property real gen_1: 0.10
readonly property real gen_2: 0.40
readonly property real gen_3: 0.70

Here, gen_1, gen_2 and gen_3 represent 1st, 2nd and 3rd generation.

Horizontally, the area was originally divided into three parts:

readonly property real left: 0.2
readonly property real center: 0.4
readonly property real right: 0.6

Aside from this, we also divided the horizontal area into four other slots, which will be necessary as it turned out later:

readonly property real left_1: 0.1
readonly property real left_2: 0.3
readonly property real right_1: 0.5
readonly property real right_2: 0.7

The nodes

The arrangement of the nodes are very simple, in which we are avoiding the problem of arranging the nodes via trial and error of the (x,y) position. The x-coordinate can be determined by selecting the best among left, right and center or among left_x or right_x (where x = 1, 2) as mentioned above and the y-coordinate can be determined via selecting the best among gen_1, gen_2 or gen_3, depending on the generation of the node.

As an example, for level 11, we define the nodePositions as follow:

nodePositions: [
        [center, gen_1],
        [left, gen_2],
        [right, gen_2],
        [left, gen_3]
]

As we can see from the level, it can be seen that it is very intuitive to determine the node positions for a given level, once we know the type of the node.

The edges

The start-end position of the edges can also be determined via the properties mentioned above along with the nodeWidth and nodeHeight properties mentioned in the previous blog post. For level 11, we calculate the edge positions as:

edgeList: [
        [center + nodeWidth / 2, gen_1 + nodeHeight, center + nodeWidth / 2, gen_2 + nodeHeight / 2],
        [rightXEdge(left), nodeMidPointY(gen_2), right, nodeMidPointY(gen_2)],
        [left + nodeWidth / 2, gen_2 + nodeHeight, left + nodeWidth / 2, gen_3]
]

As a result of these, level 11 turned out to be like this:

How it all turned up

The layout has come a long way since it was started from the beginning of the second phase of GSoC, and here are the before and after screenshots of the family activity

Initial layout of level 18

Current layout of level 18

Initial layout of level 6

Current layout of level 6

What’s Next

I have started working on the extension of the Family activity, the goal of which is: given a relation, the user will have to find the pair that demonstrate the given relation. I will be documenting the progress of the activity once that is near completion, hopefully by the end of this week.

Relevant links

• GSoC Proposal
• Phabricator task
• Development branch
• KDE Status Report

Highlighting

Renaming

Very basic code completion

This is the third post in my GSoC series. You can read the second one here.

Hey there, a few weeks has passed since my last blog post. I promised to make a new post as soon as I had something cool to show off. Well, after working hard for a lot of time, I can finally show you how the project is taking shape.

First of all let me say that everything I am going to show you is still in heavy development and, as of right now, it does look a bit ugly. But don’t worry, it will start looking better in the next weeks.

The code for the frontend is available here.

Browsing courses

The first thing I am going to present you are the basic browsing functionalities. The user is able to browse departments (the top level categories of the website), courses and read pages.

The home page. Ugly but functional

A course index. The Lorem Ipsum is just there as a placeholder

The pages are fetching the data from a backend server that I am also developing during this GSoC. This server acts a compatibility layer between the current backend and this new frontend. I will write a blog post in the future about this service because it is based on an interesting architectural pattern: backend-for-frontend.

Ui Library

Together with the browsing functionalities I started developing a simple UI library to use with the new WebApp.

The UI Elements are customizable and will be used in the rest of the project.

For example take a look at this confirm dialog

or at this Edit Page button

Building an UI Library is a very long process, that’s why another WikiToLearn developer (Demetrio Carrara) is helping me in the development of this UI Library, he designed and built input boxes and added a few styles to the buttons.

This way I can concetrate in the development of the main functionalities.

Async operations

Another interesting feature I worked on, is the support for polling operations. Right now on the website when downloading a PDF for a course you have to stare at a loading bar for a few seconds (sometimes even a minute or two), this is not ideal. That’s why with this new Web App we are going to execute these long operations in the background, without having the user look at a loading bar.

Take a look at this video. I am clicking a button to start a long operations (which as of right now does nothing) and while the operation is in progress (you can see it in the lower right part of the screen) I am still able to browse the website.

There is still some work to do, for example adding some kind of notification once the operation is complete, or letting the user close the browser without losing the operations, but the basics are already implemented.

Other details

As you can see on the video above there are transitions and loading bars when switching between pages, this is very helpful for the user, the browsing experience is much smoother.

The Web App is also quite lightweight, the external libraries and the code are less than 70KB to download, and once they are cached (this means from the second refresh of the page) they load in no time.

The Web App also supports full HTTP codes when responding to the browser: not many Web Apps do this, but after a few days experimenting and developing various solutions I found the best one and decided to use it.

What’s next?

Right now I am experimenting with user authentication. The available solutions (actually the only solution) for authenticating users that is compatible with Vue does not support Server Side Rendering, which is a must for my web application. This probably means I will have to fork the library and implement support for our use case. This could slow down the development of the web app but at the same time it will be great to contribute to an external project.

I am also working on deploying the Web App on a real and public server, making it available for everyone. It is far from usable by common users but it is a nice way to keep track of progress.

As always thanks for reading and don’t be afraid to leave comments!

This is a short public service announcement: KWin master as of today requires a compiler which supports C++14. This means at least gcc 5 or clang 3.4. All major distributions support at least one of the two.

Me, Shaza, and Ahmed

It was nice meeting Ahmed and Shaza @ faculty of Engineering, Ain Shams University in Cairo. I am proud to mentor them in Google Summer of Code.

Ahmed is working on implementing a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server is ready and he working on the configuration panel UI. See more here.

Shaza is working on a tool for image editor to be used for healing image stains with the use of another part of the image by coloring by the use of one part over the other, mainly testing on dust spots, but can be used for other particles hiding as well. See more here.

 KSysGuard — the system monitor — on FreeBSD seems oddly precise. This machine with FreeBSD 10.3 and KDE Applications 17.04.2 installed, tells me that I have 3,274,960.000000 KiB memory in use. That is, three million, two hundred seventy four thousand, nine hundred and sixty kibibytes. I’m willing to believe that, since notionally the machine has 4GB installed and FreeBSD uses up memory until it’s full and so memory use rarely reports much unused. What I’m less inclined to believe is the .000000 part of the measure: and zero millionths of a kibibyte. So that’s a .. um .. more than a millibyte, and a smidgen less than one one-hundred-twenty-secondth of a bit.

So, dragging in some information theory and plugging in some values,  using the binary entropy function, Wolfram Alpha tells me that

p ≈ 0.999314653604933

so we can be ninety-nine point nine percent sure that that is my actual memory use.

Sometimes it’s good to be precise.