PlasMate ~ UI and other stuff

[Michael Rudolph]

On Mon, Oct 19, 2009 at 21:20, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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
>

Hi Aaron,

I don't think we disagree on as many points as your reply makes it
seem. We just draw different conclusions for how the work flow should
be presented to the user.

I assume, that there will be keyboard shortcuts (like "ctrl+1",
"ctrl+2", ...) to move between the different steps of the work flow.
So the user would be coding away in his edit tab, then, when he needs
to test his code, he'd hit "ctrl+2" to open the preview tab, where his
freshly reloaded plasmoid waits for him for inspection. After he's
done, he hits "ctrl+1" to return to the edit tab. Or he hits "ctrl+3"
to submit his current code to git. Of course there's also a tab bar,
so should the user prefer to use the mouse, he can do so as well. And
he wouldn't need a single additional mouse click compared to your
design.

The "disadvantage" would be, that there's no preview area next to his
editor. But it seems it would only be a picture of the latest
save-point anyway.

The advantage would be, the whole window can be used to display the
plasmoid and therefore the possibilities for testing are much greater.
This might not be an advantage in all situations, but it's also not a
disadvantage.

Collapsing the preview dock, like you suggest, sounds like a solution,
but I'm really not in favour of it. Because it means the user would
have to manually manage the toolbox window. With a tab bar it's much
easier to make plasmate context-aware, so it reacts to what the user
is doing and can present appropriate options.

Again, I agree with most of what you said in your reply, but for the
above reasons, it leads me to a different conclusion.

michael