[Panel-devel] Kickoff / KDE 4

[Robert Knight]

> a fair amount of work indeed. *sigh*

Which is why I implemented the view classes with QWidgets.  I have a
limited amount of time for this so I put together a solution which has
a clearly separated model/view setup and then used QAbstractItemView
as a base for the view classes.

The item delegate only requires a QModelIndex and a QPainter to draw
with so that can be re-used in a widget-less view setup, as can most
of the logic in launcher.cpp

> so to make this really work we'd need to
> create something like a QGraphicsModelViewItem ;)

The question there is who is "we"?  I should point out that
qabstractitemview.cpp/.h total over 4000 lines of code.  Duplicating
that functionality, including important details such as the
accessibility support would take time.  I don't know whether the
Trolls' widgets-on-canvas plans include an item view, but if so that
would seem a much easier long term solution.

> in the meantime, the Quick Route is to make a button that pops up a top level
> window at the correct screen coordinates showing the widget.

That is what I had in mind.

> i'm not sure AbstractRunner is what is needed there, to be honest. it may make
> more sense (from a use case perspective) to simply speak xesam.

Okay, perhaps it would help if I clarify the sort of things that need
to be listed when a search is performed:

- Applications
- Places ( Bookmarks, Recently Used etc. )
- Documents
- Contacts
- Communication (Email, IRC logs etc.)
- Basic utilities (Calculator)

Documents and Communication are covered by Strigi (XESAM) in the short
term.  Applications and Places are probably the most important missing
items on that list which I don't think Strigi covers.  One option that
occurred to me would be for the Kickoff launcher to talk to KRunner
over D-Bus to get some of these additional results.

Regards,
Robert.


On 25/09/2007, Jon de Andrés <jondeandres at gmail.com> wrote:
> El Tuesday 25 September 2007 00:20:24 Aaron J. Seigo escribió:
> > On Monday 24 September 2007, Robert Knight wrote:
> > > As discussed at the last Plasma IRC meeting, I started work on a new
> > > Kickoff implementation using Qt 4 / KDE 4 frameworks.  The new
> > > implementation is currently functional (but not complete) with the
> > > exception of the search view.
> >
> > aha! awesome! i just checked it out and will be playing with it later
> today
> >
> > > * Integrating this with the desktop so that it can be launched by
> > > pressing a panel button
> >
> > i just looked and it's still all qwidgets. this REALLY needs to be ported
> > to QGraphicsItems. we can get away with it being qwidgets if absolutely
> > required for 4.0, but it will make showing it on the desktop not possible
> > (without some stupid hacks that i'm really not prepared to do).
> >
> > of course, it uses QAbstractItemModel fairly extensively. and
> > QAbstractItemView IsA QWidget, so to make this really work we'd need to
> > create something like a QGraphicsModelViewItem ;) which would connect to
> > the various signals from QAbstractItemModel to show things.
>
> I've talked many times with Rafael about the idea of develop a new class for
> plasma to connect to a Model from Qt. We think that's really necessary in
> order to port kuiserver to Plasma. It's a bit offtopic, but i thought we
> could use SVG if a PlasmaView is not developed.
>
> Anyway, since we can see it's necessary for other applets, kget for example,
> we could talk about the ideas for making the QGraphicsModelViewItem, or
> similar. In playground/base/plasma/widgets/listwidget/ Tim Beaulen has
> started a ListWidget for plasma. In the TODO and other notes I can read that
> the idea is to behave like a QListWidget, perhaps this is interesting for
> the
> topic.
>
> If you think i can help in anything about this, please tell me.
>
> Bye!
>
> >
> > a fair amount of work indeed. *sigh*
> >
> > in the meantime, the Quick Route is to make a button that pops up a top
> > level window at the correct screen coordinates showing the widget. we can
> > port things from there as time permits and the user should hopefully not
> > notice as we do so, aside from the components actually working properly on
> > the desktop (e.g. on the desktop, it shouldn't show the button you click
> > but actually show the entire interface)
> >
> > > * Making use of the KRunner 'runners' in the search view to avoid
> > > duplication there.
> >
> > i'm not sure AbstractRunner is what is needed there, to be honest. it may
> > make more sense (from a use case perspective) to simply speak xesam.
> >
> > > * Artwork.  The current code is missing the custom tab styling that
> > > Kickoff/KDE 3 had.  If the artists are interested, then we ought to
> > > discuss the aesthetics with them.
> >
> > yes, we can easily do that.
>
>
>
> --
> Jon de Andrés Frías
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>