PlasMate ~ UI and other stuff

[Yuen Hoe Lim]

>
> I don't think the preview should always be shown.
>

I think I'm starting to agree. Most actual widgets I tried out also required
more real-estate for proper testing/interaction than a small dockedwidget a
quarter the size of the window can provide. Think I'll move the previewer
into its own tab and see what happens.

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

Currently it isn't "live" in that sense - there is a "refresh" button in the
overlay toolbox that updates the state of the applet onclick. I personally
like this better than live - I won't want to see what horrid state the
applet is in mid-code and am only interested in previewing after I finished
coding a milestone and want to test it :) Which I suppose further supports
the idea that they separate tasks like you said...

Yup, I'm currently working on it in order to replace QListWidget with a more
> flexible QTableModel ( and the same for the Workflow sidebar ); currently
> I'm busy because I'm writing a presentation for the LinxDay, so be patient
> =)
>

Ok cool :) That's why I wanted to ping you guys on the list before diving in
myself. Glad I did :)


> As regarding the directory tree dock widget, what about setting a
> QTableWidget as PlasMate central widget and inserting it as first widget?
>

Not sure I like that idea - I like being able to dock/undock the editor tree
and move it all around :) Plus after we get the sidebar or timeline or both
out of the way, there shouldn't be any issues with the editor tree UI
staying the way it is anymore?


> We could also insert a new tab for each file the user wants to edit, so we
> can have multiple files editing for free :)
>

Think tabs might add a bit of clutter to the UI, but I don't think we need
tabs - the editor tree can effectively work like tabs. ie. when you select
an item on the tree it'd be equivalent to selecting a tab of that item, and
if you select another item with unsaved changes on this one, those unsaved
changes will still be there when you select the item again (could probably
have some sort indicator on the tree UI to mark which files have unsaved
changes a'la Kate). Should work since anything at all that the user might
need to edit will be in the editor tree anyway :)


> Yeah, I love this concept because describes perfectly how should work:
> hidden when its not needed, and displayed with a fancy graphics when we need
> to provide information/perform new actions ;)
>

Agreed :) Think there's no real reason the timeline should be displayed all
the time. I have 0 idea on the what and how of that 'fancy graphic' though,
but that can probably wait till later :)

Oh, one more thing I forgot to mention - after separating the editor tree
out into a dockwidget, I've been finding it rather natural to have the
editor tree visible all the time, so I was thinking we could probably remove
the 'edit' tab from the sidebar/workflow menu. When the user wants to edit
something - he could just click an item in the tree and the central widget
will automatically change to the appropriate editor with the item loaded,
instead of click 'edit' then select the item. What do you all think?

----
Jason "moofang" Lim Yuen Hoe
http://yuenhoe.co.cc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20091019/f280bc78/attachment.htm