On Thu, Oct 22, 2009 at 20:13, Aaron J. Seigo <ase...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel