Talk:Features/Edit panel on Frame


 * 	walterbender: so any thoughts about how to abstract that TextEditor class? maybe even move it outside Browse?
 * 	walterbender: (i don't mean to rush you)
 * lucian_: that is an abstraction problem I have also been strucggling with...
 * 	walterbender: i could make the TextEditor subclass gtk.Widget
 * lucian_: I would prefer to have these edit functions outside... for example, I want to sue Pippy to edit Python code that users modify in Turtle Art rather than putting a Python editor directly into Turtle Art
 * 	walterbender: but it would lose a lot of functionality it has now as a window
 * It would be good to have a general sytles editor that you could use outside of Browse...
 * lucian_: I could use ^^ to edit the styles for the epxort of HTML in Turtle Art for example
 * lucian_: so I am in favor of the stand-alone approach.
 * 	walterbender: but wouldn't that involve the Journal?
 * lucian_: also it keeps the individual activities simpler.
 * lucian_: yes.
 * 	walterbender: i don't really want users to know that there's a style.user.css file somewhere
 * lucian_: you save the styles to the journal and import them into the activity at run time
 * lucian_: why not, if they are editing the style, should they not know that there is an object associated with that edit?
 * lucian_: that they can refer to whenever they want it?
 * 	walterbender: but then how can i include the styles in the SSB bundles created by Browse?
 * lucian_: this is part of the issue I had with Turtle Art... the Rainbow stuff gets a bit in the way...
 * 	walterbender: yeah, it does
 * 	walterbender: why do we need it again?
 * lucian_: I tried to override some imports -- a reload -- in Python, but it was not robust inside of Rainbow... never really got it to work the way I wanted it to...
 * they can import the code from the Journal that they wrote in Pippy
 * 	walterbender: hmm
 * lucian_: the problem I had was that I tried to just import the code as a module from the journal and I ran into Rainbow problems.
 * lucian_: less eloquent and a bit restrictive, as I have trouble with imports
 * 	walterbender: that seems an arbitrary restriction to me
 * 	walterbender: if activities can read the code, they can eval it. so why block imports?
 * lucian_: I think it is a bug.. either in my code or Rainbow
 * lucian_: let me find the ticket that describes some of the approaches I took...
 * walterbender: it's a restriction caused by the way you're doing it
 * silbe: I know, but I tried doing it all different ways, with no luck.
 * silbe: :(
 * 	walterbender: hmm
 * 	walterbender: so i want users to be able to go to userstyles.org, copy/paste some CSS, paste it into and editor and immediately apply it to see how it looks
 * 	walterbender: i'm not sure that effect can be achieved with an external style editor
 * lucian_: I think it can be... perhaps with at most one additional step...
 * lucian_: Rainbow purposefully puts restrictions in place in terms of one activity talking directly to another...
 * lucian_: you may not agree with the rationale, but it is spelled out in the Bitfrost spec.
 * 	walterbender: with an external activity, users would at least have to switch windows to edit and see results
 * lucian_: I argue that editing it a context switch already, so what difference does it make?
 * lucian_: and then the editing experience would be consistent from activity to activity
 * <lucian_>	walterbender: that's biggest incentive for an internal editor. you write CSS in that small window, hit apply (or save) and you can see stuff instantly
 * lucian_: yes. As I said, I think you need to add one step to do it externally: pull the file from the Journal.
 * lucian_: once you have it, you can remember and pull it automatically when you want to revisit the page...
 * lucian_: but the first time, you need that extra step
 * <lucian_>	walterbender: but i'm not comfortable with having a delay between editing css and seeing results
 * <lucian_>	walterbender: right now you don't even need to reload the page, it's really instant
 * lucian_: I think you can work around it as follows:
 * lucian_: (1) download the css into the Journal (you need to download regardless of internal or external)
 * lucian_: (2) open the file into the editor (from the Journal) this is an extra step in the external version
 * lucian_: (3) refresh the browser, which by default is reading from the file you saved to the Journal
 * lucian_: I suppose by automatic, you want to avoid the refresh step in (3)
 * <lucian_>	walterbender: this would be acceptable
 * <lucian_>	walterbender: but it's not acceptable for when you want to tweak css
 * lucian_: I think this will work... It is essentially what I do for Turtle Art
 * lucian_: you lost me again... it is or it isn't?
 * <lucian_>	walterbender: you'd have to (4) find the object in the Journal, open it (5) edit css, save (6), (7) switch to Browse to see results
 * lucian_: no.
 * <lucian_>	walterbender: it's fine for when you initially add a stylesheet
 * <lucian_>	walterbender: but if you want to tweak that css, you have to keep switching
 * lucian_: yes. but you'd be switching between the context of viewing and editing regardless
 * <lucian_>	walterbender: not really, they'd both be visible
 * lucian_: the only difference is you always have to start tweaking by finding the style sheet in the Journal.
 * lucian_: how can they both be visible? Browse runs full screen
 * <lucian_>	walterbender: with an internal editor, they are both visible
 * <lucian_>	walterbender: the editor is a small window
 * lucian_: maybe we should propose an editor extension to the Frame?
 * <lucian_>	walterbender: like having an editor box attached to the frame somewhere?
 * lucian_: yes. that you can drag in and use to edit a small amount of code/text from any activity
 * lucian_: we can add it to the feature requests for 0.86 (and drive Tomeu and Erikos crazy :)
 * <lucian_>	walterbender: a bit like view source, but attached to the frame?
 * <lucian_>	walterbender: i rather like that
 * lucian_: yes...
 * walterbender: just follow the process and everything_will_be_alright
 * lucian_: me too
 * but as sdziallas would say: "you cannot get always what you want"
 * tomeu: even if you wirte the patch yourself? :)


 * tomeu	is now figuring out the features process
 * walterbender: yeah, depends on the patch itself :p
 * tomeu: we need a way to make copy to/frm frame (clipboard) more discoverable. never knew you could drag there. very cute.
 * tomeu: of course... and we can always fork... nutrasweet
 * <lucian_>	walterbender: so for now, i'll try to make a SourceEditor class that inherits gtk.Widget (or gtk.textview)

View Source dialog addition
Hi, have you considered using the view source dialog to make such changes? http://dev.sugarlabs.org/ticket/803#comment:3