A pyQt application ported to wxPython, comments and testers needed.

Chris Mellon wrote:

I know that HtmlWindow is not meant to have full browser functionality, but
unfortunately it seems to be the best we have.

wxMozilla appears to be dead (python bindings are generally built (and
sometime shared) by people on an as needed basis, but there doesn't seem to
be any Windows python support). It would be nice if wxMozilla were adopted
by the wxWidgets project.

I find it hard to believe that displaying HTML in a multi-platform
environment isn't a high priority for a lot of people.

You'd be surprised - "rich text" is whats most often needed, not a
full browser environment.

There is of course ActiveX_IEHtmlWindow, but that is Windows only AFAIK.
Not to mention that trying to work with IE via that horribly ugly Microsoft
API is a major headache.

So if I want to do multi-platform development, I'm have no real
alternatives other than HtmlWindow for displaying HTML.

I have two uses for html display:

One is to show generated content, where html seems preferable to rich text.
HtmlWindow seems okay for this, except that I would like to be able to
display forms (more on this below).

The other need is to have an embedded browser for displaying web pages.
Obviously HtmlWindow will not work for this because it is not meant to be a
full browser. This has me worried because there seems to be no solution
whatsoever that is multi-platform.

A full browser is a lot more work than you're crediting. There are
only 4 mature browser engines in existence today, and they all took
tens of thousands of man-hours of work, and they're (all) still highly
imperfect and inconsistent. None of them are especially easy to embed
in a foreign library - IE is easiest because of it's ActiveX support.

... but only on windows, and I've dealt with that IE interface from C++ before. It is quite nasty.

Mozilla is a huge beast and hard to embed. Opera isn't available for
embedding at all. KHTML/WebKit is the most likely option, and there is
a wxWebKit project, but it's still a lot of work and it's certainly
non-trivial to implement. wxWebKit, from what I hear, is the current
best option for cross-platform embedded browsing, but I don't believe
there are Python bindings.

HtmlWindow has nice support for embedding wx widgets inside html code as
in:

<wxp module="wx" class="Button" >
     <param name="label" value="It works!">
     <param name="id" value="ID_OK">
</wxp>

But there appears to be no support for html form controls such as buttons
and text inputs.

It shouldn't be *that* difficult to implement HTML forms directly in
wxHTML. Get crackin' :wink:

Yeah, I just started getting familiar with extending wxHtml with new tags. I think you are right.

It would be nice if simple forms created in an html editor could be
displayed in an HtmlWindow.

Perhaps one solution would be to make an html preprocessor to convert
proper html form controls into code for embedded wx controls. For example,
the following would be converted into the above code (I'm ignoring the
<form> tag itself):

<button type="button" name="ID_OK">It works!</button>

The button tag, on the other hand, would be hard. You'd need a nested
wxHTML window inside a custom "button-like" panel. Probably still
possible.

Anyway, I'm wondering if it was a mistake to go with wxPython instead of
GTK, given that there doesn't seem to be any obvious way to display HTML. I
really hope I'm wrong about this because I have already written a lot of
wxPython code. Was it a mistake?

Wow, you don't sound like someone making loaded petulant statements at
all! I don't know your needs or requirements, and so I can't tell you
if you made a mistake or not. If you think that GTK has a fully
featured embeddable browser suitable for viewing arbitrary web pages,
though, you're quite mistaken.

I stand corrected.

- Ken

···

On 6/5/07, Ken Seehart <ken@seehart.com> wrote:

Okay, that is a good answer!

Is WebKit also intended as a replacement for HtmlWindow?

Who's working on it?

How can I help?

What is the ETA? Is there something small I can do? (limited time and budget)

- Ken Seehart

Robin Dunn wrote:

···

Ken Seehart wrote:

Any chance that wxMozilla will be directly supported by the wxPython distribution?

No. Kevin's email details why.

A wx WebKit with support for all platforms is much more likely to happen, and is being actively worked on. In a custom WebKit we can use our own drawing APIs to draw on our own Windows instead of trying to find a way to blend the two conflicting toolkits.

Chris Mellon wrote:
>>
>> I know that HtmlWindow is not meant to have full browser
>> functionality, but
>> unfortunately it seems to be the best we have.
>>
>> wxMozilla appears to be dead (python bindings are generally built (and
>> sometime shared) by people on an as needed basis, but there doesn't
>> seem to
>> be any Windows python support). It would be nice if wxMozilla were
>> adopted
>> by the wxWidgets project.
>>
>> I find it hard to believe that displaying HTML in a multi-platform
>> environment isn't a high priority for a lot of people.
>>
>
> You'd be surprised - "rich text" is whats most often needed, not a
> full browser environment.
>
>> There is of course ActiveX_IEHtmlWindow, but that is Windows only
>> AFAIK.
>> Not to mention that trying to work with IE via that horribly ugly
>> Microsoft
>> API is a major headache.
>>
>> So if I want to do multi-platform development, I'm have no real
>> alternatives other than HtmlWindow for displaying HTML.
>>
>> I have two uses for html display:
>>
>> One is to show generated content, where html seems preferable to
>> rich text.
>> HtmlWindow seems okay for this, except that I would like to be able to
>> display forms (more on this below).
>>
>> The other need is to have an embedded browser for displaying web pages.
>> Obviously HtmlWindow will not work for this because it is not meant
>> to be a
>> full browser. This has me worried because there seems to be no solution
>> whatsoever that is multi-platform.
>>
>
> A full browser is a lot more work than you're crediting. There are
> only 4 mature browser engines in existence today, and they all took
> tens of thousands of man-hours of work, and they're (all) still highly
> imperfect and inconsistent. None of them are especially easy to embed
> in a foreign library - IE is easiest because of it's ActiveX support.
... but only on windows, and I've dealt with that IE interface from C++
before. It is quite nasty.

Indeed.

> Mozilla is a huge beast and hard to embed. Opera isn't available for
> embedding at all. KHTML/WebKit is the most likely option, and there is
> a wxWebKit project, but it's still a lot of work and it's certainly
> non-trivial to implement. wxWebKit, from what I hear, is the current
> best option for cross-platform embedded browsing, but I don't believe
> there are Python bindings.
>
>> HtmlWindow has nice support for embedding wx widgets inside html
>> code as
>> in:
>>
>> <wxp module="wx" class="Button" >
>> <param name="label" value="It works!">
>> <param name="id" value="ID_OK">
>> </wxp>
>>
>> But there appears to be no support for html form controls such as
>> buttons
>> and text inputs.
>>
>
> It shouldn't be *that* difficult to implement HTML forms directly in
> wxHTML. Get crackin' :wink:
>
Yeah, I just started getting familiar with extending wxHtml with new
tags. I think you are right.

This is actually a sort of fun challenge and I've implemented most of
form support now (improved from the attachment in my last post). The
code is still hackish and messy, but it's better than it was and it
supports most form elements and attributes now.

>> It would be nice if simple forms created in an html editor could be
>> displayed in an HtmlWindow.
>>
>> Perhaps one solution would be to make an html preprocessor to convert
>> proper html form controls into code for embedded wx controls. For
>> example,
>> the following would be converted into the above code (I'm ignoring the
>> <form> tag itself):
>>
>> <button type="button" name="ID_OK">It works!</button>
>>
>
> The button tag, on the other hand, would be hard. You'd need a nested
> wxHTML window inside a custom "button-like" panel. Probably still
> possible.
>
>> Anyway, I'm wondering if it was a mistake to go with wxPython
>> instead of
>> GTK, given that there doesn't seem to be any obvious way to display
>> HTML. I
>> really hope I'm wrong about this because I have already written a lot of
>> wxPython code. Was it a mistake?
>
> Wow, you don't sound like someone making loaded petulant statements at
> all! I don't know your needs or requirements, and so I can't tell you
> if you made a mistake or not. If you think that GTK has a fully
> featured embeddable browser suitable for viewing arbitrary web pages,
> though, you're quite mistaken.
I stand corrected.

This came across a little grumpier than I intended, but the way you
phrased it rubbed me the wrong way. Sorry.

I've posted my updated forms support on the wxPython wiki, see
http://wiki.wxpython.org/wxHTML

···

On 6/6/07, Ken Seehart <ken@seehart.com> wrote:

> On 6/5/07, Ken Seehart <ken@seehart.com> wrote:

Kevin Ollivier is working on it. See his mail of 6/5/2007 5pm.
Stani

Ken Seehart wrote:

···

Okay, that is a good answer!

Is WebKit also intended as a replacement for HtmlWindow?

Who's working on it?

How can I help?

What is the ETA? Is there something small I can do? (limited time and
budget)

- Ken Seehart

Robin Dunn wrote:

Ken Seehart wrote:

Any chance that wxMozilla will be directly supported by the wxPython
distribution?

No. Kevin's email details why.

A wx WebKit with support for all platforms is much more likely to
happen, and is being actively worked on. In a custom WebKit we can
use our own drawing APIs to draw on our own Windows instead of trying
to find a way to blend the two conflicting toolkits.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Chris Mellon wrote:

On 6/5/07, Robin Dunn wrote: In the interests of science, I whipped up a very quick & dirty form
implementation. Only text, password, and submit buttons are supported, and there’s a fair amount of hackishness in the code. See attached.
Hey! Wow! Thanks! That’s way better than science. That is exactly
the
functionality I need (text, password, submit) to get by until WebKit
becomes available. So it looks like with that, HtmlWindow takes care
of our internal content But unfortunately I have to tell my client
that general web browsing will only be available for our
Windows version (via the IE active X thing) until WebKit arrives.

Hey Robin, you think Chris’s work could be included in the wxPython
demo? I found it extremely helpful.

If I happen to need support for more form tags, I will go ahead and
implement them, and I’d be happy to contribute them.

Thank you,

  • Ken Seehart
···

robin@alldunn.com

Chris Mellon wrote:

A full browser is a lot more work than you’re crediting. There are

only 4 mature browser engines in existence today, and they all
took

tens of thousands of man-hours of work, and they’re (all) still
highly

imperfect and inconsistent. None of them are especially easy to
embed

in a foreign library - IE is easiest because of it’s ActiveX
support.

Mozilla is a huge beast and hard to embed. Opera isn’t available
for

embedding at all. KHTML/WebKit is the most likely option, and
there is

a wxWebKit project, but it’s still a lot of work and it’s
certainly

non-trivial to implement. wxWebKit, from what I hear, is the
current

best option for cross-platform embedded browsing, but I don’t
believe

there are Python bindings.

wxWebKit is being worked on by Kevin Olivier and I am helping out as I

have time for it. You’re right though that it is really the only

contender because its code is organized much better for being used in

non standard environments and on various platforms. The platform

specific parts are compartmentalized from the rest and most major

functional groups are also separated. This means it is much easier to

replace sections of the functionality with new platforms or environment

specific code. It’s still a lot of work though, and the WebKit code

rivals the wx code in size (meaning that there is lots of it) so there

is a lot to learn.

HtmlWindow has nice support for embedding wx widgets inside
html code as

in:

 <param name="label" value="It works!">
 <param name="id"    value="ID_OK">

But there appears to be no support for html form controls
such as

buttons

and text inputs.

It shouldn’t be that difficult to implement HTML forms directly
in

wxHTML. Get crackin’ :wink:

It would just take somebody implementing tag handlers for the form and

form control tags. The tag was really only meant as a way
to

embed non-standard things, or complex widgets like panels already

populated with widgets, etc. as I thought that wxHtmlWindow would

eventually be able to handle and friends too. But just
because

nobody has implemented C++ handlers for the form tags yet doesn’t mean

it can’t be done. Take a look at the implementation of the

handler for an example.



---

import wx
import wx.html
SENTINEL = object()
def GetParam(tag, param, default=SENTINEL):
""" Convenience function for accessing tag parameters"""
if tag.HasParam(param):
return tag.GetParam(param)
else:
if default == SENTINEL:
raise KeyError
else:
return default
FormSubmitEventType = wx.NewEventType()
EVT_FORM_SUBMIT = wx.PyEventBinder(FormSubmitEventType)
class FormSubmitEvent(wx.PyEvent):
"""
Event indication a form was submitted.
action is the action attribute of the form
method is "GET" or "POST"
args is a dict of form arguments
"""
def __init__(self, action, method, args):
wx.PyEvent.__init__(self)
self.SetEventType(FormSubmitEventType)
self.action = action
self.method = method
self.args = args
class FormControlMixin(object):
def __init__(self, form, tag):
if not form:
return
self.__form = form
self.name = GetParam(tag, "NAME", None)
form.fields.append(self)
self.Bind(wx.EVT_TEXT_ENTER, self.__OnEnter)
self.Bind(wx.EVT_BUTTON, self.__OnClick)
def __OnEnter(self, evt):
self.__form.submit()
def __OnClick(self, evt):
self.__form.submit()
class HTMLForm(object):
def __init__(self, tag, container):
self.container = container
self.fields = []
self.action = GetParam(tag, "ACTION", default=None)
self.method = GetParam(tag, "METHOD", "GET")
if self.method not in ("GET", "POST"):
self.method = "GET"
def submit(self):
evt = FormSubmitEvent(self.action, self.method, self.createArguments())
self.container.ProcessEvent(evt)
def createArguments(self):
args = {}
for field in self.fields:
if field.name:
args[field.name] = field.GetValue()
return args
class SubmitButton(wx.Button, FormControlMixin):
def __init__(self, parent, form, tag, *args, **kwargs):
wx.Button.__init__(self, parent, *args, **kwargs)
FormControlMixin.__init__(self, form, tag)
if tag.HasParam("value"):
self.SetLabel(tag.GetParam("value"))
else:
self.SetLabel("Submit Query")
def GetValue(self):
return self.GetLabel()
class TextInput(wx.TextCtrl, FormControlMixin):
def __init__(self, parent, form, tag, *args, **kwargs):
if form:
style = wx.TE_PROCESS_ENTER
if "style" in kwargs:
kwargs["style"] = kwargs["style"] | style
else:
kwargs["style"] = style
wx.TextCtrl.__init__(self, parent, *args, **kwargs)
FormControlMixin.__init__(self, form, tag)
#todo - should be a weakref?
self.SetValue(GetParam(tag, "VALUE", ''))
class PasswordInput(TextInput):
def __init__(self, parent, form, tag):
TextInput.__init__(self, parent, form, tag, style=wx.TE_PASSWORD)
class FormTagHandler(wx.html.HtmlWinTagHandler):
typeregister = {
"text":TextInput,
"password": PasswordInput,
"submit": SubmitButton,
}
typeregister.setdefault(TextInput)
def __init__(self):
self.form = None
wx.html.HtmlWinTagHandler.__init__(self)
def GetSupportedTags(self):
return "FORM,INPUT,TEXTAREA"
def HandleTag(self, tag):
try:
handler = getattr(self, "Handle"+tag.GetName().upper())
return handler(tag)
except:
import traceback
traceback.print_exc()
def HandleFORM(self, tag):
print "handle form"
self.form = HTMLForm(tag, self.GetParser().GetWindowInterface().GetHTMLWindow())
self.cell = self.GetParser().OpenContainer()
self.ParseInner(tag)
self.GetParser().CloseContainer()
self.form = None
return True
def HandleINPUT(self, tag):
print "handle input"
parent = self.GetParser().GetWindowInterface().GetHTMLWindow()
if tag.HasParam("type"):
ttype = tag.GetParam("type")
else:
ttype = "text"
klass = self.typeregister[ttype]
object = klass(parent, self.form, tag)
#attribute supports
cell = self.GetParser().GetContainer()
cell.InsertCell(
wx.html.HtmlWidgetCell(object)
)
wx.html.HtmlWinParser_AddTagHandler(FormTagHandler)
if __name__ == '__main__':
app = wx.App(False)
f = wx.Frame(None)
html = wx.html.HtmlWindow(f)
html.LoadFile(r"C:\htmlt.html")
def OnFormSubmit(evt):
print "Submitting to %s via %s with args %s"% (evt.action, evt.method, evt.args)
html.Bind(EVT_FORM_SUBMIT, OnFormSubmit)
f.Show()
app.MainLoop()


To unsubscribe, e-mail: For additional commands, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.orgwxPython-users-help@lists.wxwidgets.org

Hi Ken,

Okay, that is a good answer!

Is WebKit also intended as a replacement for HtmlWindow?

It should have (and improve upon) all HtmlWindow functionality, except that you won't be able to (at least initially) embed wx controls directly into the page.

Who's working on it?

Primarily myself, with Robin and Vaclav Slavik pitching in when they have some time. :slight_smile:

How can I help?

If you're interested in helping out, you could:

- Build wxWebKit and report any problems you come across. Docs on how to do this are available at: NameBright - Coming Soon

- Report on what functionality you need but that isn't yet implemented.

- Report bugs

- Fix bugs or implement missing features... :wink:

What is the ETA? Is there something small I can do? (limited time and budget)

By months end latest, we should have an alpha available for wxPython, but I suspect I'll have something in a week or two. There are still several known bugs, and many probably to be found, so an ETA for a stable version isn't really known and probably depends heavily on how much testing we can get and/or our ability to get people to help fill in the gaps.

Regards,

Kevin

···

On Jun 6, 2007, at 2:30 PM, Ken Seehart wrote:

- Ken Seehart

Robin Dunn wrote:

Ken Seehart wrote:

Any chance that wxMozilla will be directly supported by the wxPython distribution?

No. Kevin's email details why.

A wx WebKit with support for all platforms is much more likely to happen, and is being actively worked on. In a custom WebKit we can use our own drawing APIs to draw on our own Windows instead of trying to find a way to blend the two conflicting toolkits.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Ken Seehart wrote:

Chris Mellon wrote:

[Please trim your replies to only include the relevant text needed to keep the message context intact. Nobody wants to scroll six pages down through text and code they've already read to see a relatively few lines of reply text.]

Hey Robin, you think Chris's work could be included in the wxPython demo? I found it extremely helpful.

If it's generally useful, well tested, documented, demoed and supported then it can go into the wx.lib package. See http://wxpython.org/codeguidelines.php

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

I noticed that WebKit doesn't seem to have SetSelection and GetSelection functionality according to the docs. These are also missing from HtmlWindow, so a while ago, I started implementing that pair of features for wxWidgets, but I sort of put that task on the back burner when I realized that we might switch to something other than HtmlWindow before we ship (the likely replacement at this point seems to be WebKit). If anyone has the time and inclination to finish what I started (SetSelection and GetSelection for HtmlWindow), I have made some progress and would gladly hand off what I've done so far. Perhaps I can do this for WebKit instead of HtmlWindow, if that seems like a good task, but I can't get to it right away.

There are a several reasons why GetSelection and SetSelection should be supported in things like WebKit or HtmlWindow, such as ability to implement "show selection source", a variety of application specific selection operations (e.g. double-clicking might select a word, but what exactly is a word? well that sometimes depends on the application). For me, the most important is the ability to add content to the bottom of a page without affecting a selection in progress (i.e. using the Freeze/Unfreeze strategy that is also often used for stabilizing the scroll bar in similar circumstances). All of these and other issues are resolved simply by adding GetSelection and SetSelection with the simple and obvious semantics of setting and returning integer offsets into the html source.

Some people have expressed the desire to have GetSelection and SetSelection operate on the library specific internal representations of the HTML node tree instead of integer indexes into the html source. I strongly and respectfully disagree with that position as it would be a particularly good example of unnecessary strong coupling. It is natural to consider any kind of html browser widget as operating on html source strings (all browsers and browser APIs have this one thing in common), and integer indexes into strings are quite obvious and natural (and there are no problematic ambiguities or other mapping issues).

If it is desirable to access the html object tree with a selection, the best way to do this would be to also implement a separate function that returns the node and offset given a specified raw html index, and another function to return the index of the first character of a given node.

- Ken Seehart

Kevin Ollivier wrote:

···

Hi Ken,

On Jun 6, 2007, at 2:30 PM, Ken Seehart wrote:

Okay, that is a good answer!

Is WebKit also intended as a replacement for HtmlWindow?

It should have (and improve upon) all HtmlWindow functionality, except that you won't be able to (at least initially) embed wx controls directly into the page.

Who's working on it?

Primarily myself, with Robin and Vaclav Slavik pitching in when they have some time. :slight_smile:

How can I help?

If you're interested in helping out, you could:

- Build wxWebKit and report any problems you come across. Docs on how to do this are available at: NameBright - Coming Soon

- Report on what functionality you need but that isn't yet implemented.

- Report bugs

- Fix bugs or implement missing features... :wink:

What is the ETA? Is there something small I can do? (limited time and budget)

By months end latest, we should have an alpha available for wxPython, but I suspect I'll have something in a week or two. There are still several known bugs, and many probably to be found, so an ETA for a stable version isn't really known and probably depends heavily on how much testing we can get and/or our ability to get people to help fill in the gaps.

Regards,

Kevin

- Ken Seehart

Robin Dunn wrote:

Ken Seehart wrote:

Any chance that wxMozilla will be directly supported by the wxPython distribution?

No. Kevin's email details why.

A wx WebKit with support for all platforms is much more likely to happen, and is being actively worked on. In a custom WebKit we can use our own drawing APIs to draw on our own Windows instead of trying to find a way to blend the two conflicting toolkits.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org