PlasMate ~ UI and other stuff

Michael Rudolph michael.rudolph at gmail.com
Sat Oct 24 23:52:49 CEST 2009


On Thu, Oct 22, 2009 at 20:13, Aaron J. Seigo <aseigo at kde.org> wrote:
> On October 22, 2009, Michael Rudolph wrote:
>> 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.
>
> right, so that you can play with it and work on the code at the same time.
> having to switch back and forth, particularly when in the middle of coding
> when you want to check what it was doing exactly, is going to be really
> annoying.
>
> i actually used plasmate last night (including made a couple of commits ;)
> and, yes, it was extremely annoying.
>
>> 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.
>
> With a toolbox you can tear it off and expand it as well.
>
> but now you're talking about using tabs and having them simultaneously
> available so that one can have both the editor and the previewer live; that
> might work out fine as well, but I'd like to retain the ability to have a
> preview beside the editor or outside the window itself.
>
>> 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.
>
> the problem is with the definition of "appropriate options". i am constantly
> going back and forth between the plasmoid as it currently is and the code as
> it currently is and making changes to the code. after some number of changes
> then i restart/reload the plasmoid and test again.
>
> a great example was the javascript animations example i was working on last
> night. there was a problem in two different areas of the example, and i worked
> on one after the other before reloading the widget. after fixing the first
> issue, i looked back at the plasmoid that was still running to re-orient
> myself as to what the second issue was exactly then went back to fixing that.
>
> when i can see both the plasmoid and my code i can bounce between them quickly
> and naturally.
>
> when i can only see either my code OR my plasmoid, i'm hindered in doing so.
>
> so if there's a tabbing system, great. but i don't want to see it end up where
> one can only see the code OR the plasmoid. that's simply inane.
>
> --
> 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,

that's interesting. Your work flow reminds me quite a bit of my own.
But I always attributed that to me being a newbie. I go back and forth
between my code and the resulting program a lot. Usually I'd like to
check if this line needs to end in a semicolon? - No. Colon? - No.
Hmm, perhaps some parenthesis here or there? - Also, nothing. Well,
let's google the error message then! :-)

I thought, once I get the syntax down, programming would become a much
more structured process and I would sit down for at least a couple of
minutes and just write some code. Not letting myself be distracted by
my little program.

I hoped with the preview out of the way, "better" programming would be
encouraged and people could focus on their code better. But when even
pros like yourself work this way, I perhaps need to rethink this
aspect of the design.

Of course, I still maintain, that a separation would make for a much
cleaner interface. Also looking at your latest screencast (I assume
you demonstrate the very plasmoid you mentioned in your email there)
it seems that with my design proposal you could actually bounce a
little quicker between your code and your plasmoid.

You seem to hit "ctrl+s" to save the code, then right mouse button for
the context menu, then reload javascript animation to test it. In my
design you only hit one keyboard shortcut ("ctrl+tab" or "ctrl+2").
Your code will automatically be saved, your plasmoid reloaded and the
tab containing it will be moved under the very spot your eyes are
right now. (this of course assumes, that tab switching will be as fast
as tab switching usually is; if plasmate does it much slower, my whole
design idea is moot.)

This works so seemingly effortlessly because the user tells plasmate,
what he actually wants to achieve: "I want to test now". This can be
communicated in a single command ("ctrl+2") and plasmate can do the
rest, like saving, reloading and whatever else may be appropriate. In
a regular interface you could, hypothetically, hit the right mouse
button to reload the animations, but forget to save the document first
and your computer could not help you, because it does not know, what
you want to do. Sure plasmate aims to be much better in this regard
than kwrite is, but it still lacks the humane characteristics
described above.

So far I haven't found your arguments to be very convincing, as you
haven't found mine to be convincing, so until someone else wants to
refresh the discussion, I'd simply back out, as to not bore anyone
with my (our) stubbornness. :-)

michael


More information about the Plasma-devel mailing list