It's slightly strange to subclass the HTML widget from Composite, when there is already a widget (Richtext) that does all the formatting stuff. Subclass from Richtext and write code to parse (i.e. keep MwHtmlParse as it is) and format (a redesign of MwHtmlDump). I could even implement code to deal with URL:s and parallell sessions, but that's overkill for now. I just want to be able to display Siag's online help without a third party applicaion. Why not add hyperlinks to PW as well? Then the "web browser" would simply be PW in readonly mode. OK, but for now work on the HTML widget as it is. I need to move to a three-pass display algorithm. The first stage is to parse the HTML code into a tree. That is done by MwHtmlParse as usual. The next stage is to dump the tree into a line buffer, where each line contains information on its position (x,y) in the document, the type of the line (text, image, table) and the text to be displayed. These two steps are done whenever the HTML code changes. The third and final step is to render the buffered information in the widget. The reason for the intermediate representation is that it is much more efficient when we later want to map between pointer position (mouse-over, clicking on hyperlinks) and text. Soo... The public resource html, or whatever, is the text the widget is displaying at the moment. The private resource tree, or whatever, is the result of calling MwHtmlParse with the html text as argument. It is reset to NULL in SetValues whenever html changes. The public resource url is used to get the widget to retrieve text from a file or web server. When it is changed, SetValues set html to NULL. This will prompt html to be updated on the next Redisplay. The private resource text is the result of dumping out the parsed tree in a displayable form. It is an array of lines. Each line is a richtext string plus information about height, style, indentation and bop. This is almost exactly the same as PW, except that PW doesn't have the indentation stuff (but it should). Why should I care about the style? I guess it might make sense to use that information to keep track of images and such... Nah. --- Make MwLoadImage load more image formats by using netpbm utilities. It would be as simple as this: - let MwLoadImage load p?m images natively rather than xpm - use anytopnm from netpbm to read the images This will land me in problems if the netpbm package is not installed. Write a small (tiny) app that takes care of the most common formats, such as xpm, jpeg and png. It should know how to handle p?m; this code exists in my anytoany program. Netpbm by default installs into /usr/local/netpbm, which isn't in the default PATH. --- The file selector is incredibly convoluted. Change it like this: - Initialize creates all the widgets *except* the directory and format menus (including buttons). The noncreated buttons are set to None. directory is initialized to the current working directory, filename is initialized to the empty string, format is initialized to the "All (*)" string from the standard patterns. - fsel_scan scans the directory for directories and files, updates the directory and file lists, creates the directory and format menus. This means that we must add a resource for the formats, so the menu can be recreated when needed. It also sets dirbutton, formatbutton labels and filetext string. It does not recreate the extra command buttons. fsel_scan is the function to call when anything has changed or been changed. - MwFileselSetFormats is removed. - MwFileselAddExtra is removed and replaced with a resource. --- More widgets: - Calendar - Ghostview? - HTML - Colorpicker - Colorwheel --- ANSI C everywhere. --- Fix compiler warnings. --- Seems like all calendar widgets are unnecessarily complex. All I need is something that can: - display the year + something to change it (set, step up, step down) - ditto for month - ditto for day of month - display the current month with the current day highlighted - change the current date when user clicks - call callback when current data changes That should be no more than a couple hundred lines. Maybe I shouldn't even bother with the year, month, day display thingie. --- Patches for existing applications to use Mowitz. Sample applications for all widgets. Drop-in replacement for Dialog as example application. Utility routines: - Converting from Pixmap to XImage and back - Dithering - Support for major Drag and Drop protocols - Font management
