10,505
edits
Changes
Talk:Features/Edit panel on Frame (view source)
Revision as of 12:28, 6 July 2009
, 12:28, 6 July 2009Created page with ':<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) :<wal…'
:<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
|<-- iwikiwi has left freenode (Client Quit)
:<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)
:<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
|<-- iwikiwi has left freenode (Client Quit)
:<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)