Also, if someone has a log of the meeting, or can reply back with the points discussed after the netsplit happened yesterday, please reply to this mail with it.
On Fri, Mar 5, 2010 at 4:25 PM, Aaron J. Seigo <ase...@kde.org> wrote: > On March 5, 2010, Yuen Hoe Lim wrote: >> I forgot to raise this in the irc meeting earlier :( I think we should >> consider the possibility of having the previewer as its own separate >> process. > > it would be nice. i don't think it's critical for the first release, though. > please add it to the wiki if you haven't already. > >> This is good imo because >> >> 1) A crashing plasmoid won't bring Plasmate down with it. Currently if a >> plasmoid crashes on-load, every subsequent loading of the project will >> probably also result in a crash (because the previewer automatically loads >> the plasmoid). And that's pretty bad if Plasmate crashes along - the >> project will become unusable. > > of course, crashes in the plasmoid should only be coming from the c++ > underneath ... which also shouldn't happen. > > still, it can happen. what i'd suggest for now is not showing the preview by > default and leaving that up to the developer to start by pressing the preview > button. > >> 2) I think it would be very useful if we could eventually capture (and >> display in some way) the current plasmoid's console output messages, so >> that it's easier for users to debug runtime errors and such. Currently >> those output messages become Plasmate's console output, and I'm not sure >> if there is a way for Plasmate to grab them. > > this won't be solved by putting it out of process since it will then get all > the debug output from all of libplasma when really we probably just want the > widget output. instead, we should probably have a way to put a print/debug > shim into the script environment that would get us what we need. > > given that plasmate attempts to support python and ruby as well as javascript, > this is going to be much more difficult than necessary. *sigh* > >> But then if the previewer becomes it's own separate process, will it still >> be possible for it to live in a dockwidget? > > we could xembed it. > > -- > 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 > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Shantanu Tushar (UTC +0530) http://www.shantanutushar.com _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel