Re: Need a couple of volunteers (was: Re: TokamakIV update)
[...snippet ant top posting..] Sorry hehe :) I was away for the last week. Right now I'm in US for camp kde (arriving san diego tomorrow...) Yes, I plan to work with Alexis in Oslo and it's going to be wonderful to work during tokamak with the oxygen team ;) See you at camp kde! Cheers! On Thu, Jan 14, 2010 at 3:30 AM, Kevin Ottens er...@kde.org wrote: On Wednesday 13 January 2010 23:39:33 Marco Martin wrote: last time i tried i was a bit lost on broken dependencies in the packaged qt themselves (hope it's fixed by now?) and mysql, that's a bit a brutal dependency in this context, but exterminating all the pim related stuff from the build doesn't seem pretty nice as well :) On the maemo side it's being worked on ATM. Right now the mysql issues are getting solved (if everything goes well fixes will get in the upstream qt- maemo) even though depending on mysql is a temporary measure to enable everyone to start working on those platforms. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- --- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia --- Blog: http://labs.morpheuz.eng.br/blog/ PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma.include() and member visibility
Hmm, maybe the feature
(exposing the included variables and functions) is just not available.
But IMHO it should be, shouldn't it? Otherwise, there's no much point in
including a file (its use gets veeery limited).
Open a bug report, then?
--
J (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
Amos Kariuki
___
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: Review Request: Add support for Opera Bookmarks in the Bookmarks Runner.
On 2010-01-10 18:39:48, Marco Martin wrote: to me more things supported the better. plus opera bookmarks are quite simple so it doesn't add too much burden Do you mind if I'm going to refactor the code a bit as a next patch? It's a little bit messy with all the switch statements. Instead, every browser specific part could be moved into a new class, and the main class could delegates to one of them. - klebezettel --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2539/#review3637 --- On 2010-01-10 16:14:55, klebezettel wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2539/ --- (Updated 2010-01-10 16:14:55) Review request for Plasma. Summary --- This adds support for Opera Bookmarks in the bookmarks runner. Basically it just reads ~/.opera/bookmarks.adr on a prepare() signal and searches for something matching if match() is called. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/runners/bookmarks/bookmarksrunner.cpp 1072641 trunk/KDE/kdebase/workspace/plasma/generic/runners/bookmarks/bookmarksrunner.h 1072641 Diff: http://reviewboard.kde.org/r/2539/diff Testing --- Test with my opera bookmarks. Thanks, klebezettel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add support for Opera Bookmarks in the Bookmarks Runner.
On 2010-01-10 18:39:48, Marco Martin wrote: to me more things supported the better. plus opera bookmarks are quite simple so it doesn't add too much burden klebezettel wrote: Do you mind if I'm going to refactor the code a bit as a next patch? It's a little bit messy with all the switch statements. Instead, every browser specific part could be moved into a new class, and the main class could delegates to one of them. seems like a very good idea to me :) - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2539/#review3637 --- On 2010-01-10 16:14:55, klebezettel wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2539/ --- (Updated 2010-01-10 16:14:55) Review request for Plasma. Summary --- This adds support for Opera Bookmarks in the bookmarks runner. Basically it just reads ~/.opera/bookmarks.adr on a prepare() signal and searches for something matching if match() is called. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/runners/bookmarks/bookmarksrunner.cpp 1072641 trunk/KDE/kdebase/workspace/plasma/generic/runners/bookmarks/bookmarksrunner.h 1072641 Diff: http://reviewboard.kde.org/r/2539/diff Testing --- Test with my opera bookmarks. Thanks, klebezettel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: a way for a custom corona to forbid some standard context menu entries
On 2010-01-14 18:18:26, Chani Armitage wrote: :/ this feels wrong. for the screensaver, I just created a separate mouse plugin. I suppose the netbook shares actions like log out and lock screen though, which makes this a bit trickier... we don't really want to duplicate all that code, but nor do we want a special hack for the contextmenu plugin... really, all those plugins were written with just the desktop in mind, they should be in desktop/ not generic/. *thinks* abusing kauthorized wouldn't be much better, I guess? Marco Martin wrote: yeah, this was just as an experiment to see what options there could be. in the netbook a right mouse button menu makes sense, just that single action shouldn't be here... so, i see at the moment 2 possibilities: -every shell will have its own menu implementation, like DesktopMenu, NetbookMenu ScreensaverMenu etc. quite code duplication but would avoid not too pretty new api -there is a single menu plugin, but is the list of qactions that depends from te shell, so a qlist of ContamentContextActions(ugh what an ugly name) will be provided by the implementations, so the ndividua coronas... ugly api less duplication. hmmm, fscinating problem :) i don't think it's worth adding to the libplasma API for what really amounts to one plugin and a subset of its features. for the particular case mentioned, it suggest that the action should come from the corona. and i agree with that :) in that case the plugin could check if the corona has a add panel action and if so include it, otherwise don't. at the worst, simply duplicating this one plugin would be a better answer imho than the API proposal, but distributing the actions around sounds even better to me. (that particular plugin's code could also likely end up being a lot simpler than it is right now; there are a number of collection classes that are being kept in sync with each other, for instance) - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2580/#review3697 --- On 2010-01-14 11:03:23, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2580/ --- (Updated 2010-01-14 11:03:23) Review request for Plasma and Chani Armitage. Summary --- This approach doesn't look that right, but is the only way i could think of: in the netbook shell there really shouldn't be the add panel context menu entry since it isn't supported (what happens right now is the panel containment being created and no views assigned to it. we could also decide that yeah, indeed the netbook should support multiple panels too (was thinking about that for unrelated reasons) but the problem would propose itself again when we do another shell without panels but that still make sense to have context menus (like the screensaver) i tried to do a generic mechanism: all actions will be enabled by default and the corona keeps a blacklist of them (corona or containment? some actions make sense to be enabled or disabled only globally, like add panel, others could be containment dependent?) setContaimentActionEnabled() adds the action to the blacklist this is just a stub, all actions should check their availability in the future Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/containmentactions/contextmenu/menu.cpp 1070354 /trunk/KDE/kdebase/workspace/plasma/netbook/shell/netcorona.cpp 1070354 /trunk/KDE/kdelibs/plasma/containment.h 1074119 /trunk/KDE/kdelibs/plasma/containment.cpp 1074119 /trunk/KDE/kdelibs/plasma/corona.h 1074119 /trunk/KDE/kdelibs/plasma/corona.cpp 1074119 Diff: http://reviewboard.kde.org/r/2580/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma.include() and member visibility
On January 14, 2010, Amos Kariuki wrote:
I’m trying to create a javascript plasmoid with multiple modules. My
main.js file includes another script file; my problem is that I’m unable to
reference the variables and functions declared in the included file.
Example:
[lib.js]
var name = “Amos”;
[main.js]
plasmoid.include(“lib.js”);
print(name);
When I run the plasmoid, I get a message stating that x is undefined. I’m
I referencing the variables incorrectly or is there some other way to
achieve what I want?
it is a scoping problem. declaring var name means that the 'name' variable
is local to that context (the file in this case). if you instead do:
name = 'Amos'
or
plasmoid.name = 'Amos'
it works just fine. (i just tested this, in fact :)
note that reverse isn't true, however: if you declared var name in your
main.js then it will be visible in lib.js. that's because main.js is the
context for lib.js (but not vice versa)
the same, btw, is true of functions. (just tested that too :)
this keeps multiple files from conflicting with one another in odd ways just
because they have similarly named local variables and functions.
however, this can be easily changed with this patch:
Index: scriptenv.cpp
===
--- scriptenv.cpp (revision 1073899)
+++ scriptenv.cpp (working copy)
@@ -74,7 +74,13 @@
QString script = file.readAll();
//kDebug() Script says script;
-evaluate(script);
+QScriptContext *ctx = currentContext();
+if (ctx-parentContext()) {
+ctx-setActivationObject(ctx-parentContext()-activationObject());
+ctx-setThisObject(ctx-parentContext()-thisObject());
+}
+
+evaluate(script, path);
if (hasUncaughtException()) {
emit reportError(this, true);
return false;
this works with your example code.
i just took a look at the apidox for QScriptEngine::currentContext() and,
interestingly, read this:
A typical usage of these functions is when you want script code to be
evaluated in the context of the parent context, e.g. to implement an include()
function:
so apparently this is what people writing javascript expect. to me it sounds
like a problem waiting to happen:
[second.js]
var test = 'rocking'
[third.js]
var test = 'not rocking'
[main.js]
include('second.js')
include('third.js')
print(test)
the output is: not rocking
ugh. as there is a way to export such variables (don't use var or have a
global object to register them with) it seems unreasonably messy. but, yes,
since that's what is expected i'll commit this change and backport it for
4.4.0.
--
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 Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Emit signal when launchQuery finish
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2592/#review3718 --- Ship it! small name change to the signal, otherwise looks good. trunk/KDE/kdelibs/plasma/runnermanager.h http://reviewboard.kde.org/r/2592/#comment3081 perhaps just queryFinished() - Aaron On 2010-01-14 15:19:20, igorto wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2592/ --- (Updated 2010-01-14 15:19:20) Review request for Plasma and Aaron Seigo. Summary --- Right now when we use RunnerManager::launchQuery we do not know when the query finish. Knowing it we can improve some animations. This patch add a new signal called launchQueryFinished. Diffs - trunk/KDE/kdelibs/plasma/runnermanager.h 1074622 trunk/KDE/kdelibs/plasma/runnermanager.cpp 1074622 Diff: http://reviewboard.kde.org/r/2592/diff Testing --- Thanks, igorto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Emit signal when launchQuery finish
On 2010-01-15 22:51:19, Aaron Seigo wrote: small name change to the signal, otherwise looks good. oops, forgot: it needs an @since to it (4.4 if it is going to be backported to the branch, which would have to happen prior t 4.4.0 being released if it is going to be backported, otherwise 4.5_ - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2592/#review3718 --- On 2010-01-14 15:19:20, igorto wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2592/ --- (Updated 2010-01-14 15:19:20) Review request for Plasma and Aaron Seigo. Summary --- Right now when we use RunnerManager::launchQuery we do not know when the query finish. Knowing it we can improve some animations. This patch add a new signal called launchQueryFinished. Diffs - trunk/KDE/kdelibs/plasma/runnermanager.h 1074622 trunk/KDE/kdelibs/plasma/runnermanager.cpp 1074622 Diff: http://reviewboard.kde.org/r/2592/diff Testing --- Thanks, igorto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
How to make a simple PopupApplet
Hello all,
I wanted to make a simple PopupApplet which stays as an icon in the
panel and when clicked shows a popup allowing to enter username and
password. The techbase extenders tutorial seems a bit overkill for this
because it provides more functionality than what required in my case. So,
looking at the PopupApplet API, I wrote the following code -
#include sifyclient.h
K_EXPORT_PLASMA_APPLET(sifyclient, SifyClient)
SifyClient::SifyClient(QObject *parent, const QVariantList args)
: Plasma::PopupApplet(parent, args)
{
topLevelWidget = new QGraphicsWidget;
usernameLabel = new Plasma::Label(topLevelWidget);
usernameEdit = new Plasma::LineEdit(topLevelWidget);
usernameLabel-setText(Username);
QGraphicsLinearLayout *usernameLayout = new
QGraphicsLinearLayout(Qt::Horizontal, topLevelWidget);
dataTransferLayout-addItem(usernameLabel);
dataTransferLayout-addItem(usernameEdit);
topLevelWidget-setLayout(dataTransferLayout);
}
SifyClient::~SifyClient()
{
delete topLevelWidget;
}
void SifyClient::init()
{
setPopupIcon(device-notifier);//just for testing, will replace by
appropriate one later
}
QGraphicsWidget *SifyClient::graphicsWidget()
{
return topLevelWidget;
}
#include sifyclient.moc
From the API, I expected this to display 'device-notifier' icon when placed
in panel and show the username label and line edit when clicked. Instead it
displays the label and line edit directly inside the panel. What am I doing
wrong? How to get the effect I'm trying to achieve?
Thanks
--
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: a way for a custom corona to forbid some standard context menu entries
On 1/15/10, Aaron Seigo ase...@kde.org wrote: On 2010-01-14 18:18:26, Chani Armitage wrote: :/ this feels wrong. for the screensaver, I just created a separate mouse plugin. I suppose the netbook shares actions like log out and lock screen though, which makes this a bit trickier... we don't really want to duplicate all that code, but nor do we want a special hack for the contextmenu plugin... really, all those plugins were written with just the desktop in mind, they should be in desktop/ not generic/. *thinks* abusing kauthorized wouldn't be much better, I guess? Marco Martin wrote: yeah, this was just as an experiment to see what options there could be. in the netbook a right mouse button menu makes sense, just that single action shouldn't be here... so, i see at the moment 2 possibilities: -every shell will have its own menu implementation, like DesktopMenu, NetbookMenu ScreensaverMenu etc. quite code duplication but would avoid not too pretty new api -there is a single menu plugin, but is the list of qactions that depends from te shell, so a qlist of ContamentContextActions(ugh what an ugly name) will be provided by the implementations, so the ndividua coronas... ugly api less duplication. hmmm, fscinating problem :) i don't think it's worth adding to the libplasma API for what really amounts to one plugin and a subset of its features. for the particular case mentioned, it suggest that the action should come from the corona. and i agree with that :) in that case the plugin could check if the corona has a add panel action and if so include it, otherwise don't. yeah, totally agree at the worst, simply duplicating this one plugin would be a better answer imho than the API proposal, but distributing the actions around sounds even better to me. (that particular plugin's code could also likely end up being a lot simpler than it is right now; there are a number of collection classes that are being kept in sync with each other, for instance) - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2580/#review3697 --- On 2010-01-14 11:03:23, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2580/ --- (Updated 2010-01-14 11:03:23) Review request for Plasma and Chani Armitage. Summary --- This approach doesn't look that right, but is the only way i could think of: in the netbook shell there really shouldn't be the add panel context menu entry since it isn't supported (what happens right now is the panel containment being created and no views assigned to it. we could also decide that yeah, indeed the netbook should support multiple panels too (was thinking about that for unrelated reasons) but the problem would propose itself again when we do another shell without panels but that still make sense to have context menus (like the screensaver) i tried to do a generic mechanism: all actions will be enabled by default and the corona keeps a blacklist of them (corona or containment? some actions make sense to be enabled or disabled only globally, like add panel, others could be containment dependent?) setContaimentActionEnabled() adds the action to the blacklist this is just a stub, all actions should check their availability in the future Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/containmentactions/contextmenu/menu.cpp 1070354 /trunk/KDE/kdebase/workspace/plasma/netbook/shell/netcorona.cpp 1070354 /trunk/KDE/kdelibs/plasma/containment.h 1074119 /trunk/KDE/kdelibs/plasma/containment.cpp 1074119 /trunk/KDE/kdelibs/plasma/corona.h 1074119 /trunk/KDE/kdelibs/plasma/corona.cpp 1074119 Diff: http://reviewboard.kde.org/r/2580/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
