date:20220414

[ark] [Bug 452640] New: Ark does not notify on failure to archive content due to insufficient read permissions

2022-04-14 Thread Brennan Kinney

https://bugs.kde.org/show_bug.cgi?id=452640

Bug ID: 452640
   Summary: Ark does not notify on failure to archive content due
to insufficient read permissions
   Product: ark
   Version: 21.12.3
  Platform: Manjaro
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: elvis.angelac...@kde.org
  Reporter: polarathene-sig...@hotmail.com
CC: aa...@kde.org, rthoms...@gmail.com
  Target Milestone: ---

SUMMARY

When archiving some project folders into a `tar.zst` file, the process appeared
to have gone smoothly with no errors raised.

The content that was owned by root (Docker volume mounts) was silently skipped
without informing me of the omitted or corrupt (empty but non-zero sized) data.


STEPS TO REPRODUCE
1. Have some content with permissions that would prevent read access.
2. Compress that content to an archive via Ark. Note, in Dolphin context menu,
"Compress" action will be disabled if lacking write permissions, use a parent
directory with write permissions as a workaround.


OBSERVED RESULT

- Via Dolphin "Compress" right-click content menu, UI will appear successful.
- Via opening Ark through a Terminal, the directory contents not readable is
filtered out of the archive. No error via GUI or terminal output.
- Via Ark GUI, adding a specific file explicitly instead of the parent
directory will add the file of that size but is misleading as there is no
actual content (blank).


EXPECTED RESULT

It should be raised as an error when content cannot be archived due to lack of
read access permissions.

Especially when adding such a file that is listed in the file picker dialog
(with badge indicating lack of read-access), which presently gives the
impression it was added successfully but is in fact an empty file but with the
expected filename and size.

I did not expect the Ark GUI to implicitly write files that were added via menu
immediately to the target archive file either, but that is a separate UX
concern.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  X11 with Kernel 5.15.28
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3


ADDITIONAL INFORMATION

In comparison, doing a copy operation via Dolphin, the read access failures
will create dialogs "Could not read" with Retry/Skip/Skip-All/Cancel options.
That's somewhat better but is a UX problem when the number of files that would
raise this warning is large:

- Retry is useful if opting to correct permissions, though in some contexts
that's not desirable, it'd be better to request auth.
- Skip is useful when the affected paths should be noted down to address
afterwards.. but is not pleasant if there's over 100 dialogs like this for very
similar paths (usually many having common parents).
- Skip All becomes the preferred action when it's frustrating to respond to an
unknown amount of dialogs like this, but at the expense that you lose what
those paths were as a result.

A better UX would be to log the path under the same error context and notify
the user afterwards, perhaps with some options to handle individual files or in
bulk. A tree-view list would be most helpful for context, but a sorted list of
paths would work just as well for presenting that information requiring
attention.

At the very least, the user should be informed about omitted data or data
written with expected filename + size but not the real content.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 452639] New: Preferencias > Estilos > Android

2022-04-14 Thread Ronald

https://bugs.kde.org/show_bug.cgi?id=452639

Bug ID: 452639
   Summary: Preferencias >  Estilos > Android
   Product: krita
   Version: 5.0.2
  Platform: Android
OS: Unspecified
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: * Unknown
  Assignee: krita-bugs-n...@kde.org
  Reporter: thaler.t...@gmail.com
  Target Milestone: ---

Al seleccionar la opción "Preferencias " > "Estilos" > "Android". Se me cierra
la aplicación en mi galaxy tab s7 plus.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 376111] konsolehere.desktop should open the preferred terminal emulator instead of konsole

2022-04-14 Thread Brennan Kinney

https://bugs.kde.org/show_bug.cgi?id=376111

Brennan Kinney  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED
 CC||polarathene-signup@hotmail.
   ||com

--- Comment #1 from Brennan Kinney  ---
This was resolved since 2021. `konsolehere.desktop` was dropped in favor of an
alternative solution within Dolphin that will open your preferred Terminal
application.

Presently, there is a regression to the functionality if you expect the folder
to open at the location of an interacted folder, instead of the views location.
That is tracked here:
https://bugs.kde.org/show_bug.cgi?id=452637

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 450250] Game window looks ugly, mouse behaves incorrect

2022-04-14 Thread Bug Janitor Service

https://bugs.kde.org/show_bug.cgi?id=450250

Bug Janitor Service  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #10 from Bug Janitor Service  ---
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 452062] Xwayland app doesn't launch in Wayland KDE 5.24.4

2022-04-14 Thread Bug Janitor Service

https://bugs.kde.org/show_bug.cgi?id=452062

--- Comment #5 from Bug Janitor Service  ---
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 451690] degrees not shown on icon when using wettercom data source

2022-04-14 Thread Bug Janitor Service

https://bugs.kde.org/show_bug.cgi?id=451690

--- Comment #4 from Bug Janitor Service  ---
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 442191] Transform tool produces white artifacts around the edge of transformed result

2022-04-14 Thread Bug Janitor Service

https://bugs.kde.org/show_bug.cgi?id=442191

--- Comment #14 from Bug Janitor Service  ---
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are watching all bug changes.

[yakuake] [Bug 452638] New: At starting yakuake appear on screen 1 when screen 2 is selected

2022-04-14 Thread redhead

https://bugs.kde.org/show_bug.cgi?id=452638

Bug ID: 452638
   Summary: At starting yakuake appear on screen 1 when screen 2
is selected
   Product: yakuake
   Version: 21.12.3
  Platform: Manjaro
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: h...@kde.org
  Reporter: redhea...@free.fr
  Target Milestone: ---

STEPS TO REPRODUCE
1. reboot the computer
2. press F12


OBSERVED RESULT
Yakuake is on screen 1

EXPECTED RESULT
Yakuake is on screen 2


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro 5.15.28-1
(available in About System)
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
The only way to set Yakuake on screen 2 is to go to settings and select "open
screen: at mouse position", then go to screen 2, open Yakuake, go to settings
again and select "open screen: screen x" the screen number doesn't matter.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 452637] New: Action "Open Terminal" ignores path context of interacted folder

2022-04-14 Thread Brennan Kinney

https://bugs.kde.org/show_bug.cgi?id=452637

Bug ID: 452637
   Summary: Action "Open Terminal" ignores path context of
interacted folder
   Product: dolphin
   Version: 21.12.3
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: polarathene-sig...@hotmail.com
CC: kfm-de...@kde.org
  Target Milestone: ---

SUMMARY

Since 2021 releases have dropped the Konsole "Open Terminal Here" service in
favor of a generic internal alternative "Open Terminal" in Dolphin.

The new service opens a terminal at the views location, but ignores the context
of the location for any sub-location interacted with (folder, or via details
view many nested levels deep), requiring explicit navigation afterwards, or
workarounds such as opening a new tab/window to use the context menu action.

This seems like a regression, but may be intentional to support other terminals
than Konsole. However Konsole is opening at the view location, thus it seems
the UX regression is fixable.


STEPS TO REPRODUCE
1. Right-click a folder and choose "Actions => Open Terminal".
2. Terminal window opens at the views set location, not the sub-directory that
was interacted with.


OBSERVED RESULT

Terminal window opens at the views set location, not the sub-directory that was
interacted with.


EXPECTED RESULT

Terminal window opens at the location of the interacted sub-directory.

Especially useful in the "Details" view mode for a project overview, when
expanding multiple levels deep I should be able to open applications such as a
terminal without having to navigate or open a new view tab to perform the
action (current workaround).


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux, X11 with kernel 5.15.28
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3


ADDITIONAL INFORMATION

This used to be possibly prior to Konsole 20.12 from what I understand. Here is
the commit that caused the regression in favor of Dolphin's internal service
replacement:
https://invent.kde.org/utilities/konsole/-/commit/7cfe7bb380613d37427b76cc026027e547221f9e

Presently, Dolphin uses the service action `open_terminal` internally that
calls the following to launch the system terminal (instead of previously
hard-coded Konsole from `konsolehere.desktop` service:
https://invent.kde.org/system/dolphin/-/blob/3ebe3975a65d6e81fbda260d6df1806a7f82e142/src/dolphinmainwindow.cpp#L1088

The functionality appears to have been introduced with this MR by developer
Alexander Lohnau:
https://invent.kde.org/system/dolphin/-/merge_requests/81

In the referenced Reddit thread for that MR, a user attempts to adapt the
Konsole shipped service to their preferred Terminal app Tilix, and discovered
an issue with differing options to open the terminal at the expected path:

> Changing "--workdir %f" to "--working-directory %f" fixed the issue.

I am not familiar with how Dolphin is launching the `open_terminal` action
beyond the point I referenced earlier. I assume that calls code from another
project that was difficult to search for via the Gitlab UI. Hopefully this is
not a concern that would block this request from being feasible.

If it would be possible to address this regression, so that the service could
open at the expected location being interacted with, not the views top-level
location, that would be fantastic :)


WORKAROUND:

The present workaround is to disable the internal Dolphin service, and restore
the previous Konsole shipped service instead (altering it for alternative
terminal if necessary like with Tilix above). The full issue and workaround
solution was discussed recently here:

https://www.reddit.com/r/kde/comments/u1mdic/how_to_restore_dolphin_action_open_terminal_here/

With the original `konsolehere.desktop` service located here:
https://invent.kde.org/utilities/konsole/-/blob/release/20.12/desktop/konsolehere.desktop

Place it's contents in `/usr/share/kservices5/ServiceMenus/konsolehere.desktop`
and the service is restored under actions.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 452636] New: Humble request to bring back the option to turn off "activate on hover" in kickoff menu.

2022-04-14 Thread TONKAHANAH

https://bugs.kde.org/show_bug.cgi?id=452636

Bug ID: 452636
   Summary: Humble request to bring back the option to turn off
"activate on hover" in kickoff menu.
   Product: plasmashell
   Version: git-stable-Plasma/5.24
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: Application Launcher (Kickoff)
  Assignee: plasma-b...@kde.org
  Reporter: u83rmen...@gmail.com
CC: mikel5...@gmail.com, noaha...@gmail.com
  Target Milestone: 1.0

SUMMARY
***
Please bring back the option to turn off "switch on hover" on the kickoff menu.
The old menu had this option and it was always my go to cuz it drives me nuts
when things change with me activating said change. I found a discussion between
the devs regarding this like a year ago and it seems you were trying to solve
an issue of a slow UI so I want to my request very clear. Im not having any
specific issues or experiencing anything/broken not working. The "change on
hover" works as intended and is plenty snapy, I just dont like it at all. I
very much dislike having anything change via hovering my mouse over it, I'd
like it to only change when I actually activate a button. I hope its not a lot
to ask cuz I wouldnt ask if I knew it was a big request but I figure it doenst
hurt to put the request up anyway.

***


STEPS TO REPRODUCE
1.  click the kickoff icon in default panel
2.  hover your mouse over the different application categories 


OBSERVED RESULT
watch as the right side child menu changes from category to category without me
having to click anything to make that change happen. 

EXPECTED RESULT
1. click the kickoff icon in the default panel 
2. move my mouse to my desired category all the while, no changes to the menu
have occured yet
3. click on the software category to select it and see the child menu of said
category change to the list of applications within that category. 

SOFTWARE/OS VERSIONS
OS: Arch Linux x86_64 
Kernel: 5.17.1-arch1-1 
Resolution: 3840x2160, 3840x2160 
DE: Plasma 5.24.4 
WM: KWin 
Theme: [Plasma], Breeze [GTK2/3] 
Icons: [Plasma], breeze-dark [GTK2/3] 


ADDITIONAL INFORMATION

this option was in the old one,  would just be nice to have it back cuz I like
it that way, nothing is broken, just not to my liking and it cant hurt to ask
to have it back.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 452635] New: Dragging out of the color selector popup's bounds resets the Advanced Color Selector to red

2022-04-14 Thread bugzilla_noreply

https://bugs.kde.org/show_bug.cgi?id=452635

Bug ID: 452635
Summary: Dragging out of the color selector popup's bounds
resets the Advanced Color Selector to red
Product: krita
Version: unspecified
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Color Selectors
Assignee: krita-bugs-n...@kde.org
Reporter: oktop...@gmail.com
Target Milestone: ---

Created attachment 148168
--> https://bugs.kde.org/attachment.cgi?id=148168=edit
Screenshot of Krita with the Advanced Color Selector + "Show color selector"
popup while clicking + dragging to the left of the popup's area withotut
releasing yet

SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug
symbols.
See
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

This is for version 5.0.5, but that's not listed as an option for me yet.

STEPS TO REPRODUCE
1. Open Advanced Color Selector docker
2. Click the icon to configure it
3. Select HSY' as the Color Model Type
4. Select the fifth color selector shape (value / saturation rectangle for one
hue, with a hue strip at the top)
5. Click OK
6. Select some color like a teal in the Advanced Color Selector
7. Use the "Show color selector" hotkey
8. Click and drag on the popup's color selector until the cursor goes off to
the left side, the top side, or the bottom side (the right side is fine)
9. See the Advanced Color reset to red (furthest left on the hue strip)
10. Without releasing the mouse button, drag back into the popup's color
selector and see it return to the expected color
11. Continue dragging out of the popup until the color reset to red happens
again and release the click
12. Change the color on the Advanced Color Selector back to teal or some
non-red color
13. Use the "Show color selector" hotkey
14. See the popup's color selector is for red now and not the color in the
Advanced Color Selector

OBSERVED RESULT
Similar to bug 452422, the Advanced Color Selector and the "Show color
selector" hotkey's popup color selector get out of sync + dragging outside of
the popup's color selector area causes the Advanced Color Selector to reset its
hue value.

EXPECTED RESULT
Clicking then dragging outside of the popup's color selector shouldn't change
the hue of the Advanced Color Selector (they should stay in sync) and after
releasing / selecting a color in the popup and changing it in the Advanced
Color Selector the popup should reflect the newly selected color as well.

SOFTWARE/OS VERSIONS
Windows: Windows 10, Version 21H1, OS Build 19043.1645
macOS: N/A
Linux/KDE Plasma: N/A
(available in About System)
KDE Plasma Version: N/A
KDE Frameworks Version: N/A
Qt Version: 5.12.12

ADDITIONAL INFORMATION
I found this as I was trying to select a grayscale value (clicking and dragging
furthest left in the rectangle) and noticed it kept resetting my hue if I tried
to do that via the popup rather than the Advanced Color Selector directly.

1 2 >

1 - 100 of 199 matches

Mail list logo