https://bugs.kde.org/show_bug.cgi?id=379637
Nate Graham changed:
What|Removed |Added
Resolution|LATER |DUPLICATE
--- Comment #35 from Nate Graham ---
https://bugs.kde.org/show_bug.cgi?id=379637
mikz...@gmail.com changed:
What|Removed |Added
CC||mikz...@gmail.com
--
You are receiving
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #33 from Martin Flöser ---
yes, as soon as gtk adds that property window management breaks
--
You are receiving this mail because:
You are watching all bug changes.
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?
--
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #31 from David Edmundson ---
How?
--
You are receiving this mail because:
You are watching all bug changes.
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #29 from David Edmundson ---
For an example see DialogShadows.cpp in plasma-framework.
You'd have to get that done by the GTK process.
--
You are receiving this mail because:
You are watching all bug changes.
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #27 from Martin Flöser ---
the pixmap is created by the client.
--
You are receiving this mail because:
You are watching all bug changes.
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #25 from Nate Graham ---
BTW Martin, on a more personal note, I understand completely what you mean when
you say that the topic makes your heart beat quickly. I have the same
experience. It's a stressful subject for sure. :(
--
You are
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #23 from Martin Flöser ---
Sorry, I didn't want to change the status at all.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=379637
Nate Graham changed:
What|Removed |Added
Resolution|FIXED |LATER
--- Comment #22 from Nate Graham ---
https://bugs.kde.org/show_bug.cgi?id=379637
Martin Flöser changed:
What|Removed |Added
Resolution|LATER |FIXED
--- Comment #21 from Martin Flöser ---
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #19 from Martin Flöser ---
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
https://bugs.kde.org/show_bug.cgi?id=379637
David Edmundson changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #16 from Martin Flöser ---
(In reply to Gianluca Pettinello from comment #15)
> Martin am I wrong or are you the master and Lord of kwin?
I'm no longer maintainer, but probably still the KWin dev with most knowledge
in the code base.
>
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #14 from Martin Flöser ---
Btw. I'm completely not available for working on it. I got burned out over the
experience and right now my heart is beating like mad. This was extremely
frustrating when gtk broke our code and they did not fix
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #13 from Martin Flöser ---
let's get the wording right: gtk changing X in an incompatible way is not a bug
on our side. It's a new feature or requirement. Please let's not call it a bug.
The code is not fragile, the code base is huge. We
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #12 from Nate Graham ---
Martin, I interpreted your fear of regressions and breakage to suggest a
fragile codebase, since I'm pretty sure that the problem isn't a lack of skill
on your part. :) If my interpretation was incorrect, I
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #11 from Martin Flöser ---
Our code base is neither fragile nor is this a bug. Gtk requires a new not
standardized functionality which is not in line with ICCCM and EWMH. We have a
window manager implemented against the standard. Claiming
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #10 from David Edmundson ---
Bug 390550 is definitely a lot more serious but it's not necessarily solved by
the same thing.
You can have a larger CSD resize area without relying on frame extents to
signify your window content. I would
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #9 from Nate Graham ---
I can appreciate the technical problems associated with fixing this bug.
But this issue is significant from a user perspective. An even worse one is Bug
390550, which results in an impairment to function, not just
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #8 from Martin Flöser ---
My estimate for option 3 on X11 was about half a year of development effort
with huge potential to break. Basically adding support for this breaks a core
assumption of the compositor: x pixmap size equals window
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #7 from David Edmundson ---
You could hack something together, but it wouldn't work great.
If you drew a square border round the plasma dialog popups it'd look weird in
the corners.
--
You are receiving this mail because:
You are
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
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #5 from David Edmundson ---
Long term kwin needs to change.
There are 3 current implementation for shadows:
1) Server draws them based on what the deco theme says (what classic toplevels
and KDE toplevels do)
2) The client sends the
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #4 from Nate Graham ---
So what do we do?
GTK folks say it's our fault. We say it's their fault. It can't be nobody's
fault. And if it's primarily one party's fault but they won't budge, then users
suffer and we get blamed regardless.
https://bugs.kde.org/show_bug.cgi?id=379637
David Edmundson changed:
What|Removed |Added
CC||k...@davidedmundson.co.uk
--- Comment #3
https://bugs.kde.org/show_bug.cgi?id=379637
Gianluca Pettinello changed:
What|Removed |Added
CC||gianluca.pettinello@gmail.c
https://bugs.kde.org/show_bug.cgi?id=379637
Darkspirit changed:
What|Removed |Added
CC||j...@ikenmeyer.eu
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=379637
Dr. Chapatin changed:
What|Removed |Added
CC||yy...@gmx.com
--
You are
https://bugs.kde.org/show_bug.cgi?id=379637
Arthur Țițeică changed:
What|Removed |Added
CC||arthur+...@titeica.ro
https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #1 from scionicspec...@gmail.com ---
Unfortunately, it's not really so simple. We can write shadows appropriately
for WMs which interact well with the nonstandard hints GTK CSDs are using.
However, from my basic understanding, they conflict
https://bugs.kde.org/show_bug.cgi?id=379637
Nate Graham changed:
What|Removed |Added
CC||pointedst...@zoho.com
--
40 matches
Mail list logo