Re: workspace/plasma filesystem reorganization

[Marco Martin]

On Monday 14 September 2009, Aaron J. Seigo wrote:
> On September 14, 2009, Marco Martin wrote:
> > uh, and another thing: maybe the widget explorer to be another separate
> > library, so in workspace/libs we would have libplasmagenericshell (or
> > libplasmageneric) and libplasmawidgetexplorer
>
> why?
ok, so move the whole widget explorer in liplasmagenericshell?

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma

[Marco Martin]

On Tuesday 15 September 2009, Aaron J. Seigo wrote:
> On September 14, 2009, Marco Martin wrote:
> > SVN commit 1023511 by mart:
> >
> > move stuff around:
>
> i really don't like the shells/ directories.
>
> plasma/netbook/shells/netbook/
> plasma/desktop/shells/desktop/
> plasma/screensaver/shells/screensaver
>
> that's all very redundant. there are no other entries in the shells/, nor
> do i think there ever will be.. the entire point of plasma/netbook/,
> plasma/desktop/ and plasma/screensaver/ is to separate out the shells
> specific to those use cases.
yes, i agree, i can  begin to move those.
what concerns me is that there could be more than one in the future (i have 
one in playground called standaloneplasmoids, i showed it to you at tokamak) 
that could go either in generic or netbook, probably the latter, but i suppose 
the shells folder can return when needed only when needed...

> containments/, applets/ (perhaps that should be plasmoids/?), etc. make
> sense because there will be (and already are) multiple instances of those
> for the various shells.


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: QtScript bindings

[Marco Martin]

On Monday 14 September 2009, Tommi Mikkonen wrote:
> Aaron J. Seigo wrote:
> > On September 14, 2009, Tommi Mikkonen wrote:
> >> Having said that, what I would also like is a harmonized API; having
> >> finally spend some hours tonight (after traveling in conferences for
> >> some weeks!) on JS Plasmoid development with Lively content, I
> >> constantly seem to have problems on the names of widget types etc.
> >
> > can you provide some concrete examples?
>
> QFrame vs. Frame and QWebView vs. Webview is QtScriptGenerator and
> Plasmoids, and at the same time QtVertical in native Qt,
the type names of the plasma widgets are the same in the c++ api and the 
simplified js api. plasma classes don't have a letter prefix since we have the 
Plasma:: namespace
> QtScriptGenerator and Plasmoids. Another  issue is with types when
> adding a Qt widget that has been instantiated in C++. At least
> http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet
> documents that at times a QPainter etc is expected as parameter whereas
> Plasma uses name Painter etc. As the error message I get is 'script
> could not be initialized' or something similar when misspelling a class
> name, it is very frustrating to debug API usage.
>
> This is not a major issue, and any convention will be ok for me.
> However, if we have two scripting systems --- one wirh privileges and
> another without --- it will be confusing if type names etc. are
> different. An additional issue is that if we have these two sets, the
> restricted one should not fail without error messages if someone tests
> privileged APIs but give an error message etc.
>
> Personally, I can live with either API; both are probably fine for most
> developers but there should only be one. In a perfect world, we could
> have two, one for privileged apps and the other for regular ones. I am
> however worried that this will complicate the view a casual developer
> will get to Plasma widget development.
>
> tjm
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: 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@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

bug? or my bad use of threads?

[Amir Taaki]

_
Save time by using Hotmail to access your other email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

bug or bas use of threads

[Amir Taaki]

_
Save time by using Hotmail to access your other email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: associate an external tool to an applet

[Marco Martin]

> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, lines 1985-1987
> > 
> >
> > this is actually unecessary; KRun does all of this for you, including 
> > re-using the mimetype fetching job.

hmm, but i actuall need to fetch the mimetype no? runurl wants it as arameter, 
so it doesn't try to understand it by itself no?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1850
> > 
> >
> > is this synchronous? i think it is; probably should create a KRun 
> > object and connect to its signals (or just ignore the result, even?) so 
> > that it isn't synchronous and holding up the application.

ok


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1848
> > 
> >
> > you should stop the job here, no? or perhaps put it on hold and publish 
> > it so that the app can then use it?

hmm, not sure it would be useful published?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1980
> > 
> >
> > you know what would be dreadfully cool? if there was an external tool 
> > manager that, when an app was triggered, it would see if that resulted in a 
> > window popping up. if so, then it could track that window and as long as 
> > that window existed, it could become associated with the widget?
> > 
> > might not work so hot, i suppose, if you open an image in a viewer, 
> > navigate to another image in the viewer, and then click the widget's "run" 
> > icon again. hmm...
> > 
> > another benefit of having a manager for these would be that instead of 
> > having an extra set of members in the applet's dptr regardless of whether 
> > or not it uses this feature, there would only be one manager and only as 
> > many objects in memory as there are widgets using this feature.

a singleton? accessible in the public api? and it should avoid to launch the 
app two times?


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.h, lines 631-637
> > 
> >
> > external -> associated?
> > tool -> application?
> > 
> > we will need to have a non-KService version of the tool definer method 
> > since not all apps will be registered in that manner. i think we could 
> > probably just take a string and figure out ourselves internally if it's a 
> > service or an executable.
> > 
> > as for arguments ... hm. use cases could be:
> > 
> > * command line arguments (e.g. konsole -e ls -lR)
> > * URLs
> > * ...?
> > 
> > probably needs more use case thinking. 
> > 
> > if it does remain limited to URLs (and i think an API that makes 
> > launching apps with urls would be a good idea), then that might be a more 
> > generic sort of thing: associatedUrls()? 
> > 
> > it will need to support url lists.
> > 
> > a "does this applet have a valid associated app?" convenience method 
> > would be nice
> > 
> >

ok, so it should take a string and then try to obtain a service out of it.
if it fails it gets executed as a command... i wasn't really sure about that 
since i wanted to avoid people passing absolute urls and then complainig it's 
broken, but well, their bad..

for the list of urls i'm wondering if the app is not present would make sense 
to try to run all of them, it could be massive...


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1606/#review2367
---


On 2009-09-14 15:04:43, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1606/
> ---
> 
> (Updated 2009-09-14 15:04:43)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> first implementation of an idea discussed @tokamak: add api to assign the 
> execution of something to an applet. the rationale is to launch an app that 
> is the "full version" of that applet, where the applet serves as little 
> preview.
> it is possible to assign a kservice (usually used with 
> kservice::servicefromdesktopfile("app name")) and an optional argument.
> if the service is missing and the argument url is present the url will be 
> opened based on its mimetype.
> an applethandle icon and a context menu entry will be added to launch that 
> external tool
> now there are roe rough edges:
> -api: pass k

Splitting openDesktop plasmoid into two parts

[Eckhart Wörner]

Hi,

I'd like to split the openDesktop plasmoid into two parts:
- the first plasmoid should contain the user details, the friends list and the 
nearby users list
- the second plasmoid should contain the activity list (aka news feed)

Now the main question is how that split has to place. Do I have to move the 
newly created plasmoid to kdereview first?

I might add that most of the work for splitting has already been done, the 
activity list is a self-contained widget just waiting for the split. :-)

Eckhart
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Splitting openDesktop plasmoid into two parts

[Artur Souza (MoRpHeUz)]

On Tuesday 15 September 2009, 11:10 Eckhart Wörner wrote:
> I'd like to split the openDesktop plasmoid into two parts:
> - the first plasmoid should contain the user details, the friends list and
>  the nearby users list
> - the second plasmoid should contain the activity list (aka news feed)

What would be the benefits of splitting them ?

Cheers,

--
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
--
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
--


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: workspace/plasma filesystem reorganization

[Aaron J. Seigo]

On September 15, 2009, Marco Martin wrote:
> On Monday 14 September 2009, Aaron J. Seigo wrote:
> > On September 14, 2009, Marco Martin wrote:
> > > uh, and another thing: maybe the widget explorer to be another separate
> > > library, so in workspace/libs we would have libplasmagenericshell (or
> > > libplasmageneric) and libplasmawidgetexplorer
> >
> > why?
> 
> ok, so move the whole widget explorer in liplasmagenericshell?

yes, i think so.

-- 
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


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: associate an external tool to an applet

[Aaron Seigo]

> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.h, lines 631-637
> > 
> >
> > external -> associated?
> > tool -> application?
> > 
> > we will need to have a non-KService version of the tool definer method 
> > since not all apps will be registered in that manner. i think we could 
> > probably just take a string and figure out ourselves internally if it's a 
> > service or an executable.
> > 
> > as for arguments ... hm. use cases could be:
> > 
> > * command line arguments (e.g. konsole -e ls -lR)
> > * URLs
> > * ...?
> > 
> > probably needs more use case thinking. 
> > 
> > if it does remain limited to URLs (and i think an API that makes 
> > launching apps with urls would be a good idea), then that might be a more 
> > generic sort of thing: associatedUrls()? 
> > 
> > it will need to support url lists.
> > 
> > a "does this applet have a valid associated app?" convenience method 
> > would be nice
> > 
> >
> 
>  wrote:
> ok, so it should take a string and then try to obtain a service out of it.
> if it fails it gets executed as a command... i wasn't really sure about 
> that since i wanted to avoid people passing absolute urls and then complainig 
> it's broken, but well, their bad..
> 
> for the list of urls i'm wondering if the app is not present would make 
> sense to try to run all of them, it could be massive...

yes, the heuristic is probably pretty simple: if it's an absolute path, treat 
it as a command. otherwise, try and find it as a service. if that fails, use 
findExe. if that fails, they failed ;)


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1848
> > 
> >
> > you should stop the job here, no? or perhaps put it on hold and publish 
> > it so that the app can then use it?
> 
>  wrote:
> hmm, not sure it would be useful published?

it allows the application that will be launched in a few moments to 
(magically!) reuse that IOSlave so if it's accessing a remote file it doesn't 
need to establish a connection with the remote system again. 

   job->putOnHold();
KIO::Scheduler::publishSlaveOnHold();
 
is pretty magical :) but yes, krun can do it all for us.


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, line 1980
> > 
> >
> > you know what would be dreadfully cool? if there was an external tool 
> > manager that, when an app was triggered, it would see if that resulted in a 
> > window popping up. if so, then it could track that window and as long as 
> > that window existed, it could become associated with the widget?
> > 
> > might not work so hot, i suppose, if you open an image in a viewer, 
> > navigate to another image in the viewer, and then click the widget's "run" 
> > icon again. hmm...
> > 
> > another benefit of having a manager for these would be that instead of 
> > having an extra set of members in the applet's dptr regardless of whether 
> > or not it uses this feature, there would only be one manager and only as 
> > many objects in memory as there are widgets using this feature.
> 
>  wrote:
> a singleton? accessible in the public api? and it should avoid to launch 
> the app two times?

i think it can be private for the time being. Applet will use it internally.


> On 2009-09-15 04:32:47, Aaron Seigo wrote:
> > /trunk/KDE/kdelibs/plasma/applet.cpp, lines 1985-1987
> > 
> >
> > this is actually unecessary; KRun does all of this for you, including 
> > re-using the mimetype fetching job.
> 
>  wrote:
> hmm, but i actuall need to fetch the mimetype no? runurl wants it as 
> arameter, so it doesn't try to understand it by itself no?

what i meant is that you won't be using runUrl anymore and can just let KRun do 
it for you.


- Aaron


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1606/#review2367
---


On 2009-09-14 15:04:43, Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1606/
> ---
> 
> (Updated 2009-09-14 15:04:43)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> first implementation of an idea discussed @tokamak: add api to assign the 
> execution of something to an applet. the rationale is to launch an app that 
> is the "full version" of that applet, where the apple

Re: KDE/kdebase/workspace/plasma

[Aaron J. Seigo]

On September 15, 2009, Marco Martin wrote:
> yes, i agree, i can  begin to move those.
> what concerns me is that there could be more than one in the future (i have
> one in playground called standaloneplasmoids, i showed it to you at
>  tokamak) that could go either in generic or netbook, probably the latter,
>  but i suppose the shells folder can return when needed only when needed...

yes; and standaloneplasmoids would belong in generic imho. people want that on 
their laptops/desktop too.

-- 
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


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: QtScript bindings

[Tommi Mikkonen]

Marco Martin wrote:
> 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
>   
Doing this would result in an extremely powerful scripting system.
Based on our experiments, I would think that one could compose
both simple apps and mashups based on web content (assuming
that networking and xml processing APIs are also opened). This
in turn could bring onboard folks that are used to composing
apps in the web using JavaScript. With Plasma, these apps
would simply look cooler and be in place instantly without
any browser frames etc.

tjm

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Splitting openDesktop plasmoid into two parts

[Aaron J. Seigo]

On September 15, 2009, Eckhart Wörner wrote:
> I'd like to split the openDesktop plasmoid into two parts:
> - the first plasmoid should contain the user details, the friends list and
>  the nearby users list
> - the second plasmoid should contain the activity list (aka news feed)

how will they share the login settings? i doubt it makes sense to have to re-
enter your account details for every widget?

something we talked about way back in 4.0 is having a global openId 
associated with the current user's activity (and a default one for when there 
is no activity specific id). 

> Now the main question is how that split has to place. Do I have to move the
> newly created plasmoid to kdereview first?

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 Development Frameworks


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: Splitting openDesktop plasmoid into two parts

[Eckhart Wörner]

Hi Aaron,

Am Dienstag, 15. September 2009 16:54:51 schrieb Aaron J. Seigo:
> > I'd like to split the openDesktop plasmoid into two parts:
> > - the first plasmoid should contain the user details, the friends list
> > and the nearby users list
> > - the second plasmoid should contain the activity list (aka news feed)
> 
> how will they share the login settings? i doubt it makes sense to have to
>  re- enter your account details for every widget?

at the moment, the account details are a bit messed up anyway: the password is 
saved in KWallet by the ioslave responsible for ocs api requests (i.e. https 
normally), same for the user name (although you can set the user name in the 
plasmoid config dialog).

Eckhart
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Splitting openDesktop plasmoid into two parts

[Aaron J. Seigo]

On September 15, 2009, Eckhart Wörner wrote:
> at the moment, the account details are a bit messed up anyway: the password
>  is saved in KWallet by the ioslave responsible for ocs api requests (i.e.
>  https normally), same for the user name (although you can set the user
>  name in the plasmoid config dialog).

that doesn't sound messed up to me; username in the widget, password safely in 
the wallet. do you have a different idea in mind?

(and i do like the idea of being able to set one's identity "globally")

-- 
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


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: Splitting openDesktop plasmoid into two parts

[Marco Martin]

On Tuesday 15 September 2009, Eckhart Wörner wrote:
> Hi,
>
> I'd like to split the openDesktop plasmoid into two parts:
> - the first plasmoid should contain the user details, the friends list and
> the nearby users list
> - the second plasmoid should contain the activity list (aka news feed)
>
> Now the main question is how that split has to place. Do I have to move the
> newly created plasmoid to kdereview first?
>
> I might add that most of the work for splitting has already been done, the
> activity list is a self-contained widget just waiting for the split. :-)
>
> Eckhart
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
not sure,
the personal data and the friend list is something that is not often used, 
while the activity list is a kinda of news source that changes often, it gives 
the opendesktop plasmoid some interesting to look at, otherwise yeah, it's 
interesting the nearby list if i have a mobile device, otherwise hmm...

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Splitting openDesktop plasmoid into two parts

[Eckhart Wörner]

Hi Aaron,

Am Dienstag, 15. September 2009 17:30:45 schrieb Aaron J. Seigo:
> > at the moment, the account details are a bit messed up anyway: the
> > password is saved in KWallet by the ioslave responsible for ocs api
> > requests (i.e. https normally), same for the user name (although you can
> > set the user name in the plasmoid config dialog).
> 
> that doesn't sound messed up to me; username in the widget, password safely
>  in the wallet. do you have a different idea in mind?
> 
> (and i do like the idea of being able to set one's identity "globally")

Messed up means:
- the user name (and password) stored in KWallet by the https ioslave is used 
to make API calls
- the user name stored by the widget is used to show information related to 
yourself (i.e. your personal tab and your friend list)

Eckhart
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: QtScript bindings

[Robert Knight]

> smoke based? have you looked into the qscript generator that Kent @ Qt
> has been working on (for a long time now ... i wonder why there isn't more
> news about it by now...)

Please check with Kent whether there has been any change on this but
last I looked
at the binding generator (shortly after he announced the project on
the Qt Labs site)
it produced enormous binding libraries - both in terms of on disk
space and increased
private memory usage.  I think it was on the order of ~19MB non-shared
writable memory per application using
full QtCore and QtGui bindings.

Again, that is a figure from memory which I have not checked with a
recent version of the generator and I'd appreciate it
if someone could verify whether this problem still exists.

Regards,
Robert.

2009/9/15 Tommi Mikkonen :
> Marco Martin wrote:
>> 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
>>
> Doing this would result in an extremely powerful scripting system.
> Based on our experiments, I would think that one could compose
> both simple apps and mashups based on web content (assuming
> that networking and xml processing APIs are also opened). This
> in turn could bring onboard folks that are used to composing
> apps in the web using JavaScript. With Plasma, these apps
> would simply look cooler and be in place instantly without
> any browser frames etc.
>
> tjm
>
> ___
> 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

kssldlds

[Amir Taaki]

_
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma

[Chani]

On September 14, 2009 16:45:35 Aaron J. Seigo wrote:
> On September 14, 2009, Chani wrote:
> > > also, in moving i noticed the screensaver shell still tried to include
> > > and use appletbrowser.h,  i really wonder why it was still building.
> > > now those parts are just commented out but a port is badly needed.
> >
> > ah crud. :/ I don't know if I'll have time for that.
> > it could be easy, or it could run into issues with the lack of
> > windowmanagement and other strange things lockprocess does.
> 
> the new widget browser is a QGraphicsWidget, so you should be able to place
>  it right on the canvas. this should actually be easier than what you have
>  there right now as there would be no window management at all needed.
> 

yay!
...say, does DashboardView use it yet? maybe I can c&p from there a bit.

funny, I dreamt that someone else replied explaining how the windowmanagement 
part would actually be easy... :)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


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: KDE/kdebase/workspace/plasma

[Marco Martin]

On Tuesday 15 September 2009, Chani wrote:
> On September 14, 2009 16:45:35 Aaron J. Seigo wrote:
> > On September 14, 2009, Chani wrote:
> > > > also, in moving i noticed the screensaver shell still tried to
> > > > include and use appletbrowser.h,  i really wonder why it was still
> > > > building. now those parts are just commented out but a port is badly
> > > > needed.
> > >
> > > ah crud. :/ I don't know if I'll have time for that.
> > > it could be easy, or it could run into issues with the lack of
> > > windowmanagement and other strange things lockprocess does.
> >
> > the new widget browser is a QGraphicsWidget, so you should be able to
> > place it right on the canvas. this should actually be easier than what
> > you have there right now as there would be no window management at all
> > needed.
>
> yay!
> ...say, does DashboardView use it yet? maybe I can c&p from there a bit.
sadly, is still not possible to open it from dashboardview (well not even from 
desktopview, actually :p)
> funny, I dreamt that someone else replied explaining how the
> windowmanagement part would actually be easy... :)
lol

--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE/kdebase/workspace/plasma

[Chani]

On September 15, 2009 10:45:13 Marco Martin wrote:
> On Tuesday 15 September 2009, Chani wrote:
> > On September 14, 2009 16:45:35 Aaron J. Seigo wrote:
> > > On September 14, 2009, Chani wrote:
> > > > > also, in moving i noticed the screensaver shell still tried to
> > > > > include and use appletbrowser.h,  i really wonder why it was still
> > > > > building. now those parts are just commented out but a port is
> > > > > badly needed.
> > > >
> > > > ah crud. :/ I don't know if I'll have time for that.
> > > > it could be easy, or it could run into issues with the lack of
> > > > windowmanagement and other strange things lockprocess does.
> > >
> > > the new widget browser is a QGraphicsWidget, so you should be able to
> > > place it right on the canvas. this should actually be easier than what
> > > you have there right now as there would be no window management at all
> > > needed.
> >
> > yay!
> > ...say, does DashboardView use it yet? maybe I can c&p from there a bit.
> 
> sadly, is still not possible to open it from dashboardview (well not even
>  from desktopview, actually :p)
> 

wait... so... what if someone doesn't have a panel?

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


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: KDE/kdebase/workspace/plasma

[Aaron J. Seigo]

On September 15, 2009, Marco Martin wrote:
> sadly, is still not possible to open it from dashboardview (well not even
>  from desktopview, actually :p)

i actually fixed most of that last night. i abstracted the basic window from 
PanelController into a class called ControllerWindow which now:

* paints a background
* offers a top level layout to be (ab)used
* provides methods to show and, soon anyways, hide the widget explorer

-- 
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


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

bug? or my bad use of threads part 2

[Amir Taaki]

hey

http://pastebin.com/m59bfa77b
http://pastebin.com/m21f481b3

Damn typed a long email before but cant be bothered to type all those
details again :/ fckin hotmail!!!

Basically was having some trouble in my plugin so I've hacked this small
testcase. It consists of one threaded object writing to an image read by the
main Plasma Wallpaper object and drawn to the screen.

It crashes randomly in use and when I right click desktop and change the
type to it, then change it to a different wallpaper I get a crash.

KDE 4.2.2

ty


walltut.tar.gz
Description: GNU Zip compressed data
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Sort the matches of a runner

[Jan Gerrit Marker]

Hello,
I wrote a runner to kill applications (it is in playground). A user asked me 
to sort the matchs by CPU load. So my question is if there's a working 
possibility to sort the matches.

Thanks in advance

Jan
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Sort the matches of a runner

[Aaron J. Seigo]

On September 15, 2009, Jan Gerrit Marker wrote:
> I wrote a runner to kill applications (it is in playground). A user asked
>  me to sort the matchs by CPU load. So my question is if there's a working
>  possibility to sort the matches.

you can call setRelevance on matches, which is a qreal with values expected 
between 0 and 1. anything more fine grained than that would require some 
additional work in krunner.

-- 
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


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: bug? or my bad use of threads part 2

[Amir Taaki]

oops that slipped my attention. but still removing the offending code the
crash is still present

On Tue, Sep 15, 2009 at 7:43 PM, Aaron J. Seigo  wrote:

> On September 15, 2009, Amir Taaki wrote:
> > Basically was having some trouble in my plugin so I've hacked this small
> > testcase. It consists of one threaded object writing to an image read by
> >  the main Plasma Wallpaper object and drawn to the screen.
>
> Tutorial1::Tutorial1(QObject *parent, const QVariantList &args)
>: Plasma::Wallpaper(parent, args), mutex(new QMutex), blaa(parent,
> mutex, &img)
> {
>  img = NULL;
>  mutex = new QMutex;
>
> you're assigning mutex twice, once in the ctor init list and once in the
> body
> of the ctor.
>
> that means that Tutorial1 and Blaa are using separate mutexes, which
> defeats
> the purpose of having 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 Development Frameworks
>
> ___
> 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: bug? or my bad use of threads part 2

[Aaron J. Seigo]

On September 15, 2009, Amir Taaki wrote:
> Basically was having some trouble in my plugin so I've hacked this small
> testcase. It consists of one threaded object writing to an image read by
>  the main Plasma Wallpaper object and drawn to the screen.

Tutorial1::Tutorial1(QObject *parent, const QVariantList &args)
: Plasma::Wallpaper(parent, args), mutex(new QMutex), blaa(parent, 
mutex, &img)
{
  img = NULL;
  mutex = new QMutex;

you're assigning mutex twice, once in the ctor init list and once in the body 
of the ctor.

that means that Tutorial1 and Blaa are using separate mutexes, which defeats 
the purpose of having 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 Development Frameworks


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: bug? or my bad use of threads part 2

[Amir Taaki]

Also I have debugging symbols enabled but get no backtrace.

Also for some reason on ubuntu I dont get the wallpaper previewing app-
anyone know where I can find it?

On Tue, Sep 15, 2009 at 7:51 PM, Amir Taaki  wrote:

> oops that slipped my attention. but still removing the offending code the
> crash is still present
>
> On Tue, Sep 15, 2009 at 7:43 PM, Aaron J. Seigo  wrote:
>
>> On September 15, 2009, Amir Taaki wrote:
>> > Basically was having some trouble in my plugin so I've hacked this small
>> > testcase. It consists of one threaded object writing to an image read by
>> >  the main Plasma Wallpaper object and drawn to the screen.
>>
>> Tutorial1::Tutorial1(QObject *parent, const QVariantList &args)
>>: Plasma::Wallpaper(parent, args), mutex(new QMutex), blaa(parent,
>> mutex, &img)
>> {
>>  img = NULL;
>>  mutex = new QMutex;
>>
>> you're assigning mutex twice, once in the ctor init list and once in the
>> body
>> of the ctor.
>>
>> that means that Tutorial1 and Blaa are using separate mutexes, which
>> defeats
>> the purpose of having 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 Development Frameworks
>>
>> ___
>> 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: bug? or my bad use of threads part 2

[Amir Taaki]

i found this. it looks like a bug in qt with qimages

http://www.qtforum.org/article/26774/problem-when-drawing-qimages-please-help.html

On Tue, Sep 15, 2009 at 7:57 PM, Amir Taaki  wrote:

> Also I have debugging symbols enabled but get no backtrace.
>
> Also for some reason on ubuntu I dont get the wallpaper previewing app-
> anyone know where I can find it?
>
>
> On Tue, Sep 15, 2009 at 7:51 PM, Amir Taaki  wrote:
>
>> oops that slipped my attention. but still removing the offending code the
>> crash is still present
>>
>> On Tue, Sep 15, 2009 at 7:43 PM, Aaron J. Seigo  wrote:
>>
>>> On September 15, 2009, Amir Taaki wrote:
>>> > Basically was having some trouble in my plugin so I've hacked this
>>> small
>>> > testcase. It consists of one threaded object writing to an image read
>>> by
>>> >  the main Plasma Wallpaper object and drawn to the screen.
>>>
>>> Tutorial1::Tutorial1(QObject *parent, const QVariantList &args)
>>>: Plasma::Wallpaper(parent, args), mutex(new QMutex), blaa(parent,
>>> mutex, &img)
>>> {
>>>  img = NULL;
>>>  mutex = new QMutex;
>>>
>>> you're assigning mutex twice, once in the ctor init list and once in the
>>> body
>>> of the ctor.
>>>
>>> that means that Tutorial1 and Blaa are using separate mutexes, which
>>> defeats
>>> the purpose of having 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 Development Frameworks
>>>
>>> ___
>>> 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: associate an external tool to an applet

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1606/
---

(Updated 2009-09-15 21:12:44.133738)


Review request for Plasma.


Changes
---

goes trough AssociatedApplicationManager singleton


Summary
---

first implementation of an idea discussed @tokamak: add api to assign the 
execution of something to an applet. the rationale is to launch an app that is 
the "full version" of that applet, where the applet serves as little preview.
it is possible to assign a kservice (usually used with 
kservice::servicefromdesktopfile("app name")) and an optional argument.
if the service is missing and the argument url is present the url will be 
opened based on its mimetype.
an applethandle icon and a context menu entry will be added to launch that 
external tool
now there are roe rough edges:
-api: pass kservice and url or just strings to make bindings easier?
-urls: right now there is only one parameter: maybe having support for a list?
-naming: now all the names are talking about an "external tool", the applet 
handle uses the "maximize" icon, calling it maximize everywhere? i would leave 
external tool in the api and call maximize the action and the action text, that 
is what is presented to the user..


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/private/associatedapplicationmanager_p.h 
PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/private/associatedapplicationmanager.cpp 
PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1023331 
  /trunk/KDE/kdelibs/plasma/containment.cpp 1023331 
  /trunk/KDE/kdelibs/plasma/private/applet_p.h 1023331 
  /trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1023331 
  /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1023331 
  /trunk/KDE/kdelibs/plasma/applet.h 1023331 
  /trunk/KDE/kdelibs/plasma/applet.cpp 1023331 

Diff: http://reviewboard.kde.org/r/1606/diff


Testing
---


Thanks,

Marco

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: associate an external tool to an applet

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1606/
---

(Updated 2009-09-15 21:21:51.546388)


Review request for Plasma.


Summary
---

first implementation of an idea discussed @tokamak: add api to assign the 
execution of something to an applet. the rationale is to launch an app that is 
the "full version" of that applet, where the applet serves as little preview.
it is possible to assign a kservice (usually used with 
kservice::servicefromdesktopfile("app name")) and an optional argument.
if the service is missing and the argument url is present the url will be 
opened based on its mimetype.
an applethandle icon and a context menu entry will be added to launch that 
external tool
now there are roe rough edges:
-api: pass kservice and url or just strings to make bindings easier?
-urls: right now there is only one parameter: maybe having support for a list?
-naming: now all the names are talking about an "external tool", the applet 
handle uses the "maximize" icon, calling it maximize everywhere? i would leave 
external tool in the api and call maximize the action and the action text, that 
is what is presented to the user..


Diffs (updated)
-

  /trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1023331 
  /trunk/KDE/kdelibs/plasma/private/associatedapplicationmanager.cpp 
PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1023331 
  /trunk/KDE/kdelibs/plasma/applet.h 1023331 
  /trunk/KDE/kdelibs/plasma/applet.cpp 1023331 
  /trunk/KDE/kdelibs/plasma/containment.cpp 1023331 
  /trunk/KDE/kdelibs/plasma/private/applet_p.h 1023331 
  /trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1023331 
  /trunk/KDE/kdelibs/plasma/private/associatedapplicationmanager_p.h 
PRE-CREATION 

Diff: http://reviewboard.kde.org/r/1606/diff


Testing
---


Thanks,

Marco

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

QtScript Smoke Bindings

[Ian Monroe]

I've already gone over the reasons for this project on both mailing
lists. Since then I've cleaned up the code some and added a bunch of
//TODOs and //FIXMEs so the repo is ready for other contributors.

Note that unlike other language programming projects you get to use a
nice C++ Qt api to bind with, instead of some half-public C binding
api. :)

The repo is at http://gitorious.org/qtscript-smoke/qtscript-smoke and
I've given the kde-developers group commit access.

I'd rather people just push to mainline instead of creating their own
clones. Ask the sysadmins to add you to the kde-developers group or me
and I'll just add you as a committer to this repo.

Currently it can support code such as the following:
hello = new QWidget();
hello.show();
hello.setMaximumWidth( 500 );
hello.setWindowTitle( "QtScript Smoke Test: it kind of works" );

No screenshot necessary, I think you all can imagine what that looks like. ;)

There's still a lot missing though. Currently its only 300 LOC, but
thats because I've avoided the more complicated marshaling, error
handling and user subclassing. (The latter might be tricky since JS is
prototype based so mapping OOP into it is always a bit of a hack.)

Goals of project:
* Low memory usage
* To provide access to the Qt API
   - and trivial to add other Smoke bindings
* quick start time (since it will be loaded on Amarok's startup)
* To be mostly source compatible with QtScript Generator scripts (eg
not 100% compat, but make it a 5 minute job to make a script work in
both environments)

You can find me on Freenode as 'eean' in the normal places.

Thanks,
Ian Monroe
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel