How to get the Project Dashboard right

[Aleix Pol]

On Sun, May 2, 2010 at 2:14 PM, David Nolden <zwabel at googlemail.com> wrote:

> 2010/5/2 Aleix Pol <aleixpol at kde.org>:
> > Easily creating floating entities is not an issue, I can create a
> floating
> > widget in a QGV in 1 minute to, with plasma also and probably with
> QPainter
> > too. The thing is that we need some platform that:
> > * is configurable
> This is no + point for plasma, as its kind configurability doesn't
> suit our purposes, I wouldn't want to see any of the plasma
> configuration UIs in KDevelop. We don't need custom themes, we don't
> need rotatable/resizable per-pixel movable applets, etc. etc., so you
> will have to rewrite the configuration mechanisms anyway.
>

The plasma we would be integrating would have a two-column layout, as you
can see in the plasma netbook interface. We don't need custom themes but the
user might want to give it a look similar to the project branding so here
changeability is a plus (here probably plasma is too much, agree).


>
> > * is layouted
> > * lets our plugins to put as many things we want
> > * Makes it easy to create new items
> > * Makes it easy for these items to be flexible
> > * Makes it easy to modify and put new data flexibly
> >
> > One good thing I really like about plasma is that it lets us add items
> that
> > doesn't come from a plugin.
> >
> > For example:
> > we can have the user to add rss and he adds the rss plasmoid for the
> project
> > and we will get that for free and without adding a kdevelop rss plugin
> which
> > would be weird and the same with anything else. Yes, I know we don't want
> > clocks on the dashboard but I like that we can also put stuff that
> doesn't
> > depend on kdevelop but just to show. Webview applet is a good example
> too.
>
> But if you want to do anything special to the plasma RSS applet, you
> first have to create a painful stable C++ interface between KDevelop
> and the applet, and then you end up maintaining it. It may be easy to
> get going, but then it becomes complicated, and in future we will
> suffer from all the typical problems you have when you integrate a
> library that is internally permanently changing (see kate right now).
>

In that case we will have to assume that we won't want to interact with the
non-kdevelop plasmoids from KDevelop. Or more precisely, only who creates
the Plasma::Applet* and the instance itself will define what's in it.


>
> There should be tons of web RSS applets available that one can put
> into a web-page, so why not simply take such one and put it into our
> dashboard? I think since the dashboard is a kind of "information
> center" for information that comes mainly from the web, web-technology
> is the right technology to solve the problem.
>
> > (according to the plasma+kdepim guy these plasmoids will be moved to
> kdelibs
> > in the near future)
> >
> > Note: if I'm taking all that time discussing about that is because I
> > wouldn't really like to decide to do our-thing (tm) and end up by finding
> > all the problems when it's done. It's not like I have any special
> interest
> > on using Plasma but I want to have something that fits our needs now and
> in
> > the future for most users.
>
> There is one more option that seems even preferrable: Why not use
> simple Qt widgets? Then any plugin could provide a widget together
> with some information, and all the configurability you need is the
> place where you stick the widget into a QLayout. Each widget could
> then decide whether it wants to use a QWebView for the contents (for
> example for RSS), or whether it paints its contents natively.
>

I've though about that, and I think it's a good approach in fact. It's the
same as the QGV case though but using QGraphicsLayout or QLayout, both in
problems and advantages.

>
> Greetings, David
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

So do you guys all agree that we prefer to create smth custom instead of
using plasma?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100502/a6aa2cf0/attachment.html>