Re: libqaccessibilityclient now in kdereview
Am Mittwoch, 26. Juli 2017, 08:29:47 CEST schrieb Luigi Toscano: Morning [snip] > > Simon is (for the moment at least) prohibited from depending on > > libqaccessibilityclient, because Extragear (as well as Plasma and > > Applications module) applications are not allowed to depend on code > > which is in Playground or KDE Review. > > While this is true that the procedure was not followed properly in the past, > we would let our user suffer a regression, so I vote to allow for an > exception in this case. > > Is it a mandatory dependency or an optional one? If it is optional it is > less than a problem. It's an optional one for a long time. griits Mario
Re: libqaccessibilityclient now in kdereview
Am Dienstag, 25. Juli 2017, 14:55:42 CEST schrieb Albert Astals Cid: Morning Albert > El dimarts, 25 de juliol de 2017, a les 13:25:39 CEST, Jonathan Riddell va > > escriure: > > libqaccessibilityclient is now in kdereview. It's in a git repo > > called libkdeaccessibilityclient but we filed a sysadmin request to > > rename it. > > > > We just released 0.2.0 in unstable (for some reason 0.1.1 was released > > in stable some years ago). > > Do we really have to keep the Qt4 compatibility or can we kill it? Please keep it for now as the next Simon release (0.5.0 which is on its way) is still Qt4 based. Thx Mario > Cheers, > Albert > > > What is it? > > > > Since it's hard to grasp all the bits related to accessibility, I'll try > > to > > explain what the lib is for. > > Most of the stack is part of Qt 5, so nothing to worry about, that's the > > part that lets applications expose their UI over DBus for AT-SPI, so they > > work nicely with assisitve tools (e.g. Orca). In accessibility language, > > the applications act as "servers" and the screen reader for example is a > > client. > > > > This library is for writing clients, so applications that are assistive, > > such as screen readers. It currently has two users: KMag and Simon. > > KMag can use it to follow the focus (e.g. when editing text, it can > > automatically magnify the part of the document where the cursor is. > > > > For Simon Listens, the use is to be able to let the user trigger menus and > > buttons by voice input.
Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes
Am Samstag, 6. Mai 2017, 21:37:51 CEST schrieb Ben Cooksley: > Hi everyone, Morning Ben and Co > This is going to be quite a long email, my apologies in advance for that. > If you use the CI system regularly as part of your development flow it > is important you read this email in it's entirety as your action will > probably be required. If you are aware of a list I have missed in the > above, please feel free to forward it there. > > As some will have been aware of for some time we currently have a > problem where changing the system base is an incredibly disruptive > activity. We also have issues where builds sometimes fail due to files > disappearing mid-build or installations being inconsistent, and > excessive numbers of emails are generated. To top this off, everyone > has to use the same underlying "base" system for performing builds > which sets up conflicts between projects. Oh, and we also only perform > CI for Linux. > > To solve these problems we've been working on a Next Generation CI > system which introduces a new concept called 'Products'. In short, a > Product is a release unit, such as Frameworks, Plasma, KDE > Applications, which groups a series of repositories which are > developed and subsequently released together. > > A preview of this system can be viewed at https://build-sandbox.kde.org/ > > Products as part of their definition are able to define a set of > 'Platforms' on which they build. At the moment we have three Platforms > available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7. > Adding additional Platforms to this mix is fairly easy, as long as the > code can be built there. Qt will now be considered as part of the base > system, and is something we will no longer build ourselves. > > Each Product / Platform definition is fully independent. This will > allow for different products to build against different versions of Qt > among other things for instance. > > This is the first part that requires your action: we'd like > developers, particularly those whose development relies on bleeding > edge system software to assist in creating and maintaining (Linux) > Platform images. If you're interested in this, please let me know. > > As part of the shift to the Products paradigm, a number of changes > have been made to how projects are built and dependencies managed. > This particularly affects dependencies on projects which are outside > your Product (Frameworks is outside of Plasma and Applications for > instance). These dependencies will now be satisfied through > "Dependency Build" jobs, which will be executed once a week. As a > result the master version of Frameworks will no longer be available > outside Frameworks itself. > > This change is one of the big ones which massively reduces the effort > required to change base systems and thus hugely improves the > maintainability of the CI system. It is therefore quite important and > necessary, and also isolates the rest of the CI system from breakages > lower down in the stack which have happened in the past. > > This is the second point that requires your attention. If your > development process is dependent on using the latest development > version of something which is located in another product, then we will > need to add that to your Product. If this affects you, please start a > new thread (CC'ing sysadmin and kde-core-devel along with your > Product's main list) stating which specific repositories you need and > providing one to two lines of explaination for each. > > Note that requests for the entirety of Frameworks won't be accepted - > each must be requested on an individual basis with an explanation > given for why your development process is dependent on the master > version of that Framework. > > With the change to Products as a core concept for driving the CI > system, this does leave Extragear somewhat in a bit of an unusual > situation. At the moment we're planning to deal with this by having > Extragear be a 'Product' with all of them combined together. If anyone > in Extragear has any comments to make on this they're certainly > welcome here. > > Which brings me to the third point of attention. We'll only be adding > projects to the Next Gen CI system at their request going forward. For > Frameworks, Applications and Plasma this is something which we're > essentially assuming we're going to receive from their release > managers, so we'll take care of defining the initial Products for > those. For Extragear projects, please respond to this thread if you'd > like CI coverage (to continue) to be provided to you. So Simon is such an extragear project that likes to keep CI. > Thanks for all who have reached this point - my apologies again for > it's length. > > Note that the Next Gen system isn't finished yet - Notifications are > yet to be setup and there are a few other touches left to be made. > > Regards, > Ben Cooksley > KDE Sysadmin Thanks for your work on this very useful servic
Spread to more platforms - Randa Meetings 2016 open for registration
Good morning everyone Please excuse this cross-posting but all the above mailing list fit quite well this year's topic of the Randa Meetings: multi-platform end-user application development. This includes stuff like improving KDE Frameworks 5 (KF5) on other platforms like MS Windows, Android or Apple’s MacOSX, presenting and discussing how software distribution works on other systems than GNU/Linux (Windows installers, app stores and application bundles) and learning from the experience projects like Krita, digiKam, Rkward, Kdenlive & Co collected. We’d like to bring this information to more KDE Applications and work on this during a full week. So if you're interested and can help please go to: https://sprints.kde.org/sprint/301 and add yourself. And spread this information and tell people that could be of great help. This email though is just an informational email and thus not to start a discussion. Thanks and cu soon Mario
Re: libkgeomap
Am Freitag, 30. Januar 2015, 11.40:36 schrieb Luca Beltrame: Morning all As I see it this thread is not yet closed or done. Facts seem to be that: - digiKam is one of KDE's most prominent and best applications - on the other side: some Linux distros have problems to flawlessly package it Thus I'd propose to organize an IRC meeting where people of these Linux distros and digiKam people could meet and constructively discuss the difficult items and find solutions to clear this once and for all. I'd offer to organize this IRC meeting and moderate the discussion. What do you think? Gilles, Pino, Raymond, Kevin? > Gilles Caulier wrote: > > [backports from libs] > > > false. When it's possible we do it, when time permit. > > Speaking with my distro hat on, I argue that when we have to do that > ourselves the process is made more complicated because most digikam-related > repos don't have tags for releases (or betas): > > $ cd libkgeomap/ > $ git tag > > ... and no tags anywhere. This makes hard to tell at which point in time > (save looking through the commit history) commits appeared relative to the > last release (or beta). > > It would make the packagers' job a little easier (and also, it would help > wrt repo organization, IMO), if each release / beta release would also be > tagged in git. There are already scripts for it, see the ones used to > release Applications, the Frameworks scripts, or the ones used by the > Plasma team. So tagging of release branches/releases seems to be one item to discuss at this meeting. Thanks Mario
Re: Plasma 5.2 bits for kdereview
Am Donnerstag, 08. Januar 2015, 22.05:45 schrieb David Edmundson: Morning [snip] > > That said, there is no consensus here, as it seems I'm expressing I'm > > part of > > a minority view and I'm not in the release team, if no one else says > > anything > > else I would stop here for this specific case. If the problem surfaces > > again > > in future for more and more modules, I would raise it again. > > FWIW, I think it's a good idea. > I just don't think it's viable to be discussing it the day we tag a > release. > > If it's something you want to push for, raise it before another problem > surfaces, as otherwise it'll just be too late to do anything again. Good point. It's bad timing now. So let's bring this up again after this release. I agree with Luigi that we probably need another module for libraries that are not frameworks quality but need regular releases. And we've several candidates as seen as well in the kde-frameworks-devel list. Could somebody (else than me ;-) add this to his todo list for after the Plasma 5.2 release? thx Mario
Re: KDE-CI IRC meeting - Your possible KDE contributions in non-C++
Am Samstag, 22. November 2014, 21.15:01 schrieb Mario Fux: Good morning So the date is set now: Tuesday, 2nd of December, 20.00 CET (UTC+1) For the meeting, its summary and other stuff I setup: https://notes.kde.org/p/CI_IRC_Meeting_01 Thanks and cu there Mario > [Disclaimer: this email is sent to kde-devel, kde-core-devel and kde- > frameworks-devel. Please just answer to kde-devel!] > > Morning ladies and gentlemen > > Oh and please scratch the "please" above ;-). This email is about another > possibility to contribute to KDE. It's about taking work off Ben's > shoulders and about fixing the bus factor for our great CI (Continuous > Integration) [1] system: http://build.kde.org > > I'd like to start a series of weekly or bi-weekly (to be decided) IRC > meetings to coordinate the work to understand, change and enhance our CI > system and therefore we need a first date. So if you're interested please > add yourself to this Doodle (think about different timezones!): > http://doodle.com/i5f4pppb2sq6u5ee > > Prospective agenda for the IRC meeting: > - Ben: Short introduction to KDE CI > - Everybody: Short introduction incl. their skills and wishes for KDE CI > - Ben: What needs to be changed > - Everybody: Work on a roadmap and distribute work till next meeting > - Everybody: Determine date for the next IRC meeting > > This is your chance to help KDE to enhance the code quality and spread to > even more platforms and thus bring our great software to even more > computers and people. > > [1] https://community.kde.org/Frameworks/Epics/Continuous_Integration > > Best regards > Mario > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> unsubscribe <<
KDE-CI IRC meeting - Your possible KDE contributions in non-C++
[Disclaimer: this email is sent to kde-devel, kde-core-devel and kde- frameworks-devel. Please just answer to kde-devel!] Morning ladies and gentlemen Oh and please scratch the "please" above ;-). This email is about another possibility to contribute to KDE. It's about taking work off Ben's shoulders and about fixing the bus factor for our great CI (Continuous Integration) [1] system: http://build.kde.org I'd like to start a series of weekly or bi-weekly (to be decided) IRC meetings to coordinate the work to understand, change and enhance our CI system and therefore we need a first date. So if you're interested please add yourself to this Doodle (think about different timezones!): http://doodle.com/i5f4pppb2sq6u5ee Prospective agenda for the IRC meeting: - Ben: Short introduction to KDE CI - Everybody: Short introduction incl. their skills and wishes for KDE CI - Ben: What needs to be changed - Everybody: Work on a roadmap and distribute work till next meeting - Everybody: Determine date for the next IRC meeting This is your chance to help KDE to enhance the code quality and spread to even more platforms and thus bring our great software to even more computers and people. [1] https://community.kde.org/Frameworks/Epics/Continuous_Integration Best regards Mario
Re: "Automatic Info Reporting" BoF summary
Am Samstag, 27. September 2014, 22.05:03 schrieb Thomas Lübking: Morning Thomas > >>> - Ask user about their email address (stored separately of course) so > >>> we can contact them! Ask if they are interested in something special > >>> (quarter mails, new app version information, fundraiser, events in the > >>> neighbourhood, other KDE people near them, etc. pp.) > >> > >> That can be done in the kcm as extra opt-in, we don't want to present a > >> scary dialog on first boot, otherwise people will just run away. > > > > That's just my humble opinion but honestly I think contact > > information to our > > users is much more valueable than any other data. > > I guess they'll have a similar opinion - and therefore be rather reluctant > to give it away (to not be spammed by KDE or have their contact data in > one more database to be leaked from) - or they give you "m...@mail.com" > (poor fellow who actually has this addy ;-) That's the pessimistic view. I (and yes, my personal opinion ;-) only want the email address of the people that are interested in what we're doing and about news of the software they use. For a lot of people there is no such possibility atm. There are the people that are really interested in free software and some of the technical stuff behind it and they have mailing lists, the forum, the dot etc. but I think there are people that "just" want to use our great software (ok, the great software you guys make, I'm not coding much atm ;-) and want to know if there are new versions, new features etc. They don't want to visit some web page every now and then and they are quite fine to get some news about this and they might be even fine to get some information every other half a year or year about a fundraiser for their software. And I'm not mainly thinking about user of our software on Linux or other Unixes but more and more about people that (will) use our software on Mac, Android and Windows (that don't know the nice way of having a package manager or distribution ;-). I just think that we really miss a connection to our users (the people that just use our software and don't want to know how it works. They just want to get work done, sometimes a new feature, nice if some bugs are fixed and they like it that much and see it as a great value that they would give back something like money or sharing a link if they just new that we need this support and that we exists and what we are). > If the intention is to have a default pushnews service, i'd propose a > default plamoid that displays the "dot.kde.org" rss feed or something > similar which is far more defensive than asking them for their mail > address. I think I wrote above why I think the dot is not the best thing for some of our users (and I love the dot and write myself for it quite often). And another thing is that I want to reach people as well that don't use Plasma, that don't work with Linux (or don't know what the Linux is that they are using) but that just use Kdenlive on Mac for their video editing and that love it and that just use Digikam on Windows for their holiday pictures or that just use KMyMoney and want to spend some of their millions on a Swiss bank account ;-). > Cheers, > Thomas griits Mario
Re: "Automatic Info Reporting" BoF summary
Am Mittwoch, 17. September 2014, 20.34:21 schrieb Albert Astals Cid: Morning Albert and Co > > Please add as well: > > - Ask user about their email address (stored separately of course) so we > > can contact them! Ask if they are interested in something special > > (quarter mails, new app version information, fundraiser, events in the > > neighbourhood, other KDE people near them, etc. pp.) > > That can be done in the kcm as extra opt-in, we don't want to present a > scary dialog on first boot, otherwise people will just run away. That's just my humble opinion but honestly I think contact information to our users is much more valueable than any other data. [snip] gritts Mario
Re: "Automatic Info Reporting" BoF summary
Am Dienstag, 16. September 2014, 00.52:28 schrieb Albert Astals Cid: Morning Thanks a lot for bringing this forward. IMHO it's a very important topic and future communication channel with our users but I think as well that it's a multi-year thing before we can earn the first fruits. So let's start early ;-). See some comments below. > BoF that that is a follow up of > https://conf.kde.org/system/attachments/45/original/spyware.pdf?1410020392 > and > http://files.kde.org/akademy/2014/videos/The_case_for_spyware_-_Albert_Asta > ls_Cid.webm > > [snip] > What kind of data may we want? > - Version number > - Distro > - uname -a > - KConfig, GPU, which kind of hardware > - SSD vs rotational media > - Language + locale > - RTL > - Bluetooth usage - who sends files > - Usability stuff - order of menu items. When a user opens something, have > they tried other menus. Maybe this should be more opt-in because this is a > usability study. Investigate more. > - Usage data as to how frequently stuff is run on KDE > - Favorite applications > - Frequency of configuration changes > - support info hooks and dbus > - Filter the data vs users and developers. Some strange heuristics to > determine this. > - Number of users on the system --> System Info. Are they using systemd? > - Input devices? More hardware info. > - Geolocation data? Please add as well: - Ask user about their email address (stored separately of course) so we can contact them! Ask if they are interested in something special (quarter mails, new app version information, fundraiser, events in the neighbourhood, other KDE people near them, etc. pp.) > Server - needs awesome visaulization. Maybe this could be done in the KCM > as well. > It is very important to show what we are tracking and WHY. With pretty > pictures. > > Gamification? > > We need to start small. We cannot send 1.5 Gb of data. > How often should this be sent? Maybe weekly or monthly? > > Server Side > - > * Keep people's ID for a while. > * Maybe we do it per IP, but then we have NAT. > * Malicious people can send private info so that they can incriminate KDE. > * The RAW data can be dangerous. > * Some kind of data validation? Some users may trick the data. > * Make it hard to troll the server. > * We can publish public data as long as there are no private strings. And > the data is validated. > > -> How do we handle updates where we keep collecting more data each update? > Might put off some users. Tell them which data is newly collected and opt-out of an automatic update. > Consensus - > * We should always ask the users if we can / can not track stuff. > * Should not be a passive notification? > * Maybe have a "Ask me Later", but keep collecting data during that time, > but don't send the data. Thx Mario
Re: KF5 Update Meeting Minutes 2014-w28
Am Dienstag, 08. Juli 2014, 19.27:52 schrieb John Layt: Morning John [snip] > > * he'd like to see a donation button in KDE apps based on KF5 > > (developers > > > > could opt-out); > > We already have a link to the donations page buried deep in the "About > KDE" dialog under the "Support KDE" tab where no-one ever sees it. A Indeed there is something ;-). > Help menu item for "Donate to KDE..." that pops up a dialog explaining > why would be far more visible, but easily disabled by distros who So what? It's still free software so everybody can patch it away. But we can present it prominently and try and see if it helps. And I mainly think about KDE apps on Windows, Mac and Android when I want to see this donate button as we're the distributors there ourselves. But it's exactly what I meant: A "Donate to KDE..." menu item under the Help menu. > object. We could also include a "Donate to KDE" tip in every > KTipDatabase and ensure it's the first tip shown by default on an apps > first run. As an admin note, whenever we do add a donate link > anywhere we should make it unique so that we can track how successful > each channel is. +1 > > * ervin hopes to see kdepimlibs bits getting in sooner rather than > > later; > > I asked on the PIM list the other day, Montel says the plan is not to > start on frameworks until after 4.15, so maybe March/April next year? There won't be a 4.15 and I talked with Montel about this. > I think he meant porting the PIM applications though, so I'm not sure > what that means for starting on pimlibs. I'll follow up. > > > My plans: > * Write proper docs for KUnitConversion > * Make KUnitConversion Tier 1 by switching to Qt translations > * In advanced planning for replacements for ISO codes and flag images, > even have some code, see > https://community.kde.org/KDE_Core/KDE_Open_Data > ** OpenCodes: repo of json files of ISO data auto-extracted from > Wikidata, CC-0, can be used by anyone > ** KCodes: Qt library which loads OpenCodes files > ** OpenFlags: repo of SVG flag images auto-extracted from Wikidata, > with icon set auto-generated from SVGs Very interesting stuff! > Here's a bit of bike-shedding for you: when creating completely new > Frameworks in Tier 1, do we name them with a Q or with a K or with > something completely neutral? > > Cheers! > > John. Thx Mario
Re: KF5 Update Meeting Minutes 2014-w28
Am Dienstag, 08. Juli 2014, 17.30:19 schrieb Kevin Ottens: > Hello everyone, Morning > This is the minutes of the Week 28 KF5 meeting. As usual it has been held > on #kde-devel at 4pm Paris time. [snip] > * unormal is looking forward to more mac CI results; > * the windows CI is a bit stuck; > * he'd like to see progress on the android CI; > * he'd like to see a donation button in KDE apps based on KF5 (developers > could opt-out); > * he's thinking we should ask third party developers if they want to send > us some information when they use a framework to create an app; There was a small misunderstanding (probably based on my fatigue brain atm). Of course this interpretation would be nice as well I meant apps based on KF5 and to get a channel to our users. Two way: - Get to them if we need (financial) support or want to tell them about new version or other stuff - They send us automatically and agreed upon data about their use of our apps. [snip] griits Mario
Re: Bug 92237: patch submitted, but... is anyone watching?
Am Sonntag, 22. Juni 2014, 13.04:44 schrieb Simon Bachmann: Morning Simon First thanks for submitting a patch and sorry that nobody found the time to answer it yet. > May I draw your attention to bug 92237? > (https://bugs.kde.org/show_bug.cgi?id=92237) > > No, this is not a please-get-this-issue-fixed-ASAP kind of message. > It's just that I submitted a patch to that bug a few weeks ago, and I'm > afraid no one noticed (the bug's CC list is empty...) It might help that you send your patch to the Review Board: http://reviewboard.kde.org Where your patch might get more attention. Thanks and best regards Mario
KDE applications 4.14 LTS or 4.15?
Morning gals and guys First: there are several mailing lists in the "TO:" above but please just write to the kde-devel mailing list for this discussion. As the release schedule for our KDE applications in the version 4.14 [1] were finalized at the beginning of this week it's time to discuss if 4.14 should become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or if we need (at least) another features release and thus 4.15? So what do you think? And most important, what do you, the KDE apps developers, think? Do you plan to develop new features with Qt4 and the KDE Platform 4 or do you plan to port your application to the KDE Frameworks 5 as soon as they have a stable release (like this June ;-). Best regards Mario
Re: Changing the KDE Edu module maintainer
Am Donnerstag, 20. Februar 2014, 15.25:22 schrieb Anne-Marie Mahfouf: > Hi, Good morning annma > I have been the assigned KDE Edu module maintainer for the past years but > due to family life (aging parents, husband being often away for his work, > kids,…) I have not been active in the past 2 years and things will be very > busy until at least mid-September so I will not contribute again to KDE > until at least this time. I cannot go to the Randa meeting nor Akademy due > to already planned events (we’ll celebrate our 30th anniversary on the > 10th of August for example!). > > Aleix Pol will take over as module maintainer as he has been in charge > since I stepped down. > > I’d like to thank him along with all the other amazing people working on > KDE educational apps (in particular Andreas Cord-Landwehr). I did not > realise I had a formal role as maintainer which is needed for allowing new > apps in KDE Edu, otherwise I would have stepped down earlier. > > Of course I hope to contribute again and I still follow what’s happening > through the mailing lists so don’t think you’ll get rid of me for good ;-) > > Best regards to all and thanks to everyone for what you brought me so far. Let me tell you as well thank you. Thank you for your support, your help and your inspiration in the last years. All the best for you and your family. And I hope to see you soon and hug you! > Anne-Marie aka annma Best regards Mario & family
Last chance ;-). And some more information.
As my questionnaire [1] is now open for two weeks I plan to give it another 24 hours and then close it. So you’ve still time till tomorrow, Wednesday, February 19, 23.59 UTC to fill in the survey and participate in the draw. If you should need more time or planned to fill in the questionnaire [1] after tomorrow night please ping me (unormal) on freenode.net or write me an email. And thank a lot to all the people who already filled it in: thank you! And now a promise: this is the last time I write here to ask you to fill in this questionnaire [1]. Next time I write about this topic I’ll write about results. Although my diploma thesis will be in German I’ll write some summaries or blog posts about the results in English and probably will do even a presentation or two about it. And here yet another teaser: tomorrow I’ll blog on planet kde about the dates and topics of the Randa Meetings in August 2014 ;-). [1] http://survey.kde.org/index.php/249736/lang-en
Thanks for your help and please go on!
First and foremost I'd like to thank all the people who already took some time and participated in the questionnaire [1] for my diploma thesis and KDE. But it's not over yet (last chance is on 25th of February) and we still need more data and as a member of KDE I know we can do more and better. I got some feedback about the length of the questionnaire [1] and that some questions (mostly the once at the beginning of the questionnaire [1] about the 12 different tasks) are quite abstract and difficult. But please try it, try your best and take the time and brain power. The remaining part of the questionnaire [1] (after these two pages with the tasks questions) is quite easy and quickly done. So if you already started the questionnaire and gave up then or needed to run for something else: no problem, you can reopen the questionnaire and continue where you left. And don't forget the chance to win something nice - but just if you complete and submit the questionnaire [1]. And if there are any questions, feedback or you need help don't hesitate a moment to write me an email or ping me on IRC (freenode.net) as unormal. Thanks a lot for your help and tell your fellow KDE mates about this questionnaire [1] Mario Fux
I need your help. Diploma thesis about media choice and usage in KDE
Dear KDE mates and contributors Finally the end of my studies is near and thus I'm currently in the process of writing my diploma thesis. I've worked hard during the last weeks and months on a questionnaire [1] which shall collect some data for my thesis. Furthermore the data of this survey will be interesting for the KDE community as well. So please take some time and add it to your todo list or, even better, go directly to my questionnaire [1] and help me make a great diploma thesis and improve the KDE community in some ways. The questionnaire [1] takes some 20 to 30 minutes and will show you some interesting facts about our community in the last 15 years. At the end of the questionnaire you'll find a way to participate in a draw where you can even win something nice. So once again: Old and young people of KDE, documentation writers, developers, translators, bug reporters and triagers, packagers and all the others of you who contribute to all that makes KDE a great community with great software and more, please take some time and help me to filled in questionnaires [1] from all over the world. Thanks to all for reading and helping and towards the summer of 2014 you can read here what all the data you gave me showed us and where we can learn and improve. Thanks in advance Mario Fux [1] http://survey.kde.org/index.php/249736/lang-en -- Fellow of the FSFE.org and Joined the Game of KDE.org Main Organizer of the Randa Meetings (www.randa-meetings.ch) And if you need a simple computer: www.asimplecomputer.com or www.eineinfachercomputer.com
Re: Moving Baloo and Baloo-widgets into KDE SC
Am Freitag, 10. Januar 2014, 11.28:34 schrieb Sebastian Kügler: > Hey, Morning sebas and Co Here finally my answer to this thread. [snip] > > - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? > > Maybe this feature is worth delaying then? Is anybody of the Digikam team reading this? Or should somebody contact them? Please speak. > > - Dolphin > > - Gwenview > > - Conquiere > > - KPhotoalbum > > - Kamoso (seems so be ready in time) > > - Kdenlive (out of the most popular KDE apps, with some man power > > problems atm, ok, but nonetheless) > > - Nepomuk-webminer and Nepomuktvnamer > > Let me point out the obvious here: We can discuss possible quality problems > for a few more weeks, *OR* we use the time to actually test the code on a > wider range of systems. This way we wouldn't have to guess so much about > possible impact to other apps, and we can judge much better how ready Baloo > is. Sometimes pointing out the obvious is not bad ;-). Of course you're right. I just had the subjective impression that it's holding back. Which changed (at least my perception of it) which is great. > Don't see Baloo as a third party service that someone else has to fix and > debug, rather get on the train, test it, report your experience and make it > possible to get it solidly working. Ok. [snip: Plasma Active] > > So in conclusion I think that a change of Nepomuk to Baloo in 4.x without > > a 100% (very very well tested!) migration plan and testing is a no-go > > (from my side, just me). I've the strong feeling that such big changes > > are for something like kf5 and a port of the apps to kf5. > > I'm not strictly against this. Actually, we have some lenience with the > long term support workspace out, so we can recommend people to use that, > if they're slightly more adventurous, run 4.13, if they are completely > mad, help us getting Plasma 2 in shape. That's quite a nice array of > options. Communicated in the right way to our downstreams, this helps us > to avoid problems. This I don't get as it speaks against all I told people about all our three different releases (apps, workspaces and platform). But I think this may be a misunderstanding. So my conclusion. Let's do it asap and know and see the effects and get as many testers as possible so that we can release 4.13 with a great Nepomuk replacement or better evolution of Nepomuk. Thx Mario PS: About Jan's question if there are more applications that share KPhotoAlbum's slight use of Nepomuk. TBH I don't know.
Re: Moving Baloo and Baloo-widgets into KDE SC
Am Donnerstag, 09. Januar 2014, 23.26:01 schrieb Àlex Fiestas: Morning Alex > On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: > > But if the above scenario does not work, we should probably not > > introduce Baloo for KDE SC 4.x. > > I have to disagree here. And I'm probably disagree with you but let me explain below. > We can't keep playing this conservative when we have things that are in the > Nepomuk situation. If it is the most hated piece of software we have is not > by chance. > > If the breakage is minimal (which I know it is, but I will let vHanda reply > to that) I vote to replace it even if we make a bit worse the experience > using some weird application that nobody has heard of. The release schedule for 4.13 is really short (4 month). With the feature freeze in approx. 1.5 months, see [1]. As 4.13 will be one of our last release in the 4 era I think we should be quite sure that we don't break anything or even more to be 110% sure to have fallbacks, migration, APIs for Nepomuk apps to access Baloo data etc. And even though I know that Vishesh is doing a great and a hell of a job I'm not too sure if one single person can manage all of this (not just the implementation but I think it needs a lot of testing as well). IIRC it's still not clear for all the current Nepomuk apps if they work after 4.13. Let's try to list them again. - Amarok (got Nepomuk support with 2.7, will it work after 4.13? - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer - Plasma Active/Plasma mobile with Share-Like-Connect And another question. Will people who used Nepomuk extensively lose data? I know that Nepomuk was one of the most hated software, but there were and are people who like(d) and love(d) it. So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. > Ps: Some distros even disable Nepomuk by default... Really with this we are > going to annoying almost nobody. Best regards Mario [1] http://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule
Re: Fwd: The Future of Speech Recognition in KDE: Proposal
Am Freitag 06 September 2013, 12.03:39 schrieb Peter Grasch: > Dear KDE developers, Morning Peter > as part of expanding the speech-related efforts in KDE, I would like to > propose a new category in KDE's extragear called "Speech" (putting it on > the same level as e.g., "Network"). Rationale: Not all speech > recognition applications are necessarily related to accessibility (e.g., > lecture transcription) and splitting up the projects in different > categories would hinder collaboration. > > This is part of a larger proposal to advance speech recognition in KDE. > The full text can be found here: > https://mail.kde.org/pipermail/kde-community/2013q3/000147.html > > To create a new category in extragear, I'd like to get your approval. > Please respond with a +1 or -1 to this email, stating the reasons why if > possible. Big +1. I want to see much more speech recognitional stuff in KDE. > Thank you. > > Best regards, > Peter griits Mario -- Fellow of the FSFE.org and Joined the Game of KDE.org Main Organizer of the Randa Meetings (www.randa-meetings.ch) And if you need a simple computer: www.asimplecomputer.com or www.eineinfachercomputer.com
Re: SLC for all 4.10 workspaces (was: Re: How Can I change wallpaper from CLI?)
Am Sonntag 09 September 2012, 23.18:09 schrieb Albert Astals Cid: Morning > > As I'm sold to the SLC concept > > Maybe you could explain to us mere mortals what's the difference between > Share, Like and Connect. First here is a link to some more information about SLC: http://community.kde.org/Plasma/Active/Development/ActiveHIG/SLC > I understand Share, but Like and Connect is just Share to me. Please correct me if I'm wrong but as I understood it: - Share is to send or share the data (pic, URL, whatever) with someone e.g. send by email - Like is to rate or like it e.g. rate it with Nepomuk (star rating) or Facebook like (I don't know Facebook enough) - And finally connect is to build a relation as e.g. in Nepomuk to connect or relate it (the pic, person, URL, webpage, etc.) to an activity > Note: I've never used SLC since doesn't seem to be easily usable on the > desktop. That's why I'd like to change this for the Desktop. > Cheers, > Albert griits Mario
SLC for all 4.10 workspaces (was: Re: How Can I change wallpaper from CLI?)
Morning
As I'm sold to the SLC concept and start to miss it on the Plasma Desktop and
read the below message here I'd like to propose the following:
Make SLC a release goal for 4.10 and include it in as many KDE apps as
possible.
And to reach this goal I propose the following:
- Organize a weekend when the SLC developers are available for help and
interested developers and app developers can get help to integrate SLC in
their app.
- As I'm not a developer myself I'd offer some of my time to coordinate and
document this. My time proposal would be in October (as then the Randa
Meetings 2012 are done ;-).
So what do you think? Should I start a doodle to find weekend?
Thx
Mario
PS: I often use the "Send file as pdf..." in LibreOffice and would love to use
this kind of feature in all my KDE apps.
Am Donnerstag 06 September 2012, 13.50:19 schrieb Aaron J. Seigo:
> On Thursday, September 6, 2012 12:47:16 Kevin Krammer wrote:
> > The problem with that (as far as I can tell) is that this would not be
> > available to non-KDE apps, which (again as far as I understand) is the
> > case of the thread starter.
>
> if the issue was non-KDE apps, this would be an interesting starting point
> for discussion.
>
> but the discussion moved to the example of a KIPI plugin for digikam. that
> is a KDE application.
>
> once we get our own house in order, then i'd love to discuss about how we
> interface with the rest of the world.
>
> > D-Bus interfaces have the advantage of being accessible from almost any
> > program technology stack, most times even from shell scripts.
>
> qdbus org.kde.ActivityManager /ActivityManager | grep Resource
>
> we're smart enough to implement things in ways that aren't completely
> stupid. ;)
>
>
> and really this is a design question ("is associating URIs and metadata
> with windows a good / better solution? if so, how?"), not an
> implementation problem ("what is used for remote procedure calls?").
>
> even if the implementation is bad (though i don't believe it is), we can
> usefully improve the implementation as long as we have a good design to
> start with; the reverse is not true however -> design flaws don't get
> fixed by improving the implementation of them.
>
> currently when it comes to things like setting wallpapers, our design
> sucked.
>
> so some of us worked on improving that, and if you look at its use in
> Plasma Active you can judge for yourself whether or not it is an
> improvement or not.
>
> and now we're asking the rest of our community to use that improved design
> broadly including on the desktop.
>
> > > show me a dbus api for wallpaper setting that can do that. :)
> >
> > Just curious: what kind of non-D-Bus communication mechanism is used by
> > that?
>
> it uses DBus. the differentiation is that it isn't focused on "making
> something to set a wallpaper" but focused on "allowing content to be
> introspected so that things can be done for/with that content".
>
> making an API for "setting wallpaper" is not only fragile (see the
> differences in KDesktop 1, 2, 3 and Plasma; see the differences for
> windows, mac, xfce, gnome, etc) it is also very limited in scope and needs
> to be upkept in every single application.
>
> the design concept of "expose the URI of the content this application
> window is showing" suffers none of those limitations. and it lets us do
> the trivial things like "set that as a wallpaper" easily: it's writing one
> plugin for one app (SLC) instead of writing one plugin for every single
> application out there.
>
> really, it's the same thinking that went into things like kparts.
Re: [HEADS-UP] New Shared Desktop Ontologies requirement (v0.10.0)
Am Mittwoch 20 Juni 2012, 18.19:51 schrieb Allen Winter: > Howdy, Morning Little detail (just to prevent any confusion): it's version 0.10.0 (changed in the subject as well. > In a few days we will be requiring v1.10.0 (or higher) of the > shared-desktop-ontologies package for building kdepim-runtime master > (effectively for KDE SC 4.9) > > Probably your distro does not have this version yet, so you'll need to > install from source. Get the tarball at > http://sourceforge.net/projects/oscaf/ > > at the very least we will require this version for kdepim-runtime, perhaps > for kdelibs too. so please install > > -Allen Cheerio Mario
Re: Shortcuts via Mouse Buttons, etc.
Am Dienstag 27 Dezember 2011, 22.53:21 schrieb Rick Stockton: Morning Rick > Partly in reply to Albert Astals Cid and Thomas Zander, on the KDE list > (December 26): > > I am aware of the timing requirement (But Thomas- thanks for the > reminder, in case I HADN'T been.) Since I'm the person who will write > the code and doco, I HAVE TO have an idea how to make it work ;) I've > looked at some existing code, and I see two ways to get this done. One > is a variation of my original thinking, and comes from the inventor of > Qt Shortcuts and KeySequence management. The other suggestion, also from > one of the greatest Qt experts, is quite unexpected, and looks plausible > too: > > (Alt 1) Slightly higher risk of falling on my face, but "better > integration": Create a QInputSequence Class (The current QKeySequence > class would exist as a keyboard-only instance within the new, larger > class.) An input sequence could include keys which are simultaneous with > a mouse button State (the full State of all buttons, not just the XI 1.0 > mask of Buttons 1-5). And ultimately, "InputSequence" could support > events from other devices as well. > > (Alt 2) A shockingly easy kludge to write, but less ensible in concept: > Just derive one (at most, two) new Classes from QGesture. Right now > (4.8) we have QSwipeGesture, QTapGesture, and so on ... which are > invoked, on a traditional Desktop, with one mouse button in pressed > State. I could add QMouseButtonGesture, or extend Swipes and Taps to > have Button State properties. Just about everything above is already > built! But... is it just too weird for me to give people the option of > handling buttonpress, buttonclick, and buttondoublelick (with single AND > multiple buttons buttons) via 'gestures', as an alternative to the > normal 're-implement Widgit Mouse Event handlers' and scene-based mouse > programming schemes which we all use now? > > Approach #1 stays focused on Shortcuts, AND allows for future device > classes to be added via 'Copy and Paste a device instance, then modify'. > But my scheme for #2 would also give us the ability to create multiple > instances of Gestures from the same motion (e.g., horizontal swipe), > differentiated by button number. That's a pretty powerful upgrade too. > > Your votes? I'm favoring #1, even though it's possibly a bit harder, > because #2 is so strange. And #1 can have a 5.x upgrade to add the TV > remote control, or whatever, while #2 is pretty much stuck with gesture > input ONLY. As there were no further mails to this thread and you seem to do some great work here (and on other lists) just go on as you seem the expert. If there is no further mail on this in the next days just do the work which is great I'd like to thank you. thx Mario
Re: Date for IRC meeting about
Am Freitag 25 November 2011, 21.14:15 schrieb Jeremy Whiting: Morning Jeremy > I wont be able to attend the meeting at that time (which is fine, I > probably don't have a lot to add to the discussion). But like others > could probably benefit from a log of the meeting getting posted. > Could someone do that after the meeting please? Of course we will but thanks for reminding. > thanks, > Jeremy Mario
Re: Date for IRC meeting about
Am Sonntag 20 November 2011, 20.08:11 schrieb Alexander Neundorf: Morning First: I'm subscribed to both lists so no need to CC: me. > > According to our Doodle [1] we found a date which works for everybody, > > great! > > > > It's Sunday, the 4th of December at 20:00 (UTC). > > Just to make sure: that's 21:00 CET (german) time, right ? Yes that's right. For other time zones here is a link to a tz converter: http://www.timeanddate.com/worldclock/converter.html > Which channel, actually ? Sorry, forgot this: #kde-devel > Do we have/need something like an agenda ? I think there will be an more precise agenda but this is not done by me (who is just a helper) but by some frameworks developers. thx Mario
Date for IRC meeting about
Good morning According to our Doodle [1] we found a date which works for everybody, great! It's Sunday, the 4th of December at 20:00 (UTC). CU then Mario [1] http://www.doodle.com/tbndqqynre36ax9f#table
Re: IRC meeting for KDE Frameworks 5
Am Freitag 18 November 2011, 14.07:22 schrieb Giorgos Tsiapaliwkas: > On 11 November 2011 17:45, Mario Fux wrote: Morning > > In the weeks after the 20th > > have you decided the time and date for the meeting? Not yet but it strongly looks as if Sunday, the 4th of December at 20:00 (UTC) will be the date of choice. So this is a last reminder to add you to the doodle: http://www.doodle.com/tbndqqynre36ax9f#table We'll announce the final date on Sunday. > thanks Thx for your question Mario
IRC meeting for KDE Frameworks 5
Good morning In the weeks after the 20th of November there will be an IRC meeting about the state, progress and further plans and schedule for the modularization of kdelibs and KDE frameworks 5. If you're interested please add yourself to the Doodle at: http://www.doodle.com/tbndqqynre36ax9f This list is going to be informed about the final date. Regards Mario
[Randa] Short information mail about Randa2011
Morning all As there is some misinformation or unclear information about the Randa 2011 KDE meeting I'd like to summarize some stuff: - Date: 1st/2nd to 6th/7th of June 2011 - Location: Randa, Valais, Switzerland (middle of Europe) -- For more information about the location see the Randa page [2] on our community wiki. -- Big house with dinning and bed rooms. - Groups: -- Nepomuk -- KDevelop/Kate -- Multimedia/Phonon/Amarok -- Platform_11 [1] For more questions ask on kde-events where the main organization of the meeting happens, on the IRC channel #randa or me privately. The food at the meeting needs to be paid there and is 15.00 CHF (approx. 15.00 EUR) per day. Breakfast, lunch and dinner is included and We will setup a registration system in the next weeks to get information from interested people and send the KDE e.V. board a first estimated budget. More information will come in the next weeks when more is clear. Sorry for crossposting. This is the first and last mail with that many email addresses in the header. Future organizational stuff goes to kde-events and general information to kde-core-devel. Regards and good night Mario
