Adding a 'X-Plasma-MainScript' entry to plasmoid metadata.desktop files?

[Richard Dale]

2008/7/2 Aaron J. Seigo <aseigo at kde.org>:

> On Wednesday 02 July 2008, Richard Dale wrote:
> > > I think that would make sense from the JS point of view too.
> >
> > OK, please find attached a patch to try it out.
>
> i don't think this makes much sense for ecmascript stuff, it's just another
> bit
> of complexity. i understand why you are doing it for ruby, however, based
> on
> previous conversations we've had.
>
> so ... the question is how to implement this properly.
>
> all of this belongs in a PackageStructure: no code in Applet or
> AppletScript
> should be touched. the moment that happens, it's a sign something is wrong
> =)
>
> in your patch, by commenting out the setRequred mainscript line in
> AppletPackage, it's now impossible to either verify or create packages
> properly: with the patch it's completely valid to have plasmoids without
> mainscripts. so we don't want that =)

Yes, I didn't like that which is way I mentioned the whole thing needed more
thinking about - which you've now done.

>
>
> there are two ways of going about this:
>
> * define a separate PackageStructure for plasmoid bundles with configurable
> main
> scripts and leave PlasmoidPackage as it is
>        * benefits: it keeps PlasmoidPackage loading simple
>        * cons: we now have to define the PackageStructure in all ruby (or
> whatever
> other) metadata.desktop files
>
> * modify PlasmoidPackage properly and make dynmic-mainscript-location a
> possibility for all packages
>        * benefits: keeps things simpler for dynamic main script location
> packages:
> don't have to define the PackageStructure in the metadata.desktop file
>        * cons: means we read the PackageMetadata again for every plasmoid
> loaded
>
> the latter is *probably* the better of the two options from the user's POV
> but
> is worse from a performance POV.

Yes, I think having configurable 'top thing' to load at start is a pretty
general requirement, not just for scripting. For example, the name of a C++
executable or a C# .dll might not be named 'main'.

Really for Ruby the name 'clock.rb' is needed to know that the main class
inside is called 'Clock' and 'analog_clock.rb' would have 'AnalogClock'
inside it. At the moment the main class is always called 'Main' and each
applet have a different namespace for it derived from the package name.


>
>
> what needs to happen in the code is a protected void
> PlasmoidPackage::patchChanged() method needs to be added. this will get
> called
> whenever it's path() changes.
>
> in that method it will need to create a PackageMetadata for itself and read
> out the value of the main script if it exists.
>
> the default should remain as is.
>
> i think this will end up need some more API for PackageStructure in 4.2 to:
>
>        * make adjusting existing keys more straightforward
>        * allow defining which keys are configurable for package creation
> tools
>
> anyways, see attached patch. 16 lines of additions, including whitespace;
> really only 6 lines of interesting code. it's untested (well it compiles ;)
> but it should work by all intentions.

You're reading it out of KConfigGroup, whereas I was assuming it was coming
via a KTrader offer. That aspect of the package stuff is confusing - I'm not
sure when one or the other mechanism is used. plasmapkg renames
metadata.desktop on installation, but perhaps you still use if for
KConfigGroup metadata lookups from your code.

>
> the lack of documentation for this part of libplasma really sucks; i really
> do
> need to do something about that =( it makes it seem like you have to around
> changing stuff all over libplasma in big patches instead of just adding 6
> new
> lines =)

Yes, but there is nothing wrong with being forced to read and understand all
the code, and coming up with something a bit sub-optimal to get discussion
going - so I'm not too bothered about docs as long as the code is clear,
which it is mostly.

Apart from being able to change the name from 'main' to 'clock.rb' another
issue is just being able to have a language extension such as 'main.rb'.
That would be the same for all ruby plasmoids, and main.js for all
Javascript ones.

I'm not sure how people will work on scripting applet code - at the moment I
have 'tiger/contents/code/main.rb' and work on it in situ. So it matters if
it is 'main' rather than 'main.rb' for editing with syntax highlighting.
Perhaps it would be better to have all the sources and resource in a top
level directory, and only actually move them into the package structure on
installation. So you would edit 'main.rb' in the top level and that would be
moved to 'main' inside the package. That gets round the problem of plasmapkg
installing all your .svn dirs too.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080703/a589b272/attachment.html