[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: The tooltip state. Not that good. Proposal for improvement.
From: Mark <markg85 () gmail ! com>
Date: 2012-05-29 11:53:47
Message-ID: CAPd6JnGppvkyxZVEbiHkJ4kvOKQO1ehq66NEsGJ2JLPp9XYmOQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, May 29, 2012 at 1:16 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Tuesday, May 29, 2012 10:28:20 Mark wrote:
> > On Mon, May 28, 2012 at 12:34 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
> > > On Sunday, May 27, 2012 21:15:30 Mark wrote:
> > > > You perhaps made the mental leap, for met it's still "KDE" without
> the
> > >
> > > SC.
> > >
> > > > It's just the way people call KDE and that sticks. the SC seems like
> > > > some
> > > > expra part that people don't seem to remember.
> > >
> > > "SC" is part of the engineering jargon we use: it's the combined
> release
> > > of
> > > lots of separate modules. we don't use that term in public
> communication
> > > ("marketing", etc) and there's a reason for that.
> > >
> > > regardless, what i said had nothing at all to do with the SC, but
> rather
> > > about
> > > the technical design of the code base and where the lines of separation
> > > exist.
> > >
> > > for those of us working on the technology, it's really important to
> > > understand
> > > the separation between the libraries, workspaces and applications
> because
> > > that
> > > affects the technical decisons we allow ourselves to make.
> > >
> > > --
> > > Aaron J. Seigo
> > > _______________________________________________
> > > Plasma-devel mailing list
> > > Plasma-devel@kde.org
> > > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> > This tooltip stuff just got a whole lot more complicated. I asked Martin
> > (added to cc) for information about the window previews in QML. The
> reply i
>
> this is why we do things on public mailing lists instead of N different
> private
> threads. it makes it much more difficult to work together on things.
>
> > Yeah, he wants to move tooltips to KWin!
>
> yes, this is Martin's current set of ideas: move everything to the window
> manager.
>
> i disagree and think it is a horrible idea for reasons i've explained
> elsewhere.
>
That's going to be a nice battle between you two at Akademy ;-)
>
> > So how is this going to work if it's in KWin?
> > How will this be put in a library if the tooltips depend on KWin.. Surely
> > it's not the intention to let Dolphin depend on KWin for the tooltips?
>
> well, yes, this is one reason what Martin suggested makes no sense. it's
> also
> completely irrelevant to the current task of separating out tooltips, so i
> don't think you need to worry about it. we have a working system right now
> for
> window previews. and yes, it relies on a compositer running, but that is a
> rutnime dependency ..
>
> for the task of creating a set of sharable tooltip classes, don't worry
> about
> reinventing the window preview code. there will be C++ involved, and that
> C++
> can import an object into the QML that gives access to requesting window
> previews at a certain place in the tooltip (e.g. a new QML Item called
> WindowPreview that is actually a C++ class which handles all the previewing
> goodies; the QML would just create one or more of these WindowPreview
> objects
> and ensure they are placed correctly).
>
Ahh oke, i get it.
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:
http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets-cpp.html
or
if it doesn't work i can always put a big red squared stub in it as
placeholder ^_-
>
> from there, we'll see how nicely the current system works for this (we know
> from Plasma Active where we will run into challenges) and then we can start
> working on a reasonable solution for them if we need to (the current system
> may turn out to be good enough for now for plasma desktop).
>
> and please, keep discussion on the mailing list.
>
>
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.
Thank you for the clarification
> --
> Aaron J. Seigo
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
[Attachment #5 (text/html)]
<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-qwi \
dgets-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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic