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.
>
12 matches
Mail list logo
