Hello, announce the move to kdereview of an applet

[Aaron J. Seigo]

On Sunday 22 March 2009, Wang Hoi wrote:
> 2009/3/22 Albert Astals Cid <aacid at kde.kde>
>
> > Is there any possibility that backends can be automatically configured?
> > Asking the user to run
> >  ibus-daemon --panel=/<your dir>/panel.py
> > is not exactly user friendly
>
> Yeah, i've mail this problem to the author of ibus, it says ibus 1.1.0
> is under development and have some more import things to do.
> (They havn't finished their qt4 immodule yet.)
> So not provide option to specify the default panel like scim now.
> I think this status will change after ibus 1.1.0 finally released.

ok, that's sensible. we'll just wait on the ibus team for that one then :)

> 2009/3/23 Aaron J. Seigo <aseigo at kde.org>
>
> > On Sunday 22 March 2009, Wang Hoi wrote:
> > > Moved to kdereview/plasma/applets/
> >
> > forwarding this to where it belongs: plasma-devel@ ...
> >
> > if we take this same method to every plasmoid out there, we'd have an
> > unthemable mess that artists would no longer have access to. i don't
> > really understand the need for this at all, but as i personally don't
> > really use input method stuff i'm really not going to struggle with you
> > more on the topic. we had a long discussion on it on irc, bu i'm more
> > concerned with having an input method applet in updstream kde finally
> > (something kde1, kde2 nor kde3 managed).
> >
> > was this theming system a functional requirement for the widget by
> > someone? (e.g. a linux distro, or whatever?) was the idea simply to copy
> > what other input method applets on other platforms do?
>
> What does "functional requirement" mean,

i was wondering if someone had directed you that it had to be theme-able in 
this manner or if it was done this way "just because you could" :)

> user can use default theme
> happily if he doesn't like the glitter theme.

yes, it should default to the plasma theme at the very least.

> The idea to theme the panel is copy from input methods under windows,
> there's one Chinese input method, sougou pinyin,

ok, so, this is where we come to a philosophical difference, i suppose. after 
having looked at sougou pinyin it's clear to me that the idea is to create a 
product that people identify with sougou, and that it is thus designed to be 
as crazy and flashy and full of interesting (and some odd) features as 
possible.

an input method widget in plasma should instead strive to be part of the 
workspace. if it is in kdebase (where i honestly think it belongs), it isn't a 
third party add on. it should be an integrated part of the whole, and elegant 
piece of the desktop workspace that blends with everything else.

ask yourself: "would Steve Jobs be ok with something like this widget being 
included with the next Mac OS X release?" Apple strives for elegance. i'd like 
to do that as well, if in our own way.

on the other hand, i hate to say to you: "remove all your hard work or it 
can't go into kdebase!" the compassionate human in me would feel bad about 
that ;)

so my compromise position is this:

	As long as it defaults to the Plasma theme, it can go into kdebase.
	No other widgets should have such theming crazyness, even if kimpanel does.

is that ok with you?

> > instead, implement createConfigurationInterface and add pages to the
> > passed in KConfigDialog like all other widgets.
>
> You are right, need help here,  i don't know how to reuse the config
> page in kcmodule in kconfigdialog,
> I'm new to kconfig, kcfg etc.. stuff.
>
> >From my point of view , i think KCMultiDialog and KConfigDialog has
>
> similar look'n'feel and functionalities.
> And kcmultidialog can be created by merge serveral kcmodule so that
> when i provide config page for backend,
> it can be easily merged into.
> If KConfigDialog provide something like addModule, or somebody teach
> me how to load a kcmodule and get the qwidget to be addPage to
> KConfigDialog, that will be great.

KConfigDialog provides addPage, which you use this way:

dialog->addPage(configuration Page, i18n("Page TItle"), "page_icon");

each tab in your current .ui file would become a separate UI file and you 
would create and call addPage on the dialog handed to 
createConfigurationInterface for each of those layouts.

> I'd like to use KConfigDialog in applet's conifgure, but still provide
> serveral kcontrol modules for systemsettings,

which items should be in system settings? the backend configuration?

> > also, are the icon size and layout strategy settings really needed? can
> > the widget provide sensible defaults for this without user configuration?
>
> Default settings are provided, it can work properly without touch
> these settings.
> These settings are for users who want to tune the applet, eg. if he
> wants to display things vertically to save screen space.

so ... the settings are not _really_ needed? one of the problems with settings 
is that once they are there they can not be taken back (users *hate* that), 
and yet every added item makes it harder to use and the code more complex.

so strive for simplicity.

if you feel the options have value, but that they really aren't something 
people will tweak very often, try just not putting them into the configuration 
interface and let's see if our users actually request those features. we have 
very vocal users who love to tell us what they think :) if they do ask for 
that feature, we just add it back into the configuration interface.

if they don't, then we can avoid burdening the configuration interface with 
those settings.

simplicity, elegance. :)

> > you may find that the applet doesn't behave properly in all cases with a
> > plain QGraphicsView and QGraphicsScene as set up in KIMStatusBar. also,
> > how does this work when used with KIMPanelApplet?
>
> Don't quite understand, can you give me an example how it may behave
> improperly. I use the same QGraphicsWidget both in floating and embbed
> state.
> When it switch from embbed to floating state, a QWidget is created,
> which contains a QGraphicsView, view the same QGraphicsWidget (model),
> The code is quite similar to Plasma::Dialog,

except that Plasma::Dialog uses the Corona itself for all these items. hmmm.. 
looking at the code again i see that it's not the applet itself that ends up 
in there, but the plain QGraphicsWidget that is the input panel. ok .. that's 
not as bad, indeed. usually we stick those things on the corona, however, with 
corona()->addOffscreenWidget(widget); that helps to keep memory overhead down, 
but it's not critical in this case.

> > the backends run as standalone applications? can or does kimpanel start
> > them automatically as needed?
>
> Yeah, but whether It's a standalone application depends on the backend .

makes sense... :)

> > hm... how well does it work on vertical panels?
>
> The theme is all for floating status bar and floating candidate
> window, when embbed into the panel, it use system theme,
> and  try to have the same appearance with notification area.
>
> see the pic (vertical bar):
> http://lh3.ggpht.com/__wNRAxUWzAo/SbJBWdtDRaI/AAAAAAAAAB4/5Nl1oWU4FsM/01.pn
>g

great, so it works nicely there...


thanks for the quick response :)

-- 
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 Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090322/513acdaf/attachment.sig