Re: Thoughts on the Plasma Mobile calendar
On 22/6/21 7:56 μ.μ., Aleix Pol wrote: > On Mon, Jun 21, 2021 at 8:15 PM Dimitris Kardarakos > wrote: >> On 21/6/21 8:12 μ.μ., Carl Schwan wrote: >>> Le lundi 21 juin 2021 à 18:41, Dimitris Kardarakos a >>> écrit : >>> >>>> Hello everyone, >>>> >>>> Back in 2018, the Plasma Mobile ecosystem consisted of just a handful of >>>> apps. After a short discussion with Bhushan, I stepped forward to work >>>> on Calindori, the calendar application for Plasma Mobile. >>>> Calindori is written in QML/C++, it is based on Kirigami and (tries to) >>>> follow the KDE HIG. As a Kirigami based application, it can also run on >>>> desktop. In particular, some desktop specific bits have also been added >>>> to improve the desktop UI/UX. You can find more details here [1] >>>> During Akademy 2019 in Milan, Nicolas Fella suggested that a plugin >>>> system is created [2] that would make Calindori (or any other >>> application that uses KCalendarCore) support various calendar backends. >>>> So, I have been maintaining Calindori trying to fulfill these requirements: >>>> >>>> 1. Offer a mobile application, and try to leverage Kirigami convergence >>>> capabilities to improve the desktop experience >>>> 2. Support calendars that follow the iCalendar [3] standard using >>>> KCalendarCore [4] >>>> 3. Avoid to tightly couple the application with a specific calendar >>>> backend (e.g Akonadi, Sink, etc) >>>> 4. Adopt the plugin based approach for multiple calendars and online >>>> synchronization support [5] >>>> Let me now share my thoughts on the the "Plasma Mobile - Calendar" [6] >>>> Google SOC project (you can track its progress here [7]). >>>> People in the free software ecosystem are free to work on any project >>>> they feel like. Certainly, the Google SOC mentor(s) may have a plan >>>> that >>>> is not compatible with Calindori. However, I started Calindori in order >>>> to enhance the Plasma Mobile ecosystem and have been trying hard to >>>> maintain it over my limited volunteer contributor time. I am not >>>> interested in entering in competition with anyone within the Plasma >>>> Mobile team and the KDE community in general. >>>> With all this in mind, if the Plasma Mobile team is not happy with the >>>> approach of a Plasma Mobile calendar mentioned above and/or my work in >>>> general, and they would like to adopt the Google SOC project approach, >>>> I >>>> can step down as Calindori maintainer. Then, the Google SOC mentor(s) >>>> could take over maintenance and merge their work with Calindori or just >>>> continue with a separate application. >>> >>> Hi Dimitry, >>> >>> I'm sorry that you feel hurt. This wasn't my intention. My goal wasn't to >>> create a competition between Calindori and Kalendar when I started Kalendar >>> 4 months ago and QuickMail. When I was working on some Kirigami Calendar >>> components and Plasma Desktop Calendar redesign, I discussed with you the >>> possibility to redesign Calindori, you weren't very enthusiastic about >>> making >>> Calindori more complex and for example moving some view from simple ListView >>> to more complex views with the goal to make Calindori also great on the >>> desktop >>> and more feature-complete with Korganizer. >>> >>> And to be fair, I wasn't very enthusiastic either with the plugin system >>> My reasoning is that Akonadi is already an abstraction and adding an >>> additional >>> abstraction on top for viewing events, editing events, adding calendars, >>> configuring calendars wouldn't be really easy to create and maintain. It >>> doesn't >>> help that some data like the calendar name or the event colors are stored in >>> Akonadi/Sink instead of KCalendarCore. I might be wrong though. >>> >>> Maybe we should set up a bof during Akademy and discuss this a bit? Merging >>> our efforts or creating shared calendar components could be a good idea? >>> >>> Regards, >>> Carl >>> >>>> >>>> [1] https://invent.kde.org/plasma-mobile/calindori >>>> [2] https://phabricator.kde.org/D24443 >>>> [3] https://tools.ietf.org/html/rfc5545 >>>> [4] https:/
Re: Thoughts on the Plasma Mobile calendar
On 21/6/21 8:12 μ.μ., Carl Schwan wrote: > Le lundi 21 juin 2021 à 18:41, Dimitris Kardarakos a > écrit : > >> Hello everyone, >> >> Back in 2018, the Plasma Mobile ecosystem consisted of just a handful of >> apps. After a short discussion with Bhushan, I stepped forward to work >> on Calindori, the calendar application for Plasma Mobile. >> Calindori is written in QML/C++, it is based on Kirigami and (tries to) >> follow the KDE HIG. As a Kirigami based application, it can also run on >> desktop. In particular, some desktop specific bits have also been added >> to improve the desktop UI/UX. You can find more details here [1] >> During Akademy 2019 in Milan, Nicolas Fella suggested that a plugin >> system is created [2] that would make Calindori (or any other > application that uses KCalendarCore) support various calendar backends. >> So, I have been maintaining Calindori trying to fulfill these requirements: >> >> 1. Offer a mobile application, and try to leverage Kirigami convergence >> capabilities to improve the desktop experience >> 2. Support calendars that follow the iCalendar [3] standard using >> KCalendarCore [4] >> 3. Avoid to tightly couple the application with a specific calendar >> backend (e.g Akonadi, Sink, etc) >> 4. Adopt the plugin based approach for multiple calendars and online >> synchronization support [5] >> Let me now share my thoughts on the the "Plasma Mobile - Calendar" [6] >> Google SOC project (you can track its progress here [7]). >> People in the free software ecosystem are free to work on any project >> they feel like. Certainly, the Google SOC mentor(s) may have a plan that >> is not compatible with Calindori. However, I started Calindori in order >> to enhance the Plasma Mobile ecosystem and have been trying hard to >> maintain it over my limited volunteer contributor time. I am not >> interested in entering in competition with anyone within the Plasma >> Mobile team and the KDE community in general. >> With all this in mind, if the Plasma Mobile team is not happy with the >> approach of a Plasma Mobile calendar mentioned above and/or my work in >> general, and they would like to adopt the Google SOC project approach, I >> can step down as Calindori maintainer. Then, the Google SOC mentor(s) >> could take over maintenance and merge their work with Calindori or just >> continue with a separate application. > > Hi Dimitry, > > I'm sorry that you feel hurt. This wasn't my intention. My goal wasn't to > create a competition between Calindori and Kalendar when I started Kalendar > 4 months ago and QuickMail. When I was working on some Kirigami Calendar > components and Plasma Desktop Calendar redesign, I discussed with you the > possibility to redesign Calindori, you weren't very enthusiastic about making > Calindori more complex and for example moving some view from simple ListView > to more complex views with the goal to make Calindori also great on the > desktop > and more feature-complete with Korganizer. > > And to be fair, I wasn't very enthusiastic either with the plugin system > My reasoning is that Akonadi is already an abstraction and adding an > additional > abstraction on top for viewing events, editing events, adding calendars, > configuring calendars wouldn't be really easy to create and maintain. It > doesn't > help that some data like the calendar name or the event colors are stored in > Akonadi/Sink instead of KCalendarCore. I might be wrong though. > > Maybe we should set up a bof during Akademy and discuss this a bit? Merging > our efforts or creating shared calendar components could be a good idea? > > Regards, > Carl > >> >> [1] https://invent.kde.org/plasma-mobile/calindori >> [2] https://phabricator.kde.org/D24443 >> [3] https://tools.ietf.org/html/rfc5545 >> [4] https://api.kde.org/frameworks/kcalendarcore/html/index.html >> [5] https://invent.kde.org/plasma-mobile/calindori/-/merge_requests/37 >> [6] https://community.kde.org/GSoC/2021/Ideas >> [7] >> https://claudiocambra.com/2021/06/14/first-week-of-google-summer-of-code-2021/ >> >> All the best, >> >> -- >> >> Dimitris >> >> https://dimitris.cc Hello Carl, let me disagree with you on the content of the discussion we had in the past. In particular, we had an one-off short and friendly chat on Matrix where I was pretty open to any kind of UI/UX redesign. With regards to the plugin abstraction, I mentioned (and I still believe) that the Pla
Thoughts on the Plasma Mobile calendar
Hello everyone, Back in 2018, the Plasma Mobile ecosystem consisted of just a handful of apps. After a short discussion with Bhushan, I stepped forward to work on Calindori, the calendar application for Plasma Mobile. Calindori is written in QML/C++, it is based on Kirigami and (tries to) follow the KDE HIG. As a Kirigami based application, it can also run on desktop. In particular, some desktop specific bits have also been added to improve the desktop UI/UX. You can find more details here [1] During Akademy 2019 in Milan, Nicolas Fella suggested that a plugin system is created [2] that would make Calindori (or any other application that uses KCalendarCore) support various calendar backends. So, I have been maintaining Calindori trying to fulfill these requirements: 1. Offer a mobile application, and try to leverage Kirigami convergence capabilities to improve the desktop experience 2. Support calendars that follow the iCalendar [3] standard using KCalendarCore [4] 3. Avoid to tightly couple the application with a specific calendar backend (e.g Akonadi, Sink, etc) 4. Adopt the plugin based approach for multiple calendars and online synchronization support [5] Let me now share my thoughts on the the "Plasma Mobile - Calendar" [6] Google SOC project (you can track its progress here [7]). People in the free software ecosystem are free to work on any project they feel like. Certainly, the Google SOC mentor(s) may have a plan that is not compatible with Calindori. However, I started Calindori in order to enhance the Plasma Mobile ecosystem and have been trying hard to maintain it over my limited volunteer contributor time. I am not interested in entering in competition with anyone within the Plasma Mobile team and the KDE community in general. With all this in mind, if the Plasma Mobile team is not happy with the approach of a Plasma Mobile calendar mentioned above and/or my work in general, and they would like to adopt the Google SOC project approach, I can step down as Calindori maintainer. Then, the Google SOC mentor(s) could take over maintenance and merge their work with Calindori or just continue with a separate application. [1] https://invent.kde.org/plasma-mobile/calindori [2] https://phabricator.kde.org/D24443 [3] https://tools.ietf.org/html/rfc5545 [4] https://api.kde.org/frameworks/kcalendarcore/html/index.html [5] https://invent.kde.org/plasma-mobile/calindori/-/merge_requests/37 [6] https://community.kde.org/GSoC/2021/Ideas [7] https://claudiocambra.com/2021/06/14/first-week-of-google-summer-of-code-2021/ All the best, -- Dimitris https://dimitris.cc OpenPGP_0xDD10816BA7DE60CE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Invent/gitlab, issues and bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2/7/19 3:55 μ.μ., Luigi Toscano wrote: > Hi, > > one of the main point of the gitlab migration has been so far the > replacement for phabricator. We didn't discuss about bug tracking. > > Despite this, I've seen a few projects using issues as replacement > for bugzilla. > > > We can all debate which is better, whether bugzilla or the gitlab > issues, but please consider that: > > - having to ways to report a bug makes like of everyone more > complicated for users reporting bug who need to find the proper > place, and for bug triager > > - drkonqi still continue to report to bugzilla. Future versions of > drkonqi can be fixed to support the new system and we would need > also a proxy for older versions of drkonqi, but until such thing > exist, a migration is out of question. > > > My suggestion right now is to disable issues completely, or if they > need to be enable to allow us to replace phabricator tasks, then to > reduce their scope to this. > Plasma Mobile projects are not included in bugzilla. So, gitlab issues is the only "decent" alternative for bug tracking. If we disable issues, then the only alternative I see is to report issues to Phabricator, which, from my point of view, should be avoided. - -- Dimitris -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE8AvRG3JW8Vphs8uBrh0LWJZuDgwFAl0bWNQACgkQrh0LWJZu Dgzi7g/+INhX7+oavknxLD+oaHDTqYiYlf2NSu4tU+/5DTka1aAb5+Lab//3fitX LUBW5Lhi65XOhP5TGSQrKeZ6dNyG6oJARDKqUF4JoBz6Kn3zsVcgZTDySkRxqsoR 5V4BP76br7AFb8eZbvpkjiOutii1O9L0P/ca8jhkBK54gNZmYlF6MkLyBkUz3XyT sq7d4c2IfvWGjbIvqqR9MJ+zSrAqRAJQsCYcKmOO6vL67P7mP0BPSqlOj1FiVWQZ IhkpDutx2cuudEbe4ND1Ue/AX0osb5521uTZq0hkf6KP20d7DJU1ESpK07p4ipf7 EYNvWsa5TAdEFotT1NwCbBlBbtik/gMGdV5MyVu1G9tWqsk81mpU1nFvOJF/LKXd HT7NYjCyC9T8l8+JnbSK5nRPzkN+goOxHRycsfo0spxb4LreT1+71FTcRf+bfL6o DuLrdXhMYUDN90cg4CuHToln1KE8JWySPq39QYe06JnTaj0MZKxQof8w9O34dTyc beiksAv8p69r9sqRD8A4SjyJasLmir8TkdbGT1izYBcADFjyO8sZ9dTCcNsVieDu y3Up0dtPJBtiamFO0JgaghVf43BJu4TWVTgAqvPKiMfDJCUCOFW8RR63t0BhGf4c b7h6AlccH8Elvm8E6/dqaqTnPRdM/p2/1U4gjSfq0XhTLSRzPcU= =AdZ6 -END PGP SIGNATURE- 0xDD10816BA7DE60CE.asc Description: application/pgp-keys 0xDD10816BA7DE60CE.asc.sig Description: Binary data
Re: Akademy 2018 videos
Great work! Just another minor issue: student presentation video is in place of the "Bringing Community Data Analysis Back to KDE" one and vice versa. On September 5, 2018 9:48:46 PM GMT+03:00, Nate Graham wrote: >Thanks for this, Kenny. However I don't see the video for my talk: >Konquering the world, >https://conf.kde.org/en/Akademy2018/public/events/50. The "Video" link >on that page is broken. > >Nate > > > On Wed, 05 Sep 2018 11:34:35 -0700 Kenny Duffus >wrote > > Hi > > > > The Akademy 2018 videos are now available > > >> The simplest way to access them is by browsing the talks schedule, >choosing a talk you are interested in and view its details, you can >then click Video in the links section > > > > https://conf.kde.org/en/Akademy2018/public/schedule/1 > > >> Alternatively you can directly access the files on our mirror network > > > > > https://files.kde.org/akademy/2018/videos/ > > > > The videos are licensed CC BY Akademy Team > > >> Unfortunately we had a few issues with the videos this year resulting >in lower quality than planned, sorry about that. Thanks to Kenny Coyle >for getting these processed and available to you > > > > -- > > > > Kenny > > -- Σταλμένο από τη συσκευή μου Android με το K-9 Mail. Παρακαλώ συγχωρήστε την ολιγολογία μου.
Re: Improving our integration with KDE application teams, and supporting companies
As Cornelius has already mentioned, the debate is not about whether we want companies around the KDE community, or not. As long as we create high quality digital products, companies will always be around us. Imho, what really matters is to start discussing on what kind of company ecosystem we want around our community. Afterwards, or maybe simultaneously, we may start talking about what we could do so as to construct such an ecosystem. When I imagine this ecosystem, I see social purpose companies and not "only for profit" ones. These companies are governed by their social mission and not by their lust for profit and growth. I would be proud of a KDE "doing business" with companies that create products or provide services that fullfil social needs. Example: entrepreneurial initiatives to create privacy oriented, plasma mobile devices with long term support, made of recyclable components that users may substitute when broken. Moreover, I see generative companies that improve the KDE output, allocating resources for upstream work. Although we cannot prevent extractive companies that just consume our work for making profit from existing, I do not see them as our partners, since they do not improve our community and jeopardize its sustainability. In addition, I would like to cooperate with non hierarchical companies, where people do not work overtime to reach deadlines imposed on them by upper management. I' d really enjoy working with companies having as purpose to create livelihood for their members. And when success leads to the creation of surplus, the surplus would not be invested to financial products but it would be shared with the community, supporting KDE e.v. and more importantly, supporting similar entrepreneurial initiatives. So, this ecosystem does not consist of competitive companies. In a sustainable ecosystem the output of one is the input of the other. There should not exist companies that both create two distinct kirigami based file managers with similar features. Instead, companies that coordinate, working on different features and adding back to kirigami the components it lacks of, avoiding duplication of effort and wasting of resources, as well as reducing the environmental footprint. In the vision of KDE is mentioned: "Of course, there is much more to life than the 'digital' part. While we all want freedom and control in the other parts too, influencing that is beyond KDE's scope, so we limit our vision to 'digital life'." I believe that the creation of an ethical ecosystem that may allow contributors to make a living by working on what they really love is a huge step towards freedom. On August 24, 2018 5:12:28 PM GMT+03:00, Sune Vuorela wrote: >On 2018-08-24, Cornelius Schumacher wrote: >> This was a quite complex situation, there were many factors involved. >But >> again the negative feedback was not about the question if it's ok to >pay >> developers but about other aspects of how the project was handled. > >And on some of those questions, Frank has later said at public talks >that "KDE was right". (fosdem last year) > >/Sune -- Σταλμένο από τη συσκευή μου Android με το K-9 Mail. Παρακαλώ συγχωρήστε την ολιγολογία μου.
Fuzzy searching against KDE repositories
Hello everyone! Let me introduce you to a project that I am currently working on. The scope of the project is to provide an easy way to search KDE code and translations repository since I consider that such a kind of an infrastructure would help possible newcomers to easily obtain valuable information about the work of the community. For example: - which projects exist - which ones are the most active - how developers describe their work on them - find out the developers that currently work on them To make the long story short, I was thinking that a google-like search engine would facilitate onboarding of newcomers to KDE So, I ended up to a solution that: 1. Fetches git and svn commit messages from the kde-commits mailing list 2. Parses each message and creates a json file that contains the below information: - commit subject - commit message - author - project - commit date - isrevision (does a relative phabricator task exist?) - istranslation (is it a translation commit?) - fixesbug (whether the commit is bug-related) The relative code can be found here https://github.com/dimkard/kde-commits-solr 3. Loads the json recordset to an Apache Solr instance 4. On top of apache Solr, Banana (port of Kibana for Solr) has been added. A custom searching panel has been created to provide fuzzy searches against KDE repositories. Moreover, it could also be useful for KDE writers/promoters to get a clear view of the current development, either on code or translations, the new features, the bug-fixing work, etc To better illustrate the tool, let's simulate the creation of a post like https://pointieststick.wordpress.com/2018/04/29/this-week-in-usability-productivity-part-16-everything-else/ , leveraging the functionalities offered by this solution. At first, the promoter wants to get more info and add references to open/save dialog project improvements: /Open/Save dialog project/ /The dialogs now display previews for the same assortment of file types as Dolphin does (Alex Nemeth)/ /Grid Spacing in icons view has been tightened up to match Dolphin, allowing more to be shown in the window (Alex Nemeth)/ / / In case that the writer remembers the name of the committer and knows that a relative bug report does exist, the facet in the left will be used and the relative time period will also be set (top-left): https://framapic.org/z4PtCZxEul5K/L3tJZ8visR4I.png https://framapic.org/DnveENis7bEa/BsKkske4RVPz.png The records returned are: https://framapic.org/8fv0crGCijf6/cPsbeZWO1CJH.png so the commit in concern has been successfully found. In case that no committer name is available, the writer may search for sth like: https://framapic.org/wYn063MH0jPY/4zEdV8ngIidS.png Then following the search suggestion https://framapic.org/owrsQQ2a5HVW/gWUiTNz7xWTB.png the relative commit will be returned as top result: https://framapic.org/bNDgq0cbR7J7/xVd3HJqQ40Kv.png The same applies for the second search: https://framapic.org/qpddu38zvRJF/ssQO4MBEWt6s.png since the relative commit is returned as well: https://framapic.org/g31g6x5mIOxR/5PNUInPMNxYw.png Moreover, although this is not its primary role, the solution provides some useful interactive visualization tools. For example, searching work on projects like plasma-phone-components, plasma-settings, plasma-mobile and kirigami, the tool would provide useful information regarding work on Plasma Mobile. So, a relative promo article could be accompanied with some useful statistics and references to real plasma mobile commits, like this: https://framapic.org/2RW8LlxCjYkh/LbkUnVQZTyZV.png In the future, such a solution could be further extended indexing bugzilla data as well. As a result, reports about possible duplicates could be automatically generated and, why not, a fuzzy search engine could be offered to the bug reporters enhancing the reporting experience, avoiding duplicates and frustration about irrelevant results. Nevertheless, there is a set of factors that should be considered as well. At first, the amount of commits on a project is just an indicator -among many others- of the activity of a project. A lot of work may happen behind the scenes, in terms of communications, design, testing etc, and this work may be committed as a single or a few commits. So, considering all commits as equal is a trap. In addition, since the tool measures the # of commits by each developer, we may think twice about the implications of such a tool regarding the psychological effects on the personality of contributors. Do you think that such a tool could help KDE community? I look forward to hearing your thoughts, since I am not still convinced if working on this would really help the KDE ecosystem. PS: We may look at other alternatives as regards to the technologies involved. I’ve opted for the aforementioned since I have already worked on them in the past. PS1: If similar
KDE@fosscomm2017
Hi everyone. I am Dimitris, KDE Contributor from Greece. Yesterday I presented vision of KDE as well as vision of Plasma at Fosscomm2017 <https://www.fosscomm.hua.gr/>. Fosscomm (Free and Open Source Software Communities Meeting) is an annual conference about free and open source software, hosted at Harokopio University of Athens. Does any specific place exist where I may upload the presentation file to? I am going to write a short article about the vision of KDE in greek foss-related blogs and groups. Thus, it would be convenient to have a reference to the presentation file. PS. Presentation is in Greek Dimitris Kardarakos
