Re: Using xdg-desktop-portal-kde to take screenshots
When you run "dbus-monitor --session" and you perform the screenshot, do you see this signal to be called at all? Thanks Jan, I'll try that. Unfortunately no, again a limitation of the portal API as the portal is supposed to return an URI. You can however directly use KWin DBus interface to get a screenshot, specifying directly what type of screenshot you want to tak and you get the raw image. This however will make it work only in Plasma and will not work in an application running in sandbox without giving it access to DBus. My Application already supports native Plasma and Gnome Wayland Screenshots, but that does don't work if the application is packaged as Snap or when non Plasma or Gnome environments are used, so I'm trying to make this generic Wayland solution work. Also, I've been playing around with this under Gnome too and they have also a Dialog but with a Share button instead of Save. I believe they are doing it like with the native Wayland solution by saving the image in a temp directory that is deleted on reboot and just providing the path to the image. The user can decide what to do with the image, save it permanently or do nothing and the image is gone. Though there I have the same problem that the gotScreenshotResponse is never called. Best regards, Damir From: kde-devel on behalf of Jan Grulich Sent: Monday, September 21, 2020 08:08 To: kde-devel@kde.org Subject: Re: Using xdg-desktop-portal-kde to take screenshots Hi, ne 20. 9. 2020 v 18:37 odesílatel Damir Porobic mailto:damir_poro...@live.com>> napsal: Hello Jan, finally I found some time to upgrade my OS and got a newer Plasma Version but I'm still struggling with the Screenshot Portal. Here is my implementation, almost identical to yours from the test that you have linked me (pasting here only the relevant methods):I get the dialog which asks me what type of screenshot I want to take I select it, a small image is show in the dialog and I can click on save (which saves the image in my home directory) but the gotScreenshotResponse is never called. Any idea why? I have no idea. The code looks good and identical to what I have in the example. When you run "dbus-monitor --session" and you perform the screenshot, do you see this signal to be called at all? Can I tell the dialog where to save those images? Unfortunately no, I made it very basic, but patches are welcomed, it won't be a hard task to implement it. Can I tell the dialog right away what type of screenshot I want to take? Unfortunately no, this is not supported by the portal API. Can I just share the screenshot with my application without saving it? Unfortunately no, again a limitation of the portal API as the portal is supposed to return an URI. You can however directly use KWin DBus interface to get a screenshot, specifying directly what type of screenshot you want to tak and you get the raw image. This however will make it work only in Plasma and will not work in an application running in sandbox without giving it access to DBus. Regards, Jan
Building Elisa fails everytime
Hello Today I was trying to build elisa "*kdesrc-build elisa*" but it failed with a message <<< PACKAGES FAILED TO BUILD >>> > frameworkintegration - > ~/kde/src/log/2020-09-21-01/frameworkintegration/build.log > kactivities-stats - ~/kde/src/log/2020-09-21-01/kactivities-stats/build.log > kcmutils - ~/kde/src/log/2020-09-21-01/kcmutils/build.log all 3 logs says the same thing as below except different package names # kdesrc-build running: 'make' '-j' '12' > # from directory: /home/pavank/kde/build/frameworkintegration > make: *** No targets. Stop. Am new to this, can you please help me? -- Warm Regards, Pavan Kumar
Re: Building Elisa fails everytime
Hello, I am not currently using kdesrc but your failures are related to some KDE Frameworks. On lundi 21 septembre 2020 16:24:33 CEST Pavan Kumar wrote: > Hello > Today I was trying to build elisa "*kdesrc-build elisa*" but it failed with > a message > > <<< PACKAGES FAILED TO BUILD >>> > > > frameworkintegration - > > ~/kde/src/log/2020-09-21-01/frameworkintegration/build.log > > kactivities-stats - > > ~/kde/src/log/2020-09-21-01/kactivities-stats/build.log > > kcmutils - ~/kde/src/log/2020-09-21-01/kcmutils/build.log > > all 3 logs says the same thing as below except different package names > > # kdesrc-build running: 'make' '-j' '12' > > > # from directory: /home/pavank/kde/build/frameworkintegration > > make: *** No targets. Stop. > > Am new to this, can you please help me? You may have some packages missing that prohibits building those frameworks. Is there some other logs showing the result of the calls to cmake before make is called ? Best regards -- Matthieu
Re: Building Elisa fails everytime
On 21.09.20 16:24, Pavan Kumar wrote: Hello Today I was trying to build elisa "*kdesrc-build elisa*" but it failed with a message <<< PACKAGES FAILED TO BUILD >>> frameworkintegration - ~/kde/src/log/2020-09-21-01/frameworkintegration/build.log kactivities-stats - ~/kde/src/log/2020-09-21-01/kactivities-stats/build.log kcmutils - ~/kde/src/log/2020-09-21-01/kcmutils/build.log all 3 logs says the same thing as below except different package names # kdesrc-build running: 'make' '-j' '12' # from directory: /home/pavank/kde/build/frameworkintegration make: *** No targets. Stop. Am new to this, can you please help me? Please change into the ~/kde/build/frameworkintegration directory, run "cmake ." and show us the output
Question about copyright notices
Hello, I remember reading somewhere in the Internet that it is not useful or necessary to bump the year part of copyright notices. I did not manage to see if this indicated in https://community.kde.org/ Policies/Licensing_Policy Is there some consensus as to what is best for code hosted by the KDE community ? Best regards -- Matthieu
Re: Officially adopt "Noteworthy" label into KDE policy
Thank you Nate and Johannes for your positive feedback. If there are no further complaints / comments, I'll edit the Commit Policy wiki page tomorrow and add the points I listed below. Cheers, Julian / xyquadrat On 18.09.20 10:05, Julian / xyquadrat wrote: Hi all, A few months back I suggested on behalf of the Promo team the introduction of a new label for issues and merge requests (see https://marc.info/?t=15869532709&r=1&w=2 for the thread). The idea behind this "Noteworthy" label was to make it easier for Promo to keep up with all important new changes that are coming up in our software and reduce the possibility that something noteworthy gets overlooked. Since then, the GitLab migration has been completed and such a label has actually been introduced (see https://invent.kde.org/dashboard/merge_requests/?scope=all&label_name[]=Noteworthy for an overview of Merge Requests tagged with "Noteworthy"). Given that the technical challenge is now solved, I'd like to propose to make this Noteworthy label official in the sense of adding it to the "Special keywords" section of Commit Policy (if there is a more appropriate place, please suggest it!) and encourage all contributors to start using it. A few remarks: - Of course all contributions are noteworthy and important. Promo does not want to discount the work that goes into small and unnoticeable fixes. - If you are not sure whether a MR or issue should be "Noteworthy" or not, tag it with "Noteworthy" (-> be liberal with the label usage). Promo will then consider such edge cases in detail. - Not all things tagged might make it into an official announcement. This is (usually) not due to us overlooking them, but because we have to carefully prioritize what we include. If you think something was left out that should definitely have been included, reach out to us on #kde-promo and we will be happy to discuss individual cases and solutions. *Examples of noteworthy changes:* * User facing feature additions (e.g. /New useful effect added to Kdenlive/) * Big changes in UI (e.g. /a KCM is rewritten in QML and now looks distinctively different/) * Long-standing, annoying bugs (e.g. /Rework of the previously bug-ridden MTP implementation in KIO/) * Large technology shifts (e.g. /Port to Qt 6/) * Significant performance improvements (best paired with concrete numbers, but not necessary) *Examples of changes not considered noteworthy: * * Small UX annoyances and fixes. Whilst those add up to something very important, the individual changes (e.g. "more consistent padding in dialogs") are not interesting to users. * Shifts in technology that do not affect the behavior of the product (e.g. /porting from library X version Y to library X version Y+1/) * Minor changes to tools and backends used in the development process Feedback and criticism is much appreciated. Cheers and have a nice day, Julian / xyquadrat
Re: Building Elisa fails everytime
Hello Nicolas, Replying using a different email because I wasn't subscribed. I am now. I ran `cmake .` inside ~/kde/*build*/frameworkintegration but there's no CMakeLists.txt there and cmake complained the same. But I could run cmake inside ~/kde/*src*/frameworkintegration ( https://pastebin.com/TVQjzgxi output), also I saw that there is another build folder inside ~/kde/*src*/frameworkintegration and I can run cmake inside it as well. Warm Regards Pavan Kumar On Tue, 22 Sep 2020 at 00:30, Matthieu Gallien wrote: > Hello, > > I am not currently using kdesrc but your failures are related to some KDE > Frameworks. > > On lundi 21 septembre 2020 16:24:33 CEST Pavan Kumar wrote: > > Hello > > Today I was trying to build elisa "*kdesrc-build elisa*" but it failed > with > > a message > > > > <<< PACKAGES FAILED TO BUILD >>> > > > > > frameworkintegration - > > > ~/kde/src/log/2020-09-21-01/frameworkintegration/build.log > > > kactivities-stats - > > > ~/kde/src/log/2020-09-21-01/kactivities-stats/build.log > > > kcmutils - ~/kde/src/log/2020-09-21-01/kcmutils/build.log > > > > all 3 logs says the same thing as below except different package names > > > > # kdesrc-build running: 'make' '-j' '12' > > > > > # from directory: /home/pavank/kde/build/frameworkintegration > > > make: *** No targets. Stop. > > > > Am new to this, can you please help me? > > You may have some packages missing that prohibits building those > frameworks. > > Is there some other logs showing the result of the calls to cmake before > make > is called ? > > Best regards > > -- > Matthieu > > > -- Warm Regards, Pavan Kumar
