El Dijous, 11 de desembre de 2014, a les 13:15:55, Martin Gräßlin va escriure:
> On Thursday 11 December 2014 00:05:52 Albert Astals Cid wrote:
> > El Dimecres, 10 de desembre de 2014, a les 15:44:02, Thomas Lübking va
> >
> > escriure:
> > > On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph
On Thursday 11 December 2014 00:05:52 Albert Astals Cid wrote:
> El Dimecres, 10 de desembre de 2014, a les 15:44:02, Thomas Lübking va
>
> escriure:
> > On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote:
> > > Every interactive on-screen element must have a text, either as a
> >
El Dimecres, 10 de desembre de 2014, a les 15:44:02, Thomas Lübking va
escriure:
> On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote:
> > Every interactive on-screen element must have a text, either as a
> > label, or as a tooltip. This is a simple accessibility requirement.
>
>
On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote:
Every interactive on-screen element must have a text, either as a
label, or as a tooltip. This is a simple accessibility requirement.
Does this imply a formal representation (eg. to be accessed as object property from some
sc
On Wednesday 10 December 2014 08:07:25 Martin Gräßlin wrote:
> My personal opinion is that it doesn't need the tooltips. If one
> cannot recognize the buttons than the design language of the
> decoration is really bad.
Every interactive on-screen element must have a text, either as a
label, or as
On Wednesday 10 December 2014 00:31:03 Thomas Lübking wrote:
> On Mittwoch, 10. Dezember 2014 00:21:38 CEST, Albert Astals Cid wrote:
> > Where did the strings such as
> >
> > "Not on all desktops"
>
> They were/are not part of KDecoration, but KCommonDecoration - an optional
> "simplifying" wrap
On Wednesday 10 December 2014 00:21:38 Albert Astals Cid wrote:
> El Divendres, 28 de novembre de 2014, a les 15:30:23, Martin Gräßlin va
>
> escriure:
> > On Friday 28 November 2014 15:25:03 Thomas Lübking wrote:
> > > On Freitag, 28. November 2014 14:55:43 CEST, Martin Gräßlin wrote:
> > > > Bot
On Mittwoch, 10. Dezember 2014 00:21:38 CEST, Albert Astals Cid wrote:
Where did the strings such as
"Not on all desktops"
They were/are not part of KDecoration, but KCommonDecoration - an optional
"simplifying" wrapper class.
I assume it would make sense to deliver pre-defined (and i18n'd)
El Divendres, 28 de novembre de 2014, a les 15:30:23, Martin Gräßlin va
escriure:
> On Friday 28 November 2014 15:25:03 Thomas Lübking wrote:
> > On Freitag, 28. November 2014 14:55:43 CEST, Martin Gräßlin wrote:
> > > Both signals are now removed. Works like a charm with the
> > > handling direct
On Wednesday 12 November 2014 15:27:00 Thomas Lübking wrote:
> On Mittwoch, 12. November 2014 08:19:54 CEST, Martin Gräßlin wrote:
> > My thought was that it's going to be
> > * rect for top
> > * rect for left
> > * rect for right
> > * rect for bottom
> >
> > leaving out the center element. Thus
On Friday 28 November 2014 15:25:03 Thomas Lübking wrote:
> On Freitag, 28. November 2014 14:55:43 CEST, Martin Gräßlin wrote:
> > Both signals are now removed. Works like a charm with the
> > handling directly in KWin.
>
> I foresee trouble/complicfication on this (at least limitation)
>
> Assum
On Freitag, 28. November 2014 14:55:43 CEST, Martin Gräßlin wrote:
Both signals are now removed. Works like a charm with the
handling directly in KWin.
I foresee trouble/complicfication on this (at least limitation)
Assume a decoration wants to alter the current tab on wheel, depending on the
On Friday 28 November 2014 12:52:44 Christoph Feck wrote:
> > > > Q_PROPERTY(QFont font
> > >
> > > When I want to compute pixel sizes for the requested font, how
> > > do I get the correct QPaintDevice needed for the QFontMetrics?
> > > Otherwise, please provide a QFontMetrics (see QStyleOption).
Martin GräßlinOn Friday 28 November 2014 12:00:43 wrote:
> > >void titleBarDoubleClicked();
> >
> > Maybe it might sense to have the event here, to check keyboard
> > modifiers?
> >
> > >void titleBarWheelEvent(const QPoint &angleDelta);
> >
> > Why not simply pass the QWheelEvent? I mi
On Friday, November 28, 2014 14:16:38 Martin Gräßlin wrote:
> On Friday 28 November 2014 13:53:07 Sebastian Kügler wrote:
> > On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote:
> > >
> > > The documentation is copied from Plasma. I don't know anything about
> > > high
> > > DPI, so maybe
On Friday 28 November 2014 13:53:07 Sebastian Kügler wrote:
> On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote:
> > > Given that you call it "fundamental", I suggest to allow qreal here.
> > > A "millimeter" is really small, and if you only allow integer values,
> > > the precision might
On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote:
> > Given that you call it "fundamental", I suggest to allow qreal here.
> > A "millimeter" is really small, and if you only allow integer values,
> > the precision might be too coarse.
>
> The documentation is copied from Plasma. I don't
On Friday 28 November 2014 12:00:43 Martin Gräßlin wrote:
> On Sunday 16 November 2014 23:30:35 Christoph Feck wrote:
> > On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote:
> > > today I want to start the review process for the new
> > > KDecoration
> >
> > Hi Martin,
> >
> > thanks for the
On Sunday 16 November 2014 23:30:35 Christoph Feck wrote:
> On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote:
> > today I want to start the review process for the new KDecoration
>
> Hi Martin,
>
> thanks for the work, here are some random comments from my side. I
> hope I am not too late.
On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote:
> today I want to start the review process for the new KDecoration
Hi Martin,
thanks for the work, here are some random comments from my side. I
hope I am not too late.
* decoration.h
> Rendering whether the Decoration is fully opaque.
On Mittwoch, 12. November 2014 08:19:54 CEST, Martin Gräßlin wrote:
My thought was that it's going to be
* rect for top
* rect for left
* rect for right
* rect for bottom
leaving out the center element. Thus a QRegion to render it in one go.
My thought was that we'd generate a buffer for each
Martin GräßlinOn Tuesday 11 November 2014 17:53:53 wrote:
> On Tuesday 11 November 2014 17:48:58 Thomas Lübking wrote:
> > On Dienstag, 11. November 2014 17:06:53 CEST, Martin Gräßlin wrote:
> > > In case you have better naming suggestions please let me know.
> >
> > "::geometry(Qt::WindowFrameSe
On Tuesday 11 November 2014 23:23:09 Thomas Lübking wrote:
> On Dienstag, 11. November 2014 13:30:09 CEST, Martin Gräßlin wrote:
> > Added a QRegion parameter (thought is to be able to render the complete
>
> > decoration in one go if needed):
> Why a region? The core sends a rect (needs implicit
On Dienstag, 11. November 2014 13:30:09 CEST, Martin Gräßlin wrote:
Added a QRegion parameter (thought is to be able to render the complete
decoration in one go if needed):
Why a region? The core sends a rect (needs implicit QRegion construction) and
the deco will likely call boundingRect() o
On Tuesday 11 November 2014 17:48:58 Thomas Lübking wrote:
> On Dienstag, 11. November 2014 17:06:53 CEST, Martin Gräßlin wrote:
> > In case you have better naming suggestions please let me know.
>
> "::geometry(Qt::WindowFrameSection tile)" ?
>
> If you need parameterless accessors, i'd just add
On Dienstag, 11. November 2014 17:06:53 CEST, Martin Gräßlin wrote:
In case you have better naming suggestions please let me know.
"::geometry(Qt::WindowFrameSection tile)" ?
If you need parameterless accessors, i'd just add a geometry
::topLeftGeometry()
Cheers,
Thomas
On Tuesday 11 November 2014 17:00:24 Thomas Lübking wrote:
> On Dienstag, 11. November 2014 14:43:56 CEST, Martin Gräßlin wrote:
> >> "BorderSize" - do we *really* want to keep this or rather allow
> >> pixel/pointwise configuration of 2,3, or 4 border sizes globally?
> >
> > could you please expl
On Thursday 06 November 2014 15:14:52 Thomas Lübking wrote:
> decorationshadow.h
> --
> QSize topLeft() etc. etc.:
> a) shadow->topLeft() does not sound like a size
> b) the entire information (9 tiles) can also be provided by two rects
> (innerRect, outerRect) c) with a conv. func.
On Dienstag, 11. November 2014 14:43:56 CEST, Martin Gräßlin wrote:
"BorderSize" - do we *really* want to keep this or rather allow
pixel/pointwise configuration of 2,3, or 4 border sizes globally?
could you please explain your alternative approach? I'm kind of
not getting it and yes I'm also
On Thursday 06 November 2014 15:14:52 Thomas Lübking wrote:
> decoratedclient.h
> --
>
> "maximal available" -> "maximal possible"
Addressed in 389ff3b
> "borderingScreenEdges" -> "adjacentScreenEdges" or "touchedScreenEdges"
Renamed to adjacentScreenEdges:
* kdecoration: f8d114
On Thursday 06 November 2014 15:14:52 Thomas Lübking wrote:
> decorationdefines.h, decorationsettings.h
> -
> "BorderSize" - do we *really* want to keep this or rather allow
> pixel/pointwise configuration of 2,3, or 4 border sizes globally?
could you please
On Thursday 06 November 2014 13:31:57 Thomas Lübking wrote:
> decoration.h
> -
> borderLeft|Right|Bottom|Top
> Use QMargins here as well (they'll usually be required together)?
addressed with:
* kdecoration: f4ab8e4
* kdecoration-viewer: 1a1bbad
* breeze: db43181
* kwin: 1c90ca9
>
>
On Donnerstag, 6. November 2014 15:20:25 CEST, Martin Gräßlin wrote:
property means X11 property? In that case: good suggestion and
clearly useful.
"generic" - I could assume it would work on wayland as well?
But X11 property itfp, yes.
Cheers,
Thomas
On Thursday 06 November 2014 15:14:52 Thomas Lübking wrote:
> decoratedclient.h
> --
>
> "maximal available" -> "maximal possible"
> "borderingScreenEdges" -> "adjacentScreenEdges" or "touchedScreenEdges"
>
> additional request:
> void monitorProperty(const QString &prop, bool ono
decoratedclient.h
--
"maximal available" -> "maximal possible"
"borderingScreenEdges" -> "adjacentScreenEdges" or "touchedScreenEdges"
additional request:
void monitorProperty(const QString &prop, bool onoff);
signals: void propertyChanged(const QString &prop, const QVariant &dat
On Donnerstag, 6. November 2014 13:58:24 CEST, Martin Gräßlin wrote:
It's the "titleBarRect" - buttons and caption. The idea is to
have the backend
know which are is the titlebar, so that it can react on mouse clicks
accordingly. While writing this I realize that it might not be
needed at all
On Thursday 06 November 2014 13:58:24 Martin Gräßlin wrote:
> On Thursday 06 November 2014 13:31:57 Thomas Lübking wrote:
> > "paint"
> > w/o having looked at the paint system, but assuming it operates on
> > translation and clip"region"(rect), maybe explicitly hand the rect for
> > this
> > pass t
On Thursday 06 November 2014 13:31:57 Thomas Lübking wrote:
> decoration.h
> -
> borderLeft|Right|Bottom|Top
> Use QMargins here as well (they'll usually be required together)?
>
> extendedBorder*
> QMargins as well?. Also maybe "resizeOnlyBorder"? (extendedBorder is very
> generic)
w
decoration.h
-
borderLeft|Right|Bottom|Top
Use QMargins here as well (they'll usually be required together)?
extendedBorder*
QMargins as well?. Also maybe "resizeOnlyBorder"? (extendedBorder is very
generic)
"titleRect"
is this "titleBarRect" or "captionRect" - and should the name b
On Tuesday 04 November 2014 13:40:30 Milian Wolff wrote:
> > I'd rather stress "notice that the return value can be nullptr and change
> > during the lifetime of the DecoratedClient".
> >
> > The user can still do
> > Decoration *m_deco = m_client->decoration(); // fails at some point
> >
> > Ove
On Tuesday 04 November 2014 11:53:55 Thomas Lübking wrote:
> On Dienstag, 4. November 2014 10:20:18 CEST, Martin Gräßlin wrote:
> >> DecorationSettings
> >> onAllDesktopsAvailableChanged
> >> -> remove the "on" prefix
> >
> > No, maybe the name is bad, but if the on is removed the meaning
> > chan
On Dienstag, 4. November 2014 10:20:18 CEST, Martin Gräßlin wrote:
DecorationSettings
onAllDesktopsAvailableChanged
-> remove the "on" prefix
No, maybe the name is bad, but if the on is removed the meaning
changes. It's
whether one can put DecoratedClients "on all desktops" (at lest two virtu
On Monday 03 November 2014 23:33:15 Milian Wolff wrote:
> On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote:
> > Hi KDE core developers,
> >
> > today I want to start the review process for the new KDecoration
> > library[1]. This library is intended to replace the window decoration
> > libr
On Monday 03 November 2014 22:29:22 Albert Astals Cid wrote:
> El Divendres, 31 d'octubre de 2014, a les 08:22:53, Martin Gräßlin va
>
> escriure:
> > Hi KDE core developers,
> >
> > today I want to start the review process for the new KDecoration
> > library[1]. This library is intended to repla
On Friday 31 October 2014 08:22:53 Martin Gräßlin wrote:
> Hi KDE core developers,
>
> today I want to start the review process for the new KDecoration library[1].
> This library is intended to replace the window decoration library used by
> KWin and addresses some of the shortcomings we hit with
El Divendres, 31 d'octubre de 2014, a les 08:22:53, Martin Gräßlin va
escriure:
> Hi KDE core developers,
>
> today I want to start the review process for the new KDecoration library[1].
> This library is intended to replace the window decoration library used by
> KWin and addresses some of the s
Hi KDE core developers,
today I want to start the review process for the new KDecoration library[1].
This library is intended to replace the window decoration library used by KWin
and addresses some of the shortcomings we hit with the existing library.
The library is a tier 1 in frameworks spea
47 matches
Mail list logo
