Testing wxPython 2.5.1p8 in win98

Jean-Michel_Fauth · March 4, 2004, 6:12pm

Hi Robin Dunn,

Some news from a win98 user (win98se, Py 2.3.3, wxPy 2.5.1.0p8)

o Installation without any problem

o (Default)Height of the ComboBox.
This has been reported (Chris Barker) and it also happens on my
win98 platform. As this bug also happens in "black-box" controls,
like the zoom factor in the PrintPreview, I conclude, this is a real
wxWidgets bug.

o Echeverria Rabi, Cristián: wx.SplitterWindow issue on winXP.
Same issue on win98.

o demo / VListBox and HtmlListBox
Can not move the selection with arrow keys, ok with a mouse click.
Has been reported.

o Just noticed the menu definition and its binding introduced in the
p7 release is still working with the p8 release.
What is or will be the "official" way to do this?

o Still the "StretchDIBits" issue in the demo.
I wonder if something has been done or could be done to solve this
issue. Now that I know where this is coming from (wx.Logxxx), I do
not worry too much about this. But what would a new wxPython user say?
However, the problem is critical for demo apps like the AnalogClock,
where the exposed window is constantly "refreshed", this leads to
a general demo crash.

o DC and SetBrush
I read the story (Kevin Altis). SetBrush is working fine on my win
platform. The point I do not understand, lies in the DC.Clear() method.
Which Brush is used for this Clear method? According to the doc,
clearing uses the last defined Brush. I can define the Brush as I
wish (eg. wx.RED_BRUSH), this is not working. The Clear() method
does not use any defined Brush. It will always repaint the
wx.Window with the BackgroundColour set for this window. Note,
that this was also the case in 2.4.2.4

o I read somewhere, you plan to introduce Release Candidates. I think,
that a good idea.

o When switching from one demo app item to one onother, I see
a flashing gray rectangle (with a constant size) on the upper left
corner of the wx.SplitterWindow, on the notebook. Rendering/refreshing
issue ???

o A little bit out of this topic.
Seeing all the complains and questions about the wxTextCtrl widget
(SetSelection, Styling, Focussing, ...), I just wonder if this control
should not be reworked and splitted into two differents controls.
A basic TextCtrl with a restricted set of styles for entering raw text
and a second more sophisicated one, that allows styling, saving, ....
Something like a wx.RTF widget.

Regards.
Jean-Michel Fauth, Switzerland

Robin · March 4, 2004, 7:19pm

Jean-Michel Fauth wrote:

Hi Robin Dunn,

Some news from a win98 user (win98se, Py 2.3.3, wxPy 2.5.1.0p8)

o Installation without any problem

o (Default)Height of the ComboBox.
This has been reported (Chris Barker) and it also happens on my
win98 platform. As this bug also happens in "black-box" controls,
like the zoom factor in the PrintPreview, I conclude, this is a real
wxWidgets bug.

Yep.

o Echeverria Rabi, Cristián: wx.SplitterWindow issue on winXP.
Same issue on win98.

Yes, this is a generic issue. The design of the feature depended on the default size of the slpitter window being very small so it broke when the default on MSW changed. I'm working on a fix right now.

o demo / VListBox and HtmlListBox
Can not move the selection with arrow keys, ok with a mouse click.
Has been reported.

I fixed that last night. I also took care of a couple other things while I was there.

o Just noticed the menu definition and its binding introduced in the
p7 release is still working with the p8 release.
What is or will be the "official" way to do this?

See the MigrationGuide.

o Still the "StretchDIBits" issue in the demo.
I wonder if something has been done or could be done to solve this
issue. Now that I know where this is coming from (wx.Logxxx), I do
not worry too much about this. But what would a new wxPython user say?
However, the problem is critical for demo apps like the AnalogClock,
where the exposed window is constantly "refreshed", this leads to
a general demo crash.

Oops, I fixed the problem with the BLit speed that this log message led us to, but forgot to go back and deal with this particular message. It's on the list now.

o DC and SetBrush
I read the story (Kevin Altis). SetBrush is working fine on my win
platform.

The problem is if you use dc.GetBrush(), change the brush attributes, and then use dc.SetBrush(). The brush used by the DC doesn't change. This has been fixed.

The point I do not understand, lies in the DC.Clear() method.
Which Brush is used for this Clear method? According to the doc,
clearing uses the last defined Brush. I can define the Brush as I
wish (eg. wx.RED_BRUSH), this is not working. The Clear() method
does not use any defined Brush. It will always repaint the
wx.Window with the BackgroundColour set for this window. Note,
that this was also the case in 2.4.2.4

dc.Clear() will use the brush that has been set with dc.SetBackground(brush)

o I read somewhere, you plan to introduce Release Candidates. I think,
that a good idea.

Yep. I'll do it the same as I did for 2.4.1 and 2.4.2. I'll make a 2.5.1.1 build and announce it here for testing. If there are no major problems then it will be uploaded to SF and announced generally. If it is not ready then I'll fix things and make a 2.5.1.2 and try again.

o When switching from one demo app item to one onother, I see
a flashing gray rectangle (with a constant size) on the upper left
corner of the wx.SplitterWindow, on the notebook. Rendering/refreshing
issue ???

Yes. In earlier versions I had to put a bunch of extra refreshes and yeilds in there to get the page changes and etc. to look right on all platforms. Now I can start removing some of them.

o A little bit out of this topic.
Seeing all the complains and questions about the wxTextCtrl widget
(SetSelection, Styling, Focussing, ...), I just wonder if this control
should not be reworked and splitted into two differents controls.
A basic TextCtrl with a restricted set of styles for entering raw text
and a second more sophisicated one, that allows styling, saving, ....
Something like a wx.RTF widget.

Yes, that is the way I would like to see things go as well. At least a few of the other core developers agree with me, as does OSAF. We just need to find somebody with the time, skills and inclination to do the RTF control.

···

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

Kevin_Altis · March 4, 2004, 7:47pm

It certainly seems like it would be relatively simple to make the existing control more restrictive, but in the past, my emails to wx-dev and wx-user about a hook to strip styles on Paste and other issues related to a more restrictive control didn't yield any fruit. There will still be issues on each platform depending on the underlying native control. In PythonCard I simplified to single line TextCtrl (plain or password) and a multiline control (wxTE_MULTILINE | wxTE_RICH2). The plus side of using a wxTE_RICH style is that the control will handle large amounts of text limited to whatever the native control can deal with rather than some small 32K or 64K limit. The control also behaves similarly across platforms, so you avoid some problems with internal CR/LF line endings on Windows that throw off position counting. The styles in TextCtrl are almost useless since you can't do much more than set them and the fact that styled text in the clipboard pastes into the control is a constant annoyance and confuses the user. The sooner styles can be restricted the better. In the short term, I would be happy if there was a flag to set so Paste and Drag-n-drop behaved correctly, that is, styled text can't make it into the control.

For any styled text needs it is worth trying to use wxSTC, but of course this has its own problems, not the least of which is the much more complicated Scintilla API.

ka

···

On Mar 4, 2004, at 11:19 AM, Robin Dunn wrote:

Jean-Michel Fauth wrote:

o A little bit out of this topic.
Seeing all the complains and questions about the wxTextCtrl widget
(SetSelection, Styling, Focussing, ...), I just wonder if this control
should not be reworked and splitted into two differents controls.
A basic TextCtrl with a restricted set of styles for entering raw text
and a second more sophisicated one, that allows styling, saving, ....
Something like a wx.RTF widget.

Yes, that is the way I would like to see things go as well. At least a few of the other core developers agree with me, as does OSAF. We just need to find somebody with the time, skills and inclination to do the RTF control.

Robin · March 4, 2004, 7:56pm

Kevin Altis wrote:

For any styled text needs it is worth trying to use wxSTC, but of course this has its own problems, not the least of which is the much more complicated Scintilla API.

Also the fact that it is not designed to be a general purpose rich text editor, but a source code editor. Think about trying to do something like MS WordPad with it. The limited number of styles and the fixed line height (size of largest style) would prevent you from getting even close.

···

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

Kevin_Altis · March 4, 2004, 8:28pm

Right. There is another use case that doesn't quite fit a rich styled text control either, that is probably best served by wxMozilla or a more capable wxHtml control. That is the need for rich display of text with or without images where the text can at least be selected and copied, even if it can't be edited. What can be displayed in a browser is so far beyond what we can do with existing wxWidgets controls that there probably isn't an option other than using a browser wrapper, so the sooner that happens the better.

Is the current thinking that we might get platform-specific native HTML controls or is Mozilla going to get used instead? What is the timeframe for distribution in wxPython? I know Kevin O. is working on some wxMozilla stuff.

ka

···

On Mar 4, 2004, at 11:56 AM, Robin Dunn wrote:

Kevin Altis wrote:

For any styled text needs it is worth trying to use wxSTC, but of course this has its own problems, not the least of which is the much more complicated Scintilla API.

Also the fact that it is not designed to be a general purpose rich text editor, but a source code editor. Think about trying to do something like MS WordPad with it. The limited number of styles and the fixed line height (size of largest style) would prevent you from getting even close.

Kevin_Ollivier4 · March 4, 2004, 8:58pm

Hi Kevin,

Kevin Altis wrote:

For any styled text needs it is worth trying to use wxSTC, but of course this has its own problems, not the least of which is the much more complicated Scintilla API.

Also the fact that it is not designed to be a general purpose rich text editor, but a source code editor. Think about trying to do something like MS WordPad with it. The limited number of styles and the fixed line height (size of largest style) would prevent you from getting even close.

Right. There is another use case that doesn't quite fit a rich styled text control either, that is probably best served by wxMozilla or a more capable wxHtml control. That is the need for rich display of text with or without images where the text can at least be selected and copied, even if it can't be edited. What can be displayed in a browser is so far beyond what we can do with existing wxWidgets controls that there probably isn't an option other than using a browser wrapper, so the sooner that happens the better.

Is the current thinking that we might get platform-specific native HTML controls or is Mozilla going to get used instead?

Both. You can pick. =) IE or Mozilla on Windows, Safari/WebKit or Mozilla on Mac, or Mozilla on Linux. The idea is that there will be a wxHTML2 type class which will let you either explicitly pick a renderer, or if you don't, it will use the platform default (i.e. the renderer most commonly used or most likely to be available).

What is the timeframe for distribution in wxPython? I know Kevin O. is working on some wxMozilla stuff.

If you want to play with wxMozilla in wxPython, you can download the Py2.3 installer from: http://sourceforge.net/project/showfiles.php?group_id=5530

It works in Linux too, so long as you have wxPython-dev installed and are willing to do the configure/make/make install dance (see the BUILD.UNIX.txt for more info)

It, well, kinda sorta works on Mac, but I've learned way too much about how Mac drawing works in figuring out why it doesn't work as easily as other ports. (Which, to be fair, is really a problem with wxMac and Mozilla not talking very well with each other rather than anything else.) Hopefully after my patch to wxMac it will work much better than kinda sorta, and after that I can make a nice installer package like for Windows.

Both browsing and editing basically work, but the editor particularly needs tweaking. It works like a RichText editor, i.e. no DOM editing or anything like that yet, but images, links, etc. are supported. Table editing works, but it's never been a strong suit of Mozilla's editor, unfortunately. (You could also go to http://www.eclass.net/newlook/ to see it in action in a real, live wxPython program. I personally think the cross-browser page preview is pretty smooth. =)

The problem with bundling wxMozilla with wxPython is that it's currently a 5MB add-on for Windows, not sure about other ports. Of course, I wouldn't mind seeing it built in, but then again, I'm a bit biased.

Thanks,

Kevin

···

On Mar 4, 2004, at 12:28 PM, Kevin Altis wrote:

On Mar 4, 2004, at 11:56 AM, Robin Dunn wrote:

Chris_Barker1 · March 4, 2004, 9:05pm

Kevin Altis wrote:

Right. There is another use case that doesn't quite fit a rich styled text control either, that is probably best served by wxMozilla or a more capable wxHtml control.

Yup. A more capable HTML control would be GREAT.

That is the need for rich display of text with or without images where the text can at least be selected and copied, even if it can't be edited.

I've heard that the latest version of the wxHTML control can do that.

What can be displayed in a browser is so far beyond what we can do with existing wxWidgets controls that there probably isn't an option other than using a browser wrapper,

while a browser wrapper is a great idea, there is another option: USing an exisitng library to parse the HTML and figure out the layout, but draw it natively. This could result in a full featured wxHTML widget that was also well integtrated with wxWidgets. You could embed wxWidgets in ti t, for instance. It strikes me that khtml from the KDE project would be a good candidate. If it can be used with both QT and Cocoa (in Apple's Safari), you'd think it could be used with wxWidgets. Mahogany would really benefit from this too....

Note that this is said without so much as a glance at the code, or a check of licensing issues. I ahve neither the time nor the skills to do any of it either...

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Vaclav_Slavik1 · March 10, 2004, 10:00pm

Hi,

Chris Barker wrote:

in ti t, for instance. It strikes me that khtml from the KDE
project would be a good candidate. If it can be used with both QT
and Cocoa (in Apple's Safari)

IIRC it was used in Safari only because Apple implemented a minimal
subset of Qt API needed by khtml that wrapped Mac's native APIs.

Vaclav

···

--
PGP key: 0x465264C9, available from http://pgp.mit.edu/

Chris_Barker1 · March 10, 2004, 10:10pm

Vaclav Slavik wrote:

Chris Barker wrote:

It strikes me that khtml from the KDE
project would be a good candidate. If it can be used with both QT
and Cocoa (in Apple's Safari)

IIRC it was used in Safari only because Apple implemented a minimal subset of Qt API needed by khtml that wrapped Mac's native APIs.

Thanks, I was wondering how they did that. It would be nicer if khtml was really designed to be GUI-toolkit independent. I wonder how big a subset of QT one would have to emulate? WHat about Gecko? is it any better in that respect..apparently Apple didn't think so.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier4 · March 10, 2004, 10:39pm

Hi Chris,

Vaclav Slavik wrote:

Chris Barker wrote:

It strikes me that khtml from the KDE
project would be a good candidate. If it can be used with both QT
and Cocoa (in Apple's Safari)

IIRC it was used in Safari only because Apple implemented a minimal subset of Qt API needed by khtml that wrapped Mac's native APIs.

Thanks, I was wondering how they did that. It would be nicer if khtml was really designed to be GUI-toolkit independent. I wonder how big a subset of QT one would have to emulate? WHat about Gecko? is it any better in that respect..apparently Apple didn't think so.

Well, after working on wxMozilla for over a year now, I can honestly say KHTML would be much easier to turn into some sort of wxWindows HTML renderer. =) Don't get me wrong, Mozilla/Gecko is a great product and there's nowhere else I can find an open source WYSIWYG HTML editor, but it's a massive codebase and a very complex one. Just learning it would take a significant amount of time even for an experienced developer. In addition, the Mac implementation of wxMozilla has actually been the most problematic of the implementations by far, and a big reason for that is that the low-level drawing code is actually based on OS 9 and could really use an update. Apple would have definitely had to refactor much of the rendering code and while I would have liked to see that, KHTML probably needed much less backend work to get going with their toolset.

I've actually considered making a wxWindows-based Gecko implementation, but it would basically be the same conceptually as creating a wxWindows port. That is, we'd have to write a wxWindows 'platform' implementation for Mozilla that used wxWindows controls for all the nsControl APIs and make a wxWindows-based DC for Mozilla. Could it be done? Certainly. But it would be a major effort. (The payoffs would be pretty big too, but as you know with wxWindows, a new port could take a year or more to get off the ground even with folks spending serious time and effort on it.) I recently saw a presentation on Mozilla future directions that talked about more native LNF so I was thinking about bugging the Mozilla folks to consider this, but without their help I don't think this could really happen. (Though for them there's the big plus of no longer having to maintain 3+ separate codebases for their drawing APIs.)

For HTML controls, I honestly think the best approach for wxWindows is 'wrapping' whatever popular browsers on a particular platform that we can. The way Stefan is moving forward with the wxMac improvements, I think I could have a wxSafari going by the end of 2.5.2 or maybe 2.5.3. So that would mean we've wrapped IE, Safari and Mozilla, which are the 'major' browsers out there. If someone wants a wxKonqeror, maybe wxSafari could be the basis for that, I don't know. But I think it fits with the wxWindows philosophy of providing native tools.

Thanks,

Kevin

···

On Mar 10, 2004, at 2:10 PM, Chris Barker wrote:

Chris_Barker1 · March 11, 2004, 12:52am

Kevin Ollivier wrote:

For HTML controls, I honestly think the best approach for wxWindows is 'wrapping' whatever popular browsers on a particular platform that we can.

Here's what I want, and I thought it would be easier to get it with a html widget that drew to a wxDC, than a wrapper around a full pre-existing HTML widget. Maybe I'm wrong, I imagine both Vaclav and Kevin O. are much better qualified that me to comment on that.

1) The ability to display modern html, with style sheets and all that
2) HTML easy printing with modern html
3) embedding wxControls on an HTML page.
4) similarly rendered output on all platforms, particularly printing.

Honestly, I'm not in a position to actually write any of this, but I'll test it!

ON a related note, I've been thinking about the HTML easy printing issue. I love html easy printing because its so, well, easy. However, it doesn't do all that fabulous a job of laying out text, and you don't really have that much control over how it ends up looking. In thinking about this, I asked myself: what open source appliation does a really good, platform indpendent job of laying out text? The answer, of course, is TeX. TeX is a better typsetting program than almost anything out there, and it is very efficient and platform independent.

So my proposed project is a wxTeXEasyPrinting class and a wxTeX Window. In theory, it's pretty easy. TeX outputs a DVI (Device independent) file. All you'd need to do is write a wxDC DVI Driver. A DVI driver is essentially a simple virtual machine that understands a few small sets of commands like: move here, draw this text, etc.

The easiest way to make it all work is to use a pre-installed TeX installation. All you'd need to do is send your TeX commands to TeX, and then process the DVI file. However, this is really only a practicle solution on Linuxm and other Unixes where one might reasonably expect a TeX distribution to be installed. Plus, you could have problems with fonts. Any font you wanted to use would have to be available in TeX format, and a format that wx could deal with (proably TrueType these days).

Ultimatmely, if we wanted to make this generally useful, we'd want to embed all the Tex stuff so it wouldn't have to be separately installed.

Does anyone wlse think this is a usefull idea?

By the way, this one I might be abel to worek on myself, though I'd do it all in Python.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier4 · March 11, 2004, 1:29am

Hi Chris,

Kevin Ollivier wrote:

For HTML controls, I honestly think the best approach for wxWindows is 'wrapping' whatever popular browsers on a particular platform that we can.

Here's what I want, and I thought it would be easier to get it with a html widget that drew to a wxDC, than a wrapper around a full pre-existing HTML widget. Maybe I'm wrong, I imagine both Vaclav and Kevin O. are much better qualified that me to comment on that.

1) The ability to display modern html, with style sheets and all that
2) HTML easy printing with modern html
3) embedding wxControls on an HTML page.
4) similarly rendered output on all platforms, particularly printing.

A wrapper is easier from a technical perspective (at least IMHO) because you're generally only concerned about converting input/output data back and forth and can get to a running start quicker. (i.e. typically I can 'wrap' a function in 5-10 minutes) Once you commit to re-writing a rendering engine in wxDC, you have to be sure that wxDC can do everything the "original" rendering engine can do, and that for every case of #1, 2, and 4 it produces the same output as the original rendering engine on all major platforms. (i.e. Windows, Linux and Mac) At least for someone with my background, that's much more complex than wrapping.

For items 1, 2, and 4, I'd say Mozilla is "good enough" as is, except that I haven't gotten around to wrapping the print functions. It wouldn't take long, it's just that there hasn't been much demand yet. Granted, the HTML printing in Mozilla or any other browser may not be perfect, but that's more due to the HTML format than anything else.

ON a related note, I've been thinking about the HTML easy printing issue. I love html easy printing because its so, well, easy. However, it doesn't do all that fabulous a job of laying out text, and you don't really have that much control over how it ends up looking. In thinking about this, I asked myself: what open source appliation does a really good, platform indpendent job of laying out text? The answer, of course, is TeX. TeX is a better typsetting program than almost anything out there, and it is very efficient and platform independent.

So my proposed project is a wxTeXEasyPrinting class and a wxTeX Window. In theory, it's pretty easy. TeX outputs a DVI (Device independent) file. All you'd need to do is write a wxDC DVI Driver. A DVI driver is essentially a simple virtual machine that understands a few small sets of commands like: move here, draw this text, etc.

The easiest way to make it all work is to use a pre-installed TeX installation. All you'd need to do is send your TeX commands to TeX, and then process the DVI file. However, this is really only a practicle solution on Linuxm and other Unixes where one might reasonably expect a TeX distribution to be installed. Plus, you could have problems with fonts. Any font you wanted to use would have to be available in TeX format, and a format that wx could deal with (proably TrueType these days).

Ultimatmely, if we wanted to make this generally useful, we'd want to embed all the Tex stuff so it wouldn't have to be separately installed.

Does anyone wlse think this is a usefull idea?

I'm not sure I understand, are you talking about a rich text editor for TeX, or just a wx class that prints TeX docs?

Kevin

···

On Mar 10, 2004, at 4:52 PM, Chris Barker wrote:

Chris_Barker1 · March 11, 2004, 9:18pm

Kevin Ollivier wrote:

Here's what I want

1) The ability to display modern html, with style sheets and all that
2) HTML easy printing with modern html
3) embedding wxControls on an HTML page.
4) similarly rendered output on all platforms, particularly printing.

A wrapper is easier from a technical perspective\

I'm sure it's easier. no question there.

> Once you commit to re-writing a

rendering engine in wxDC, you have to be sure that wxDC can do everything the "original" rendering engine can do, and that for every case of #1, 2, and 4 it produces the same output as the original rendering engine on all major platforms.

Actually, I don't see any reaso nit has to produce the saem output, just correct output. HTML does not specify escatly what the output looks like.

For items 1, 2, and 4, I'd say Mozilla is "good enough" as is, except that I haven't gotten around to wrapping the print functions. It wouldn't take long, it's just that there hasn't been much demand yet.

I think HTMLEasyPrinting is very popular. If there could be a wxMozilla version, I think it would get a lot of use. How would print preview be handled?

So my proposed project is a wxTeXEasyPrinting class and a wxTeX Window.

I'm not sure I understand, are you talking about a rich text editor for TeX, or just a wx class that prints TeX docs?

Pretty much just a wx class that prints (and displays) TeX docs. A TeX based rich text editor wouuld be very difficult, because of how TeX works. TeX can't lay ouot the first line of your text until it has figured out the whole page (and in some cases, the whole document, if there are cross references). This is why it does a better job of typesetting than any WYSIWIG tool. I suppose computer are fast enough that you coulud have TeX re-set the entire page whenever anything was changed, but I image it would be tricky.

What I'm thinking about is essestially wxEasyPrinting and wxHTML, but with TeX, instad of HTML as the language, and with TeX as the layout engine. It would be most usefull for reports, rather than documents that need to be edited.

I've even imagined that you could make a simple HTML to TeX translator, as far more people are familiar eith HTML these days. Such a thing might even exist, is certainly does for some subsets of SGML And XML.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov