 Hi everyone, I am Shashwath, a GSOC 2020 student working on the project Etisync Sync backend for Econadi. My project is about adding a new sync functionality to KDPM apps. All KDPM apps that come under contact like KAddressbook and KOrganizer can currently sync the user's personal information through a variety of services like Google Contacts, Google Calendars, Microsoft EWS, DAVGRAPHIA servers and others. So the aim is to add to this list a secure end-to-end encrypted open-source sync solution called Etisync. So a little more about what Etisync is. So Etisync as I said is a secure end-to-end encrypted open-source solution for your contacts, calendars and tasks. Etisync clients are available for a number of platforms including Android, iOS, the desktop CalDAF CardDAF bridge, the web client and a Thunderbird plugin has been developed recently. The server is also open-source and can be self-hosted. Etisync integrates really well with your existing applications. For example on Android, you could simply download the Etisync app and use your favorite calendar app to sync your Etisync events. Now a little about Econadi. So Econadi is the backend framework for storage, indexing and retrieval of the user's personal information like contacts, calendars and tasks. So the benefit of Econadi is that it provides a centralized system for user data management. Otherwise, all PIM apps would have their own cache and data management. Econadi provides an extensive client API to make development easier. One such implementation is called the Econadi resource. So all external services that are integrated into contact like as I said Google, Microsoft or the DAF servers, all these external services have their resources. Have Econadi resources running which interface between Econadi and your server. So my work is to make a new resource to enable native Etisync integration in Econadi. Note that users could previously also use Etisync by setting up the Etisync DAF bridge and using the DAF resource. But my project enables native Etisync integration, which is clearly better. So the project status is that the resource is ready for beta testing and we would love to have more testers. So do reach out if you are interested. I'll give a small demo of the working resource. So here I have the organizer open. I can add a calendar and the Etisync entry shows up. So I'll add my test credentials. I have locally hosted the server and that's why this IP is a local IP. I enter my Etisync encryption password and all the events are fetched. So we can also add a new event. Let's call this test event 6 and we can go to the Etisync web client and refresh this to see that it has been fetched. So similarly K address books syncs all your address books and contacts. So for example, if I delete this contact here and if I go to the web client and refresh it, you can see the contact is deleted from Etisync. So there's a lot more than this demo shows including journal edition collection, journal edition modification, deletion and item modification. But that's it for this presentation. To know more about the project, you can join the IRC channels hash, economic and hash Etisync. You can read more about the project and the status updates on my blog or the Etisync blog or you could also contact me directly. So thank you all. Thanks a lot for listening. That's it. Myself Shivam Balikonwar, I worked on adding file processing for Rockside during season of KD in your 2020 this summer, particularly introduction about me. So I contributed for, as I already said, I contributed for KD and in the past also contributed from Chromium and Linux as well in Rush, C++ and related to compilers and operating systems. Coming back to my project we're doing this, that's okay. So first I'll start with the basic part, what are files? So file is a collection of data, when we structurally logically array this data into hierarchical data structure, then we have this respective file formats. In this case we went with KML file format. So how about this file format process? First the Rockside opens the file, imports it as a bit stream. Now from that stream, we have file parsers, written using QI parsers in even notation grammar. So using this grammar, the parser parsers this stream and creates a parse tree out of that. From this parse tree, we can generate tokens which give the real information data which is stored in the respective files for the respective file format, which in this case is the KML. So coming to the work that was done during the SDK, for the first week there was a debate regarding why was KML an important file format that was required in Rockside. So the reason was obvious because it was widely used, it is widely used today and it is user friendly and easy to read and visualize. So that was the main reason behind this. During this my mentor, Sao Donati, helped me in guiding me through this entire network. Till now after this first week, there was a second and third week where I invested in discussing the file structure, researching on other file formats and learning from them. And after researching and documenting an approach on the right hand side, as you can see, this is the file structure of KML in Rockside that is for that we have implemented parser and grammar. So using this parser and grammar, we are able to import and process this file format and generate tokens out of it. So it's the progress till now and from the table, you can see the information regarding the various tags and the information, the data that these tags contain. Coming up, the REST part is integrating this parser with a graph engine, which will import the tokens and create graph out of it and testing and documentation. Now on the right side, you can see the screen shot of what will be the KML file structure look like. You can have graph drive, then types, directed, then IDs for nodes, then color for this node, then edge defining the different edge from one node to another and connect to connect one node to other and its respective color representation. In the visualization, you can see is directed to B and is directed to C, the edges of blue and the node as well as blue with IDs, A, B and C. And on the left hand side, we have the parser implementation that is currently implemented. From the entire SOK, I learned it was quite a great experience for me. I learned the value of open source, software development, then the positivity of community, which helped young developers to get a head start in open source and making your contributions for it. And also, both C++ library and pipe processing, which was my main interest behind this contribution. So that's all from myself. Thank you. Hello, everyone. My name is Paritosh and I'm working on a QT3D based back end for KSTARS in my Google summer of code 2020. My mentors are Mike Kruse and Jason Mutlak and you can contact me using this. So let's begin. So first I'll start by introducing what a planetarium software is. It's simply a program that simulates the night sky at any location of the Earth at any given time. And there are separate planetarium software such as Telerium, KSTARS, Skymap, formerly known as Google Skymap. Now there are mostly two parts to this planetarium software. The one part, it focuses on getting the data of the positions of the object in 3D or 2D coordinates. And the second part is the drawing part, which actually draws the sky objects from the data. Now softwares like Telerium, they are capable of drawing in 3D. However, other softwares like KSTARS, they currently only use a 2D based back end. For 2D we have a popular back end known as Q-Painter and there was also work on an open GL version. Right now what we aim in this project is to add a 3D back end and which will be based on a QT 3D based framework. So this is a brief overview of how KSTARS actually draws the sky objects. As I said, there's a information bit or a data bit and a draw bit. So we have the information in KSTARS and we have a class known as Skymap, which is actually the widget on which everything is drawn. So Skymap actually can use either Skymap Q draw or Skymap GL draw. And this Q draw, this actually is the Q-Painter based back end widget and the GL draw is the open GL based back end widget. Again, we have something known as the Skymap composite and this is where everything is drawn. This controls the draw calls for each sky object and this sky object is just a base class for each and everything. This includes planets and comets, moon, everything. The individual classes of these have the draw call which could either utilize Q-Painter or open GL and this has been served using a common interface SkyPainter. Now since the SkyPainter draw calls which are called in the SkyObject class, they occur at every paint event. So we can't utilize QT3D using this interface. We can't do this. And the reason behind this is because QT3D utilizes something known as scene graph as its drawing principle and which basically means you have to give all the information to QT3D and it will handle the drawing. Thus, the only solution to solving this problem is actually having both initialization and update draw calls in Skymap composite and this means each and every sky object that needs to have these two calls. And the initialization call it will be utilized to use to initialize the scene graph and the update call will just use a transformation coordinates or anything related to projections or colors. So this was what I said in the previous slide. We have a custom window which is derived from the QT3D window and each SkyObject it has the option to actually modify the QT3D window which the custom window we have used here and this will have calls for everything. This includes initializing some SkyObject be it a planet or a moon or anything and even for updates, update calls for all those. So till now we mainly discussed the integration section that is how to integrate QT3D inside case charts. Now we are talking about some technicalities related to drawing as in using that back end to draw in 3D and this mainly covers two main topics which is astronomical predictions and instance standard. So we generally when we use 3D software or we play 3D games we actually use something known as perspective or orthogonal projection. They however don't apply for astronomical soft softwares and for astronomical softwares we have a set of six projections inside case charts. These include Lambert or EQV rectangular etc. The main complexion was to employ these projections inside the shaders and when we are drawing it. So instead of the X, Y or Z coordinate which is served which is given to the S vertex position to the vertex shader while drawing we have actually to have to give the right ascension and the declination of the SkyObject to the vertex shader and this will actually project it using one of the six projection astronomical projections. And project them on a 2D screen and then it is further given to the fragment shader and the coloring etc. So this was a difficult bit to tackle and was the first problem in the drawing side. The second problem is related to instance rendering. So as case charts it can have a lot of stars or a lot of SkyObjects and we can't draw all of them individually by giving like separate buffers for every every time we send shader info to a graphic card. To solve this we use something known as instance rendering which is we give all the vertex positions and other shader information in the that is the other shader parameters in just one buffer and it handles the drawing for multiple objects at the same time. So instance rendering was utilized throughout case charts and most importantly when we use it to draw stars and the grid. So this can include the grid lines which are similar to latitude of latitude or longitude for lantanetarium softwares. So for example for rendering stars we actually just place the points at the given write its ascension and declination for that projection and then we pass in this happens in the vertex shader and then we pass it to a geometric shader which is someone's cortilateral at that particular point and it has the texture for the star we want to draw and then it is passed to the fragment shader. The results and as you can see we have our sun we have a few grid lines we have a few stars and some keyboard and mouse actions are working right now. This includes zooming and panning and changing predictions or turning off the particular sky object. Similarly we have more textures and we'll add more 3d models for the other sky objects as well. So this was my work and thank you and you are free to ask any queries that you have. Hello everyone my name is Anuj Bansal and I'm a final year undergraduate student from India. I have been working with the KDE web team since December 2019 and I'm currently working on improving the web infrastructure for KDE as part of Google Summer of Code 2020. My GSOC project consists of two parts. As the first part of my project I worked on porting KDE's main website kde.org to Hugo. The website is currently built using PHP. Now the website for the most part is a static website and the parts of it that are dynamic like the applications page have already been built as a sub-site. So it doesn't make a lot of sense to use PHP for it. There's also a lot of problems like slow build times and the need for manual work. For example the list of announcements on the website is built manually by adding each announcement to a list. This is where Hugo comes into play. Hugo is a static site generator based on Golang and provides great speed and flexibility. It solves many of the problems with the PHP site. It allows us to construct layouts which reduce the amount of duplicate code. For example every announcement only changes slightly from the other ones so we can have a layout that has the dynamic part inserted into it. There are also Hugo shortcuts that are sort of like functions that provide some syntactic sugar. I can use the single line of code to embed a youtube video into a page and we can also create some custom shortcuts for some functionality. I'm happy to say that this part of my project is now complete and is now being tested after which it can be deployed. The second part of my project involves a complete revamp of the season of KDE website. The website now looks much more modern and mobile friendly. The website now also uses the new OAuth based identity service that is currently being built by my mentor Carl. Some of the new functionality on the website includes a nice and easy to use admin panel, badges assigned to students and mentors and the support for multiple mentors for a project. One of the most helpful new features I believe would be the new markdown support. The students can have much more detailed and nice looking proposals. Some of the students may remember some random html being added to their proposal from last year. Currently I'm working on adding the ability for the mentors and students to be able to comment on the proposals for feedback and also automatic certificate generation at the end of the program. Finally I would like to say that it has been a wonderful experience contributing to the KDE community. That's all from me. Thank you so much for listening to me. Have a wonderful day.