On Tuesday 22 January 2013 15:24:55 Michail Vourlakos wrote:
> Στις 21/01/2013 01:57 μμ, ο/η Aaron J. Seigo έγραψε:
> > On Monday, January 21, 2013 12:37:43 Martin Graesslin wrote:
> >> The logic to determine the size of the thumbnail is not very difficult.
> >> We
> >> could provide a QML item (ou
Στις 21/01/2013 01:57 μμ, ο/η Aaron J. Seigo έγραψε:
On Monday, January 21, 2013 12:37:43 Martin Graesslin wrote:
The logic to determine the size of the thumbnail is not very difficult. We
could provide a QML item (outside KWin) which has the same algorithm
implemented and annotate code in KWin
On Monday 21 January 2013 12:52:07 Marco Martin wrote:
> On Monday 21 January 2013, Martin Graesslin wrote:
> > > in QML terms, the perfect solution would be an item than knows the
> > > geometry of the thumbnail it will be rendering, and then all of the
> > > above problems go away.
> > >
> > > b
On Monday, January 21, 2013 12:37:43 Martin Graesslin wrote:
> The logic to determine the size of the thumbnail is not very difficult. We
> could provide a QML item (outside KWin) which has the same algorithm
> implemented and annotate code in KWin and the item to keep it in sync.
sounds good .. i
On Monday 21 January 2013, Martin Graesslin wrote:
> > in QML terms, the perfect solution would be an item than knows the
> > geometry of the thumbnail it will be rendering, and then all of the
> > above problems go away.
> >
> > but if that QML item is not in kwin (something that should be avoide
On Monday 21 January 2013 12:03:54 Aaron J. Seigo wrote:
> On Thursday, January 17, 2013 08:04:14 Martin Gräßlin wrote:
> > So my suggestion is to send updates for needed thumbnails together with
> > the
> > damage events. We have to look into how we can achieve it, but it would
> > bring some adva
On Thursday, January 17, 2013 08:04:14 Martin Gräßlin wrote:
> So my suggestion is to send updates for needed thumbnails together with the
> damage events. We have to look into how we can achieve it, but it would
> bring some advantages:
> * existing code path inside KWin can be reused
> * thumbnai
I have thought about it a little bit more. What you actually want is having
the UI completely in one place. You don't want to have the thumbnails, you
want to be able to render/implement the UI in a way as if you have the
thumbnails. Passing the thumbnails from KWin to Plasma is one possible way
On Wednesday, January 16, 2013 15:22:10 Martin Gräßlin wrote:
> On Wednesday 16 January 2013 14:12:16 Aaron J. Seigo wrote:
> > On Wednesday, January 16, 2013 13:11:35 Martin Gräßlin wrote:
> > > On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> > > * providing the thumbnail s
On Wednesday 16 January 2013 14:12:16 Aaron J. Seigo wrote:
> On Wednesday, January 16, 2013 13:11:35 Martin Gräßlin wrote:
> > On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> > there have been more reasons to do it that way. One is that only KWin has
> > information to the most recen
On Wednesday, January 16, 2013 13:11:35 Martin Gräßlin wrote:
> On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> there have been more reasons to do it that way. One is that only KWin has
> information to the most recently used windows.
you mean that it is the only process that current
On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> hi all ...
>
> currently, whenever there is a window thumbnail on screen, kwin paints it.
> on plasma desktop, this is currently not a big problem for our default
> setup since we only use them in tooltips on window listing plasmoids.
>
hi all ...
currently, whenever there is a window thumbnail on screen, kwin paints it. on
plasma desktop, this is currently not a big problem for our default setup
since we only use them in tooltips on window listing plasmoids.
in Active, it has been and continues to be more problematic. this is
13 matches
Mail list logo
