Talk:Features/Edit panel on Frame

From Sugar Labs
Jump to: navigation, search
<lucian_> walterbender: so any thoughts about how to abstract that TextEditor class? maybe even move it outside Browse?
<lucian_> walterbender: (i don't mean to rush you)
<walterbender> lucian_: that is an abstraction problem I have also been strucggling with...
<lucian_> walterbender: i could make the TextEditor subclass gtk.Widget
<walterbender> 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
<lucian_> walterbender: but it would lose a lot of functionality it has now as a window
<walterbender> It would be good to have a general sytles editor that you could use outside of Browse...
<walterbender> lucian_: I could use ^^ to edit the styles for the epxort of HTML in Turtle Art for example
<walterbender> lucian_: so I am in favor of the stand-alone approach.
<lucian_> walterbender: but wouldn't that involve the Journal?
<walterbender> lucian_: also it keeps the individual activities simpler.
<walterbender> lucian_: yes.
<lucian_> walterbender: i don't really want users to know that there's a style.user.css file somewhere
<walterbender> lucian_: you save the styles to the journal and import them into the activity at run time
<walterbender> lucian_: why not, if they are editing the style, should they not know that there is an object associated with that edit?
<walterbender> lucian_: that they can refer to whenever they want it?
<lucian_> walterbender: but then how can i include the styles in the SSB bundles created by Browse?
<walterbender> lucian_: this is part of the issue I had with Turtle Art... the Rainbow stuff gets a bit in the way...
<lucian_> walterbender: yeah, it does
<lucian_> walterbender: why do we need it again?
<walterbender> 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...
<walterbender> they can import the code from the Journal that they wrote in Pippy
<lucian_> walterbender: hmm
<walterbender> 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.
<walterbender> lucian_: less eloquent and a bit restrictive, as I have trouble with imports
<lucian_> walterbender: that seems an arbitrary restriction to me
<lucian_> walterbender: if activities can read the code, they can eval it. so why block imports?
<walterbender> lucian_: I think it is a bug.. either in my code or Rainbow
<walterbender> lucian_: let me find the ticket that describes some of the approaches I took...
<silbe> walterbender: it's a restriction caused by the way you're doing it
<walterbender> silbe: I know, but I tried doing it all different ways, with no luck.
<walterbender> silbe: :(
<lucian_> walterbender: hmm
<lucian_> 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
<lucian_> walterbender: i'm not sure that effect can be achieved with an external style editor
<walterbender> lucian_: I think it can be... perhaps with at most one additional step...
<walterbender> lucian_: Rainbow purposefully puts restrictions in place in terms of one activity talking directly to another...
<walterbender> lucian_: you may not agree with the rationale, but it is spelled out in the Bitfrost spec.
<lucian_> walterbender: with an external activity, users would at least have to switch windows to edit and see results
<walterbender> lucian_: I argue that editing it a context switch already, so what difference does it make?
<walterbender> 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
<walterbender> lucian_: yes. As I said, I think you need to add one step to do it externally: pull the file from the Journal.
<walterbender> lucian_: once you have it, you can remember and pull it automatically when you want to revisit the page...
<walterbender> 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
<walterbender> lucian_: I think you can work around it as follows:
<walterbender> lucian_: (1) download the css into the Journal (you need to download regardless of internal or external)
<walterbender> lucian_: (2) open the file into the editor (from the Journal) this is an extra step in the external version
<walterbender> lucian_: (3) refresh the browser, which by default is reading from the file you saved to the Journal
<walterbender> 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
<walterbender> lucian_: I think this will work... It is essentially what I do for Turtle Art
<walterbender> 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
<walterbender> 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
<walterbender> lucian_: yes. but you'd be switching between the context of viewing and editing regardless
<lucian_> walterbender: not really, they'd both be visible
<walterbender> lucian_: the only difference is you always have to start tweaking by finding the style sheet in the Journal.
<walterbender> 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
<walterbender> lucian_: maybe we should propose an editor extension to the Frame?
<lucian_> walterbender: like having an editor box attached to the frame somewhere?
<walterbender> lucian_: yes. that you can drag in and use to edit a small amount of code/text from any activity
<walterbender> 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
<walterbender> lucian_: yes...
<tomeu> walterbender: just follow the process and everything_will_be_alright
<walterbender> lucian_: me too
<tomeu> but as sdziallas would say: "you cannot get always what you want"
<walterbender> tomeu: even if you wirte the patch yourself? :)
  • tomeu is now figuring out the features process
<tomeu> walterbender: yeah, depends on the patch itself :p
<daveb> tomeu: we need a way to make copy to/frm frame (clipboard) more discoverable. never knew you could drag there. very cute.
<walterbender> 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