<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I don't think the preview should always be shown.<br clear="all"></blockquote><div><br>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.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">But I hold, that one can't even get such a preview feature into the<br>
"good" state. For various reasons:<br>
- It would have to be "live", which means constantly saving and<br>
reloading and puts an unnecessary load on the system.<br></blockquote><div> </div><div>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... <br>
</div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>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 =)<br>
</div></div></blockquote><div><br>Ok cool :) That's why I wanted to ping you guys on the list before diving in myself. Glad I did :)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>
As regarding the directory tree dock widget, what about setting a QTableWidget as PlasMate central widget and inserting it as first widget?<br></div></div></blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>We could also insert a new tab for each file the user wants to edit, so we can have multiple files editing for free :)<br>
</div></div></blockquote><div><br>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 :)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>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 ;)<br>
</div></div></blockquote><div><br>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 :)<br>
<br>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?<br>
<br>----<br>Jason "moofang" Lim Yuen Hoe<br><a href="http://yuenhoe.co.cc/" target="_blank">http://yuenhoe.co.cc/</a><br></div></div>