KGeotag development
Dear devs, some time ago, I introduced the KGeoTag project. Meanwhile, the git repository has been moved from my personal projects to graphics/, we have a Bugzilla product (already used for a translation-related issue), and an IRC channel. The hardworking i10n enthusiasts team actually already translated the whole thing in several languages (despite the project still being beta and lacking a first stable release!). At least two KDE devs have had a closer look at the code, Nicolas Fella concerning the build system and Johannes Zarl-Zierl helping me with the item model and the drag and drop support. So, apparently, I'm not the only one thinking this could be a convenient program for KDE :-) Ben Cooksley said that necessarily, a new project at first is declared as "playground", until some review process is passed and it then can become an "extragear" app. I think, at least for a first release, the program now is feature-complete, and currently, I'm also not aware of any bugs. So what are the next steps for KGeoTag to become extragear and making it possible to do a first "official" release? Thanks again for all the support and interest :-) Cheers, Tobias
Re: Getting involved in SoK
Hello, Thanks alot for helping me. I have basically understand what you have provided me, what next step shall I do to start in this project? Thanks in advance. On Mon, 9 Nov 2020, 3:40 pm Aleix Pol, wrote: > On Fri, Nov 6, 2020 at 7:37 PM Mariam Fahmy > wrote: > > > > Hello, > > Thanks alot for your advice. > > I have installed the project locally and I start discovering how > backends work with codebase. > > I have understood but I am missing things. > > After doing some research and gathering information, here's what I can't > clearly understand: (Sorry if questions are little bit silly) > > Hi Mariam, > No need to worry, feel free to ask away. > > > 1- what does it mean by resource? > > When I searched about it, I found that resources may be data required by > user or requests from clients, is it right ? > > You can see here the class that defines a resource, should help you > see what it represents: > > https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResource.h > > In general, it's an asset: be it an application, a wallpaper or > anything that can be listed and installed. > > > 2- to create a new resources backend we need to implement two classes, > > The first class is the basic class which saves all created resources and > install & remove application or cancel transactions. > > The second class, I didn't understand it's functionality, I found that > it is related to plugins but didn't understand it. > > The second important one is the resource I just mentioned above. > Please explain a bit more what you don't understand. > > > 3-Filters in the base class: its target to filter the new requested > resources? > > filters we just use when searching, to see what's being searched. > In the case of this project it shouldn't be very important, since we > will just be listing a system image. > > > 4- for each new resource backend, it should include all the methods of > base class, right? > > As these methods acts as properties for each new resource. > > You need to implement all the abstract (i.e. virtual = 0) methods. The > rest of virtuals you can override if you want to give it a different > functionality. > > > 5- I have searched about plugins, but I didn't fully understand it, > plugins enable programmers to update host program while keeping the user > within the program's environment, but I can't understand what is the role > of plugins here if we receive new requests and make new resources? > > It is meant that while creating a new resource, we need plugin in order > to keep the user with the program's environment without altering it or > affecting it while creating new resources? > > It's just a way to build the applications so the whole project doesn't > depend on a specific technology. You can see the ones we implement > right now here: > https://invent.kde.org/plasma/discover/-/tree/master/libdiscover/backends > > This project should be adding a new OSTreeRPMBackend folder in here > that will only take care of this one implementation. > > I hope this helps, > Aleix >
Re: KGeotag development
El diumenge, 15 de novembre de 2020, a les 10:32:39 CET, Tobias Leupold va escriure: > Dear devs, > > some time ago, I introduced the KGeoTag project. > > Meanwhile, the git repository has been moved from my personal projects to > graphics/, we have a Bugzilla product (already used for a translation-related > issue), and an IRC channel. > > The hardworking i10n enthusiasts team actually already translated the whole > thing in several languages (despite the project still being beta and lacking a > first stable release!). > > At least two KDE devs have had a closer look at the code, Nicolas Fella > concerning the build system and Johannes Zarl-Zierl helping me with the item > model and the drag and drop support. > > So, apparently, I'm not the only one thinking this could be a convenient > program for KDE :-) > > Ben Cooksley said that necessarily, a new project at first is declared as > "playground", until some review process is passed and it then can become an > "extragear" app. I think, at least for a first release, the program now is > feature-complete, and currently, I'm also not aware of any bugs. > > So what are the next steps for KGeoTag to become extragear and making it > possible to do a first "official" release? Please see https://community.kde.org/Policies/Application_Lifecycle Ask if you find anything in that page unclear so we can fix it for the next person :) Cheers, Albert > > Thanks again for all the support and interest :-) > > Cheers, Tobias > > >
Re: RSIBreak / KIdleTime on Wayland
El dissabte, 14 de novembre de 2020, a les 12:46:41 CET, Dominik Waurenschk va escriure: > Hi, I just came across the issue that RSIBreak is unable to count down in > wayland, after 1 second it always resets its timer. > > I investigated the code and found that it calls KIdleTime, which in turn > calls a platform-specific plugin. > > In particular, it calls forcePollRequest() to get the current idle time > (instead of waiting for a timeout event or similar) > > For Wayland this function prints a warning that this plugin doesn't support > polling idle time, but then always returns 0, which RSIBreak later interprets > as activity, since it thinks 0 seconds passed, this halting the countdown. > > This plugin in turn uses KWayland::Client::Idle, which does indeed seem to > only support timeouts and no getting the actual idle time. So if it is really > not possible to count idle time in wayland (I don't know enough about wayland > to implement it myself at this time), then I think it would be useful to, > instead of only printing a warning to console/log, the function would > actually return some type of error code to the caller. (It could return -1, > or throw an exception, or similar) > > > So then the caller can react to the fact that polling is not supported, and > could perhaps implement a different way of measuring time on that platform. > (it could perhaps use its own timer and reset when the platform plugin emits > resumingFromIdle, i haven't tried out how this works yet). > > So do you think it makes sense to have the function return some form or error > instead of just returning 0, or is there a good reason it is not doing that > already? I agree, if we can't make the KIdleTime framework work in Wayland there should be a way to query the framework if it's going to work or not. CC'ing the frameworks devel list. Cheers, Albert > > Thank you, > Dominik >
Re: RSIBreak / KIdleTime on Wayland
> I agree, if we can't make the KIdleTime framework work in Wayland there > should be a way to query the framework if it's going to work or not. Just to make sure that's not misread by others; the framework works for the majority of methods used in the common case, just not this one polling method. > > So do you think it makes sense to have the function return some form or > > error instead of just returning 0, or is there a good reason it is not > > doing that already? I don't think it helps with a lot, you need to change clients to handle the error, at which point we've not really solved a lot. If you're going to use the addIdleTimeout API you may as well do it everywhere. It is considerably lighter on X11 too. Like Albert suggested, a capabilities flag could make sense. At a super bare minimum the documentation needs updating. At the other extreme we could even deprecate it. If after trying to port rsibreak to use the event driven API and it turns out there really is a use case for a polling API, we do still have the option to start a discussion about extending the relevant wayland protocol to have such a query mechanism. >RSIBreak is unable to count down in wayland, after 1 second it always resets >its timer. Just to make sure we're talking about the same thing: Is it when you have a shortbreak set after N minutes and you get a "please relax for 20seconds" with a progress bar? If so, simplest option is to start a 1s idletime timer. We don't need to know how long we've been idle via polling, just if/when we're interrupted during the 20s countdown. David
Re: RSIBreak / KIdleTime on Wayland
> > Yes, I meant that progress bar. > I've had that 1s idle timer idea as well, unfortunately after writing this, > but thank you for confirming that this would indeed work. > I will give that a try and if I can get RSIBreak to a working state on > wayland submit a PR for it. Excellent, thank you very much. Please do please reach out if there are any questions with regards to the wayland side. David
Re: RSIBreak / KIdleTime on Wayland
> > > So do you think it makes sense to have the function return some form or > > > error instead of just returning 0, or is there a good reason it is not > > > doing that already? > I don't think it helps with a lot, you need to change clients to > handle the error, at which point we've not really solved a lot. If > you're going to use the addIdleTimeout API you may as well do it > everywhere. It is considerably lighter on X11 too. > Like Albert suggested, a capabilities flag could make sense. Now that it was mentioned, I agree that having some way of checking if this feature works (like a capability flag) is a better idea than changing the expected behaviour of the function. > > RSIBreak is unable to count down in wayland, after 1 second it always > > resets its timer. > Just to make sure we're talking about the same thing: Is it when you > have a shortbreak set after N minutes and you get a "please relax for > 20seconds" with a progress bar? > > If so, simplest option is to start a 1s idletime timer. We don't need > to know how long we've been idle via polling, just if/when we're > interrupted during the 20s countdown. > David Yes, I meant that progress bar. I've had that 1s idle timer idea as well, unfortunately after writing this, but thank you for confirming that this would indeed work. I will give that a try and if I can get RSIBreak to a working state on wayland submit a PR for it. Dominik signature.asc Description: OpenPGP digital signature
