<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From: Yuen Hoe Lim <<a href="mailto:yuenhoe86@gmail.com">yuenhoe86@gmail.com</a>><br>
<div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">i wonder if a purpose-built tool just<br>
for making theme packages wouldn't be better. what do you think of dropping<br>
themes from the target use cases?<br></blockquote><br>It's all the same for me. Yuen Hoe, Shantanu, what do you think ? <br></blockquote><div><br>I'm not really in position to comment knowledgeably because I don't know anything about theming (yet). It would probably be a little weird though if PlasMate ends up being a complete, one-stop tool for everything else (at least for Plasmoids we're close to and aiming for this) but will never be as such for themes, if I understood Aaron's point correctly.<br>
</div></div></blockquote><div><br>Agreed, that's my point of view indeed.<br>By the way, with theme packaging enabled too, PlasMate won't be a complete Plasma development tool because we still don't provide any Wallpaper plugin support. And, afaik, there is only python bindings for that (apart from c++, of course).<br>
So, should we discard theming support, or add Wallpaper support too (for python at least, and wait for 4.5SC to get js and ruby bindings) and make plasmate complete ?<br>Or simply, release it as it is now, refining the actual features, and listen to users feedbacks ?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>
<br>That's my 2cents. I think Aaron and Diego should probably make the final decision on this (and Shantanu too if you know ought about theming).<br> </div></div>----<br>Jason "moofang" Lim Yuen Hoe<br><a href="http://yuenhoe.co.cc/" target="_blank">http://yuenhoe.co.cc/</a><br>
<br>From: "Aaron J. Seigo" <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>><br>
> > the javascript DataEngine and Runner APIs are not documented. unless<br>
> > someone<br>
> > else get to it, they won't be before 4.5 is out. which is ok, since those<br>
> > Javascript APIs have known (at least to me ;) deficiencies in 4.4. those<br>
> > are<br>
> > really more 4.5 targets.<br>
><br>
> Ok, so should we disable the js ( and ruby ) radio button when selecting a<br>
> runner or dataEgine project, until we get an improved API ?<br>
<br>
yes, probably makes sense. we should make sure that they are enabled by the<br>
time KDE SC 4.5 is available, though. but that's 6 months away :)<br></blockquote><div><br>Nice, it's time to ping kde-bindings guys then :) <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>
> > And theme support is still unavailable, in this current state.<br>
> ><br>
> > theme support would be fairly easy to add, as far as packaging goes, but<br>
> > it will still require an external tool such as Inkscape for the<br>
> > forseeable future. so it will never be "perfect" for theming, it really<br>
> > would be just more of a packaging and previewing tool.<br>
><br>
> Ok, then something like "create the theme directory hierarchy" -> "drag and<br>
> drop svgs and color scheme" -> "preview" -> "publish" should be fine :)<br>
<br>
yes, that's all that's needed.<br>
<br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br></blockquote></div>