Re: [Sugar-devel] View Source Code [BROWSE]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
That feature is already kind of there. Open browse. Then open view source
from the frame (ctrl-shift-v probably). The current HTML is displayed under
"current activity source", the default tab.
Thanks,
Sam
On 5 May 2016 5:20:08 PM AEST, Utkarsh Tiwari
wrote:
>Hi,
>I need to add the facility to view the source code of the current
>open webpage in a new tab. I tried that by fetching the source code
>using webkit and displaying it via javascript query
>'browser.execute_query('JS_Query')' but have been some problems while
>parsing the html code to string.
>
>Could anyone here suggest any other possible way to get about it?
>
>Thanks,
>Utkarsh Tiwari
>___
>Sugar-devel mailing list
>Sugar-devel@lists.sugarlabs.org
>http://lists.sugarlabs.org/listinfo/sugar-devel
- --
Sent from my phone. Please excuse my brevity.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQJOBAEBCgA4BQJXK7OlMRxTYW0gUC4gKE1vYmlsZSBOZXh1cyA0IEN5YW5vZ2Vu
KSA8c2FtQHNhbS50b2RheT4ACgkQvdyMwXnhrYPL+w//X67nooKXUUUwfWwMtG1b
I2+36xz1ffsU6zof27GzuwndDJn7TCXUQ9+ELycQcMQA0498ma21kOQMT7wqcSg+
q21YLE+4P67gRFPURgoRGH24/3uC91IrdH5Tq27A2EEMsNe/Mn7X+a3JnP8IvjLk
2/22hRygbZEYIlHpqAnZnz1LQ6aeLsQiK6CebXUkb/CPAzYMIpn6TYGb3TtLc6bL
K+bHh/MCnJBAmuaxPztIUgLsNlgW9oK0IncVIvw6VBJ2CUo7/XwCl7Dmrqm1bP4Q
0cg+oodNaKeuwG33bC4pEJ7FOPOVkSV78thJc+1Gp5gZPMpiEujPQb9M1NwYxqp/
N+qjaeax94rrjKtHRE5balCOs4LdTooUyvLBAAh6mmeaotB5MicDx/c+0w2IlCMe
EbW5dNxkKjDDOzg/Tyzacer4NaCgNPjCQaaliorh+TGco//23X6jpL/JstE0Ekip
PCXdgqhtI7W2LMHBVr0Ig5TNRYBwmHkT9oOlCA30e8lmqAfrX+HcpXwmnCkSYJso
e747Or7LgJ907xe0Cw7b0tYsvAch9viTWvFPQaOeNco3SjvPvIffUOyZkXDjglNc
7+gYnEd+3/ofy0ebtN6G316QDmHRPc/hfZGbdLwXxT72KVvzyHraWzPe63C2Kxdt
ZeclxHXyk0Ke9arOCuxYZyc=
=kN6k
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] View Source Code [BROWSE]
El 06/05/16 a las 00:39, Utkarsh Tiwari escribió:
>
> Hi Sebastian,
> I want to display the html code of the
> current open webpage in a new tab inside Browse. For that I tried
> 'document.write('fetched-html-code') but it isn't working as expected.
>
I don't think you should use Javascript for that; instead use the Python
API to fill the webview. Try to use text/plain mime type to avoid it
rendering the HTML.
While you are exploring source browsing in Webkit, one interesting
feature of it is the Inspector tool. Basically it is possible to use
similar developer tools as Chrome includes. I played with it to some
extent in 2011 [1]. Perhaps it makes sense to not reinvent it, or
perhaps a simpler version would be good to have.
[1] http://git.sugarlabs.org/websdk
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] View Source Code [BROWSE]
El 05/05/16 a las 02:20, Utkarsh Tiwari escribió:
> Hi,
> I need to add the facility to view the source code of the current
> open webpage in a new tab. I tried that by fetching the source code
> using webkit and displaying it via javascript query
> 'browser.execute_query('JS_Query')' but have been some problems while
> parsing the html code to string.
>
> Could anyone here suggest any other possible way to get about it?
It is not clear 100% to me what you are asking but from Webkit
documentation you can try the method
`browser.load_string( content, mime_type, encoding, base_uri )` instead.
Reference:
http://webkitgtk.org/reference/webkitgtk/stable/webkitgtk-webkitwebview.html#webkit-web-view-load-string
>
> Thanks,
> Utkarsh Tiwari
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] View Source Code [BROWSE]
Hi, Utkarsh
Naturally, the html page is a text file. A simple technique would be:
web.html
the text of the html file
On 05/05/2016 08:20 AM, Utkarsh Tiwari wrote:
Hi,
I need to add the facility to view the source code of the current
open webpage in a new tab. I tried that by fetching the source code
using webkit and displaying it via javascript query
'browser.execute_query('JS_Query')' but have been some problems while
parsing the html code to string.
Could anyone here suggest any other possible way to get about it?
Thanks,
Utkarsh Tiwari
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] View Source Code [BROWSE]
Hi,
I need to add the facility to view the source code of the current
open webpage in a new tab. I tried that by fetching the source code
using webkit and displaying it via javascript query
'browser.execute_query('JS_Query')' but have been some problems while
parsing the html code to string.
Could anyone here suggest any other possible way to get about it?
Thanks,
Utkarsh Tiwari
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] view source patch series
I have done an overhaul of viewsource in order to fix a few bugs and to add two major enhancements: (1) an option to copy bundle_source into a new activity; and (2) the ability to view Sugar source. The minor bug fixes include: * Accounting for a bundle exec path that is not in the root directory (#2846) * Cleaning up the grammar of debug message * Making consistent use of _logger.debug * Not returning if HandleViewSource service available (#2862) * Preventing view source display of .pyo, .pyc, .so, .mo and ~ files (#2854) The two enhancements are: * Add copy submenu to viewsource (#2859) * Add view Sugar source to viewsource Note that an additional patch (sent in a separate email) adds a new icon used as an overlay when copying the bundle. This is at the suggestion of Ana Cichero with help from Manuel Quiñones. -walter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] view source
As well as Browse, see Turtle Blocks, which gives alternate views of source ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] view source
Excerpts from Erik Blankinship's message of Mon Aug 30 23:13:45 +0200 2010: > How do you customize what is shown when "view source" is selected for an > activity? Check out sugar.activity.activity.Activity.handle_view_source(). I don't see any activity implementing it, so can't provide any details, but maybe Tomeu or Simon will. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] view source
On 30.08.2010, at 23:54, Erik Blankinship wrote: > Is there no way to intercept the view source event? EToys handles view > source differently than most other activities. Etoys (note spelling ;) implements HandleViewSource(): http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#D-Bus_Methods - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] view source
Is there no way to intercept the view source event? EToys handles view source differently than most other activities. On Mon, Aug 30, 2010 at 5:30 PM, Lucian Branescu wrote: > You can't customise it, but you can offer a document to be viewed alongside > the python source. Check how Browse does it. > > On 30 Aug 2010 22:13, "Erik Blankinship" wrote: > > How do you customize what is shown when "view source" is selected for an > activity? > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] view source
You can't customise it, but you can offer a document to be viewed alongside the python source. Check how Browse does it. On 30 Aug 2010 22:13, "Erik Blankinship" wrote: How do you customize what is shown when "view source" is selected for an activity? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] view source
How do you customize what is shown when "view source" is selected for an activity? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] View source in TA (was Re: [IAEP] Sugar Digest 2009-02-03)
On Tue, Feb 3, 2009 at 10:43 AM, Walter Bender wrote:
> === Sugar Digest ===
>
> Baselines, Part 1: A few months ago, Tomeu Vizoso set a baseline for
> the Sugar "view source" functionality that had largely gone unrealized
> in most Activities. In the upcoming (March) release of Sugar, the
> default behavior of all Activities will be to have their source code
> opened inside of Pippy, the Python editor written by Chris Ball and
> maintained by C. Scott Ananian. (This is already the default behavior
> of Chat—try it, you'll like it.)
>
> While this is a baseline, it is clear that for many Activities, it is
> not sufficient. In some Activities, such as Browse, view source is
> geared towards the content being browsed, rather than the Browser
> itself. In a manner similar to the Mosaic web browser—and most
> browsers built since—view-source shows the HTML content from which the
> page is created. Browse puts a copy of the HTML content into the
> Journal from where it can be viewed and modified by the Write
> Activity.
>
> It has often been argues by me (and many others) that view source is
> what made the web transparent and enabled any consumer of web content
> to become a producer. Indeed, this was the threshold through which a
> generation has passed—remix is a part of our culture, not just
> something for Trekkies and other fringe groups as observed by Henry
> Jenkins in the mid 1980s.
>
> I have been thinking about view source within the content of Turtle
> Art lately. I had gotten immersed in Turtle Art when some teachers on
> the Sur list began asking for some extensions. At the time I tried to
> get them to make the extensions themselves, but the floor was too
> high. I jumped in in order to document the process of modifying an
> Activity and also to try to understand first hand where the
> difficulties laid. My early attempts are described in the wiki
> ([[Patching_Turtle_Art|Patching Turtle Art]]).
Thanks. The code seems to contain many Magic Numbers, as in 'sqrt':
(('num',True,0,20),('num',False,42,20)),
Are they documented anywhere?
> Between Bill Kerr's subsequent questions
> ([[Talk:Patching_Turtle_Art|Talk:Patching Turtle Art]]) and my own
> experiences, I was awakened to the fact that we have a long ways to go
> in terms of making view source meaningful to the teacher, the student,
> and the potential Sugar contributor.
I added some questions.
http://sugarlabs.org/go/Talk:Patching_Turtle_Art#Earth_Treasury
> View source was central to the discussion I had with Bill Kerr and
> Tony Forster last week in Melbourne. We agreed that it worthwhile
> exploring the impact of the addition of some more steps between using
> an Activity and viewing the project's Python code; indeed, it would be
> necessary if any but the most dedicated would venture forth.
That's what I am planning for a book on teaching with Turtle Art.
> Tony has
> braved the GNU/Linux shell to try to modify Turtle Art; he has been
> documenting his efforts ([http://tonyforster.blogspot.com/ Tony
> Forster blog]) Previously I had added an export function to Turtle Art
> so that the psuedo Logo generated in the graphical interface could be
> viewed inside a text-based, fully featured Logo environment—a one-way
> path towards more sophisticated programming concepts.
What would it take to provide the return path?
> As a result of the Melbourne discussion, I decided to take a slightly
> different approach. I have added two new blocks to Turtle Art
> (actually, at the moment, just to Turtle Art Portfolio, a fork of
> Turtle Art).
>
> One block lets you try Python code directly into it. It can be used
> for simple, in-line extensions, such as added new functions from the
> math library. It uses a simple set of assumptions: there is one input
> (int or float) and one output (float), e.g., typing sin(x) into the
> block turns the block into the sine function. It is similar to the
> programmable extensions found in may environments, such as
> [http://rupert.id.au/schoolgamemaker/morethan.htm Gamemaker]. While I
> expect that this will satisfy the needs of many of those who are
> looking for simple extensions to the Turtle Art environment, I don't
> think it addresses the question of how to provide a stepping stone
> towards modifying Turtle Art itself—in fact, it may discourage many
> from every bothering to view the source code because they can make
> changes without having to "look under the hood."
I'm going to see about explaining the transition and encouraging
people to take it up.
> I have higher hopes for the second block I introduced. Internally it
> calls a Python procedure, myblock, that is currently a "nop"—it simply
> returns without executing any code. The idea is that myblock, which is
> loaded as a separate module, will be modified by the end user. When
> Turtle Art Portfolio is launched for the first time, it makes a copy
> of myblock in the Journal. It can be opened in Pippy, where it can be
> modified and saved b
Re: [Sugar-devel] View Source
On Wed, Nov 26, 2008 at 12:20 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > On 26.11.2008, at 12:07, Tomeu Vizoso wrote: > >> [cc'ing [EMAIL PROTECTED] because this subject is of importance to >> activity authors and I know many haven't yet subscribed to >> [EMAIL PROTECTED] Please subscribe!] >> >> On Tue, Nov 25, 2008 at 5:16 PM, Bert Freudenberg <[EMAIL PROTECTED]> >> wrote: >>> >>> On 22.11.2008, at 16:35, Simon Schampijer wrote: >>> Some great work has been going into this release regarding the 'View source' support. The source of all the activities can be shown, and browse does still support showing the source of the document. === sugar-toolkit === * Add view-source-related methods HandleViewSource and GetDocumentPath === sugar === * Implement a global handler for the view source key >>> >>> Since I could not find any discussion, let alone documentation about >>> this, I (again) got out my rusty Emacs, fed it with some grep'ed >>> source files, and reverse-engineered the whole thing. My findings are >>> here: >> >> Sorry, announcing this properly is something that has been in my TODO >> for a while, but hadn't managed to get to it yet. >> >>> http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods >> >> All looks good to me. >> >>> I like the idea so far, but here are the issues I have with the >>> current implementation: >>> >>> 1. HandleViewSource should return a boolean to indicate whether the >>> request was handled or not. >>> This would also get rid of the Python-specific dbus error handling >>> code in viewsource.py because handle_view_source in activity.py could >>> simply answer False. >> >> Hmm, but we still need to handle the case where a non-python activity >> hasn't implemented the method, right? > > Oh certainly, the logic is sound, it's just the "not implemented" Pythonism > there that is not necessary. > >>> 2. GetDocumentPath is a poor name for what it does. >>> It should contain "source" because it's not the document that is >>> viewed, but its source. How about GetSourcePath()? >> >> Well, the idea is that, by default, sugar will show the activity's >> source. This method is intended for displaying a textual >> representation of the sources behind a document, be it html for >> browse, logo for turtleart, etc. So perhaps getDocumentSourcePath()? > > Sure. > >>> Also, this file is deleted unconditionally when the source view is >>> closed. I'd add a boolean "transfer_ownership" flag to indicate that >>> it's okay to delete (similar to the datastore API). >> >> Sounds good, if activity authors think this added complexity is ok, I >> can add it. > > Well, it's more complexity to having to make a copy just so Sugar can delete > it ... Agreed, I'm starting to think that we are going to have to add a similar parameter to all functions in sugar that accept a temp file path, so we can make very clear what the surrounding code needs to do in order to properly dispose temp files. >>> Also, what kinds of source does this support? I noticed the >>> Browser's HTML source was highlighted. Is that determined by the file >>> name extension? >> >> The sugar shell tries its best to display a formatted view of the >> source code based on the extension and the contents of the file. >> Currently, it uses gtksourceview2 for that. If an activity author >> would like an improved or new formatter, we should talk to the >> upstream maintainers to add it. It's quite configurable and should be >> a matter of editing some xml files. > > Also, the call could additionally answer a mime type which would override > the guessing. Yes, one more policy decision I'm thinking of lately is to only guess mime types as fallbacks and do all that is possible to pass mime types around. Thanks for the ideas, Tomeu >>> On a more general note, activityservice.py should be annotated with >>> the actual DBus signatures. >> >> True, added it to my TODO at http://sugarlabs.org/go/User:Tomeu > > > :) > > - Bert - > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] View source redesign
On Wed, Dec 3, 2008 at 7:54 PM, Jameson Quinn <[EMAIL PROTECTED]> wrote:
> I am in the process of writing a patch to make the view source key extension
> able to open source in an appropriate activity. The basic scheme is:
>
> user presses view source
> extension asks activity (over dbus) if it wants to handle this one by itself
> if not, it asks activity if there is a local document it wants to give as a
> source option. activity replies with mime type, path, title, and human
> readable flag (whether to try to show it in the window)
> extension brings up a window, which has buttons at top for activity and
> document
> those buttons show the thing in the window (if possible). If path is a file,
> the file; if it is a dir, a list view/ file viewer combo.
> Dropdowns from these buttons allow you to open the {activity, document} in
> external editor which handles the mime type
> If path is a dir and external editor is launched, extension asks current
> activity to bundle it up for the external activity, and gets back a jobject
> id.
>
> My one question is whether there will ever be a case where an activity will
> want to give the option to see two or more different kinds of "source"
> besides the activity source. I think not; I think one "document" at a time
> is plenty.
>
> As an example: if you're in basicbrowse activity, you press view source, you
> have option of seeing python source of basicbrowse, or html of current page.
> If you're in superbrowse, you get options of seeing superbrowse source or (a
> bundle with html, css, svg, gif, jpg, subframe html, etc.). I think making
> each of those things available separately as independent entities just leads
> to a more complicated API for activity programmers with nearly no real gain.
> Do others agree?
I agree with all that, though would like to see comments about the
user experience, specially from Eben.
Thanks,
Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] View source redesign
I am in the process of writing a patch to make the view source key extension
able to open source in an appropriate activity. The basic scheme is:
1. user presses view source
2. extension asks activity (over dbus) if it wants to handle this one by
itself
3. if not, it asks activity if there is a local document it wants to give
as a source option. activity replies with mime type, path, title, and human
readable flag (whether to try to show it in the window)
4. extension brings up a window, which has buttons at top for activity
and document
5. those buttons show the thing in the window (if possible). If path is a
file, the file; if it is a dir, a list view/ file viewer combo.
6. Dropdowns from these buttons allow you to open the {activity,
document} in external editor which handles the mime type
7. If path is a dir and external editor is launched, extension asks
current activity to bundle it up for the external activity, and gets back a
jobject id.
My one question is whether there will ever be a case where an activity will
want to give the option to see two or more different kinds of "source"
besides the activity source. I think not; I think one "document" at a time
is plenty.
As an example: if you're in basicbrowse activity, you press view source, you
have option of seeing python source of basicbrowse, or html of current page.
If you're in superbrowse, you get options of seeing superbrowse source or (a
bundle with html, css, svg, gif, jpg, subframe html, etc.). I think making
each of those things available separately as independent entities just leads
to a more complicated API for activity programmers with nearly no real gain.
Do others agree?
Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
