<br><br><div class="gmail_quote">2008/7/2 Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wednesday 02 July 2008, Richard Dale wrote:<br>
> > I think that would make sense from the JS point of view too.<br>
><br>
> OK, please find attached a patch to try it out.<br>
<br>
</div>i don't think this makes much sense for ecmascript stuff, it's just another bit<br>
of complexity. i understand why you are doing it for ruby, however, based on<br>
previous conversations we've had.<br>
<br>
so ... the question is how to implement this properly.<br>
<br>
all of this belongs in a PackageStructure: no code in Applet or AppletScript<br>
should be touched. the moment that happens, it's a sign something is wrong =)<br>
<br>
in your patch, by commenting out the setRequred mainscript line in<br>
AppletPackage, it's now impossible to either verify or create packages<br>
properly: with the patch it's completely valid to have plasmoids without<br>
mainscripts. so we don't want that =)</blockquote><div>Yes, I didn't like that which is way I mentioned the whole thing needed more thinking about - which you've now done. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
there are two ways of going about this:<br>
<br>
* define a separate PackageStructure for plasmoid bundles with configurable main<br>
scripts and leave PlasmoidPackage as it is<br>
* benefits: it keeps PlasmoidPackage loading simple<br>
* cons: we now have to define the PackageStructure in all ruby (or whatever<br>
other) metadata.desktop files<br>
<br>
* modify PlasmoidPackage properly and make dynmic-mainscript-location a<br>
possibility for all packages<br>
* benefits: keeps things simpler for dynamic main script location packages:<br>
don't have to define the PackageStructure in the metadata.desktop file<br>
* cons: means we read the PackageMetadata again for every plasmoid loaded<br>
<br>
the latter is *probably* the better of the two options from the user's POV but<br>
is worse from a performance POV.</blockquote><div>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'. <br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
what needs to happen in the code is a protected void<br>
PlasmoidPackage::patchChanged() method needs to be added. this will get called<br>
whenever it's path() changes.<br>
<br>
in that method it will need to create a PackageMetadata for itself and read<br>
out the value of the main script if it exists.<br>
<br>
the default should remain as is.<br>
<br>
i think this will end up need some more API for PackageStructure in 4.2 to:<br>
<br>
* make adjusting existing keys more straightforward<br>
* allow defining which keys are configurable for package creation tools<br>
<br>
anyways, see attached patch. 16 lines of additions, including whitespace;<br>
really only 6 lines of interesting code. it's untested (well it compiles ;)<br>
but it should work by all intentions.</blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
the lack of documentation for this part of libplasma really sucks; i really do<br>
need to do something about that =( it makes it seem like you have to around<br>
changing stuff all over libplasma in big patches instead of just adding 6 new<br>
lines =)</blockquote>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.<br>
<br>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. <br>
<br>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.<br>
<br>-- Richard<br><br></div><br>