Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-05 Thread Patrick Aljord
On Tue, Jan 5, 2010 at 4:45 AM, Sebastian Kügler  wrote:
> It doesn't address one important design principle in the least: Separating 
> content
> from layout and logic.

What do you mean? Many websites get their content through a REST api,
rails for example has a activeresource for that. Or am I missing
something?

> And if it's not WebGL, then we'll just get more flash apps, and maybe other
> proprietary runtimes in the future.

It's not like the non web world hasn't been plagued by proprietary
runtimes either.

> Where's this separation of data and presentation?

See above.

> Where's the semantic web that's been talked about for 10 years?

Check that maybe http://linkeddata.org/

Semantic web is already being used through microformats too.

> Seriously, today's web sucks, and it doesn't look
> good for tomorrow's.

I actually love it and it's getting better everyday.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-05 Thread Sebastian Kügler
On Tuesday 05 January 2010 11:18:21 Marco Martin wrote:
> > Where's this separation of data and presentation? Where's the semantic
> > web that's been talked about for 10 years? Seriously, today's web sucks,
> > and it doesn't look good for tomorrow's.
> > 
> 
> there is a problem of mentality here that i'm starting to doubt it woud
>  ever  be overcomed: website owners want 100% control over the final look
>  of the web site/web app that will be presented to the user. things like
>  semantic web basically says: present the -content- in a way that makes
>  sense for a machine, then it becomes trivial to present the data in the
>  exact form the -user- or, the one wo designed the software that parses
>  this content wants.
> this scares contents creators to death, becase it will remove control from 
> them (especially because it becomes very easy to do things such as remove
>  ads) so now we have sites that explicitly forbids web scrapping or even if
>  they provide a sensible api its license is so ridiculous that's almost
>  impossible to actually use it and stay legal.

I agree that it's scary for content owners, but at the same side it's their 
problem. 
One of the things we're trying to achieve with Silk is to separate those two, 
for 
example by providing the data from a webservice as a dataengine, probably even 
abstracted away per service, like the videoengine does.

This way, we open up possibilities for new uses with the data, not only putting 
a new 
UI on top of it, but also being able to remix this information, and combine it. 
If 
some website owner goes belly up because they didn't feel it's a good idea to 
separate these two, well, then their product just didn't cut it. If your 
business 
model purely relies on webad income, bad luck. We're not responsible for 
unstable 
business models. In fact, it's something we're suffering from.

There's not reason for us to hold back on sensible technical implementations 
just 
because some company's business model sucks. Granted, those companies make our 
job 
harder, but the best way to have them change their mind is showing that they're 
missing out on some market and losing users because the user wants 
data/content, not 
messy websites with all of it mixed that only runs on very specific systems.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-05 Thread Marco Martin
On Tuesday 05 January 2010, Sebastian Kügler wrote:
> On Tuesday 05 January 2010 00:54:53 Patrick Aljord wrote:
> > > but if the world goes "all in" on the web technology
> > > boat 100% we will be in a world of pain as time goes on.
> >
> > I don't think so, stuff like canvas, web sockets, fast js engines,
> > webgl or even native client will turn the browser into a powerful
> > platform not only for traditional web apps but I guess time will tell.
> 
> It doesn't address one important design principle in the least: Separating
>  content from layout and logic. The web fails here today, and none of these
>  new technologies suggests that it won't in the future.
> 
> And if it's not WebGL, then we'll just get more flash apps, and maybe other
> proprietary runtimes in the future.
> 
> Where's this separation of data and presentation? Where's the semantic web
>  that's been talked about for 10 years? Seriously, today's web sucks, and
>  it doesn't look good for tomorrow's.
> 
there is a problem of mentality here that i'm starting to doubt it woud ever 
be overcomed: website owners want 100% control over the final look of the web 
site/web app that will be presented to the user. things like semantic web 
basically says: present the -content- in a way that makes sense for a machine, 
then it becomes trivial to present the data in the exact form the -user- or, 
the one wo designed the software that parses this content wants.
this scares contents creators to death, becase it will remove control from 
them (especially because it becomes very easy to do things such as remove ads)
so now we have sites that explicitly forbids web scrapping or even if they 
provide a sensible api its license is so ridiculous that's almost impossible 
to actually use it and stay legal.

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


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-05 Thread Sebastian Kügler
On Tuesday 05 January 2010 00:54:53 Patrick Aljord wrote:
> > but if the world goes "all in" on the web technology
> > boat 100% we will be in a world of pain as time goes on.
> 
> I don't think so, stuff like canvas, web sockets, fast js engines,
> webgl or even native client will turn the browser into a powerful
> platform not only for traditional web apps but I guess time will tell.

It doesn't address one important design principle in the least: Separating 
content 
from layout and logic. The web fails here today, and none of these new 
technologies 
suggests that it won't in the future.

And if it's not WebGL, then we'll just get more flash apps, and maybe other 
proprietary runtimes in the future.

Where's this separation of data and presentation? Where's the semantic web 
that's 
been talked about for 10 years? Seriously, today's web sucks, and it doesn't 
look 
good for tomorrow's.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Aaron J. Seigo
On January 4, 2010, Patrick Aljord wrote:
> On Mon, Jan 4, 2010 at 6:10 PM, Aaron J. Seigo  wrote:
> > relative to what we're doing, it is. i somehow doubt it will work at all
> > with remote widgets, for instance.
> 
> Ok I didn't think about remote widgets. Point taken.
> 
> > in particular, it's pretty evident that html5 storage has been designed
> > for use in web browsers. it's really that specific. because we don't use
> > html anywhere else, right? *sigh* the people looking after the web
> > standards are truly myopic.
> 
> I just assumed that the web plasmoid was done to write browser or web
> apps in plasmoids.

it's more the other way around: the idea is to write plasmoids using web 
technology. yes, you can certainly shove a regular web app into a plasmoid 
using this script engine, but that's not the main reason behind it.

a webkit plasmoid should still exhibit the behaviour of a plasmoid (e.g. it 
should be remotable, themable, etc). it should still have access to things 
that we can provide in a nicer / more powerful way and allow for the creation 
of items that can be stacked together to create larger applications (the whole 
"widget" idea in Plasma).

a lot of people know/understand html/js and there are a lot of resources that 
are easy to get to using html/js; the webkit script engine provides a bridge 
between Plasma and those advantages. it doesn't, however, turn Plasma into a 
bunch of small web browser frames. we already have a widget for that :)

the browser-centric features in the html standard are therefore of less 
interest than the general render/fetch/run javascript features.

> > but if the world goes "all in" on the web technology
> > boat 100% we will be in a world of pain as time goes on.
> 
> I don't think so, stuff like canvas, web sockets, fast js engines,
> webgl or even native client will turn the browser into a powerful
> platform not only for traditional web apps but I guess time will tell.

"web services" are certainly a "permanent" part of computing; the browser and 
html-for-the-browser i doubt (at least as an app dev platform). it's been 
tried numerous times and tends to fail for the same reasons, despite all the 
apparent upside to such things.

in the end all they are doing is, at best, reinventing what we already had on 
client side computing 10+ years ago only with far more overhead. the saving 
grace? it comes with networking and advanced text and image rendering built in 
and a well thought out deployment strategy.

given the amount of resources being thrust into it, it's a really stupid 
approach to the problems of network access, rendering and deployment. only 
deployment is even remotely difficult, and even that has reasonable solutions. 
solving a "5% of the cost" problem by spending the other 95% all over again 
(and so far poorly) is insane.

web apps will certainly get more advanced. the resources pouring into that 
will ensure it happens. but those working on such things really ought to lift 
their heads up to get some perspective on what people use, want and need 
combined with what else is out there that makes sense in a complimentary 
fashion. some research about how new technology tends to displace rather than 
replace might even be useful.

instead, we'll spend another N years making slower progress in the tech 
industry than we really ought to due to the spending decisions of certain 
large companies. which is to say, business as usual. ;)

> > thoughts/ideas/improvements/refinements?
> 
> I like your version with no namespace pollution better:

:)

> > var storage = new Storage
> > storage.document = noteId()
> > storage.store("text", noteText())
> 
> Interestingly, the couchdb guys wrote an API on top of html5 storage
> to turn it into a key value store, it looks like this in JS:

yes, the storage side could be almost anything really. we'll have to explore 
more as to what would work out best. for Plasma, it should be something that 
doesn't require an html5 runtime, however, for the other languages and 
bindings out there.

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Patrick Aljord
On Mon, Jan 4, 2010 at 6:10 PM, Aaron J. Seigo  wrote:
>
> relative to what we're doing, it is. i somehow doubt it will work at all with
> remote widgets, for instance.

Ok I didn't think about remote widgets. Point taken.

>
> in particular, it's pretty evident that html5 storage has been designed for
> use in web browsers. it's really that specific. because we don't use html
> anywhere else, right? *sigh* the people looking after the web standards are
> truly myopic.

I just assumed that the web plasmoid was done to write browser or web
apps in plasmoids.

>
> but if the world goes "all in" on the web technology
> boat 100% we will be in a world of pain as time goes on.

I don't think so, stuff like canvas, web sockets, fast js engines,
webgl or even native client will turn the browser into a powerful
platform not only for traditional web apps but I guess time will tell.

> thoughts/ideas/improvements/refinements?


I like your version with no namespace pollution better:

> var storage = new Storage
> storage.document = noteId()
> storage.store("text", noteText())

Interestingly, the couchdb guys wrote an API on top of html5 storage
to turn it into a key value store, it looks like this in JS:

var jsondb = new JSONDB("dbname");

jsondb["some_key"] = {"some":"json"};

jsondb.forEach(function(key, value) {
  // in order traversal
});

jsondb.forEach(function(key, value) {
  // reverse order traversal
}, {
  "descending":true
});

jsondb.forEach(function(key, value) {
  // inorder traversal,
  // starting from "startkey",
  // ending with "endkey"
  // you can use throw() to stop traversal
},{
  "startkey":"a",
  "endkey":"z"
});

jsondb.forEach(function(key, value) {
  // reverse order traversal, starting from "startkey"
  // you can use throw() to stop traversal
},{
  "startkey":"z",
  "descending":true
});

// delete a btree
JSONDB.drop("dbname");

http://github.com/jchris/WebWorkerStorage/blob/ba716338d2627377fb1369193d7bf5dcf96b7ddd/JSONDB.md
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Aaron J. Seigo
On January 4, 2010, Patrick Aljord wrote:
> On Mon, Jan 4, 2010 at 4:23 PM, Aaron J. Seigo  wrote:
> > On January 4, 2010, Patrick Aljord wrote:
> > > Could be, but the thing would be to use web technologies only.
> > 
> > if i understand it correctly, the request is for easy access to data
> > persistence (separate from configuration data), correct?
> 
> Correct. The reason I'm insisting (and sorry if I sound annoying) it's
> because when it comes to the web plasmoid at least, it makes sense to make
> use of web technologies as much as possible IMO, it's also easier for
> portability (if I want to reuse the widget with apple dashboard widgets or
> windows widgets). Also, html5 storage is not a toy, it's used by google on
> the iphone for example and will get bigger with the time.

relative to what we're doing, it is. i somehow doubt it will work at all with 
remote widgets, for instance. there are lots of technologies out there used by 
all sorts of products, people and projects. use alone does not make it 
suitable, nor does it make it "non-toy". NASA uses relatively ancient CPUs, 
things we'd call "toys" in the modern world, on many/most of their missions. 
the use of those CPUs in multi-billion dollar cutting edge space projects does 
not make them even remotely interesting for Plasma, however.

in particular, it's pretty evident that html5 storage has been designed for 
use in web browsers. it's really that specific. because we don't use html 
anywhere else, right? *sigh* the people looking after the web standards are 
truly myopic.

yes, i think that much of what's going on in web technology today is highly 
short sighted and severely limited. i've seen these cycles before, and what 
we're witnessing imho is "shortest path" development by people who are 
actually interested in something completely different (providing large server 
farm backed services) from what they are producing in this case (client side 
technology to display content and provide interaction). some great stuff is 
happening, certainly, but if the world goes "all in" on the web technology 
boat 100% we will be in a world of pain as time goes on. we will be severely 
limited in what we are able to do and severely locked into some very narrow 
ways of working.

the world is slightly more interesting and complex than html5 (or any 
subsequent numbering of that standard will ever likely be) and i refuse to let 
ourselves be limited by it. we can work with it, adopt and adapt, integrate, 
etc, absolutely! but limiting ourselves to its limitations? no.

the reverse is also true, btw. what we do in Plasma isn't meant to be able to 
solve all the problems the html people face, and some of the things we're 
doing are "toy like" in their problem space, i'm sure.

it would be nice if we could all realize that and start using good solutions 
for the problem instead of trying to shape problems around ad-hoc solutions 
created elsewhere. it's a fool's errand.


> But yeah, having
> data persistence would be good even if we're not using html5 storage.

let's define an API for this, then. something we can use in any / all 
plasmoids and commit to it actually doing what we need.

as Chani notes, this might be best backed by Akonadi. or it may be better 
being backed by something like couchdb, or even as simple as sqllite. either 
way, that should be an implementation detail. my biggest concerns are:

* a good API (obviusly :)

* maybe async so that we have greatest flexibility and can even get remote 
support for free, e.g. by using Plasma::Service

* easily travel with the containment / applet configuration. i really don't 
want to see a proliferation of files just because applets store data and all 
the trouble (performance, maintenance) that comes with

so we need to solve:

* storage
* API
* mechanism

for "mechanism" i'd prefer a Plasma::Service (i don't think pairing it with a 
DataEngine in this particular case is the best option as they are implicitly 
shared, so we can't keep data published using a DataEngine private); storage 
is a technical detail which requires some research; API is the easy entry 
point and the part that probably most interests you, Patrick...

so let's start there perhaps.

we need to be able to store and fetch little bits of data. is key/value alone 
enough? 

*  store(key, data)
*  retrieve(key)
*  remove(key)
*  exists(key)
*  listAllKeys()
*  clear()

we could make it so that the service requires an applet associated with it and 
keep its requests to only entries keyed under that applet's id? if we go with 
the Plasma::Service approach, we offer the ability for multiple "documents" 
such as couchdb provides. that would add the following API:

*  listAllDocuments()
*  setCurrentDocument()
*  currentDocument()

using Plasma::Service, this would give us something like:

Service *s = Plasma::Service::load("storage", this);
s->setDestination(noteId());
KConfigGroup op = s->operationDescription("store");
op.writeEntry("

Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Patrick Aljord
On Mon, Jan 4, 2010 at 4:23 PM, Aaron J. Seigo  wrote:

> On January 4, 2010, Patrick Aljord wrote:
> > Could be, but the thing would be to use web technologies only.
>
> if i understand it correctly, the request is for easy access to data
> persistence (separate from configuration data), correct?
>
>
Correct. The reason I'm insisting (and sorry if I sound annoying) it's
because when it comes to the web plasmoid at least, it makes sense to make
use of web technologies as much as possible IMO, it's also easier for
portability (if I want to reuse the widget with apple dashboard widgets or
windows widgets). Also, html5 storage is not a toy, it's used by google on
the iphone for example and will get bigger with the time. But yeah, having
data persistence would be good even if we're not using html5 storage.
It looks like it's qt bug though
https://bugs.webkit.org/show_bug.cgi?id=28682 and maybe we'll get html5
storage for free with the next qt version :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Aaron J. Seigo
On January 4, 2010, Patrick Aljord wrote:
> Could be, but the thing would be to use web technologies only.

so now we're back to "why?" the answer to which seems to be "ease of use". 
now, since storing things using html5 dbs is really not going to work out 
overly well for plasmoids (these kinds of "web technologies" border on toy 
status relative to what we need), the question becomes how we can make it easy 
enough that there's no (or at least less ;) temptation to go the "web 
technologies" route.

so, again ... let's try and collect some requirements and then see if we can't 
come up with a solution for it.

if i understand it correctly, the request is for easy access to data 
persistence (separate from configuration data), correct?

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Patrick Aljord
On Mon, Jan 4, 2010 at 3:45 PM, Chani  wrote:
>
> > HTML5 storage would allow making apps such as todo lists, note taker, or
> > whatever that could make use of a db without the need of writing or using
> a
> > data engine. Not perfect but nice.
>
> kinda sounds like data you'd want to access through akonadi...?
>
>
Could be, but the thing would be to use web technologies only.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Chani
On January 4, 2010 10:02:29 Patrick Aljord wrote:
> On Sun, Jan 3, 2010 at 11:39 PM, Aaron J. Seigo  wrote:
> > and probably give poor, or even incorrect, results. what exactly are you
> > wanting to accomplish?
> 
> HTML5 storage would allow making apps such as todo lists, note taker, or
> whatever that could make use of a db without the need of writing or using a
> data engine. Not perfect but nice.

kinda sounds like data you'd want to access through akonadi...?

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-04 Thread Patrick Aljord
On Sun, Jan 3, 2010 at 11:39 PM, Aaron J. Seigo  wrote:
>
> and probably give poor, or even incorrect, results. what exactly are you
> wanting to accomplish?
>
>
HTML5 storage would allow making apps such as todo lists, note taker, or
whatever that could make use of a db without the need of writing or using a
data engine. Not perfect but nice.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Aaron J. Seigo
On January 3, 2010, Patrick Aljord wrote:
> Ok, I tested in arora and I get the same error so it's probably Qt related.
> It would be cool to have that though, it would enable to write real
> "desktop web app" like adobe air, I know I can use data engines but having
> that would be great too and easier for web devs.

and probably give poor, or even incorrect, results. what exactly are you 
wanting to accomplish?

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Patrick Aljord
On Sun, Jan 3, 2010 at 10:54 PM, Patrick Aljord  wrote:

> On Sun, Jan 3, 2010 at 9:18 PM, Aaron J. Seigo  wrote:
>>
>> anything else?
>>
>>
> Maybe this is not related but html5 storage doesn't seem to work, I get
> this error when starting the plasmoid:
>
>

Ok, I tested in arora and I get the same error so it's probably Qt related.
It would be cool to have that though, it would enable to write real "desktop
web app" like adobe air, I know I can use data engines but having that would
be great too and easier for web devs.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Patrick Aljord
On Sun, Jan 3, 2010 at 9:18 PM, Aaron J. Seigo  wrote:
>
> anything else?
>
>
Maybe this is not related but html5 storage doesn't seem to work, I get this
error when starting the plasmoid:

"Failed to open the database on disk.  This is probably because the version
was bad or there is not enough space left in this domain's quota" (I do have
plenty of disk space)

This is the example I used: http://webkit.org/demos/sticky-notes/ you can
just copy and past the code of that page into main.html of a web plasmoid.
It would be good also if when restarting plasma, it would remember what was
in the database.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Aaron J. Seigo
On January 2, 2010, Petri Damstén wrote:
> I think dataengines in webkit plasmoids have worked since KDE 4.3.

since we're talking about webkit plasmoids (thread hijacking, so 
rude!) ..

.. there are some things that could be improved for the webkit plasmoids. it 
might be helpful to compile a list and then either create a TODO in svn or on 
techbase.

here's my short list:

* the context menu has things like "reload" which obviously don't work 
properly. those items should be disabled.

* there is the temporary file that is created to hold the style sheet. highly 
inefficient; see the comments in PlasmaWebApplet::makeStylesheet()
for my thoughts on this

* documentation. who knew that there were calls to JavaScript functions called 
themeChanged, init, dataUpdated and configChanged that can (and often are) 
made?

anything else?

(i need to compile a similar list for the QScript engine as well; it too has 
its warts)

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Aaron J. Seigo
On January 3, 2010, Patrick Aljord wrote:
> It would be cool if there was a way to start the webkit web
> inspector from the web plasmoid. Any idea if that is possible?

svn up in kdebase/workspace/plasma/generic/scriptengines/webkit :)

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-03 Thread Patrick Aljord
I saw you committed your changes, looks cool. I used to test my plasmoids in
firefox with firebug but now using window.plasmoid makes the whole thing
fail. It would be cool if there was a way to start the webkit web inspector
from the web plasmoid. Any idea if that is possible?

Thanks in advance,

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


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-02 Thread Aaron J. Seigo
On January 2, 2010, Petri Damstén wrote:
> On Saturday 02 January 2010 03:56:48 Aaron J. Seigo wrote:
> > On January 1, 2010, Patrick Aljord wrote:
> > > I just read a comment by Aaron saying that DataEngines can be accesed
> > > from JavaScript in the Web Plasmoids. I tried to figured how it can be
> > > done but couldn't so far. Any clue? :)
> > 
> > kdeexamples/plasma/webkit/plasmoids/
> > 
> > requires today's trunk for everything to work perfectly
> 
> I think dataengines in webkit plasmoids have worked since KDE 4.3.

ugh, yes, indeed. (been looking through the svn history this morning, though 
the moving of things around in trunk, e.g. the scriptengines from 
workspace/plasma/scriptengines to workspace/plasma/generic/scriptengines, has 
made that a lot more difficult). the problem is that the API is utterly unlike 
the other scriptengines and the "tests" that were in the webkit/tests/ 
directory since day 1 of this script engine's existence  were completely 
ignored by subsequent work and they stopped functioning. funny and sad :) 

(i've since moved the data engine "test" to kdeexamples and spified it up a 
bit more)

right now there are two objects in the JS of the webkit plasmoids: "plasma" 
and "applet". "plasma" contains one method: "knownDataEngines". this is the 
old style API from 4.2, even, and should be listAllDataEngines. besides that, 
it really doesn't make sense to have two different objects, one which has 
exactly one function in it. confusing++, when one will do just fine. moreover, 
we are calling the object "plasmoid" in the QScript-driven JavaScript 
ScriptEngine, and "applet" in the WebKit one. the lack of consistency isn't 
good.

it sucks to change the API at this point, but it doesn't look like this API 
was very well groomed to start with. we've changed some of the API in the 
JavaScript API as well in 4.4, so i'd like to get this all "right" for 4.4 (as 
much as we can do such a thing) and commit to API stability from 4.4 on for 
both JavaScript and WebKit driven plasmoids.

i will commit shortly. sorry for breaking your plasmoids with this, but the 
fixes are easy and should never have been necessary if we'd been watching over 
this script engine with more diligence and care.

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-02 Thread Petri Damstén
On Saturday 02 January 2010 03:56:48 Aaron J. Seigo wrote:
> On January 1, 2010, Patrick Aljord wrote:
> > I just read a comment by Aaron saying that DataEngines can be accesed
> > from JavaScript in the Web Plasmoids. I tried to figured how it can be
> > done but couldn't so far. Any clue? :)
> 
> kdeexamples/plasma/webkit/plasmoids/
> 
> requires today's trunk for everything to work perfectly

I think dataengines in webkit plasmoids have worked since KDE 4.3. 

Webkit applet using dataengines, config dialog etc.:
http://www.gitorious.org/pdamsten/plasmoids/blobs/master/scriptedimage/contents/code/main.html

Petri


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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-02 Thread Patrick Aljord
On Fri, Jan 1, 2010 at 8:56 PM, Aaron J. Seigo  wrote:
>
> requires today's trunk for everything to work perfectly
>
> enjoy.
>
>
thanks, today's trunk is what will become kde 4.4 right? Or has that moved
to a branch already?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-01 Thread Aaron J. Seigo
On January 1, 2010, Patrick Aljord wrote:
> I just read a comment by Aaron saying that DataEngines can be accesed from
> JavaScript in the Web Plasmoids. I tried to figured how it can be done but
> couldn't so far. Any clue? :)

kdeexamples/plasma/webkit/plasmoids/

requires today's trunk for everything to work perfectly

enjoy.

-- 
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: how can I access DataEngines from JavaScript in the Web Plasmoids?

2010-01-01 Thread Patrick Aljord
For people reading this coming from a google search, Aaron answered me here
http://identi.ca/conversation/17912580#notice-17985515
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel