The tooltip state. Not that good. Proposal for improvement.

Mark markg85 at gmail.com
Tue May 29 11:53:47 UTC 2012


On Tue, May 29, 2012 at 1:16 PM, Aaron J. Seigo <aseigo at 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 at 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 at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120529/689ad0e2/attachment.html>


More information about the Plasma-devel mailing list