Re: JS Scriptengine in libplasma
Hi it would probably belong in runtime, actually. kdebase/runtime/plasma/javascript? Yes, I'll appreciate this. This allows applications with Applet containers without the need for workspace. Plasma is a great Widget framework not stricly bound to be only usable for desktop environments... Makes sense to me. Although technically we no longer depend on kdebase/runtime (we just required oxygen which moved to kdesupport). technically, all kde apps depend on kdebase-runtime. :) Yes because most of the applets, containments, shells, etc there depend on resources from kdebase-runtime. Only the script engines there are more independed and may be moved further down? Regards, Andy signature.asc Description: OpenPGP digital signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009 07:39:43 Andreas Stricker wrote: Hi it would probably belong in runtime, actually. kdebase/runtime/plasma/javascript? Yes, I'll appreciate this. This allows applications with Applet containers without the need for workspace. Plasma is a great Widget framework not stricly bound to be only usable for desktop environments... Yep, that's my thinking :) Makes sense to me. Although technically we no longer depend on kdebase/runtime (we just required oxygen which moved to kdesupport). technically, all kde apps depend on kdebase-runtime. :) Yes because most of the applets, containments, shells, etc there depend on resources from kdebase-runtime. Only the script engines there are more independed and may be moved further down? Something else that just came up---plasmapkg is in kdebase/workspace as well. Would it make sense to bump that one over too? I ask because that seems to be the way to install scripted plasmoids, and a scriptengine w/out means of installation is a bit weird. Especially as GHNS requires a command-line program to use to install (otherwise given the scriptfile i could call Plasma::Package manually) Another thing about plasmapkg: it would be nice if we could set the ServicePrefix from the commandline, so we can pass it from a GHNS .knsrc. Otherwise i don't see how to tell plasmapkg to install my amarok applet properly. leo - lfran...@kde.orgTufts University 2010 leonardo.fran...@tufts.edu The KDE Project ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Wed, May 6, 2009 at 8:59 PM, Leonardo Franchi lfran...@kde.org wrote: hola folks, so i'm (finally) looking into adding scripted applet/dataengine support to amarok. it's really easy and transparent and all of that (yay plasma!) but we have a minor issue. we depend only on kdelibs, and the scriptengines are in kdebase/workspace. i understand that most of them have external deps, which may be undesirable. Indeed, we'll most likely restrict all applets/engines to being javascript, so as to not require the user to install random *-bindings package. But moving the javascript dataengine to the plasma in kdelibs would really be nice. I agree that the python and ruby script engine bindings have more dependency problems than QScript bindings, and it wouldn't make sense to put them in kdelibs. However, on the other hand, the python and ruby ones are not really equivalent to the QScript bindings in kdebase as they pretty much cover the entire C++ Plasma Applet api, whereas the QScript one covers a simpler minimal api. At one time, in the kde playground module, there was work going on into developing some more complete JavaScript bindings based on the QtJambi parser/code generator. So I wonder if anyone is intending to develop the more complex bindings further? Have we had enough feedback yet to know whether or not the simpler bindings are sufficient for what most people want to do? -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009 11:48:48 Richard Dale wrote: On Wed, May 6, 2009 at 8:59 PM, Leonardo Franchi lfran...@kde.org wrote: hola folks, so i'm (finally) looking into adding scripted applet/dataengine support to amarok. it's really easy and transparent and all of that (yay plasma!) but we have a minor issue. we depend only on kdelibs, and the scriptengines are in kdebase/workspace. i understand that most of them have external deps, which may be undesirable. Indeed, we'll most likely restrict all applets/engines to being javascript, so as to not require the user to install random *-bindings package. But moving the javascript dataengine to the plasma in kdelibs would really be nice. I agree that the python and ruby script engine bindings have more dependency problems than QScript bindings, and it wouldn't make sense to put them in kdelibs. However, on the other hand, the python and ruby ones are not really equivalent to the QScript bindings in kdebase as they pretty much cover the entire C++ Plasma Applet api, whereas the QScript one covers a simpler minimal api. At one time, in the kde playground module, there was work going on into developing some more complete JavaScript bindings based on the QtJambi parser/code generator. So I wonder if anyone is intending to develop the more complex bindings further? Have we had enough feedback yet to know whether or not the simpler bindings are sufficient for what most people want to do? Ah, I wasn't aware that the JS bindings aren't full bindings like the Ruby or Python ones. In amarok 2 we decided to limit all scripts two javascript/qtscript in order to a) avoid the mess of having scripts require certain *-qt4/kde4 bindings, which lead to users not being able to install them, and b) with the qtscriptgenerator bindings we get for free a full set of qt bindings. We then expose an additional qtscript API for amarok. We will most likely limit scripted amarok applets to qtscript as well. What sort of limitations do the JS bindings have? leo - lfran...@kde.orgTufts University 2010 leonardo.fran...@tufts.edu The KDE Project ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009, Leonardo Franchi wrote: On Thursday 07 May 2009 11:48:48 Richard Dale wrote: On Wed, May 6, 2009 at 8:59 PM, Leonardo Franchi lfran...@kde.org wrote: hola folks, so i'm (finally) looking into adding scripted applet/dataengine support to amarok. it's really easy and transparent and all of that (yay plasma!) but we have a minor issue. we depend only on kdelibs, and the scriptengines are in kdebase/workspace. i understand that most of them have external deps, which may be undesirable. Indeed, we'll most likely restrict all applets/engines to being javascript, so as to not require the user to install random *-bindings package. But moving the javascript dataengine to the plasma in kdelibs would really be nice. I agree that the python and ruby script engine bindings have more dependency problems than QScript bindings, and it wouldn't make sense to put them in kdelibs. However, on the other hand, the python and ruby ones are not really equivalent to the QScript bindings in kdebase as they pretty much cover the entire C++ Plasma Applet api, whereas the QScript one covers a simpler minimal api. At one time, in the kde playground module, there was work going on into developing some more complete JavaScript bindings based on the QtJambi parser/code generator. So I wonder if anyone is intending to develop the more complex bindings further? Have we had enough feedback yet to know whether or not the simpler bindings are sufficient for what most people want to do? Ah, I wasn't aware that the JS bindings aren't full bindings like the Ruby or Python ones. In amarok 2 we decided to limit all scripts two javascript/qtscript in order to a) avoid the mess of having scripts require certain *-qt4/kde4 bindings, which lead to users not being able to install them, and b) with the qtscriptgenerator bindings we get for free a full set of qt bindings. We then expose an additional qtscript API for amarok. We will most likely limit scripted amarok applets to qtscript as well. What sort of limitations do the JS bindings have? you have access only to methods decalred as Q_PROPERTY or Q_INVOKABLE all the plasma widgets export as properties most of their functionality but not nativeWidget() (so it's not accessible the full api of the underlying qwidget) leo - lfran...@kde.org Tufts University 2010 leonardo.fran...@tufts.edu The KDE Project ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thu, May 7, 2009 at 12:26 PM, Marco Martin notm...@gmail.com wrote: On Thursday 07 May 2009, Leonardo Franchi wrote: On Thursday 07 May 2009 11:48:48 Richard Dale wrote: On Wed, May 6, 2009 at 8:59 PM, Leonardo Franchi lfran...@kde.org wrote: hola folks, so i'm (finally) looking into adding scripted applet/dataengine support to amarok. it's really easy and transparent and all of that (yay plasma!) but we have a minor issue. we depend only on kdelibs, and the scriptengines are in kdebase/workspace. i understand that most of them have external deps, which may be undesirable. Indeed, we'll most likely restrict all applets/engines to being javascript, so as to not require the user to install random *-bindings package. But moving the javascript dataengine to the plasma in kdelibs would really be nice. I agree that the python and ruby script engine bindings have more dependency problems than QScript bindings, and it wouldn't make sense to put them in kdelibs. However, on the other hand, the python and ruby ones are not really equivalent to the QScript bindings in kdebase as they pretty much cover the entire C++ Plasma Applet api, whereas the QScript one covers a simpler minimal api. At one time, in the kde playground module, there was work going on into developing some more complete JavaScript bindings based on the QtJambi parser/code generator. So I wonder if anyone is intending to develop the more complex bindings further? Have we had enough feedback yet to know whether or not the simpler bindings are sufficient for what most people want to do? Ah, I wasn't aware that the JS bindings aren't full bindings like the Ruby or Python ones. In amarok 2 we decided to limit all scripts two javascript/qtscript in order to a) avoid the mess of having scripts require certain *-qt4/kde4 bindings, which lead to users not being able to install them, and b) with the qtscriptgenerator bindings we get for free a full set of qt bindings. We then expose an additional qtscript API for amarok. We will most likely limit scripted amarok applets to qtscript as well. What sort of limitations do the JS bindings have? you have access only to methods decalred as Q_PROPERTY or Q_INVOKABLE all the plasma widgets export as properties most of their functionality but not nativeWidget() (so it's not accessible the full api of the underlying qwidget) Can you create Plasma widgets though? Maybe I'm completely missing something, but looking at the code I can only see a reference to a Plasma VideoWidget being created, along with loading things from a .ui file at runtime. Is it possible to have Plasma widgets in a .ui file? -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009, Leonardo Franchi wrote: Yes because most of the applets, containments, shells, etc there depend on resources from kdebase-runtime. Only the script engines there are more independed and may be moved further down? Something else that just came up---plasmapkg is in kdebase/workspace as well. Would it make sense to bump that one over too? I ask because that good point; yes, that should probably move over as well. Another thing about plasmapkg: it would be nice if we could set the ServicePrefix from the commandline, so we can pass it from a GHNS .knsrc. Otherwise i don't see how to tell plasmapkg to install my amarok applet properly. makes sense. want to try a patch? :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009, Andreas Stricker wrote: Only the script engines there are more independed and may be moved further down? the ScriptEngine plugin is a runtime dependency, not a build time dependency. moreover, kdebase-runtime is, by policy, a required dependency to use any application that links against kdelibs. so it belongs in runtime. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: FIXME part of quicklaunch
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/649/ --- (Updated 2009-05-07 08:56:57.415417) Review request for Plasma and Aaron Seigo. Changes --- I did indentation for the code. And its working :) Summary --- This patch is regarding the FIXME part of the quicklaunchApplet.cpp. I had added one more method named dropApp. Added the processDrop as per Aaron seigo. Diffs (updated) - trunk/KDE/kdebase/workspace/plasma/applets/quicklaunch/quicklaunchApplet.h 964135 trunk/KDE/kdebase/workspace/plasma/applets/quicklaunch/quicklaunchApplet.cpp 964135 Diff: http://reviewboard.kde.org/r/649/diff Testing --- Done basic testing and it works. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009, Richard Dale wrote: Can you create Plasma widgets though? yes, several of the examples in scriptengines/javascript/tests/ do just that. Is it possible to have Plasma widgets in a .ui file? that hasn't been added yet, no. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009, Richard Dale wrote: I agree that the python and ruby script engine bindings have more dependency problems than QScript bindings, and it wouldn't make sense to put them in kdelibs. well, none of the ScriptEngines are going to move to kdelibs. they are runtime deps, not build time debs. i'd have not particular issue with the ruby and python ScriptEngines also moving to runtime, though that probably puts an even greater maintenance requirement on them. the web, google gadgets, macos and edje scriptengines should remain in workspace imho. there was work going on into developing some more complete JavaScript bindings based on the QtJambi parser/code generator. So I wonder if anyone is intending to develop the more complex bindings further? that's the idea; unfortunately it seems rather difficult to keep people interested in doing bindings and it's really not my forte either. Have we had enough feedback yet to know whether or not the simpler bindings are sufficient for what most people want to do? they are sufficient for most of what i need to do, but they certainly do not cover all use cases by a long shot. the idea was always to offer a full API alongside the simplified one. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thursday 07 May 2009 16:52:10 Aaron J. Seigo wrote: On Thursday 07 May 2009, Leonardo Franchi wrote: Yes because most of the applets, containments, shells, etc there depend on resources from kdebase-runtime. Only the script engines there are more independed and may be moved further down? Something else that just came up---plasmapkg is in kdebase/workspace as well. Would it make sense to bump that one over too? I ask because that good point; yes, that should probably move over as well. Another thing about plasmapkg: it would be nice if we could set the ServicePrefix from the commandline, so we can pass it from a GHNS .knsrc. Otherwise i don't see how to tell plasmapkg to install my amarok applet properly. makes sense. want to try a patch? :) I think i'm actually going to be doing it in-code for now, at least that way we don't have to wait till we can depend on 4.3. but i will also patch it up when i get a chance. leo - lfran...@kde.orgTufts University 2010 leonardo.fran...@tufts.edu The KDE Project ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bug in the python bindings? [was: Plasma crashing with QGraphicsLinearLayout.addStretch]
Aaron J. Seigo wrote: On Wednesday 06 May 2009, Johannes Wolter wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb3db9720 (LWP 11622)] 0xb741e737 in QGraphicsLayoutItem::isLayout () from /usr/lib/libQtGui.so.4 (gdb) bt #0 0xb741e737 in QGraphicsLayoutItem::isLayout () from /usr/lib/libQtGui.so.4 #1 0xa85debf1 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #2 0xa8b60bdd in PyCFunction_Call (func=0xa7078a6c, arg=0xa772a48c, kw=0x0) at ../Objects/methodobject.c:73 #3 0xa8bb2f09 in PyEval_EvalFrameEx (f=0x846620c, throwflag=0) at ../Python/ceval.c:3612 #4 0xa8bb3e3f in looks like a bug in the python bindings, perhaps? Can anyone give me a hint how to debug this problem? From the backtrace it looks like the bindings are generated via SIP, which I'm not familiar with. (others on the list: note that Johannes is not sub'd to the list and so would probably appreciate being kept in the CC's) Now I am. Thanks for any suggestion, Johannes -- Johannes Wolter Cognitive Neuroinformatics, University of Bremen http://www.informatik.uni-bremen.de/cog_neuroinf/ Office: Cartesium 04.051 Phone: +49(0)421-218-64218 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: JS Scriptengine in libplasma
On Thu, May 7, 2009 at 4:56 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday 07 May 2009, Richard Dale wrote: Can you create Plasma widgets though? yes, several of the examples in scriptengines/javascript/tests/ do just that. Ah yes, sorry I've found the code now in uiloader.cpp - I had thought that was to do with loading ui files, and not instantiating Plasma widgets. BTW: In Qt 4.5 (and Qt 4.5.1 onwards with namespaced classes like Plasma:: ones), you can add 'Q_INVOKABLE' to constructors, which might simplify QScript bindings as you only need to register the class and you get a pretty much complete binding. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Device Notifier - Western Digital USB drive not recognised
On Wednesday 06 May 2009 18:24:34 Mr Fixit wrote: I'm not sure if this is an openSUSE problem or a KDE4 problem, so please excuse me if I have posted in the wrong area. Since I updated to KDE4.2.2 my external USB drive no longer shows up in device notifier when I plug it in. CDs and other USB memory sticks work perfectly, but not my USB drive. The drive appears in Dolphin's list, and once I have clicked on it in Dolphin and entered the LUKS password, it then appears in the device notifier list. The drive has only 1 partition, it is an encrypted (LUKS) Reiser partition if that makes any difference. Another odd thing is that the drive automatically unmounts itself after use, ie I watch a movie from the drive, then when the movie is finished, the drive is automatically unmounted. Even though I still have an open Dolphin window on the drive. The device notifier plasmoid functioned normally before I updated from KDE 4.1 to 4.2.2. Please file a bug on bugs.kde.org. The fact that you're using LUKS is probably more important than the brand (or do other LUKS encrypted device not show this problem?). -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
