[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: How to get the Project Dashboard right
From: Aleix Pol <aleixpol () kde ! org>
Date: 2010-05-02 13:32:58
Message-ID: n2s757d9a551005020632mf326b66fs54817610df27a778 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, May 2, 2010 at 2:14 PM, David Nolden <zwabel@googlemail.com> wrote:
> 2010/5/2 Aleix Pol <aleixpol@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@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?
[Attachment #5 (text/html)]
<div class="gmail_quote">On Sun, May 2, 2010 at 2:14 PM, David Nolden <span \
dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> 2010/5/2 Aleix Pol <<a \
href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>>:<br> <div class="im">> \
Easily creating floating entities is not an issue, I can create a floating<br> > \
widget in a QGV in 1 minute to, with plasma also and probably with QPainter<br> > \
too. The thing is that we need some platform that:<br> > * is configurable<br>
</div>This is no + point for plasma, as its kind configurability doesn't<br>
suit our purposes, I wouldn't want to see any of the plasma<br>
configuration UIs in KDevelop. We don't need custom themes, we don't<br>
need rotatable/resizable per-pixel movable applets, etc. etc., so you<br>
will have to rewrite the configuration mechanisms \
anyway.<br></blockquote><div><br></div><div>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).</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br>
> * is layouted<br>
> * lets our plugins to put as many things we want<br>
> * Makes it easy to create new items<br>
> * Makes it easy for these items to be flexible<br>
> * Makes it easy to modify and put new data flexibly<br>
><br>
> One good thing I really like about plasma is that it lets us add items that<br>
> doesn't come from a plugin.<br>
><br>
> For example:<br>
> we can have the user to add rss and he adds the rss plasmoid for the project<br>
> and we will get that for free and without adding a kdevelop rss plugin which<br>
> would be weird and the same with anything else. Yes, I know we don't \
want<br> > clocks on the dashboard but I like that we can also put stuff that \
doesn't<br> > depend on kdevelop but just to show. Webview applet is a good \
example too.<br> <br>
</div>But if you want to do anything special to the plasma RSS applet, you<br>
first have to create a painful stable C++ interface between KDevelop<br>
and the applet, and then you end up maintaining it. It may be easy to<br>
get going, but then it becomes complicated, and in future we will<br>
suffer from all the typical problems you have when you integrate a<br>
library that is internally permanently changing (see kate right \
now).<br></blockquote><div><br></div><div>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.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 \
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br>
There should be tons of web RSS applets available that one can put<br>
into a web-page, so why not simply take such one and put it into our<br>
dashboard? I think since the dashboard is a kind of "information<br>
center" for information that comes mainly from the web, web-technology<br>
is the right technology to solve the problem.<br>
<div class="im"><br>
> (according to the plasma+kdepim guy these plasmoids will be moved to kdelibs<br>
> in the near future)<br>
><br>
> Note: if I'm taking all that time discussing about that is because I<br>
> wouldn't really like to decide to do our-thing (tm) and end up by \
finding<br> > all the problems when it's done. It's not like I have any \
special interest<br> > on using Plasma but I want to have something that fits our \
needs now and in<br> > the future for most users.<br>
<br>
</div>There is one more option that seems even preferrable: Why not use<br>
simple Qt widgets? Then any plugin could provide a widget together<br>
with some information, and all the configurability you need is the<br>
place where you stick the widget into a QLayout. Each widget could<br>
then decide whether it wants to use a QWebView for the contents (for<br>
example for RSS), or whether it paints its contents \
natively.<br></blockquote><div><br></div><div>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.</div> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <br>
Greetings, David<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" \
target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br><div>So do you guys all agree that we prefer to \
create smth custom instead of using plasma?</div><div><br></div><div><br></div>
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic