<div class="gmail_quote">On Tue, May 29, 2012 at 1:16 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tuesday, May 29, 2012 10:28:20 Mark wrote:<br>
> On Mon, May 28, 2012 at 12:34 AM, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>
> > On Sunday, May 27, 2012 21:15:30 Mark wrote:<br>
> > > You perhaps made the mental leap, for met it's still "KDE" without the<br>
> ><br>
> > SC.<br>
> ><br>
> > > It's just the way people call KDE and that sticks. the SC seems like<br>
> > > some<br>
> > > expra part that people don't seem to remember.<br>
> ><br>
> > "SC" is part of the engineering jargon we use: it's the combined release<br>
> > of<br>
> > lots of separate modules. we don't use that term in public communication<br>
> > ("marketing", etc) and there's a reason for that.<br>
> ><br>
> > regardless, what i said had nothing at all to do with the SC, but rather<br>
> > about<br>
> > the technical design of the code base and where the lines of separation<br>
> > exist.<br>
> ><br>
> > for those of us working on the technology, it's really important to<br>
> > understand<br>
> > the separation between the libraries, workspaces and applications because<br>
> > that<br>
> > affects the technical decisons we allow ourselves to make.<br>
> ><br>
> > --<br>
> > Aaron J. Seigo<br>
> > _______________________________________________<br>
> > Plasma-devel mailing list<br>
> > <a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
><br>
> This tooltip stuff just got a whole lot more complicated. I asked Martin<br>
> (added to cc) for information about the window previews in QML. The reply i<br>
<br>
</div></div>this is why we do things on public mailing lists instead of N different private<br>
threads. it makes it much more difficult to work together on things.<br>
<div class="im"><br>
> Yeah, he wants to move tooltips to KWin!<br>
<br>
</div>yes, this is Martin's current set of ideas: move everything to the window<br>
manager.<br>
<br>
i disagree and think it is a horrible idea for reasons i've explained<br>
elsewhere.<br></blockquote><div><br></div><div>That's going to be a nice battle between you two at Akademy ;-) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> So how is this going to work if it's in KWin?<br>
> How will this be put in a library if the tooltips depend on KWin.. Surely<br>
> it's not the intention to let Dolphin depend on KWin for the tooltips?<br>
<br>
</div>well, yes, this is one reason what Martin suggested makes no sense. it's also<br>
completely irrelevant to the current task of separating out tooltips, so i<br>
don't think you need to worry about it. we have a working system right now for<br>
window previews. and yes, it relies on a compositer running, but that is a<br>
rutnime dependency ..<br>
<br>
for the task of creating a set of sharable tooltip classes, don't worry about<br>
reinventing the window preview code. there will be C++ involved, and that C++<br>
can import an object into the QML that gives access to requesting window<br>
previews at a certain place in the tooltip (e.g. a new QML Item called<br>
WindowPreview that is actually a C++ class which handles all the previewing<br>
goodies; the QML would just create one or more of these WindowPreview objects<br>
and ensure they are placed correctly).<br></blockquote><div><br></div><div>Ahh oke, i get it.</div><div>For the moment i can even try to use a QGraphicsProxyWidget and just send WindowPreview to QML. It actually seems fairly easy to do as described here: <a href="http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets-cpp.html">http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets-cpp.html</a> or if it doesn't work i can always put a big red squared stub in it as placeholder ^_-</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
from there, we'll see how nicely the current system works for this (we know<br>
from Plasma Active where we will run into challenges) and then we can start<br>
working on a reasonable solution for them if we need to (the current system<br>
may turn out to be good enough for now for plasma desktop).<br>
<br>
and please, keep discussion on the mailing list.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>It does seem like this will be useful anyway and just one small part that is problematic (window previews) so I'll continue with it and get it working.</div>
<div><br></div><div>Thank you for the clarification </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Aaron J. Seigo</font></span><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>