On Mon, Mar 25, 2002 at 02:40:02PM +0100, Michael Polak wrote: > Witold Filipczyk wrote: > > >>3) Let's talk about open source Arachne instead.... and how to force OEM > >>customers to subsidize Arachne development anyway... ;-) > > >INPUT could be been not only network, but eg. keyboard. > >Arachne in addition to "browser" could be WYSIWYG HTML editor, or even > >word processor (Keyboard is much slower than network). > > Hmm, this is too complicated, and additionaly, anyone can launch Mozilla > for that, it is done already in high quality. And in StarOffice, you can > even copy+paste HTML table from HTML page to DOC page (generic text > editor window...). > > I want Arachne to stay lightweight. Norton/Midhnight commander-type > application. HTML viewing and e-mail are both basic tasks of current > PCs. WYSIWYG HTML editing not...
WYSIWYG HTML editor will be "side effect". In one frame simple JS application - text editor. In second frame text will be rendered. > >Events from User should be treated in similar way. > > Well, this is not done this way. Only common user even api is URL input > field. It would be nice to be able to redefine hotkeys - maybe all API > should be JavaScript, and user can define own menu and hotkey map using > mapping to JavaScript commands (I don't like JS, but we must implement > it, and why implementing more than one API ?) JavaScript read and write some fields and that's all. Parser fills them before. Keyboard and mouse fill some fields, too. Plugins will have acess to them, too. CSS do the same. And "manager" decide which part of browser process those data. BTW, settings in .conf file should take precedence. eg. GIF could be rendered by other program. Possibility to add new protocols without modyfing sources of core. In addition to .dgi scripts possibility to read from pipe. Is it now implemented? Pipes are avalailable under DOS, aren't they. eg. more Additional feature: plugins. What they could do, and what is not allowed and how the prevention will be look like. > >First step is to: > >- define structures "after parser" and "before render" > > This more or less exist in current Arachne. > > But I am rather talking about defining lower level API - for portable > JavaScript library. Let's implement about 20-30 basic I/O and graphical > commands, which will be available on all supported platforms.... JavaScript applets could|should|must be translated to p-code (implement loops, conditions and data access). Sorry, how much Flowerpot is done, already? All crossplatform libraries are too slow and|or too complicated to use. Source code written with use of crossplatform is the same size as with use of native libraries, but machine code is double. Main problem is multitasking, just lack of multitasking in DOS. I would rather portable Arachne "look and feel" than portable sources. WF
