[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #35 from gianluca.pettine...@gmail.com --- I still believe it is inconsistent because the selection behaves differently if the folder icon is of a regular folder or a hidden folder. -- You are receiving this mail because: You are watching all bug changes.
[Skanpage] [Bug 483151] New: Skanpage scans only 75dpi
https://bugs.kde.org/show_bug.cgi?id=483151 Bug ID: 483151 Summary: Skanpage scans only 75dpi Classification: Applications Product: Skanpage Version: 24.02.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: a.stipp...@gmx.net Reporter: g_...@hotmail.com Target Milestone: --- SUMMARY When I launch a scan in skanpage, no matter the dpi I choose, it will default to 75 dpi STEPS TO REPRODUCE 1. Open skanpage 2. select a resolution higher than 75 dpi 3. perform the scan OBSERVED RESULT The saved file has 75 dpi resolution EXPECTED RESULT The saved file has the resolution chosen SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0 Qt Version: 6.6 ADDITIONAL INFORMATION None -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #30 from gianluca.pettine...@gmail.com --- Hello all, Will the new ocean breeze theme have the same white select folder? Btw if a folder is hidden it does not get white. So it is an inconsistent behavior. Thanks for an update Gianluca -- You are receiving this mail because: You are watching all bug changes.
[Skanpage] [Bug 475622] New: Skanpage doesn't change dpi
https://bugs.kde.org/show_bug.cgi?id=475622 Bug ID: 475622 Summary: Skanpage doesn't change dpi Classification: Applications Product: Skanpage Version: 23.08.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: a.stipp...@gmx.net Reporter: g_...@hotmail.com Target Milestone: --- SUMMARY When scanning a page with skanpage, despite the resolution chosen, the scanner is always defaulting to 75 dpi. Scanner Samsung SCX3405FW STEPS TO REPRODUCE 1. Open skanpage 2. Set DPI to 1200 DPI 3. Scan the page OBSERVED RESULT Scanned page is 75 DPI EXPECTED RESULT Scanned page 1200 DPI SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Archlinux Kernel 6.5.7 (available in About System) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #28 from gianluca.pettine...@gmail.com --- Is there any update on this issue? If you could point me in the good code byte I could spend some time trying to fix it. Thanks -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #26 from gianluca.pettine...@gmail.com --- I solved as suggested here by creating a local icon set slightly darker for the folders, which by the way is even more awesome. After all why to have selection and folder color the same? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #22 from gianluca.pettine...@gmail.com --- Any progress on this? Or can an expert point to the code where the code is implemented? Thanks -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #21 from gianluca.pettine...@gmail.com --- Another side effect of the bug is that when you are editing a line in dolphin, all the other fields become white on white ie invisible. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 457679] New: In Wayland the CTRL+ click doesn't work with Latte-Dock
https://bugs.kde.org/show_bug.cgi?id=457679 Bug ID: 457679 Summary: In Wayland the CTRL+ click doesn't work with Latte-Dock Product: lattedock Version: git (master) Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: g_...@hotmail.com Target Milestone: --- 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 *** Latte-Dock allows to create a new instance of an application by CTRL+left click on the icon. This is valid for X11 but doesn't work in Wayland STEPS TO REPRODUCE 1. Selecte KDE session Wayland 2. Launch Latte Dock 3. Open the first time an application with mouse left click 4. Open a second instance by CTRL+left click OBSERVED RESULT Second instance doesn't open EXPECTED RESULT Second instance opens SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux 5.18.16 (available in About System) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 455513] Small icons no longer respect the "Small Icon" size configurable in the Icons KCM
https://bugs.kde.org/show_bug.cgi?id=455513 --- Comment #11 from gianluca.pettine...@gmail.com --- I agree with you that the way I (and probably others) scale the screen is weird. The reasons are: - widgets size is too big with uniform scaling. I saw there is some discussion to have an adjustable parameter to reduce padding/thickness - I prefer colored folder icons, which are only from 32 px size Both reasons are "silly" vs the principle of having only one way of scaling the screen, which I fully support. Maybe by having a widget adjustable size parameter the weird scaling way can be removed. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 455513] Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513
--- Comment #9 from gianluca.pettine...@gmail.com ---
Hello Nate,
I found the root cause:
it is in kstyle/breezestyle.cpp
***
//__
int Style::pixelMetric(PixelMetric metric, const QStyleOption *option, const
QWidget *widget) const
{
// handle special cases
switch (metric) {
case PM_MenuHMargin:
case PM_MenuVMargin:
return Metrics::MenuItem_HighlightGap;
// small icon size
case PM_SmallIconSize:
if (isTabletMode()) {
return 22;
} else {
return 16; //<-- here is the root cause
}
***
This override causes small icons to be insensitive to a change in size in
system settings.
I'm not a programmer but I think that forcing these numbers is not elegant.
I suggest to first read the size and then increase by one level for tablet mode
instead of fixing absolute values
What do you think?
Regards
Gianluca
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 455513] Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513 gianluca.pettine...@gmail.com changed: What|Removed |Added Resolution|NOT A BUG |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #7 from gianluca.pettine...@gmail.com --- Hello Nate, I tried to scale the screen with video scaling as you suggested. You see Dolphin in the screenshot. The tree and menu drop down icons are still insensitive to icon size change. The "small icons" are insensitive to any change of icon size through System Settings -> Appearance -> Icons -> Configure Icons Size. So definitely it is a bug. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 455513] Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513 --- Comment #6 from gianluca.pettine...@gmail.com --- Created attachment 150130 --> https://bugs.kde.org/attachment.cgi?id=150130=edit Dolphin with screen resized 150% I tried to scale with video scaling to 150% and the result is ugly. I mean the font is OK but the widgets are all too big, buttons and scrollbars. And the tree like the menu icons are not resizing with configure icon size while all the other icons are sensitive to icon size change. Definitely it is a bug -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 455513] Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513 --- Comment #4 from gianluca.pettine...@gmail.com --- System settings, appearance, icons, configure icons size. I normally set small icons to 32. That's enough up to plasma 5.24.5. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 455513] Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513 --- Comment #2 from gianluca.pettine...@gmail.com --- Hello Nate, agreed but before 5.25 I could scale like this. The proble is that small icons are not sensitive to changing its size in system settings. I think it is a bug. Gianluca -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455513] New: Tiny icons in Dolphin tree and in menu dropdown
https://bugs.kde.org/show_bug.cgi?id=455513 Bug ID: 455513 Summary: Tiny icons in Dolphin tree and in menu dropdown Product: plasmashell Version: master Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: g_...@hotmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 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 *** STEPS TO REPRODUCE 1. Open dolphin with tree visible 2. Set font dpi 144 and video size 100% on a macbook pro 15" 2880x1800 OBSERVED RESULT Icons are tiny even when configuring icon size more than 32 px EXPECTED RESULT Before plasma 5.25 the icons where 32 px and not 16 px in dolphin tree and in menu drop-down SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Archlinux (available in About System) KDE Plasma Version: 5.25 KDE Frameworks Version: 5.95 Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 445087] Selected folder icons are drawn in white
https://bugs.kde.org/show_bug.cgi?id=445087 gianluca.pettine...@gmail.com changed: What|Removed |Added CC||g_...@hotmail.com --- Comment #5 from gianluca.pettine...@gmail.com --- Can we then solve by coloring the folder just similar to the color scheme? Will it be the case for new icon breeze ocean? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #17 from gianluca.pettine...@gmail.com --- (In reply to medin from comment #12) > Created attachment 146158 [details] > Dark shadow behind selected icons Definitely the best solution -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #16 from gianluca.pettine...@gmail.com --- I think that the best solution is to dralw a dark shadow around the folder icon. It is definitely more consistent with the desktop behaviour. Do you agree? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in selected list items
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #9 from gianluca.pettine...@gmail.com --- In reply to Nate: maybe a good solution is to draw a white or black shadowed border on the icon to not have it merged with the selection -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 447215] Unable to rename the last file in details view
https://bugs.kde.org/show_bug.cgi?id=447215 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #2 from Gianluca Pettinello --- +1 for me -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in Compact or Details view
https://bugs.kde.org/show_bug.cgi?id=446468 --- Comment #5 from gianluca.pettine...@gmail.com --- Is there any update? Saw in Nate's post that Dolphin 22.04 will have full line selection. Maybe it solves also this bug. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446468] Selected folder icon becomes white in Compact or Details view
https://bugs.kde.org/show_bug.cgi?id=446468 gianluca.pettine...@gmail.com changed: What|Removed |Added CC||g_...@hotmail.com --- Comment #4 from gianluca.pettine...@gmail.com --- No solution for this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428800] Screen flicker after long screen lock upon resume
https://bugs.kde.org/show_bug.cgi?id=428800 --- Comment #5 from Gianluca Pettinello --- (In reply to Gianluca Pettinello from comment #4) > (In reply to Nate Graham from comment #3) > > Sure, that would be be great, thanks! > > Just done, so far no issue, I'm in X11 session Hi Nate, I can confirm that flickering is not present with intel modesetting You can close the bug Thanks Gianluca -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428800] Screen flicker after long screen lock upon resume
https://bugs.kde.org/show_bug.cgi?id=428800 --- Comment #4 from Gianluca Pettinello --- (In reply to Nate Graham from comment #3) > Sure, that would be be great, thanks! Just done, so far no issue, I'm in X11 session -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428800] Screen flicker after long screen lock upon resume
https://bugs.kde.org/show_bug.cgi?id=428800 --- Comment #2 from Gianluca Pettinello --- (In reply to Nate Graham from comment #1) > Are you still experiencing this with Plasma 5.22? Hello Nate, sorry for late reply. No I don't experience flickering any more. I moved to Intel 2D graphics drivers (xf86-video-intel) instead of modesetting and I disable panel self refresh, still when I was in 5.21 series. If you want I can try to move back to modesetting and see if it flickers again. Regards Gianluca -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices and SD cards after disconnecting and re-connecting them
https://bugs.kde.org/show_bug.cgi?id=438874 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #25 from Gianluca Pettinello --- Hello everybody, is this bug fixed? Thanks Gianluca -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 413394] An option to set font size
https://bugs.kde.org/show_bug.cgi?id=413394
Gianluca Pettinello changed:
What|Removed |Added
CC||gianluca.pettinello@gmail.c
||om
--- Comment #8 from Gianluca Pettinello ---
workaround
file: DigitalClock.qml
State {
name: "oneLineDate"
// the one-line mode has no effect on a vertical panel because it
would never fit
when: plasmoid.formFactor !== PlasmaCore.Types.Vertical &&
main.oneLineMode
PropertyChanges {
target: main
Layout.fillHeight: true
Layout.fillWidth: false
Layout.minimumWidth: contentItem.width
Layout.maximumWidth: Layout.minimumWidth
}
PropertyChanges {
target: contentItem
height: sizehelper.height
width: dateLabel.width + dateLabel.anchors.rightMargin +
labelsGrid.width
}
AnchorChanges {
target: labelsGrid
anchors.right: contentItem.right
}
PropertyChanges {
target: dateLabel
height: timeLabel.height
width: dateLabel.paintedWidth + PlasmaCore.Units.smallSpacing
font.pixelSize: 20 //workaround
verticalAlignment: Text.AlignVCenter
anchors.rightMargin: labelsGrid.columnSpacing
fontSizeMode: Text.VerticalFit
}
AnchorChanges {
target: dateLabel
anchors.right: labelsGrid.left
anchors.verticalCenter: labelsGrid.verticalCenter
}
PropertyChanges {
target: timeLabel
height: sizehelper.height
width: sizehelper.contentWidth
font.pixelSize: 20 //workaround
fontSizeMode: Text.VerticalFit
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 438494] New: Flickering when closing modal dialog
https://bugs.kde.org/show_bug.cgi?id=438494 Bug ID: 438494 Summary: Flickering when closing modal dialog Product: kwin Version: 5.22.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY When closing a modal dialog with Dialog Parent effect enabled, after the closing there is a black flicker occurring STEPS TO REPRODUCE 1. Enable Dialog Parent effect 2. Open a modal dialog, the parent window will dim 3. Close the modal dialog and the parent will flicker OBSERVED RESULT Flickering EXPECTED RESULT No flickering SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux / Plasma KDE Plasma Version: 5.22.0 KDE Frameworks Version: 5.82.0 Qt Version: 5.15 ADDITIONAL INFORMATION None -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 433115] Global Scaling Options Seems to "lower" resolution unlike old "force font DPI"; consider re-adding it as an option
https://bugs.kde.org/show_bug.cgi?id=433115 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #12 from Gianluca Pettinello --- (In reply to Nate Graham from comment #1) > So there are a few things here: > > 1. Yeah, we removed the Force Fonts DPI setting from the fonts KCM on the > logic that it was redundant with simply being able to change the fonts. > Maybe that was a bad idea. > > 2. Because Wayland only does integer scaling, setting 150% scale will > internally do 200% scale and then scale down the resulting image, which does > cause some blurriness > > 3. 200% scale does not result in any downscaling at all, so it should be > nice and sharp--exactly as when using the old Force Font DPI setting > > > Can you confirm that 200% scale produces an image that's as sharp as using > the old force fonts DPI setting did? It should, and it does for me; if it > doesn't for you, that's a bug that needs to be investigated. > > I suspect that this will ultimately lead to multiple bug reports, but let's > start with one thing at a time. :) Yes please restore Force Fonts DPI! Please...Please...Please -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 430891] Kickoff/KRunner displaying blank entry upon search
https://bugs.kde.org/show_bug.cgi?id=430891 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #5 from Gianluca Pettinello --- Baloo 5.78 seems to fix the problem -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 409499] Krunner returns empty item
https://bugs.kde.org/show_bug.cgi?id=409499 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #18 from Gianluca Pettinello --- Same for me -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 430436] Baloo runner can't find any of my files inside "/home/nate/SpiderOak Hive/"
https://bugs.kde.org/show_bug.cgi?id=430436 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #2 from Gianluca Pettinello --- Same story for me -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428800] New: Screen flicker after long screen lock upon resume
https://bugs.kde.org/show_bug.cgi?id=428800 Bug ID: 428800 Summary: Screen flicker after long screen lock upon resume Product: plasmashell Version: 5.20.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: gianluca.pettine...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY After resuming from long screen lock the screen starts to flicker especially at the bottom. Sometimes the flicker disappears after some minutes. The phenomenon is more evident when using Firefox after the screen unlock STEPS TO REPRODUCE 1. Wait the screen lock to activate 2. Leave the screen locked for a long period 3. Open firefox and scroll a bit 4. The flicker starts OBSERVED RESULT Screen flickering EXPECTED RESULT Screen not flickering SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux (available in About System) KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75 Qt Version: 5.15.1 ADDITIONAL INFORMATION Graphical card Intel Iris Pro 5200 Nomodeset driver -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422023] New: Feature request: add minimize all on present windows effect
https://bugs.kde.org/show_bug.cgi?id=422023 Bug ID: 422023 Summary: Feature request: add minimize all on present windows effect Product: kwin Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY It would be nice to add the option "Minimize All" when clicking on the desktop during "Present Windows" mode. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 421273] Slow zoom animation
https://bugs.kde.org/show_bug.cgi?id=421273 --- Comment #1 from Gianluca Pettinello --- Just to update, the git version doesn't have this issue while version 0.9.11-1 in Arch has -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 421273] New: Slow zoom animation
https://bugs.kde.org/show_bug.cgi?id=421273 Bug ID: 421273 Summary: Slow zoom animation Product: lattedock Version: 0.9.11 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY Zomm animation in latte dock isnow slow after update of kde Frameworks 5.70 STEPS TO REPRODUCE 1. Upgrade kde frameworks to 5.70 2. Enable zoom effect in latte dock 3. Very slow zoom animation. Then it is fast when scrolling the zoom -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 411833] Krita crashes on close
https://bugs.kde.org/show_bug.cgi?id=411833 Gianluca Pettinello changed: What|Removed |Added Platform|Other |Archlinux Packages -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 411833] New: Krita crashes on close
https://bugs.kde.org/show_bug.cgi?id=411833 Bug ID: 411833 Summary: Krita crashes on close Product: krita Version: 4.2.6 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY When I close krita, no matters what I do, the program crashes STEPS TO REPRODUCE 1. Open Krita 2. Close Krita 3. Crash OBSERVED RESULT Not a real problem as the system works but really annoying. Thanks for solving Gianluca EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 409518] Visiting Fonts KCM changes antialliasing settings without warning
https://bugs.kde.org/show_bug.cgi?id=409518 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #1 from Gianluca Pettinello --- Same for me -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 365924] Breeze GTK should add shadows to context menus
https://bugs.kde.org/show_bug.cgi?id=365924 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #3 from Gianluca Pettinello --- A bit of necrobump but I agree with Nate. The shadows should be created and drawn as for any other client simply ignoring what gtk has set as shadow properties -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 408711] New notifications are opaque
https://bugs.kde.org/show_bug.cgi?id=408711 --- Comment #2 from Gianluca Pettinello --- Ok, and sorry if my tone was harsh, since you work hard every day to make kde better. If ever you consider one day to add transparency and blur to the notification and to increase the border padding that would be perfect. Thanks again. Gianluca -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 408711] New: New notifications are opaque
https://bugs.kde.org/show_bug.cgi?id=408711 Bug ID: 408711 Summary: New notifications are opaque Product: plasmashell Version: 5.16.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Notifications Assignee: k...@privat.broulik.de Reporter: gianluca.pettine...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY New notifications are completely opaque and there is a thin vertical bar showing when the notification is going to disappear. Looks very Spartan. Is it possible to set transparency and remove the vertical line? Thanks Gianluca STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405521] New: Blinking launch feedback wrong blinking
https://bugs.kde.org/show_bug.cgi?id=405521 Bug ID: 405521 Summary: Blinking launch feedback wrong blinking Product: kwin Version: 5.15.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY When you enable launch feedback Blinking and you start an application the cursor is blinking with white square instead of lighting the colors STEPS TO REPRODUCE 1. Enable Blinking launch feedback 2. Launch an application OBSERVED RESULT The cursor blinks to a white square back to the colored icon EXPECTED RESULT The cursor blinks to lighter icon back to normal colored icon as in the past SOFTWARE/OS VERSIONS Linux version: Archlinux kernel 5.0.2 KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.1 Qt Version: 5.12.1 ADDITIONAL INFORMATION No additional information -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #34 from Gianluca Pettinello --- (In reply to Martin Flöser from comment #33) > yes, as soon as gtk adds that property window management breaks But if we added _KDE_NETWM_SHADOW property with shadw pixmaps, how can gtk destroy them? And then if kde_netwm_shadow exists then kwin renders the shadows, isn't it? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #32 from Gianluca Pettinello --- (In reply to David Edmundson from comment #31) > How? If we use the DialogShadows.cpp code and apply it to each Window that has _GTK_FRAME_EXTENTS enabled (we can trap it in kwin events.cpp)? Too naif? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #30 from Gianluca Pettinello --- (In reply to David Edmundson from comment #29) > For an example see DialogShadows.cpp in plasma-framework. > > You'd have to get that done by the GTK process. And if we trap it and force shadows done as KDE model? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #28 from Gianluca Pettinello --- (In reply to Martin Flöser from comment #27) > the pixmap is created by the client. Could you tell me in which point of the code? Thanks :) -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #26 from Gianluca Pettinello --- Coming back to the topic as I'm hard to give up if I think the goal is reachable. The function: Xcb::Property property(false, id, atoms->kde_net_wm_shadow, XCB_ATOM_CARDINAL, 0, 12); as it is called in function: readX11ShadowProperty is the key to get the shadow properly rendered in pop up menus. As already described in: https://community.kde.org/KWin/Shadow the last four uint32_t contain the padding of the shadow (I deliberately injected a piece of code to manipulate them) The first eight uint32_t contain the id of the pixmaps. Who creates the pixmaps. In which point of the code could I find it? Thanks Gianluca -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 330820] Scaling to fit print margins incorrectly scales cropped page
https://bugs.kde.org/show_bug.cgi?id=330820 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #14 from Gianluca Pettinello --- Confirmed and other softwares are ok. Possible to copy their code for printing? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #24 from Gianluca Pettinello ---
(In reply to Nate Graham from comment #22)
> RESOLVED FIXED isn't an appropriate status if the issue of GTK3 headerbar
> windows not getting shadows hasn't actually been fixed.
>
> RESOLVED INTENTIONAL would be appropriate if you don't plan to fix it, but
> it sounds like David has a plan to eventually fix it on Wayland. Therefore
> the original RESOLVED LATER status was appropriate. Changing back.
I'm very happy to know that David will fix the issue in Wayland
My DE/WM before KDE was xfce with compiz. And with that wm shadows were
rendered in gtk apps and also in apps which are neither gtk nor kde, for
instance gmsh. Since compiz is a very old piece of software but still working
along many version of gtk, it means that the shadow rendering was designed
agnostic of the toolkit. In the case of kde I see this piece of code in
shadow.cpp
QVector< uint32_t > Shadow::readX11ShadowProperty(xcb_window_t id)
{
QVector ret;
if (id != XCB_WINDOW) {
Xcb::Property property(false, id, atoms->kde_net_wm_shadow,
XCB_ATOM_CARDINAL, 0, 12);
uint32_t *shadow = property.value();
if (shadow) {
ret.reserve(12);
for (int i=0; i<12; ++i) {
ret << shadow[i];
}
}
}
return ret;
}
where I see that only windows supporting kde_net_wm_shadow will be rendered
correctly (at least I hope to have interpreted the code well).
Anyway I understand that nothing will be done for X11 and I will temporarily
switch to my old DE waiting for Wayland to support shadows also for non KDE
apps.
Regards
Gianluca
--
You are receiving this mail because:
You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #20 from Gianluca Pettinello --- (In reply to Martin Flöser from comment #19) > Ok, I think I need to explain more on the situation on X11. The problem is > not that the code is fragile, undocumented or umaintained. The code is good, > the quality of the code in question is superb and one can easily understand > which area of X11 it reflects. No increase of documentation would make it > possible to implement this change request. > > Let's look at the root problem. On X11 the window geometry is retrieved > through the get_geometry call: > https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests: > GetGeometry > > This specifies the geometry of a drawable - either a pixmap or a window. > That's what KWin's geometry handling code is based on. Now what GTK did is > use this window geometry and added the shadow into it. Additional there is a > property which indicates what to subtract from the x geometry to get to the > window geometry. If we wouldn't subtract it, we would snap to shadow, quick > tiling would include shadow, maximize would include shadow, etc. etc. > > So basically everywhere where we use geometry we would have to remove that > this maps to x window geometry and replace it by an abstract geometry > concept which is either the geometry or the geometry subtracted by shadow. > And this is the fundamental problem for us. When KWin was developed nobody > thought that the geometry of a window would not match the geometry. Now you > might wonder how things like window decorations work? Well it's still a > window. The actual client window gets reparented to the window decoration > and then we just use the geometry of the decoration window again. > > The geometry handling in KWin is deep involved and the assumption is carried > everywhere. It goes into the effect system (e.g. Present Windows uses it to > layout), it's deep in the compositor (we actually have a check to verify the > geometry matches the pixmap size, if it doesn't we don't render the window, > see https://phabricator.kde.org/source/kwin/browse/master/scene.cpp$1042). > We have multiple level of convenient api for it: Toplevel::width, > Toplevel::height, Toplevel::x, Toplevel::y, Toplevel::size, Toplevel::pos, > etc. So it's not just one method we have to check. Then there are methods > like isOnScreen intersecting the screen geometry with the window geometry. > > So all of that is a huge effort to restructure the code base to support this > new requirement. And then there are multiple things which are completely > unknown to me as this is a not standardized protocol: when resizing do we > have to add the shadow or not? A maximized window does it include the shadow > or not? How does gravity interact with shadow? What if a base increment is > set? What about vertical only or horizontal only maximize state? Gtk doesn't > like those, so do they support it? Is it possible to have shadows only on > some sides or is it always all? Can we expect that Gtk won't change that? > After all they broke us here several times. > > So to reiterate some important points: > * this is not a bug on our side, our code is written against the X > protocol, ICCCM and EWMH > * GTK changed basic understanding of what a window geometry is, this > understanding is completely incompatible to the assumptions KWin was > implemented on > * The code base is in a superb state, geometry handling has very seldom > bugs, it's a done and working code base > * The effort is comparable to adding Wayland support - the difficult part > was getting the geometry handling done > * implementing the change is a huge effort as the code base is large and it > touches complex areas of X where the expected behavior is undocumented by > GTK (I just tried google for _GTK_FRAME_EXTENTS and found nothing) > > > Comparing to the state on Wayland: on Wayland the geometry and visual > geometry are separated. The visual geometry is defined by the size of the > attached buffer. The geometry of the window is not directly mapped from the > buffer as we have concepts such as scale built into the protocol. While KWin > still is largely based on the idea that visual geometry matches window > geometry, it's not as bad as on X11. We already weakened the assumption a > lot by adding window decorations ;-). Implementing the required request > should be relatively straight forward and doable without larger problems. We > have a well tested code base on Wayland and I am sure it can be implemented > without regressions. The main reason why the request is not implemented is > that there was a little bit of version mess when that area of code got > written. That's now resolved and it's possible
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #17 from Gianluca Pettinello --- I understand the point. My suggestions coming from my experience in a chemical industry: 1) Be the teacher to the others since you have deep knowledge. Write a document explaining the structure of kwin classes and what each method does, what is the flow of actions once a window is created etc. 2) are you still in contact with the old developers to push them to do the same? And in the future with Wayland do the same otherwise the project will die -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #15 from Gianluca Pettinello --- I think discussion is getting too much emotional, probably because there is a lot of past efforts and frustration due to gtk always changing cards on the table. Is it not better to force server side decorations for CSD windows and pop up menus. By the way Libreoffice has menus without shadows, same Firefox. It is difficult to say they can be discarded to have a non gtk environment. Martin am I wrong or are you the master and Lord of kwin? So why you say we don't have the competency any more? -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 --- Comment #6 from Gianluca Pettinello --- Is it possible to implement 1) Server side shadows on both top level windows and to popups and menus? It would give more consistency to the applications. If we give each client the freedom to draw shadows as they want then we could end up with a program having red shadows and another program having blue shadows. Consistency is key for me. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 403440] New: Menu blur not working move to pop up menu
https://bugs.kde.org/show_bug.cgi?id=403440 Bug ID: 403440 Summary: Menu blur not working move to pop up menu Product: Breeze Version: 5.14.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- SUMMARY The bug happens when menu transparency is enable for Breeze theme under X11: if I copy a file and the menu pops out, the menu is grey and menu items become light blue on hover STEPS TO REPRODUCE 1. Enable transparency for Breeze widgets 2. Try to copy a file to the desktop, the Copy To/ Move To menu pops out OBSERVED RESULT The menu background is grey and the items get light blue when hovered EXPECTED RESULT The menu background is transparent blurred SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.14.0 to 5.14.90 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.0 ADDITIONAL INFORMATION None -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 402730] Light fontstyles for headings are causing visual and legibility issues
https://bugs.kde.org/show_bug.cgi?id=402730 --- Comment #7 from Gianluca Pettinello --- Thanks Nate for the(In reply to Nate Graham from comment #6) > You already can, sort of. What you can't currently do is choose the font > size/style etc. just for headings. That's something we do want to implement/ Thanks Nate -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 402730] Light fontstyles for headings are causing visual and legibility issues
https://bugs.kde.org/show_bug.cgi?id=402730 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #5 from Gianluca Pettinello --- I like the thin character, looks to me professional. Is it possible to have it under font configuration (e.g. use thin fonts) so that if somebody wants can use thin fonts? KDE is configurability after all :) Ciao Gianulca -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 336617] Feature request: disable fit-to-page while printing.
https://bugs.kde.org/show_bug.cgi?id=336617 Gianluca Pettinello changed: What|Removed |Added Version|0.19.1 |1.6.0 CC||gianluca.pettinello@gmail.c ||om --- Comment #18 from Gianluca Pettinello --- +1 to have the possibility to set scaling options in printing. Also it would be nice if the options are already displayed when printing (follow the philosophy of less clicks). Cheers Gianluca -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 391917] Add shadows for CSD windows
https://bugs.kde.org/show_bug.cgi?id=391917 --- Comment #19 from Gianluca Pettinello --- But can we trap a gtk window and let breeze make the shadow its own way? So we get also consistency in the shadow rendering, while csd is against consistency. Silly question: is it breeze or kwin who says if the shadow has to be drawn? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 391917] Add shadows for CSD windows
https://bugs.kde.org/show_bug.cgi?id=391917 --- Comment #16 from Gianluca Pettinello --- What you mean that gtk has to upload the shadow? Has gtk to fill an atom with the properties of the shadow? Sorry if I say something wrong but I'm not an expert. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 391917] Add shadows for CSD windows
https://bugs.kde.org/show_bug.cgi?id=391917 --- Comment #14 from Gianluca Pettinello --- Going nowhere indeed :( -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 391917] Add shadows for CSD windows
https://bugs.kde.org/show_bug.cgi?id=391917
--- Comment #13 from Gianluca Pettinello ---
First of all I apologize for the late reply
@Martin
You are right indeed Gnome developers are difficult to convince.
I have a question.
If we use gtk-nocsd package (in Archlinux AUR) we get server side decorations
and shadow on the window. But I still miss the shadow under the menus in gtk
apps. Looking at kwin code I see there is a piece of code in client.cpp
void Client::readGtkFrameExtents(Xcb::Property )
{
m_clientSideDecorated = !prop.isNull() && prop->type != 0;
emit clientSideDecoratedChanged();
}
which I'm trying to hack into
void Client::readGtkFrameExtents(Xcb::Property )
{
m_clientSideDecorated = true;
emit clientSideDecoratedChanged();
}
Am I going nowhere by forcing the compositor to treat gtk windows as normal
windows?
Regards
Gianluca
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 391917] Add shadows for CSD windows
https://bugs.kde.org/show_bug.cgi?id=391917 --- Comment #10 from Gianluca Pettinello --- We all know that gnome developers are doing wrong because they build a DE based on their view imposed to the commumity rather than listening to the needs of the community. We also know that they regularly break standards and eve their own code as a theme valid for one version of gtk is not valid any more for the next. It is for this reason that, after many years of unity and xfce I moved to kde, I was tired to debug my theme every month... This said I kindly ask to Martin to tell us how we can approach gnome community so that they fix the standard. I mean we can be many KDE users and if we push all together on the same point maybe we can get the result. Gianluca -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 400634] New: No menu drop shadow in libreoffice, firefox and gtk apps
https://bugs.kde.org/show_bug.cgi?id=400634 Bug ID: 400634 Summary: No menu drop shadow in libreoffice, firefox and gtk apps Product: kwin Version: 5.14.2 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: gianluca.pettine...@gmail.com Target Milestone: --- Created attachment 116067 --> https://bugs.kde.org/attachment.cgi?id=116067=edit No menu drop shadow SUMMARY Gtk apps, firefox, chrome and libreoffice don't have menu drop shadow. Kde apps have. It is annoying as the menu merges with background and is hardly focused Intel driver STEPS TO REPRODUCE 1. Open geany gtk app 2. Press whatever menu OBSERVED RESULT Menu without shadow EXPECTED RESULT Menu with shadow SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14.2 KDE Frameworks Version: 5.51.0 Qt Version: 5.11.2 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 400611] Blur context menu on file drop
https://bugs.kde.org/show_bug.cgi?id=400611 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #2 from Gianluca Pettinello --- I confirm the bug, intel driver. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379637] breeze-gtk should draw shadows for client-side-decorated windows
https://bugs.kde.org/show_bug.cgi?id=379637 Gianluca Pettinello changed: What|Removed |Added CC||gianluca.pettinello@gmail.c ||om --- Comment #2 from Gianluca Pettinello --- I think that it is related to the same topic: menus on gtk apps like libreoffice or firefox have no drop shadow. I'm running plasma 5.14.2 on Archlinux and my graphic card is Intel Iris. I use mesa and intel drivers and compositor uses opengl 3.1 Anyway to solve the issue? Thanks Gianluca -- You are receiving this mail because: You are watching all bug changes.
