notmart at gmail.com
Tue Sep 15 10:57:23 CEST 2009
On Tuesday 15 September 2009, Tommi Mikkonen wrote:
> Aaron J. Seigo wrote:
> > Frame is not a QFrame, it's a Plasma::Frame.
> > WebView is not a QWebView, it's a Plasma::WebView.
> Ok, accepted; the problem is that I'm aiming at porting
> from QtScript to Plasma, and this is one of the things where
> I constantly make mistakes. Can I create a QFrame inside a
> plasmoid then? Or should I always use Plasma Frame?
> Moreover, is there real difference to the developer which
> widget is being created, or is this just a matter of which
> API has been opened?
> How about LinearLayout? According to
> it constructs a QGraphicsLinearLayout, but is this
> really a Plasma item, too?
simply a QGraphicsLinearLayout, we don't have qgraphicslayout subclasses in
the api at the moment
> > any suggestions for getting enums into the JS namsepace?
> Not at present; I think that we will have to live with
> the stuff where we have made the binding.
> > yes, there isn't a nice debugging system yet..
> Qt Script comes with a nice debugger, so moving to that environment
> will introduce improved capabilities automatically. Of course, the
> will not be available if there are other VMs that are used as well.
> > i'm not so sure. learning the difference between Plasma::WebView and
> > WebView, depending on the script bindings used, is probably pretty
> > nominal compared to becoming acquainted with the entire Qt API.
> As I'm currently aiming at porting QtScript apps to Plasmoid,
> I'd like to get as much access to Qt as possible. Probably this is not
> a typical situation, but for me there has been a lot of problems with
> Qt widgets vs. Plasma widgets and things that are not available
> in the latter. But you are right, to someone who is new to the
> entire system things can be different.
the api of plasma widget is limited to protect the simple js bindings, in the
full ones there could be the access to nativeWidget() i suppose, so they could
have the full api of the underlying embedded qwidget
> > also note that the simple applet JS bindings do not bind the entire API
> > of all the classes offered, either.
> I've noticed. What's the reason of offering these particular
> classes? Has there been a particular set of apps in mind? I've
> tried porting a number of Lively apps, and the ones that would
> fit the layouting idea run to a dead end since they would like to
> use the web, and the standalone apps on the other hand would
> need access to QColor, QPolygon (our first real demo, Asteroids)
> Plasma-devel mailing list
> Plasma-devel at kde.org
More information about the Plasma-devel