hi,<br><div><div><br>
It's nice to see that finally there is something going in plasma in
"open" . Although I know that the core-work were going with full pace
behind the doors :-) .<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">applet theming needs to be centralized. right now it's a PITA to try and get<br>all your SK widgets looking the same. and they look far nicer when they do. i
<br>have noticed some graphical themes are carried across SK widgets, but it's<br>pretty haphazard. the biggest thing is the widget background and borders,<br>really. these are already written in as part of the plasma theme, so that
<br>shouldn't be a big issue. and this way the user can select a given widget<br>style and all the widgets will match. there is no reason "custom backgrounds"<br>for applets can't be added, of course. but applets shouldn't have to care
<br>about it; this should be handled by the AppletComposer.</blockquote><div><br>
I could understand it, please clarify. AFAIK SK widgets are native kde
widgets with its own customisations. Those customisations are defined
by theme writer. If they don't, it will fall back to default. So,
where this theming funda comes from? I may be missing something
probably.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">applet configuration should be standardized. requiring PyQt is a bit much (and<br>
becomes insane if people will be mix'n'matching applets in different langs),<br>and we can do better than using KDialog. i'm thinking we use KConfigXT XML<br>and include those in the applet bundle. an AppletConfigXT class would then
<br>read in the KConfigXT XML and create an appropriate KConfigSkeleton item.<br>combined with a designer .ui file, this can create automagically working<br>config dialogs. designer files can be instantiated at runtime (obviously) and
<br>connected with a KConfigSkeleton object (also obvious =). so an applet could<br>simply call:<br><br> showConfig();<br><br>and given a .ui file get a nice shiny GUI. if the .ui is missing, we could<br>provide a standard (boring) widget or even rely on KConfigDialog to autogen
<br>the UI for us.</blockquote><div><br>
I am okay with the idea of configurationXT . I am just thinking about
signals and slots though. I think, there XML file or UI file can be
extended to call the slots or generate signal, when user does something
to UI, and then those signal/slots can be used by whatever language
theme for doing something.<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">applet bundles: applets should come with bundles. C++ based applets will ship<br>
both a library and a bundle,</blockquote><div><br>
Some problems with compiled languages. The library would be compatible
with the underlying system or not.....who knows ? Some ABI issues,
versioning issues etc ?<br>
I think, that's where scripting langauges have advantages.<br>
</div></div><br>
I am sorry, I am to tired to think atm, so may be I would have done some mistakes in the mail.<br>
<br>
Vinay Khaitan<br>