Re: KDE and Google Summer of Code 2018
On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham wrote: > I've submitted an idea for System Settings: Improve handling for touchpads > and mice with Libinput Speaking of systemsettings, would be a good fit porting to qml some medium-to-big kcm? -- Marco Martin
Re: KDE and Google Summer of Code 2018
On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote: > Note that they'll be finishing GSOC around the same time as 5.14, so that > potentially means GSOC work released in 5.15. > We shouldn't pick high priority ones that we want done before then. basing on the priorities recorded in https://phabricator.kde.org/project/view/ 254/ a possible list, among the "medium": * removable devices * printers * spell check * formats among the "high", but we can live if gets delayed a bit: * mouse (can of worms?) * date/time * user manager other suggestions? -- Marco Martin
Adding Kirigami Gallery to kde-sdk
Hi all, in the kirigami framework repo, there is a little gallery application which outgrew the point of being a small example. It's now becoming a tutorial app: on each page an example and documentation on how to use a particular component and when with links on the relevant source code and HIG page about such component (if available) becoming a developing aide while writing a Kirigami application. Also, since it's planned to add more graphics and heavy media files, makes it not particularly ideal to still use the framework repository. If no objections, it will be moved as a standalone repo as part of kde-sdk as developing aide. -- Marco Martin
Re: KDE Frameworks 5.58.0 released
On Mon, May 13, 2019 at 9:50 PM David Faure wrote: > > 13th May 2019. KDE today announces the release of KDE Frameworks 5.58.0. Hi, unfortunately there was a regression in gethotnewstuff, making installation fail for several types (look and feel themes, plasma themes and possibly some others) It has been fixed yesterday, but unfortunately too late to make it into the release. The repo is frameworkintegration and the commit is e0df1f28231c54d0f92213b2a62428df578e581a -- Marco Martin
Re: KDE Frameworks 5.58.0 released
On martedì 14 maggio 2019 11:52:53 CEST Marco Martin wrote: > On Mon, May 13, 2019 at 9:50 PM David Faure wrote: > > 13th May 2019. KDE today announces the release of KDE Frameworks 5.58.0. > > Hi, unfortunately there was a regression in gethotnewstuff, making > installation fail for several types (look and feel themes, plasma > themes and possibly some others) Sorry David, unfortunately after some user report it turns out the fix that got in 5.58.1 for frameworkintegration wasn't actually covering all cases (and now old plasma workspace with new frameworks has gethotnewstuff broken again) the last commit 134d1ebd0e8ebe74496c43697741fea79fb25933 now fixes the situation for both plasma workspace 5.15 and prior and 5.16 It would be needed (ouch) a 5.58.2 for frameworkintegration -- Marco Martin
Re: Request for help for developing new XDG StatusNotifier/AppIndicator spec for KDE+GNOME
On lunedì 17 gennaio 2022 22:16:12 CET Neal Gompa wrote: > The new specification development has been kicked off with an issue on > the xdg-specs repository: > https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/84 Modernizing the spec to be usable in sandboxed apps would be a thing i'm intersted in.. (original spec dates as back as 2009 btw so yeah, they really weren't a thing back then) On the KDE side I'm wondering what would be the best approach, we would probably have to migrate both the semi-deprecated kstatusnotifieritem in knotifications and qdbussystemtray upstream in Qt -- Marco Martin
Re: Plasmoids: X-KDE-PluginInfo-Website=http://plasma.kde.org/ invalid?
On Friday 25 April 2014 11:20:51 Aleix Pol wrote: > > > > +1 > > FWIW, we could also make kde sysadmin point plasma.kde.org to that url, > otherwise we'll have lost links all over the place, which is a huge loss > either way. yeah, I would prefer that as well. Also (if we want to really push "Plasma" as the desktop product, a pretty user facing website would be handy in the future) -- Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Projects using the plasma-framework for inspiration
On Sunday 22 November 2015, Olivier Churlaud wrote: > Le 22/11/2015 00:46, Aleix Pol a écrit : > > On Sat, Nov 21, 2015 at 5:36 PM, Olivier Churlaud wrote: > >> Hi, > >> > >> I'm porting Amarok to KF5. I'm basically done with the pure C++/Qt part. > >> There is a folder that used to be powered by Plasma::Applet [1]. I have > >> now to port this to plasma-framework. Could you redirect me to a > >> project which use them so that it can inspire me? I have no idea of how > >> to begin > > > > You can look at plasma-workspace/shell. Note that most Plasmoids are > > written in QML nowadays, rather than C++. > > I know that plasmoids are in QML and that's exactly my problem. I don't > know how to build the context with the plasma-framework, and I've never > seen a project which uses it (out of plasmoids, but it's not what I'm > looking for). I could try to do pure QML in the project, but it was > designed with the old plasma-framework and I think it should stay like > this. Hi, I think all depends what are your design goals. If you want to maintain a similar thing, a view with applets that can be added and removed, I think using plasma-framework makes sense because it gives you the infrastructure to have such applets in self contained packages and a layout to save and restore from. Regardless if you decide to use the whole plasma-framework, I think if you want to maintain the "addon, applet" nature of the things in the amarok context view, you should use the same approach for packages: they can also be used separately from plasma with the kpackage framework (managed install, update, remove and load from tarballs with your qml code inside, useful to interact with things like kdelook) If you end up using plasma, I don't think a straight port of the current amarok context view is very feasible, because plasma is changed quite a lo (not beingbased on qgraphicsview anymore and all) what i suggest you is to start to experiment by writing a standalone app as little as possible that loads/saves plasmoids, a minimal shell ( hmm, i should add one in the examples in p-w now that i think about) and then if you are able to make it work as your liking, you take those class you written and stick it as a view in amarok. I suggest you to take a look at the file "standaloneappcorona.cpp" in plasma- framework, is way simpler than "shellcorona.cpp" that is the use used in a normal desktop session: you won't have to worry about things like multi screen, panels or activities (what you need to implement is a Corona subclass, it's the central part for layout save and restore). After that, In order to make the single applet talk with the Amarok internals, there are several methods possible, but all quite simple, so it's secondary at the moment i think :) There are somethings i can think about for which probably plasma-framework is not quite ready, but if there is interest i can work to fix them,, like you may need some headers of a library which doesn't install headers yet (plasmaquick) and the filter on desktop entry keys "X-KDE-ParentApp" should be reimplemented, but it's all an easy fix. Personally, I would like an application using plasma-framework, as it would mean the part of using it as a library would be debugged and ironed out (as the kf5 is not used that way so far) Of course all of this wouldn't be necessary if the context view would become a more fixed thing with one single view and not extensible... again it all depends what the design goals are ;) -- Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Projects using the plasma-framework for inspiration
On Monday 23 November 2015, Olivier Churlaud wrote: > Le 23/11/2015 17:18, Olivier Churlaud a écrit : > > Le 23/11/2015 16:15, Marco Martin a écrit : > >> I suggest you to take a look at the file "standaloneappcorona.cpp" in > >> plasma- > >> framework > > > > I just cloned plasma-framework but didn't see standaloneappcorona (I'm > > on master). > > Sorry for the spam, it was in plasma-workspace... > now the example in the branch mart/customShell in plasma-framework should have most of what you need... depending what's most needed i could either leave it like it is or resurrect the kpart approach that was available in Plasma 4 as well, maybe try it and see adapting that example shell is ok for you or an approach using KPart could be more convenient/less code. Also, a shell package will be needed (it provides things like the qml files common to everything, such as the applets config dialogs, logic for loading containments etc. I was thinking to provide within plasma-framework one such thing intended for applications using a shell (it would be a greatly simplified version of what we are now using for the normal desktop shell). -- Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bugzilla Update: Antispam modification deployed
On Wed, Oct 26, 2016 at 9:42 AM, Ben Cooksley wrote: > Hi all, > > As some of you will already be aware, Bugzilla has recently been > experiencing some issues with spam - courtesy of the same group that > were previously attacking our Wikis and Forums. > > I've now deployed antispam countermeasures on Bugzilla, which should > mitigate many forms of the spam which were previously affecting us. > > If you see any instances of legitimate comments being blocked, please > let us know. Hi Ben, thanks for taking care of this. However, had a couple of problems with the new bugzilla upgrade: tried to use the BUG: git hook to close a bug, but it neither closed the bug nor posted the comment. then tried to manually post a comment with a link to the commit. I guess the scary looking url (http://commits.kde.org/plasma-workspace/274752cda7e723ee21386bb642499a1244223409) triggered the antispam, as that comment gets blocked -- Marco Martin
Re: plasma 5 desktop scripting file locations / examples?
On Tuesday 28 February 2017 23:46:00 Patrick Schleizer wrote: > Hi, > > I am Patrick, a maintainer of Whonix, which Whonix is a Linux derivative > with at least several thousand users, that by default is using Debian > with Debian KDE packages. Is it okay if I ask a few questions on how to > pre-configure KDE as a Linux distribution? > > Are you aware of any example (Debian) packages that pre-configure > plasma 5? These could help me to figure out the correct file locations > and environment variables. > > In KDE 4, essentially the following worked. > > [1] > /usr/share/whonix-gw-kde-desktop-conf/share/apps/plasma-desktop/init/00-defa > ultLayout.js in Plasma5, some settings are condensed in theme packs called look and feel packages, that include things such default layout, widget style, icon theme... https://www.youtube.com/watch?v=RX5HwumKPP8 here is a little video tutorial how to do them https://www.youtube.com/watch?v=Hac3c6fADQM there is an utility in Plasma 5.8/5.9 called lookandfeelexplorer, that can create a l&f package that exports the current settings values supported by it (included default plasmoids layout). for distributions with a custom look, it's advised to create one of them. then the only config key you have to replace is in kdeglobals [KDE] LookAndFeelPackage=org.whonix.yourthemename where org.whonix.yourthemename is the name of your package (folder name and plugin name in its metadata.desktop) > [4] > /etc/X11/Xsession.d/50kde-sounds-off > > if [ -z "$XDG_CONFIG_DIRS" ]; then >XDG_CONFIG_DIRS=/etc/xdg > fi > export XDG_CONFIG_DIRS=/usr/share/kde-sounds-off/:$XDG_CONFIG_DIRS > > [5] > /usr/share/kde-sounds-off/knotifyrc sounds and notifications configurations are not supported in the look and feel packages, so you still need to do this -- Marco Martin
Re: plasma 5 desktop scripting file locations / examples?
On Tuesday 28 February 2017 23:46:00 Patrick Schleizer wrote: > Hi, > > I am Patrick, a maintainer of Whonix, which Whonix is a Linux derivative > with at least several thousand users, that by default is using Debian > with Debian KDE packages. Is it okay if I ask a few questions on how to > pre-configure KDE as a Linux distribution? about look&feel packages, you can see several examples here on the kde store, may be useful see how they are done: https://store.kde.org/browse/cat/121/ -- Marco Martin
Re: GSoC: Educational desktop
On Tue, Mar 15, 2011 at 5:48 PM, Marc Mauri Alloza wrote: > Hello everybody, > My name is Marc Mauri. I'm a computer engineering student from Catalonia > (Spain). I'm interested on participating on GSoC project plasma educational > desktop. I've ridden the 2011 GSoC KDE idea, and I liked it very much, but > there is no mentor assigned to the project. I would like to know who is Hi Marc, this would be awesome, basically, if you stick a while on #plasma and #kde-edu irc channels on IRC, you can have a chat with me, with aaron, with anma... so more details can be discussed.. however, a thing that i always say on who wants to write a gsoc applicatio... think about it and surprise us :p Cheers, Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Introducing components, how to
Hi all, sending here as well after plasma-devel and active there is still some work to do, but the components are almost done in their final structure (good for the upcoming freeze, ehehe :) components are imported with: import org.kde.plasma.components regardless of the platform we're in. We have at the moment 37 widgets in the touch profile, 35 in the normal one, tried to follow the standard api as much as possible even tough with some little deviations (especially where it was too unbearably ugly :p) As for documentation, of course any help will always be welcome :p If you are writing an application, just use kdeclarative, and the proper import paths will be setted. to see what component is available, just take a look at the qmldir file in the source directory of kde-runtime kde-runtime/plasma/declarativeimports/plasmacomponents/qml/ or kde- runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch/ now, two things: Q: why checking qmldir? A: not all files are available, the ones not shown there are private api Q: what are those two folders? A: hardware specific components: the plasma QtComponents are targeted to two things: * Plasma Desktop widgets * Plasma Active widgets and applications (for desktop applications, we can only wait to see whatever it happens with desktop components but is way too early to know ;) When writing a widget, an application etc, just use import org.kde.plasma.components, the proper one is decided by the kdeclarativerc file, if it has [Components-platform] name=touch for packagers: in plasma active among the default files this kdeclarativerc has to be installed the imports in platformcomponents/touch will override the standard one, actually giving a series of touch optimized widgets. only a few that needed have different implementations, the other ones are duplicated by being installed 2 times by cmake some of the differences: * Buttons and lineedits don't have mouseover effects * by default scrollbars behave like scroll decorators on touch * scrolldecorators are installed only on touch (provided just for compatibility, use scrollbar instead, it behaves the right way(tm) ;)) * sectionscroller looks like the iphone addressbook scroller on touch, like a scrollbar on desktop * Window is *not* provided on desktop: in desktop widgets makes really no sense * QueryDialog uses a KDialog on desktop, on touch uses qml items and is in a Plasma::Dialog * the same way, Menu/ContextMenu is a QMenu on desktop, while is a more plasma looking thing on touch this architecture is going to be final once released in 4.8 (at least until frameworks5), so "speak now or forever shut up" :p Cheers, Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Introducing components, how to
On Wednesday 09 November 2011, Marco Martin wrote: > When writing a widget, an application etc, just use > import org.kde.plasma.components, the proper one is decided by the > kdeclarativerc file, if it has > [Components-platform] > name=touch something Sune just noted to me.. maybe an environment variable would be better to chose this? opinions? ;) Cheers, Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Status of QML Porting
On Friday 14 September 2012, Alex Fiestas wrote: > This is the site: > http://community.kde.org/Plasma/QMLPorting > > We have moved old bits of information to it, so even though the table is > quite full of information it is surelly outdated. > > Everybody is invited to take a look at the page, and updated it if there is > some information missing or incorrect. > besides being able to better coordinate, we can have the point of the > situation and see what plasmoids is realistic to push for inclusion in > 4.10. kudos alex for tidying up the list ;) i really want to stress out how much keeping the wiki page up to date is important. is something that interests you if: * you have started one and are either still working on it or oyu have that branch and didn't touch it for a while * you didn't do anything yet, but want to start a port of a qml plasmoid or want to start a new one, in qml * you just want to help and noticed that some important thing is still missing from that list and if you think your work can realistically go into 4.10, don't forget the feature plan :) Cheers, Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Status of QML Porting
On Sunday 16 September 2012, Weng Xuetian wrote: > > I'm currently maintaining a plasmoid which is hard to port to qml (due > to qml limitation), I have tried several month ago but finally gave > up.. > Any advice for my situation? Implement a qml wrapper for my c++ > widget? Or leave it there? > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> unsubscribe << for plasmoids thatare not possible as qml only, i think they should be hybrid: c++ applet with qml user interface. there are several of them as example, like the pager or the weather ones. if something that can't be directly done in qml makes sense as common component an import can be made, but i would like to avoid them as much as possible (remember, as soon you put anything usable with import org.kde.foo you have the responsibility to maintain it with retrocompatibility just as it was a public library, and should *not* be taken lightly ;) Cheers, Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: QML-using app developers: use private.* imports
On Thursday 26 September 2013 02:23:31 Aleix Pol wrote: > The question would be then, why is it that there's some API that's only > needed for internal usage? If it's needed internally, it will be most > likely needed externally, at some point. The fact that you decide to label > it as private makes frustrated developers. > > Either way, I have no idea of what we're talking about here. :D is the fact that the most feasible way to bridge the c++ of an app and the qml part is trough imports. you once told me you did some imports for use in muon for instance, and while there may be some parts of those that does have an use outside that application for everybody to use, all of it surely isn't, being its use just bridge functionality of that particular application, and that's fine. However, i would like everything in org.kde.* to be considered a library, with all the requirements of api stability for the entire lifecycle, and requiring this kind of discipline from all random developers is simply not realistic. then, of course if an app developer decides that a part of his private.foo may make sense for everybody to use can always move it, but by accepting all the social contract that maintaining a library means -- Marco Martin >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Proposal unify back our release schedules
On Friday, 19 April 2024 17.50.44 CEST Neal Gompa wrote: > > > * "KDE Framework" will still exists as an entity and its ABI and API > > > > > > compatibility requirement. Only change is the release frequency and > > > the > > > > > > introduction of a stable branch in sync with the other components. > > > > That part I'm against for the above mentioned reasons, KF's release > > frequency is a major feature of it. > > As a distribution, I found it tremendously helpful to integrate and > qualify the MegaRelease. That doesn't mean that we need *every* > release of KF and Gear to be MegaReleases. One thing I would like to hear from the distribution standpoint, is that in the past i also heard our release schedule being part of the reasons some enterprise distros dropped our stuff completely from the official release (suse and red hat). In part it sounded kinda an excuse to me, but if there is any part of truth is worth exploring. is changing frequency or dates something that would help significantly distros? is there something about our current schedules that is a significant hindrance for distributions to the point "we don't feel we can adequately support it"? a part of this discussion should have the point of a good relatioship with downstream in consideration (also because is part of the broader "getting to more users") -- Marco Martin
Re: VDG application design sprint?
for me would work either first half of june or july On Thu, Apr 11, 2024 at 4:26 PM Nicolas Fella wrote: > > On 1/24/23 00:43, Nicolas Fella wrote: > > Hi, > > > > I think it would make sense for us to have a VDG sprint of sorts in the > > near-ish future. This would allow to discuss some larger design topics > > and set a vision for the longer-term future. I believe this is important > > for us to be able to work together effectively. > > > > I'd suggest to focus on application design topics, like layout, > > structure, and arrangement of apps, and less on things like Plasma and > > styles/themes. I'd also suggest to approach this more from a design/UX > > PoV and don't let us be driven by implementation details. But these are > > just my suggestions that are subject to debate. > > > > Time/place/modality is all to be discussed, I'm mainly writing this to > > gauge interest, so if you are interested let me know. > > Hi, > > I'd like to pick up this topic again since it's as relevant as ever. > > I have a possible venue in central Germany where I live (in an old > castle, so in good KDE tradition). We could accomodate up to 10 people > there, and more people nearby if needed. > > For those interested, what would be a good timeframe in terms of dates > and duration? > > Cheers > > Nico >
Re: KDE Review Request: Keep Secret
Should it already be moved to another more public-facing repo to start to setup CI ? On Tue, Jul 15, 2025 at 3:22 PM Marco Martin wrote: > > Hi all, > > I have been working over the last months on an application called Keep Secret. > It is intended to be a password manager gui which uses the Secret > Service DBus api > as backend, therefore it works with KWallet, gnome-keyring, oo7 etc.. > > The current home is: > > https://invent.kde.org/mart/keepsecret > > It can be tested by having any secret service set up (or just secret > service enabled in the KWallet config. > > I've added a kdereview issue here: > https://invent.kde.org/mart/keepsecret/-/issues/1 > > The final place for this should be i think in gear, under kdeutils? > > did i miss something? > > -- > Marco Martin -- Marco Martin
KDE Review Request: Keep Secret
Hi all, I have been working over the last months on an application called Keep Secret. It is intended to be a password manager gui which uses the Secret Service DBus api as backend, therefore it works with KWallet, gnome-keyring, oo7 etc.. The current home is: https://invent.kde.org/mart/keepsecret It can be tested by having any secret service set up (or just secret service enabled in the KWallet config. I've added a kdereview issue here: https://invent.kde.org/mart/keepsecret/-/issues/1 The final place for this should be i think in gear, under kdeutils? did i miss something? -- Marco Martin
Re: KDE Review Request: Keep Secret
Hi, Unfortunately QtKeychain while perfect for saving and reading of a password from an application, doesn't do what i need. I wanted a tool that can list all secret collections, create/delete them, and list all secrets in a collection saved by any application, also those from other desktops. QtKeychain can only read and write from the default collection, and list passwords saved with its own qtkeychain "schema" In SecretService, schemas are a set of metadata keys that are allowed, and different apps can use different ones, so QtKeychain for the ways it does queries to secretservice, doesn't "know" about them (but that's fine, because the alternative is much more complicated and a bug would give access to other secrets, that are out of the scope of the library) I don't think that expanding QtKeychain to support all is needed is either desiderable nor feasible, because on one hand, the QtKeychain api has to more or less map to the minimum common denominator of what's allowed by the api of every supported platform (i would doubt that android would ever let a normal app look at the secrets of all other apps for instance) and on the other hand, the goal of QtKeychain is really to be a no frills api for the use case "i have an app that needs to store a secret, i want a simple api to store and read that secret, and nothing else" I don't think adding extra stuff for being able to be a system password manager makes much sense (if possible at all on some of the supported platforms) On Thu, Jul 17, 2025 at 5:19 PM Ingo Klöcker wrote: > > On Donnerstag, 17. Juli 2025 14:39:57 Mitteleuropäische Sommerzeit Marco > Martin wrote: > > Thanks, > > I got it mostly working. > > However i had to disable Android and windows because of the dependency > > to GNOME libsecret which i don't think is available there? > > (also, on Android I think it would really make no sense as the > > application needs a DBus connection to SecretService which is not > > really possible there) > > This may be a stupid question, but why didn't you use qtkeychain which has > backends for all major OS and which we use in most if not all KDE apps that > store passwords? > > https://github.com/frankosterfeld/qtkeychain > > Regards, > Ingo -- Marco Martin
