PlasMate ~ UI and other stuff

[Aaron J. Seigo]

On October 18, 2009, Michael Rudolph wrote:
> On Sun, Oct 18, 2009 at 18:22, Marco Martin <notmart at gmail.com> wrote:
> > not sure about making it an overlay: has it enough "value" to be always
> > shown or can be usually hidden and shown only when needed?
> 
> Hi Yuen Hoe, hi Marco,
> 
> I don't think the preview should always be shown.
> 
> If the preview feature were really, really good, it would still also
> be a distraction.

the entire point of using plasmate is to create a plasmoid/dataengine/runner. 
it is the sole reason one is using it. i can't see how being able to easily 
glance at what you have so far in your project is a distraction.

> Writing a plasmoid and testing it are two separate
> tasks or steps in the work flow, so it would be best to also separate
> them in the user interface.

here's the use case:

* i write a new plasmoid with three buttons and a text area that shows some 
data based on which button i press

* i go to the preview area and click on a button and see it does nothing 
(oops! i connected the wrong signal!); i fix this in the code

* i click a different button that does work and notice that the text area's 
alignment isn't what i wanted so i change that in the code too

* i hit reload in the preview area and get to test my changes

this kind of tight code-test cycle is very productive for such components and 
should be made easy. breaking it up into a multi-stage "work flow" would make 
it unnecessarily hard to do such development.

if it's a distraction to you or you want to create a multi-stage workflow, you 
can close/open or just move the preview elsewhere.

> But I hold, that one can't even get such a preview feature into the
> "good" state. For various reasons:
> - It would have to be "live", which means constantly saving and
> reloading and puts an unnecessary load on the system.

a) "unnecessary load" isn't bad when it comes to development tools if it makes 
the tool more useful. unlike the desktop shell which must get out of the way 
of applications at all opportunities, an app like plasmate can use the CPU 
anyway it likes if it improves the experience

b) "live" makes no sense; only the user knows when it makes sense to reload 
the widget after they've done a certain amount of coding. so this is a moot 
point.

> - It's not obvious how to preview a data engine or a runner. (not
> really a big problem)

plasmaengineexplorer shows how this could be done. and for previewing runners 
it would be the same thing: re-run a query or set of queries. they are 
input/output beasts, so one creates a set of inputs and then the output can be 
displayed.

fancier ways to drive this (e.g. scripts containing data sets and/or mappings 
between input and expected output) are easy to imagine as well.

> - For most plasmoids previewing doesn't make much sense, they need to
> be "pre-interacted with", which further supports the claim, that
> writing and previewing are separate tasks.

i'm not sure what you mean by "pre-interacted" with, but i do know from 
developing plasma applets and kicker applets before that that the most common 
thing to do is "write some code, compile it, start the applet in the single-
window launcher (plasmoidviewer for plasma, i forget what the kicker analog 
was called now, even!) and play with it, repeat. i don't know of any plasmoids 
where this isn't the case.

if you mean that it would be nice to have the ability to script some "before i 
start testing this feature, these N things need to be done" that'd be really 
cool. it would also be way beyond what we have now with the existing tools, so 
it isn't a deal breaker if we don't have such a feature right now.

> An additional advantage of not always showing the preview is that the
> user interface won't be that cluttered.

given that the entire point of using plasmate is to create these objects, 
saying that showing the object somewhere is clutter is a bit odd. that said, 
you can easily close/move a toolbox window.

-- 
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 Development Frameworks
-------------- 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/20091019/a5ad40c8/attachment.sig