QtScript bindings

[Marco Martin]

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
> http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet
> 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
> facilities
> 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)
> etc.
>
> tjm
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


-- 
Marco Martin