[gwenview] [Bug 382842] Segfault when opening certain image
https://bugs.kde.org/show_bug.cgi?id=382842 Henrik Fehlauer changed: What|Removed |Added CC||krzak.pa...@gmail.com --- Comment #12 from Henrik Fehlauer --- *** Bug 397722 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 397722] Gwenview Crashes in Exiv2::ExifData::findKey()
https://bugs.kde.org/show_bug.cgi?id=397722 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||rk...@lab12.net --- Comment #5 from Henrik Fehlauer --- The crash happens in Exiv2, and most likely is already fixed upstream (http://dev.exiv2.org/issues/0001283 looks like it). Try upgrading once Neon switches its base to Ubuntu 18.04. *** This bug has been marked as a duplicate of bug 382842 *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 397613] crash after changed home directory
https://bugs.kde.org/show_bug.cgi?id=397613 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|UNCONFIRMED |NEEDSINFO CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for your message. I'm not really sure what you are doing. Are you saying that opening a specific image works fine when it is located in a particular directory, but crashes Gwenview when it is located in another directory? What do you mean exactly with "changing home directory"? As for the crash, please install debugging symbols and resubmit the backtrace (see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports). Lastly: > Could not get a valid KFileMetaInfo instance That string has been removed from Gwenview's source for version 17.04 with https://phabricator.kde.org/R260:047bc063ec5c21f3bed9fcdc6667892efe6dd8db. I don't know it this is related, but in any case you should try to reproduce the problem with a recent version of Gwenview, e.g. 17.12.3 as found in Kubuntu 18.04. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397390] Screenshot not added to clipboard if 'Quit after Save or Copy' is enabled
https://bugs.kde.org/show_bug.cgi?id=397390 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for the report. Unfortunately this is still an issue, see Comment 1 of the duplicate for a workaround. *** This bug has been marked as a duplicate of bug 393708 *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 393708] Copy to clipboard doesn't seem to work with default Klipper settings
https://bugs.kde.org/show_bug.cgi?id=393708 Henrik Fehlauer changed: What|Removed |Added CC||q4...@uwaterloo.ca --- Comment #22 from Henrik Fehlauer --- *** Bug 397390 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 327211] build fails: importer/fileutils.cpp:133:10: error: use of undeclared identifier 'mkdtemp'
https://bugs.kde.org/show_bug.cgi?id=327211 Henrik Fehlauer changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #3 from Henrik Fehlauer --- No answer, closing for now. Feel free to reopen if it is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 173850] Add an option to hide folders from thumbnail view
https://bugs.kde.org/show_bug.cgi?id=173850 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Henrik Fehlauer --- > first see a full page of folders I don't want to see. In recent versions Gwenview selects and centers the first image in the viewport upon entering a folder, regardless of the number of folders display before that image. I think that solves the use case nicely, so we don't have to add an extra option and can close the bug as fixed. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 397292] Occasional delay when opening image file
https://bugs.kde.org/show_bug.cgi?id=397292 Henrik Fehlauer changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #4 from Henrik Fehlauer --- If a restart of Gwenview does not fix the issue, but a restart of the computer does, I'm pretty sure Gwenview cannot be at fault. Sounds like excessive swapping or high CPU usage to me, you might want to check with KSysGuard. Also double-check whether other apps are affected too, e.g. by opening an image in Okular. I'm closing this for now, but feel free to reopen and possibly change the Bugzilla product once you have more certainty on what component is causing the issue. In that case a video recording might be helpful, and looking at it with gdb. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 397292] Occasional delay when opening image file
https://bugs.kde.org/show_bug.cgi?id=397292 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net --- Comment #2 from Henrik Fehlauer --- > Gwenview sometimes delays when opening an image file. I'm not really sure what you mean by that, could you be more specific? For example: - How are you opening the image? - What is delayed exactly, opening of Gwenview, opening the image, displaying the image, general unresponsiveness of the whole computer? - Do you experience the delay also when switching to that image? > this image seems to consistently cause Gwenview to lag I don't notice anything wrong with that image, for me it's opening fine just like any other image really. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397307] Hide or show pointer only effects the following screenshot
https://bugs.kde.org/show_bug.cgi?id=397307 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for your message. If we implemented your suggestion, changing options after the fact should also work for all of the other options. However, I don't think that's feasible from a performance and memory perspective, because the number of possible combinations would just be too high. The workflow is supposed to be like this: - Set options. - Take screenshot. - Save. Other apps use a more wizard-like workflow, but I think that's tedious and the current way serves most Spectacle users well enough. --- I suppose your use case was to exclude the mouse pointer after you took the screenshot, because you had no use for it? If so, we probably rather should disable the mouse pointer by default, see Bug 397121. -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 389794] "Print Images" always greyed out when opening "Plugins" menu the first time
https://bugs.kde.org/show_bug.cgi?id=389794 Henrik Fehlauer changed: What|Removed |Added Product|gwenview|kipiplugins Component|general |general Assignee|gwenview-bugs-n...@kde.org |imaging-bugs-n...@kde.org Version|18.04.3 |5.8.0 CC||rk...@lab12.net --- Comment #4 from Henrik Fehlauer --- Let's move this bug to kipi-plugins for now, since Gwenview has no special handling for specific plugins, and for other plugins it's working fine (why, though?). It might very well be an old problem which only surfaced due to 1fc7d86dbc94. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 210238] Error while compiling kdegraphics from SVN
https://bugs.kde.org/show_bug.cgi?id=210238 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Since this is about a 9 year old compilation failure, and current distros are shipping recent versions of kamera and libgphoto just fine, I'm going to assume that this has been solved in the meantime. Feel free to open a new bug against Frameworks if this is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 113430] camera detection via konqueror
https://bugs.kde.org/show_bug.cgi?id=113430 --- Comment #4 from Henrik Fehlauer --- *** Bug 127931 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 127931] error when connecting a camera to usb port
https://bugs.kde.org/show_bug.cgi?id=127931 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||rk...@lab12.net --- Comment #5 from Henrik Fehlauer --- As far as I can see Daniel reported the same issue one year earlier already, see Bug 113430. As for Comment 1, Comment 2 and Comment 3, those are likely different problems. Please open new/separate bugs if they can still be reproduced. *** This bug has been marked as a duplicate of bug 113430 *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 202704] Configure dialog too big for Nikon D60
https://bugs.kde.org/show_bug.cgi?id=202704 Henrik Fehlauer changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||rk...@lab12.net Resolution|--- |DUPLICATE --- Comment #2 from Henrik Fehlauer --- Sorry nobody looked at this for 9 years. It turns out this is actually a duplicate of a 15 year old bug. That said, as far as I can tell the issue has been resolved by now… *** This bug has been marked as a duplicate of bug 63356 *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 217900] The camera model chooser dialog should contain a search field
https://bugs.kde.org/show_bug.cgi?id=217900 Henrik Fehlauer changed: What|Removed |Added Ever confirmed|0 |1 CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED --- Comment #4 from Henrik Fehlauer --- > camera chooser dialog should contain a search field Regardless of autodetection, adding a search field might still make sense from a UI perspective. Of course separating out serial cameras might also be an option. See also Bug 74553, which tracks improving grouping. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 63356] camera settings window is too high in kcmkamera
https://bugs.kde.org/show_bug.cgi?id=63356 Henrik Fehlauer changed: What|Removed |Added CC||schwar...@kde.org --- Comment #7 from Henrik Fehlauer --- *** Bug 202704 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 278844] kio_kamera leaks memory when copying large files from camera
https://bugs.kde.org/show_bug.cgi?id=278844 Henrik Fehlauer changed: What|Removed |Added Ever confirmed|0 |1 CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED --- Comment #2 from Henrik Fehlauer --- > pass-through mode As far as I can tell from a short test, as of v18.07.90 kio_kamera.so still gobbles up memory when copying a large file, so this probably has not been implemented yet. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 208755] kio_camera segfault with PTP camera
https://bugs.kde.org/show_bug.cgi?id=208755 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net --- Comment #3 from Henrik Fehlauer --- Bernhard: Thanks for the update (and sorry nobody responded in the last 7 years). Great to hear it works now for you, however it does not sound to me like it was the same issue the bug was originally about (the segfault in particular). Daniel: Could you test whether this still is an issue for you with a recent version? (With a another device it is working fine for me as of kamera v18.07.90 and libmtp 1.1.14, so if this is still an issue it's likely hardware specific.) -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 183159] files copied from camera:/ have no write permissions
https://bugs.kde.org/show_bug.cgi?id=183159 Henrik Fehlauer changed: What|Removed |Added Ever confirmed|0 |1 CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED --- Comment #1 from Henrik Fehlauer --- > files have no write permissions That's still an issue as of v18.07.90. However, I wonder whether instead of hardcoding r/w permissions this should simply respect the umask of the target directory. > it would be really nice if there were some pop-up Only one issue per bug please ;) Anyway, that should be working fine in Plasma nowadays. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 183159] files copied from camera:/ have no write permissions
https://bugs.kde.org/show_bug.cgi?id=183159 Henrik Fehlauer changed: What|Removed |Added CC||anase...@linux.it --- Comment #2 from Henrik Fehlauer --- *** Bug 290704 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 290704] gwenview_importer creates write-protected files
https://bugs.kde.org/show_bug.cgi?id=290704 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |DUPLICATE Status|CONFIRMED |RESOLVED --- Comment #3 from Henrik Fehlauer --- *** This bug has been marked as a duplicate of bug 183159 *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 305577] USB PTP devices failure, Unknown code error: 150
https://bugs.kde.org/show_bug.cgi?id=305577 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|--- |WAITINGFORINFO Status|UNCONFIRMED |NEEDSINFO --- Comment #6 from Henrik Fehlauer --- Germano, Marcus: Could you test whether that's still an issue with recent versions? If so, please move the bugs to a Frameworks component. (This might be related to Bug 308542 which also features a Galaxy SII, however someone with access to multiple devices should probably also test whether those are still mixed up.) -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 308542] I am not work the Dolphin file manager when connecting with USB my cellular phone Samsung Galaxy SII I9100 with Android 4.0.X
https://bugs.kde.org/show_bug.cgi?id=308542 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|--- |WAITINGFORINFO Status|CONFIRMED |NEEDSINFO --- Comment #3 from Henrik Fehlauer --- Pablo: Is this still an issue for you with a recent version? (With a similar device it is working fine for me as of kamera v18.07.90 and libmtp 1.1.14, so if this is still an issue it's likely hardware specific.) -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 307599] camera:/ fails to retrieve data from Galaxy Nexus via MTP/PTP
https://bugs.kde.org/show_bug.cgi?id=307599 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Sven: Is this still an issue for you with a recent version? (With a similar device it is working fine for me as of kamera v18.07.90 and libmtp 1.1.14, so if this is still an issue it's likely hardware specific.) -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 67469] Improvements required in Kamera
https://bugs.kde.org/show_bug.cgi?id=67469 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for the report, and sorry nobody looked at this in the last 15 years. > This report is more like a combo report Please only report a single bug or idea per bug, because otherwise tracking becomes really difficult for us. > - It should support EXIF information in preview (in the tooltip) As of v18.07.90, I still don't get any metadata showing in Dolphin's sidepanel or the tooltips. > - It should have an icon in the "Services" or "Devices", in konqueror. > Maybe automatic, when the camera is detected. That's tracked in bug 386060. > - It should display in desktop, just like other drives, > like CD-Rom and stuff. These days, Plasma does not show devices on the desktop anymore by default. > - It shouldn't be listed under "Internet Protocols" in > Konqueror->Configure->"Previews & Metadata" As of KDE 4, you cannot configure which protocol is classified as local or remote anymore from the GUI. That said, with "Skip previews for files above 0 MB" I still got previews, so camera:/ is now a local protocol (confirmed by looking at camera.protocol, which has "Class=:local"). > launch konqueror when the camera is detected. When you attach a camera, nowadays Plasma's device notifier will pop up. --- In summary: One issue (showing EXIF information and other metadata) is still open. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 63486] showing popup if camera or gphoto2-driver don't support uploading (usability)
https://bugs.kde.org/show_bug.cgi?id=63486 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #2 from Henrik Fehlauer --- Trying to move a file to a device opened through camera:/ in PTP mode, Dolphin shows "Could not write to file .", so I assume this is still an issue 11 years later as of v18.07.90. In a way Dolphin's message is a "popup", but let's keep this open until kamera supports writing (camera.protocol currently still has "writing=false"). -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 74553] grouping camera's per vendor like in kdeprint (usability)
https://bugs.kde.org/show_bug.cgi?id=74553 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #4 from Henrik Fehlauer --- As of v18.07.90, there's still only a single (ungrouped) list when adding a camera. Adding a search field is tracked in Bug 217900. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 202707] Tooltip on the Information dialog appears over whole screen
https://bugs.kde.org/show_bug.cgi?id=202707 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Henrik Fehlauer --- As of v18.07.90, I don't get any tooltip in the information dialog anymore, so I assume this has been fixed in the meantime. Feel free to reopen and move the bug to Frameworks if this is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 41488] Kamera lacks serial port speed setting in Control Center
https://bugs.kde.org/show_bug.cgi?id=41488 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #3 from Henrik Fehlauer --- As far as I can tell from the sources (lacking a serial port camera), there's still no speed setting as of v18.07.90. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 63341] kio kamera does not work with Olympus c 2020 z
https://bugs.kde.org/show_bug.cgi?id=63341 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net Status|ASSIGNED|NEEDSINFO --- Comment #8 from Henrik Fehlauer --- gerard: 12 years later, is this still an issue with recent versions of kamera (assuming you still own a Olympus c 2020 z)? -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 63356] camera settings window is too high in kcmkamera
https://bugs.kde.org/show_bug.cgi?id=63356 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Henrik Fehlauer --- > the settings window is higher than a 1024*768 screen. > ... > Created attachment 2357 [details] I was only able to test the "Camera Status Information" tab in that dialog, but in v18.07.90 it automatically showed a scrollbar upon opening on a small screen, so this has probably been fixed in the meantime. Feel free to reopen and move the bug to Frameworks if this is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 113430] camera detection via konqueror
https://bugs.kde.org/show_bug.cgi?id=113430 Henrik Fehlauer changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||rk...@lab12.net Resolution|--- |UNMAINTAINED --- Comment #3 from Henrik Fehlauer --- If it works with camera:/ but not media:/camera, there might be an issue in the media:/ kioslave. However, the latter is not shipped with KF5 anymore (IIRC it was last used in KDE 3). I'm closing this now, but feel free to open a new bug if the Plasma based device notifier still has problems accessing your images. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 182395] can't compile kamera with libgphoto-svn
https://bugs.kde.org/show_bug.cgi?id=182395 Henrik Fehlauer changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED CC||rk...@lab12.net --- Comment #2 from Henrik Fehlauer --- Since this is about a 9 year old compilation failure involving two unreleased versions, and current distros are shipping recent versions of kamera and libgphoto just fine, I'm going to assume that this has been solved in the meantime. Feel free to open a new bug against Frameworks if this is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 79835] camera:/ in sidebar not expandable
https://bugs.kde.org/show_bug.cgi?id=79835 --- Comment #3 from Henrik Fehlauer --- *** Bug 79836 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 79836] Integration of kio_camera with konqueror sidebar
https://bugs.kde.org/show_bug.cgi?id=79836 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |DUPLICATE CC||rk...@lab12.net Status|UNCONFIRMED |RESOLVED --- Comment #2 from Henrik Fehlauer --- > filed this issue as bug 79835 under konqueror/sidebar …which is closed now. Next time, just ask for the bug to be refiled to the appropriate component, because otherwise keeping both bugs in sync might be forgotten (for 14 years, in this case ;) *** This bug has been marked as a duplicate of bug 79835 *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 140154] more video handling options
https://bugs.kde.org/show_bug.cgi?id=140154 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |WORKSFORME CC||rk...@lab12.net Status|UNCONFIRMED |RESOLVED --- Comment #2 from Henrik Fehlauer --- Thanks for the suggestions, and sorry nobody looked at this during the last 11 years. > -disable it altogether (not by filters) That's now possible (Configure → General → Show videos). > --don't autoplay but playback on pressing a hotkey That's tracked in Bug 274901, sadly not implemented yet. > --allow custom parameters > --allow custom calls Gwenview is supposed to be a simple app, I don't think the amount of UI required for that would be a good fit. Nevertheless, you should be able to create a custom desktop file, and then use "Open With". Also, in System Settings you can configure some of the aspects you mentioned. I'm now closing this bug, since handling multiple requests in a single bug is always a bit unwieldy. I hope you understand! -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 391299] Rectangular Region: Remember selected area by default
https://bugs.kde.org/show_bug.cgi?id=391299 --- Comment #11 from Henrik Fehlauer --- > it displays *a* selection rectangle by default, > not that it remembers the last selection rectangle Your concern was about the initial selection rectangle as such, how the initial size is determined has nothing to do with this. >> KSnapshot, which remembered the region until restart of the app. > That I didn't know, and it's very relevant information. It's not as if I didn't mention this in Comment 1… >> Alternative proposal for a combobox or radiobuttons in the settings dialog > I like this idea. Let's do it. Glad to hear that. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 392057] Creating region screenshot from the keyboard does not respect setting for "include mouse pointer"
https://bugs.kde.org/show_bug.cgi?id=392057 --- Comment #16 from Henrik Fehlauer --- There are two locations to configure shortcuts for Spectacle: - The "Custom Shortcuts" KCM (aka KHotKeys), section "Screenshots", which shows 4 shortcuts. This seems to match spectacle.git/desktop/spectacle.khotkeys, and the section label makes sense. - The "Global Keyboard Shortcuts" KCM, component "KDE Daemon" (I believe in earlier version there was a separate component "System Settings Module", which has since been merged into "KDE Daemon"). I guess KDED is actually responsible for making KHotKeys work these days, but for users that category can be a bit surprising. Both locations seem to be in sync when I change shortcuts. I agree that's not an ideal situation, but certainly that's more because of the technical restriction @cfeck mentioned rather than not wanting to arrange things properly. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 391299] Rectangular Region: Remember selected area by default
https://bugs.kde.org/show_bug.cgi?id=391299 --- Comment #9 from Henrik Fehlauer --- BTW, as far as I can tell from https://youtu.be/4fWzNFzGjXk?t=193, the new macOS screenshot interface seems to also display a rectangle by default, without having to drag the cursor around. (Please confirm whether that's the case, or it was simply due to the editing of that video.) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 392057] Creating region screenshot from the keyboard does not respect setting for "include mouse pointer"
https://bugs.kde.org/show_bug.cgi?id=392057 --- Comment #12 from Henrik Fehlauer --- > I'd say "No, don't look at spectacle settings for shortcut". Hm, that's not really what I envision. Let's wait what others have to say on that topic. > the only one that's worth having is PrintScreen TBH, I find the current selection of shortcuts keeps a good balance between offering too few and too many options. > Is there another way to talk about new features of KDE other > than this "bugs" site? Contributors can also use tasks on the workboards and mailing lists. If you are a user, there is the forum for "talking" and Bugzilla (for wishes). There's IRC too. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 392057] Creating region screenshot from the keyboard does not respect setting for "include mouse pointer"
https://bugs.kde.org/show_bug.cgi?id=392057 --- Comment #10 from Henrik Fehlauer --- > If we have too many shortcuts, why not create a section > called "Spectacle" in the left side menu? Creating a new section won't solve the issues having too many shortcuts results in: - This is not only about "Rectangular region", but would have to be added to every other type too (doubling the number of shortcuts). - We have an in-progress patch for adding copying to the clipboard (doubling the number of shortcuts again). - There are many other options, each increasing the number of shortcuts. - Are there even enough modifier keys on a keyboard to create a shortcut scheme people can actually remember and which would not conflict with other global shortcuts? I'm not saying we should prevent people from adding specialized shortcuts by themselves, I'm just against shipping all of them by default. As for your other comments, I'm afraid they are a bit off-topic for this particular bug (we prefer to handle only a single topic per bug to keep things manageable, I hope you understand). -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 391299] Rectangular Region: Remember selected area by default
https://bugs.kde.org/show_bug.cgi?id=391299 --- Comment #8 from Henrik Fehlauer --- > The reason why I'm not in favor of turning this on by default is that it's > not expected behavior, nor is it obvious to average users that they can > simply replace the existing selection box by clicking and dragging > a new one. I disagree, and I think you are ignoring the following facts: - People are often asking for it (see duplicate, where people say creating new selections would not become too difficult when I asked). - There were no complaints in KSnapshot, which remembered the region until a restart of the app. > Another option would be to make the checkbox to turn off remembering > easily accessible in the overlay UI I now tried to fit this into the existing overlay UI, and I'm very unhappy in how that turned out: It added bloat, it looked quite out-of-place, felt unnatural and most of all at that stage (i.e. when you already restarted capturing) it is too late, we already forgot the previous size. Nobody will see and check the box when taking the first screenshot, but everybody will get frustrated once they realized they should have checked the box before taking the second screenshot. --- > I'm in favor of making the feature more discoverable > for the people who would benefit from it. Alternative proposal for a combobox or radiobuttons in the settings dialog (wording not final): - Remember region until restart (default, like KSnaphot) - Remember region across restarts - Do not remember region This would have the following advantages: - The novice users you are targetting only ever take a single screenshot, and would not be affected at all. - People taking multiple screenshots in the same session for comparison purposes would get what they expect. - Everybody else can get exactly what they want by changing the setting. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397072] Wishlist > Option to repeat last capture
https://bugs.kde.org/show_bug.cgi?id=397072 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Henrik Fehlauer --- Thanks for your comments! I'm now closing this as a duplicate of Bug 391299, where there is already some discussion (I wanted to hear your unbiased comments here first, sorry ;) Note that I'm very much in favour of turning the option on by default because users are asking for this every few weeks, but I have a hard time convincing others who are used to the way macOS takes screenshots and are against remembering the region by default. This would (mostly) restore the way KSnapshot used to work (where nobody complained about creating new selections being too difficult either, just like you confirmed). I'll add one more proposal to the other bug, feel free to comment over there. --- > add a new one in the existing options I don't think we should clutter those options even more. That setting is not really an option, but more of a preference and thus belongs in the dialog: You are not choosing between exclusively adding or modifying the region, because even with the preselected region you would still be able to add a new region by clicking on an empty spot on the screen or by right-clicking to reset the selection. It's not like adding the mouse pointer or not, because you still can do both. > "Repeat Last Capture" The combobox already shows the capture mode used last, so there is no point in adding an extra option. The question is simply whether to remember the last used region by default or not. *** This bug has been marked as a duplicate of bug 391299 *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 391299] Rectangular Region: Remember selected area by default
https://bugs.kde.org/show_bug.cgi?id=391299 Henrik Fehlauer changed: What|Removed |Added CC||musik...@hotmail.com --- Comment #7 from Henrik Fehlauer --- *** Bug 397072 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 392057] Creating region screenshot from the keyboard does not respect setting for "include mouse pointer"
https://bugs.kde.org/show_bug.cgi?id=392057 Henrik Fehlauer changed: What|Removed |Added Summary|Invoking region screenshot |Creating region screenshot |from the keyboard and |from the keyboard does not |doubleclicking makes the|respect setting for |cursor show in the image|"include mouse pointer" --- Comment #7 from Henrik Fehlauer --- >From https://stackoverflow.com/a/51664338: If you press the hotkey, a D-Bus command is invoked [...] qdbus org.kde.Spectacle / org.kde.Spectacle.RectangularRegion true The argument for this RectangularRegion method indicates the value for includeMousePointer https://bugs.kde.org/show_bug.cgi?id=397113#c1 > Do you request the default [for the shortcut] to be changed? IMO it makes sense to follow the setting in the GUI, everything else is just confusing to the user. However, we should probably still provide a DBus option to explicitly specify the behaviour. > Or a secondary hotkey with the different behaviour? I think we already have too many shortcuts, and it would be difficult to communicate to the user what the difference between all those options is. As for implementing a fix: Is there a way to set default parameters for arguments of DBus calls? If not, perhaps it would make sense to only have a single string parameter, which would allow to specify all options? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397113] includeMousePointer on rectangular snapshot when used as a shortcut
https://bugs.kde.org/show_bug.cgi?id=397113 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Resolution|WAITINGFORINFO |DUPLICATE Status|NEEDSINFO |RESOLVED --- Comment #4 from Henrik Fehlauer --- Thanks for your comments and the initial investigation, let's continue in Bug 392057. As for hiding the cursor by default: I agree, and opened Bug 397121. *** This bug has been marked as a duplicate of bug 392057 *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397121] New: Hide mouse pointer by default
https://bugs.kde.org/show_bug.cgi?id=397121 Bug ID: 397121 Summary: Hide mouse pointer by default Product: Spectacle Version: 18.04.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: rk...@lab12.net Target Milestone: --- It's what KSnapshot did, what I get when pressing Meta+Print on Windows 10, and as far as I can tell is what macOS is doing. gnome-screenshot also defaults to hiding the cursor. More often than not, the cursor is placed at a random location and will unintentionally obscure what's on the screenshot. Only in selected cases the cursor is positioned exactly over an element on purpose, in which case the user could still check the option to include it manually. Let's optimize for the common use case, and what other platforms converged to. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 392057] Creating region screenshot from the keyboard does not respect setting for "include mouse pointer"
https://bugs.kde.org/show_bug.cgi?id=392057 Henrik Fehlauer changed: What|Removed |Added CC||robertvandeneynde@hotmail.c ||om --- Comment #8 from Henrik Fehlauer --- *** Bug 397113 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397072] Wishlist > Option to repeat last capture
https://bugs.kde.org/show_bug.cgi?id=397072 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for your suggestion. Spectacle already allows to "Remember (the) selected area", see "Configure → General → Rectangular Region". Since that topic comes up from time to time, I'd like to get your opinion on something: - Is that setting difficult to find, i.e. why did you miss to discover it? - Should we check that setting by default, because otherwise it will be missed? - Some argue that creating new rectangles will be more difficult when there is already a preselected region. Could you try that and tell me if that is the case for you? (A compromise would be to add another option to the combobox like you are suggesting. However, the combobox is already quite crowded, and that option feels more like a general/one-time setting to me.) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397005] When spectacle is launched, the focus should be on the 'save' button
https://bugs.kde.org/show_bug.cgi?id=397005 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Henrik Fehlauer --- Okay, great. I'm closing this now. BTW, the shortcut is displayed once you click on the arrow next to "Save" (we still lack a proper "Configure Shortcuts" dialog, though). -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 397005] When spectacle is launched, the focus should be on the 'save' button
https://bugs.kde.org/show_bug.cgi?id=397005 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- Thanks for the idea, however I'm not sure doing this would actually make keyboard usage easier. Currently it works this way: - Ctrl-S / Ctrl-Shift-S to save. - Enter to take a new screenshot. - Space to select a different capture mode. With your idea, Saving would have two shortcuts (Ctrl-S and Space), but for accessing the combobox you'd have to tab around in the UI, which does not strike me as desirable. Does that make sense to you? I'd say we already support your workflow. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 396974] Popup menu when dragging to the desktop can be cut off
https://bugs.kde.org/show_bug.cgi?id=396974 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 Target Milestone|--- |1.0 Component|general |Desktop Containment CC||plasma-b...@kde.org, ||rk...@lab12.net Product|gwenview|plasmashell Summary|Set Image feature not |Popup menu when dragging to |always visible |the desktop can be cut off Assignee|gwenview-bugs-n...@kde.org |se...@kde.org Version|18.04.3 |5.12.90 --- Comment #1 from Henrik Fehlauer --- Thanks for the report, I can confirm the issue. However, that dialog is not coming from Gwenview, but from Plasma. Essentially when any kind of context menu is opened, the top-left corner should be at the cursor position, and in case that would mean the menu is cut off at the bottom or to the right, it should be moved in such a way it is still visible. This partly works when dragging to the desktop, but some of the options at the bottom are added only later on, making the menu grow beyond what's being visible. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 326273] When run from konsole, gwenview prints many useless logs
https://bugs.kde.org/show_bug.cgi?id=326273 --- Comment #5 from Henrik Fehlauer --- What version is that? I remember we recently touched exactly this, so perhaps in 18.04 or in 18.08 this should be fixed. For me, current master and a clean config is absolutely silent on first startup. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 321933] mouse pointer with red-eye reduction
https://bugs.kde.org/show_bug.cgi?id=321933
Henrik Fehlauer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED |RESOLVED
Latest Commit||https://commits.kde.org/gwe
||nview/e97eda1df871cebc87834
||822a08c5f34fc80938b
Version Fixed In||18.08.0
--- Comment #4 from Henrik Fehlauer ---
Git commit e97eda1df871cebc87834822a08c5f34fc80938b by Henrik Fehlauer.
Committed on 26/07/2018 at 18:36.
Pushed by rkflx into branch 'Applications/18.08'.
Fix crosshair cursor not showing in red eye reduction tool
Summary:
`RedEyeReductionTool::toolActivated` sets `Qt::CrossCursor` to allow for
more precise positioning where to apply the red eye reduction.
Due to `RasterImageView::setCurrentTool` calling `updateCursor`
afterwards, that change is immediately overridden again, though.
By moving around the latter, the issue can be fixed.
FIXED-IN: 18.08.0
Test Plan:
In {nav View} mode, activate the {nav Red Eye Reduction} tool. A
crosshair cursor should show, and hide again upon closing the tool.
Reviewers: #gwenview, ngraham
Reviewed By: #gwenview, ngraham
Subscribers: muhlenpfordt, ngraham
Differential Revision: https://phabricator.kde.org/D14386
M +5-1lib/documentview/rasterimageview.cpp
https://commits.kde.org/gwenview/e97eda1df871cebc87834822a08c5f34fc80938b
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 327211] build fails: importer/fileutils.cpp:133:10: error: use of undeclared identifier 'mkdtemp'
https://bugs.kde.org/show_bug.cgi?id=327211 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #2 from Henrik Fehlauer --- Hi Philip, sorry nobody looked into this until now. On Linux, mkdtemp lives in stdlib.h, which is already included. Is this still an issue for you on macOS? If it is, this should probably be ported to something like QTemporaryDir, or we should add the include (if the reason for de3a0b069c08 still applies). -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 337772] 'esc' key should close when in standalone viewing mode
https://bugs.kde.org/show_bug.cgi?id=337772 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rk...@lab12.net Resolution|--- |WONTFIX --- Comment #1 from Henrik Fehlauer --- Going to Browse mode when pressing Esc is what most people expect, so it makes sense to have this as a default. Making this context aware as is being proposed here also opens up potential for confusion, because not every user might expect this silent change in behaviour. Lastly, we don't want to add a configuration option for this either. Note that since Bug 385242 was fixed, you could bind Esc to quit to get the old behaviour back (you would still be able to use Enter to switch to Browse mode). Therefore I'm closing this bug. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 326273] When run from konsole, gwenview prints many useless logs
https://bugs.kde.org/show_bug.cgi?id=326273 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||rk...@lab12.net --- Comment #3 from Henrik Fehlauer --- I'm going to close this, because nowadays Gwenview runs pretty silently when started from a shell (there is still some output if you happen to run into an actual problem, but none of the warnings from above). Feel free to open a new bug should you still encounter too much log spam, and add the specific situation that happens in. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394499] No Visible Guidelines Show for Rectangular Region Grab
https://bugs.kde.org/show_bug.cgi?id=394499 --- Comment #11 from Henrik Fehlauer --- Rafael: It would be great if you could add details for your hardware. David: Does disabling KWin's compositing by pressing Alt + Shift + F12 before taking a screenshot fix the issue for you? This might be a workaround for you, and a confirmation for us that indeed this is a graphics problem. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 376516] Rectangular selection not visible when compositor activated
https://bugs.kde.org/show_bug.cgi?id=376516 Henrik Fehlauer changed: What|Removed |Added Resolution|WAITINGFORINFO |DUPLICATE Status|NEEDSINFO |RESOLVED CC||rk...@lab12.net --- Comment #2 from Henrik Fehlauer --- This is a problem with the graphics driver, graphics stack or Qt. There were no changes in Spectacle in that regard for the last releases. Closing this as a duplicate of a newer bug for now, because that one has more details already. *** This bug has been marked as a duplicate of bug 394499 *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394499] No Visible Guidelines Show for Rectangular Region Grab
https://bugs.kde.org/show_bug.cgi?id=394499 Henrik Fehlauer changed: What|Removed |Added CC||rafael.linux.u...@gmail.com --- Comment #10 from Henrik Fehlauer --- *** Bug 376516 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 376865] Busy Cursor Captured in Rectangular Region if Launched Directly
https://bugs.kde.org/show_bug.cgi?id=376865 Henrik Fehlauer changed: What|Removed |Added CC||k...@privat.broulik.de, ||rk...@lab12.net Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #2 from Henrik Fehlauer --- Yes, this is still a problem, and affects all capture actions (but not launching Spectacle directly). (Julian: The desktop actions should still be there, otherwise you broke your installation. For example when pinning Spectacle to the taskbar, you should get them when right-clicking.) org.kde.spectacle.desktop contains "StartupNotify=false", and when you normally launch Spectacle, its taskbar entry is hidden before the screenshot is captured. However, for all of the desktop actions from the context menu (as defined in the lower part of the desktop file) this does not seem to work, for them the taskbar entry (along with all startup animations and bouncy cursors) is still shown and captured. Kai: The desktop file notification handling does not seem like an issue specific to Spectacle. Do you know which component this should be assigned to? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394947] Provide keyboard shortcuts/navigation for moving and resizing the selection rectangle
https://bugs.kde.org/show_bug.cgi?id=394947 Henrik Fehlauer changed: What|Removed |Added CC||sc...@spharvey.me --- Comment #5 from Henrik Fehlauer --- You're welcome! Thanks to Scott for implementing the feature. BTW, the change will be included in the next release, which will be Spectacle version 18.08 on August 16. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 396736] no antialiasing applied before first zoom change
https://bugs.kde.org/show_bug.cgi?id=396736
Henrik Fehlauer changed:
What|Removed |Added
Resolution|--- |FIXED
Version Fixed In||18.08.0
Status|CONFIRMED |RESOLVED
Latest Commit||https://commits.kde.org/gwe
||nview/1ce062a458b1eb653d982
||7480e1eb826236b58dc
--- Comment #2 from Henrik Fehlauer ---
Git commit 1ce062a458b1eb653d9827480e1eb826236b58dc by Henrik Fehlauer.
Committed on 24/07/2018 at 06:03.
Pushed by rkflx into branch 'Applications/18.08'.
Fix image smoothing sometimes not getting applied
Summary:
In {nav View} mode, smoothing is applied for scaling up raster images up
to 400%. In general this works fine, but in some cases the smoothing
becomes visible only after zooming manually.
This is due to defaulting to `Qt::FastTransformation` and switching to
`Qt::SmoothTransformation` only for changes in the zoom level and for
the {nav Fit/Fill} zoom modes, but not when the zoom level is unchanged
when navigating to an image.
The issue can be fixed by calling `onZoomChanged`, which not only calls
`updateBuffer` as before, but also `setTransformationMode`.
FIXED-IN: 18.08.0
Test Plan:
Enable {nav Image View > Zoom mode > Keep same zoom and position}, zoom
in to a zoom level just below 400% and switch to the next image.
Smoothing should be applied immediately, without having to zoom in and
out again.
Reviewers: #gwenview, ngraham
Reviewed By: #gwenview, ngraham
Subscribers: muhlenpfordt, ngraham
Differential Revision: https://phabricator.kde.org/D14269
M +1-1lib/documentview/rasterimageview.cpp
https://commits.kde.org/gwenview/1ce062a458b1eb653d9827480e1eb826236b58dc
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 396800] Gwenview crashes when open Pentax camera images
https://bugs.kde.org/show_bug.cgi?id=396800 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rk...@lab12.net Resolution|--- |UPSTREAM --- Comment #2 from Henrik Fehlauer --- Thanks for the report. I downloaded your example image and opened it in Gwenview, which worked just fine on Tumbleweed and Kubuntu 18.04. On a Neon installation (based on Ubuntu 16.04) I indeed get it to crash: #0 0x714cbb4f in Exiv2::ExifData::findKey(Exiv2::ExifKey const&) const () from /usr/lib/x86_64-linux-gnu/libexiv2.so.26 #1 0x71515f81 in Exiv2::Internal::PentaxMakerNote::printShutterCount(std::ostream&, Exiv2::Value const&, Exiv2::ExifData const*) () from /usr/lib/x86_64-linux-gnu/libexiv2.so.26 #2 0x773c1623 in Exiv2::operator<<(std::ostream&, Exiv2::Metadatum const&) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #3 0x773c30f3 in void Gwenview::ImageMetaInfoModelPrivate::fillExivGroup >(QModelIndex const&, Gwenview::MetaInfoGroup*, Exiv2::ExifData const&) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #4 0x773c0821 in Gwenview::ImageMetaInfoModel::setExiv2Image(Exiv2::Image const*) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #5 0x7737a74d in Gwenview::Document::setExiv2Image(std::auto_ptr) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #6 0x77377aea in Gwenview::AbstractDocumentImpl::setDocumentExiv2Image(std::auto_ptr) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #7 0x77382df7 in Gwenview::LoadingDocumentImpl::slotMetaInfoLoaded() () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #8 0x77440957 in Gwenview::LoadingDocumentImpl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from lib/x86_64-linux-gnu/libgwenviewlib.so.5 #9 0x73717b89 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x73526a71 in QFutureWatcherBase::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x74e9c29c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #12 0x74ea3917 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #13 0x736eae38 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x736eda3e in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x737425c3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7fffebca0197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x7fffebca03f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x7fffebca049c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x73741bcf in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #20 0x7fffdee30c11 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #21 0x736e91ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x736f22d4 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #23 0x0046a0d7 in main () However, the crash happens in Exiv2, and most likely is already fixed upstream (http://dev.exiv2.org/issues/0001283 looks like it). Try upgrading once Neon switches its base to Ubuntu 18.04. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 378061] Display full path of image on main window
https://bugs.kde.org/show_bug.cgi?id=378061 Henrik Fehlauer changed: What|Removed |Added Status|CONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net --- Comment #4 from Henrik Fehlauer --- I'm not sure whether I understand you correctly, but as far as I can see we already show all information in the UI: - In Browse mode, the folder is visible in the URL bar (note that you can also set it into "editing" mode). - In Browse mode, the full filename can be accessed from the Information sidebar, which was built exactly for this purpose and without resorting to mouse-over. - In View mode, we don't want to show the full path in the window title, because then in the taskbar most Gwenview windows would show the same title with the more important filename part cut off (and we don't want to make that an option either, because Gwenview should stay simple enough with only the most relevant options). - In View mode, there is also the sidebar, and quickly accessing the URL bar can be done by pressing Enter (press Enter again to go back). - In both Browse and View mode, Edit → Copy will quickly copy the full path to the clipboard. @juan: Please let us know about your exact use cases, so we can better understand what you actually want to achieve (i.e. describe the root problem, opposed to proposing a solution). -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 396741] Notification text gets longer with every screenshot
https://bugs.kde.org/show_bug.cgi?id=396741 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Henrik Fehlauer --- Thanks for the report, can confirm. See also https://phabricator.kde.org/D11203. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 396736] no antialiasing applied before first zoom change
https://bugs.kde.org/show_bug.cgi?id=396736 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Henrik Fehlauer --- Thanks for the report, I can confirm the issue. Your initial investigation has been really helpful, saving us time in finding the cause. You are touching the right spot, but calling all of AbstractImageView::setZoom is not necessary, it will be enough to call RasterImageView::onZoomChanged, which will then set the appropriate transformation mode for image smoothing. Diff: https://phabricator.kde.org/D14269 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 377880] Gwenview There are two actions (Cut, Delete)
https://bugs.kde.org/show_bug.cgi?id=377880 Henrik Fehlauer changed: What|Removed |Added CC||janthony...@gmail.com --- Comment #49 from Henrik Fehlauer --- *** Bug 396673 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 396673] Occurred Upon selecting an image
https://bugs.kde.org/show_bug.cgi?id=396673 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- *** This bug has been marked as a duplicate of bug 377880 *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 396360] Shortcut F does not toggle between original size and fit to window any more
https://bugs.kde.org/show_bug.cgi?id=396360
--- Comment #8 from Henrik Fehlauer ---
Git commit 11ed44cdf988db2a055265afc76f6b7c8be64fb6 by Henrik Fehlauer.
Committed on 16/07/2018 at 22:11.
Pushed by rkflx into branch 'Applications/18.08'.
Add mouse shortcut for Fill and adapt docbook
Summary:
D14093 will add back middle-clicking to toggle between {nav Fit} (with
{key F} as its keyboard shortcut) and {nav 100%} zoom. In addition,
D14094 sets {key Shift F} as a shortcut for {nav Fill}.
Going along with this, here we add {key Shift}-middle-clicking for
{nav Fill}. The code is moved to `DocumentView` in order not to
duplicate the handling of the toggling behaviour.
We also adapt the docbook accordingly, as some users still seem to read
the manual.
Depends on D14093
Test Plan:
Middle-click multiple times on an image in {nav View} mode and observe
{nav Fit} is toggled. Repeat while holding down {key Shift} for
{nav Fill}.
Proof-read docbook ("View mode" and "Tips" sections).
Reviewers: #gwenview, muhlenpfordt
Reviewed By: #gwenview, muhlenpfordt
Subscribers: muhlenpfordt, kde-doc-english
Tags: #documentation
Differential Revision: https://phabricator.kde.org/D14103
M +3-4doc/index.docbook
M +0-8lib/documentview/abstractimageview.cpp
M +13 -0lib/documentview/documentview.cpp
M +1-0lib/documentview/documentview.h
https://commits.kde.org/gwenview/11ed44cdf988db2a055265afc76f6b7c8be64fb6
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 396360] Shortcut F does not toggle between original size and fit to window any more
https://bugs.kde.org/show_bug.cgi?id=396360 --- Comment #3 from Henrik Fehlauer --- At least commits shouldn't break people's existing workflows ;) We could provide default shortcuts for every mode (Fit/Fill/100%), but switching back and forth is much quicker when you don't have to hunt for another key and can simply toggle the same shortcut. How about doing both: - "=" for 100%, Ctrl++ and Ctrl+- for Zoom In/Out (like in Firefox) - "F" for Fit (zoom to 100% if already zoomed to fit) - "Shift+F" for Fill (zoom to 100% if already zoomed to fill) And for middle-clicking, it could work like this (to be added to the docbook): - Middle-click: Toggle between Fit and 100% - Shift + middle-click: Toggle between Fill and 100% -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 396360] Shortcut F does not toggle between original size and fit to window any more
https://bugs.kde.org/show_bug.cgi?id=396360 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Henrik Fehlauer --- Thanks for the report, I can confirm the issue. As a workaround, you can middle click to toggle between Fit and 100%. Bisecting shows that this has been broken by https://phabricator.kde.org/R260:3e10699ac37c4b8ffc510546913e26fb9f89aa6c, i.e. since Gwenview 17.08.0. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Henrik Fehlauer changed: What|Removed |Added Latest Commit||https://commits.kde.org/gwe ||nview/07a2e7f9eccd92c19da4e ||f269f453d61a44b6846 Resolution|--- |FIXED Version Fixed In||18.04.3 Status|UNCONFIRMED |RESOLVED --- Comment #15 from Henrik Fehlauer --- Git commit 07a2e7f9eccd92c19da4ef269f453d61a44b6846 by Henrik Fehlauer. Committed on 09/07/2018 at 19:50. Pushed by rkflx into branch 'Applications/18.04'. Fix external application menu occasionally slowing down startup Summary: If moving the menubar entries to a button in the window decoration is enabled, the bug reporter experiences delays of up to 25 seconds in the startup of Gwenview. Bisecting points to 9631043c1, which added MPRIS support through providing a D-Bus interface. While the exact nature of the problem remains unclear due to not being reproducible outside of the bug reporter's environment, moving the initialization of the MPRIS support after `createGUI` is reported to correct the issue. This may be due to avoiding conflicts or races with the D-Bus connection, which is used for the MPRIS service, the ScreenSaver service and the application menu integration. Thanks to Duncan for reporting the bug and coming up with a fix. FIXED-IN: 18.04.3 Test Plan: `dbus-send --session --dest=org.mpris.MediaPlayer2.Gwenview --type=method_call /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next` still moves to the next image in Gwenview. The external application menu is still working fine. Reviewers: #gwenview, kossebau Subscribers: broulik Differential Revision: https://phabricator.kde.org/D13995 M +6-6app/mainwindow.cpp https://commits.kde.org/gwenview/07a2e7f9eccd92c19da4ef269f453d61a44b6846 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 386034] Wish: Drag image from Gwenview's view mode to initiate drag and drop operation
https://bugs.kde.org/show_bug.cgi?id=386034
--- Comment #3 from Henrik Fehlauer ---
Git commit 3215716e422ef1d6dc93d83a25c655095bb0ba6d by Henrik Fehlauer.
Committed on 08/07/2018 at 22:45.
Pushed by rkflx into branch 'master'.
Do not allow to drag an image onto itself
Summary:
The combination of 131d25855e11 and 984b9737f079 led to the user being
able to drag an image in {nav View} mode and immediately drop it again.
The drag cursor implied Gwenview allowed this kind of operation, while
actually nothing would happen as the URL did not change.
To prevent confusion, we do not allow to drop the image in that
situation anymore. It is still possible to drop multiple images which
include the current image, so a future patch could implement switching
to {nav Compare} mode in that case.
As a side effect a small visual bug is fixed: When moving very slowly
while initiating a drag, the `ForbiddenCursor` would appear briefly
until you moved the mouse further along and the actual drag cursor
appeared. With the patch applied, the cursor will always keep being set
to `ForbiddenCursor`, preventing any flickering.
Test Plan:
Slowly start to drag an image in {nav View} mode. The cursor should
indicate no dropping is allowed.
Reviewers: #gwenview, huoni
Reviewed By: #gwenview, huoni
Subscribers: huoni
Differential Revision: https://phabricator.kde.org/D13724
M +9-1lib/documentview/documentview.cpp
https://commits.kde.org/gwenview/3215716e422ef1d6dc93d83a25c655095bb0ba6d
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #14 from Henrik Fehlauer --- Diff: https://phabricator.kde.org/D13995 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #13 from Henrik Fehlauer --- Thanks for the continued investigation, Duncan, that's really helpful. Awesome solution, I'll create a Diff on Phabricator tonight. Could you try one more thing, so we know a bit better whether the problem is a real fix or more of a workaround for another problem? As you have plenty of time on a slow/broken startup, please attach GDB to the process, interrupt execution and get a backtrace: $ gdb gwenview |& tee backtrace.log $ r - press Ctrl-C while Gwenview is stuck (but after loading debug symbols finished) $ thread apply all bt - attach the backtrace to the bug As for your patches, both are basically reverting the whole feature: - First patch: You don't set HAVE_QTDBUS in CMakeLists.txt anymore, so the rest of the MPRIS integration won't even get compiled. - Second patch: You skip creating Mpris2Service, which would otherwise be the main entry point for everything else of the MPRIS integration. Regarding MPRIS: That's a DBus service provided by Gwenview (org.mpris.MediaPlayer2.Gwenview), which other parts of the infrastructure can call into because it uses a standardized interface (org.mpris.MediaPlayer2). IOW it isn't a separate dependency to install. For example Plasma's mediaplayer applet can list all services providing that interface and call the forward/play/pause methods. Same thing for KDE Connect. I think even with the patch we should investigate why your media keys are not working: - Can you see Gwenview's DBus service in "qdbusviewer"? - Can you change to the next picture with "dbus-send --session --dest=org.mpris.MediaPlayer2.Gwenview --type=method_call /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next"? - Can you see other services in "qdbusviewer" implementing the interface, e.g. when running VLC? - Can you control VLC with Plasma's mediaplayer applet? - What does your global shortcut configuration in Systemsettings (Media Controller component) look like? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #6 from Henrik Fehlauer --- @Nate, @Friedrich: Are you able to reproduce, and if so, how? > gwenview would take a long time to startup again @Duncan: Could you quantify how long regular and slow startup is taking for you each, i.e. barely noticable, seconds, or minutes? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395890] No Error when same Picture name is selected
https://bugs.kde.org/show_bug.cgi?id=395890 --- Comment #5 from Henrik Fehlauer --- > a regression introduced while porting to Qt 5 Turns out this was due to a change in what is now KJobWidgets: efbf655b7ab5 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395890] No Error when same Picture name is selected
https://bugs.kde.org/show_bug.cgi?id=395890 --- Comment #4 from Henrik Fehlauer --- Looked more into this: - Showing a warning in Browse mode instead of the Rename / Overwrite / Cancel" dialog worked before, so it is actually a regression, caused by 6ca0b93e6029 in KIO (according to git blame). Perhaps "setData" in PreviewItemDelegate::setModelData now needs to be replaced with manual handling of the renaming, using KIO::moveAs instead of the implicit KIO::rename. - Showing no warning in View mode is a regression introduced while porting to Qt 5 (it works fine with a KDE 4 based version, but is already broken with Gwenview 14.12.0, KIO 5.7.0, KJobWidgets 5.0.0, KCoreAddons 5.0.0 or somewhere else in KF5). In FileOperations::rename, showErrorMessage() does not seem to have an effect anymore. As nothing relevant changed in fileoperations.cpp in that time frame, this is likely a behavioural change in KF5 (either a bug, or something Gwenview missed to be ported to). To fix the issue, the call can be removed in exchange for setAutoErrorHandlingEnabled(true). However, the better dialog from KIO::moveAs might make more sense. It might be worth checking whether the better dialog for renames in both View and Browse mode can be implemented in a single place, e.g. in FileOpsContextManagerItem::rename. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395890] No Error when same Picture name is selected
https://bugs.kde.org/show_bug.cgi?id=395890 --- Comment #3 from Henrik Fehlauer --- > Henrik, did you test with KIO 5.47.0? See also bug 394318. I now tested with KIO 5.47, but as I suspected the bug is still there. Bug 394318 was about pasting and unconditionally overwriting, while here the issue is with renaming and silently aborting if the file already exists. Sounds like a genuine Gwenview problem to me. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395890] No Error when same Picture name is selected
https://bugs.kde.org/show_bug.cgi?id=395890 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Henrik Fehlauer --- Thanks for the report. I can confirm the issue with Gwenview 18.04.2. When pressing F2 in View mode, renaming is aborted, but no error is shown. Also I wonder whether we could show a "File already exists: Rename / Overwrite / Cancel" dialog (cf. Dolphin) instead of the plain error message for both View and Browse mode. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 340667] Add "sort By" rating option
https://bugs.kde.org/show_bug.cgi?id=340667
Henrik Fehlauer changed:
What|Removed |Added
Resolution|--- |FIXED
Latest Commit||https://commits.kde.org/gwe
||nview/faa19b06b14eb2e6c74b6
||c88f170f5c66a77b80a
Status|CONFIRMED |RESOLVED
--- Comment #1 from Henrik Fehlauer ---
Git commit faa19b06b14eb2e6c74b6c88f170f5c66a77b80a by Henrik Fehlauer, on
behalf of Farid Boudedja.
Committed on 23/06/2018 at 22:03.
Pushed by rkflx into branch 'master'.
Add possibility to sort by rating
Summary:
Gwenview allows to rate images but there is no option to sort images by rating.
Add 'Rating' as a sorting option to Gwenview's SortedDirModel.
Add 'Rating' to Gwenview's 'Sort By' menu.
Add 'Rating' to Gwenview's 'Sorting' configuration entry.
Depends on: D13669
Test Plan:
- Give specific ratings to some images in Gwenview.
- Click {nav View > Sort By > Rating}.
- The images should be sorted according to their ratings.
Reviewers: #gwenview, rkflx
Reviewed By: #gwenview, rkflx
Subscribers: muhlenpfordt, rkflx, broulik
Differential Revision: https://phabricator.kde.org/D13344
M +14 -0app/browsemainpage.cpp
M +1-0lib/gwenviewconfig.kcfg
M +16 -5lib/semanticinfo/sorteddirmodel.cpp
M +4-1lib/sorting.h
https://commits.kde.org/gwenview/faa19b06b14eb2e6c74b6c88f170f5c66a77b80a
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor when Gwenview is already maximized
https://bugs.kde.org/show_bug.cgi?id=372417 Henrik Fehlauer changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #10 from Henrik Fehlauer --- Okay, I can now reproduce after noticing a small detail in your more extensive description in Comment 5: - I does not matter on which screen you first start Gwenview on. - The important part is that you have to actively move Gwenview to a different screen while at the same time maximizing it (by dragging it to the top of the screen). - First moving Gwenview and then maximizing in a second step won't trigger the bug upon activating fullscreen mode. Building on that insight, I tested on more systems and noted the version of Qt: - I can reproduce with Qt 5.6.2, Qt 5.9.2, Qt 5.9.3 and Qt 5.9.5 (note in particular that the different versions of Qt 5.9 were on various distros and with both older and newer kernels + graphics stacks). - I cannot reproduce with Qt 5.10.0 and Qt 5.11.0 (Qt 5.11 was tested with both a very old and a very new base distro). Therefore I suspect Qt 5.10 fixed the problem. @Daniel: Please let us know your version of Qt, and possibly retest with the more detailed instructions from above. @Quincy: Do you have a way to test with a newer Qt? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor when Gwenview is already maximized
https://bugs.kde.org/show_bug.cgi?id=372417 --- Comment #9 from Henrik Fehlauer --- @Quincy: Just to rule out any weird configuation issue (e.g. KWin's window rules), could you try to reproduce with a fresh/new user account? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394499] No Visible Guidelines Show for Rectangular Region Grab
https://bugs.kde.org/show_bug.cgi?id=394499 Henrik Fehlauer changed: What|Removed |Added Resolution|WORKSFORME |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #9 from Henrik Fehlauer --- Thanks for the update. I'm reopening this for now because we don't know yet where the real issue is. Nevertheless, I doubt we are doing anything wrong from Spectacle's side, since it's working fine on a bunch of different hardware. This seems like a problem with Qt, Mesa or Nouveau. You could also try to boot another recent distro (e.g. openSUSE Leap 15) from a USB thumb drive, to see whether it works there with a particular kernel version or graphics stack (your Qt and KF5 seem recent enough). It might also be worth asking Qt or the Nouveau developers for advice. Finally, more reports from people using similar hardware are appreciated. BTW, there is currently work underway to port the rectangular region selector to a different backend (see https://phabricator.kde.org/D12626), which might avoid the issue. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 326348] Dancing cursor when dragging picture
https://bugs.kde.org/show_bug.cgi?id=326348 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||rk...@lab12.net Status|UNCONFIRMED |NEEDSINFO --- Comment #3 from Henrik Fehlauer --- The videos linked in the description are not available anymore, but I guess "dragging" refers to panning the image (opposed to drag-and-drop). If so, with a recent version of Gwenview it works fine for me, i.e. after pressing down and while moving the mouse the cursor changes to the "closed hand" style. @Fisiu: Could you try whether you can still reproduce? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 390415] Feature request - Spectacle - Save to file and clipboard
https://bugs.kde.org/show_bug.cgi?id=390415 --- Comment #11 from Henrik Fehlauer --- Just for reference, https://phabricator.kde.org/D13493 has more comments on the topic, still inconclusive, though. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394499] No Visible Guidelines Show for Rectangular Region Grab
https://bugs.kde.org/show_bug.cgi?id=394499 --- Comment #6 from Henrik Fehlauer --- Thanks for the image, I can now see what you mean. > Also, please let us know what graphics driver your system is using. Could you provide this information, e.g. by running "sudo lspci -k | grep -EA3 'VGA|3D|Display'" or by looking into KInfoCenter (Graphical Information → OpenGL)? In addition, your version of Qt would be good to know (Spectacle's Help button → About Spectacle → Libraries). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395034] QMenu becomes invisible when cleared while still open
https://bugs.kde.org/show_bug.cgi?id=395034 --- Comment #9 from Henrik Fehlauer --- Before the bug was reported, I checked with a KDE 4 based system, where the share button is working fine. The only change on Gwenview's side since then is [1], where David ported from KMenu to QMenu. However, in KMenu [2] I could not find anything special really. Farid: I guess the last thing you could try is reporting this to https://bugreports.qt.io, and hope that it's a problem in Qt that is triggered by turning on KWin's compositing. [1] https://phabricator.kde.org/R260:2e69abc63776f05668a188f5ea3f58d0c8243754#change-OOnyLJlEzc3C [2] https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kmenu_8cpp_source.html -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395034] QMenu becomes invisible when cleared while still open
https://bugs.kde.org/show_bug.cgi?id=395034 --- Comment #6 from Henrik Fehlauer --- Sorry David, I haven't written any additional sample code, I thought the code above was enough to show the nature of the problem. Is there any issue with Farid's code (besides omitting the boilerplate and not coming in tar.gz form)? If you are interested, this bug originates from the discussion in https://phabricator.kde.org/D13312 (please don't mind the detours over there). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395034] QMenu becomes invisible when cleared while still open
https://bugs.kde.org/show_bug.cgi?id=395034 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #4 from Henrik Fehlauer --- Thanks for your response, Martin. > KWin has nothing to do with that. It is not responsible for input handling. Could you tell us why you think input handling is the problem (we are mainly interested in the menu showing, because that's not working right, input handling seems fine)? > If the application reacts on input for a not visible window that is an > application bug. That's not the problem. The problem is that the menu is _invisible_ with compositing on, while with compositing off it is perfectly visible as it should be. Any suggestions in solving this on the application side? I guess a different code path in the application when compositing is off is not the way to go, but what else are we doing wrong? Perhaps it's a bug in Qt, but then why is it working fine with KWin's compositing turned off (on X11)? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394949] again rectangle screenshot. rectangle is auto resize.
https://bugs.kde.org/show_bug.cgi?id=394949 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rk...@lab12.net Resolution|--- |WORKSFORME --- Comment #1 from Henrik Fehlauer --- > but rectangle 200px x 199px. Sorry, I cannot reproduce that with Spectacle 18.04. Regardless of whether "Remember selected area" is checked in the settings or not, my screenshots always end up with the correct size. > spectacle result is not 200px x 200px Given this monitor: $ xdpyinfo | grep dots resolution:96x97 dots per inch …I get those results (in PPI instead of PPCM): $ identify -format '%w,%h\n' x.png 200,200 $ identify -verbose -units PixelsPerInch x.png | grep Resolution Resolution: 96.01x97 I don't think there's anything wrong with that. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 394947] Provide keyboard shortcuts/navigation for moving and resizing the selection rectangle
https://bugs.kde.org/show_bug.cgi?id=394947 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net Summary|move rectangle only from|Provide keyboard |mouse drug? |shortcuts/navigation for ||moving and resizing the ||selection rectangle Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #1 from Henrik Fehlauer --- Thanks for your message, but please don't report multiple issues in a single bug in the future. > result: this time -2px. Sorry, I cannot reproduce that with Spectacle 18.04. > move rectangle from keyboard arrow I think that's a valid wish, let's make the bug about that. I'll adapt the title a bit. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 293333] Should be able to sort by descending as well as ascending order
https://bugs.kde.org/show_bug.cgi?id=29
Henrik Fehlauer changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Latest Commit||https://commits.kde.org/gwe
||nview/8f12830652356e49bdecc
||c16fa531b9c3deac3ac
Resolution|--- |FIXED
--- Comment #1 from Henrik Fehlauer ---
Git commit 8f12830652356e49bdeccc16fa531b9c3deac3ac by Henrik Fehlauer, on
behalf of Farid Boudedja.
Committed on 04/06/2018 at 19:06.
Pushed by rkflx into branch 'master'.
Add possibility to sort by descending order
Summary:
Gwenview only allows sorting by ascending order. This patch adds the
possibility to switch the sorting order to descending.
It is implemented similarly to the sorting menu in Dolphin.
The sorting order is also saved into the Gwenview configuration file.
Before:
{F5878226}
After:
{F5878227}
Test Plan:
- Open a folder which contains images in Gwenview
- Check 'Descending' in View > Sort By
- The sorting order will be switched to descending
- Uncheck 'Descending' in View > Sort By
- The sorting order will be reverted to ascending
Reviewers: #gwenview, rkflx
Reviewed By: #gwenview, rkflx
Subscribers: muhlenpfordt, rkflx, xyquadrat
Tags: #gwenview
Differential Revision: https://phabricator.kde.org/D13213
M +32 -11 app/browsemainpage.cpp
M +2-2app/gwenviewui.rc
M +4-0lib/gwenviewconfig.kcfg
M +1-1lib/semanticinfo/sorteddirmodel.cpp
https://commits.kde.org/gwenview/8f12830652356e49bdeccc16fa531b9c3deac3ac
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 386753] Share button doesn't prompt to install kipi-plugins if it's not installed
https://bugs.kde.org/show_bug.cgi?id=386753 Henrik Fehlauer changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://commits.kde.org/gwe ||nview/bc1d4c545a86242a64bec ||4a53353b7d286beb20d Status|CONFIRMED |RESOLVED --- Comment #2 from Henrik Fehlauer --- Git commit bc1d4c545a86242a64bec4a53353b7d286beb20d by Henrik Fehlauer, on behalf of Farid Boudedja. Committed on 03/06/2018 at 06:19. Pushed by rkflx into branch 'master'. Prompt to install kipi-plugins when the share button is clicked Summary: When 'kipi-plugins' is not installed, the 'Share' menu shows 'No Plugin Found'. With this patch it will present a link to install the missing plugins instead (Similarly to what the 'Plugins' menu does). Test Plan: Without the **kipi-plugins** package installed, click on Share in the Gwenview toolbar. It should display a menu action 'Install Plugins' which triggers the AppStream URL (appstream://photolayoutseditor.desktop). Reviewers: #gwenview, ngraham, rkflx Reviewed By: #gwenview, ngraham, rkflx Subscribers: rkflx, nicolasfella Tags: #gwenview Differential Revision: https://phabricator.kde.org/D13197 M +5-1app/kipiinterface.cpp https://commits.kde.org/gwenview/bc1d4c545a86242a64bec4a53353b7d286beb20d -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 394940] "Open file" dialog does not handle search correctly
https://bugs.kde.org/show_bug.cgi?id=394940 Henrik Fehlauer changed: What|Removed |Added CC||rk...@lab12.net --- Comment #2 from Henrik Fehlauer --- I'm a bit confused regarding the topic of this bug: The screenshot shows a GTK file dialog, you can reproduce with Dolphin, and you suggest to work on this in the file dialog task. Could you add some steps to reproduce, what you expected to happen, and what really happened? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 377880] Gwenview There are two actions (Cut, Delete)
https://bugs.kde.org/show_bug.cgi?id=377880 Henrik Fehlauer changed: What|Removed |Added CC||g.ja...@lijbrandt.nl --- Comment #47 from Henrik Fehlauer --- *** Bug 394942 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 394942] version 16.04.3
https://bugs.kde.org/show_bug.cgi?id=394942 Henrik Fehlauer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||rk...@lab12.net --- Comment #1 from Henrik Fehlauer --- *** This bug has been marked as a duplicate of bug 377880 *** -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 393708] Copy to clipboard doesn't seem to work with default Klipper settings
https://bugs.kde.org/show_bug.cgi?id=393708 --- Comment #21 from Henrik Fehlauer --- @elman: > option for Klipper to run in the background Klipper is already running in the background (on Plasma, at least), the problem is how to handle images. > If I have Spectacle opened in the background, pressing PrtSc does nothing. We know about that problem, but as you said, it's a different bug, and thus it should not be discussed here. Please try to find an existing bug, and if there is none, file a new bug. Thanks! --- @Nate: > retain a maximum of one image at a time that's tagged I'm not sure how that's different from what I already wrote in Comment 13: > For example, Klipper could only store a single image with that tag, > and don't save it for the next session at all. I'll now go back to other things, maybe that'll be more productive… -- You are receiving this mail because: You are watching all bug changes.
