I have seen "newbuild" directory on arachne-dist FTP archive, but I
haven't seen any changes in README file compared to 1.70, so I haven't
tired it yet.
Myself, I see only one reason for releasing updated 1.x Arachne for DOS,
and that is three-digit color bug in CSS, which was easy to fix, and
people may need it.
I have recently spent lot of time doing custom web programming (MySQL,
PHP, JavaScript, CSS, layers...) because I wanted to understand latest
trends in webdesign - I could never wrote Arachne, if I was not working
as webmaster in 1996. I was forced to use latest web techologies
available these days, so I was able to implement them in Arachne too.
First of all - this DOM, layer, CSS, JavaScript etc. stuff is very
complex. We can never add it all to Arachne just by "patching" existing
code.
So far, there are 4 players left, who can do latest HTML-related tricks,
including layer visibility,etc.: MSIE 6, Opera 5(or 6, I am not sure
about numbering), Mozilla 1/Netscape 6.x (Gecko engine), and Konquerer
browser (KHTML class). If we want to write 5th full featured browser
(and Arachne 1.x can never become full featured browser - it can end up
on Netscape 4.x level, which is already abaned by webmasters, and uses
non-compatible implementation of layers, which won't be supported by
future browsers).
I suggest full Gecko/Mozilla compatibility, so we can merge
Arachne-advocacy/evangelism with Mozilla-advocay/evangelism. I would
mark it as Mozilla/5.0 internaly, adding MSIE string to user
agent/navigator.appVersion strings, so javascripts and such stuff can
send us let's say MARQUEE tag. Myself, I don't mind MARQUEE tag at all,
and as it is used on so many web pages, browser like Arachne or Mozilla
have no other chance but implement it (at least in Europe and my country
- MSIE-ism is terribly wide-spread).
Another question is Java - most Java I have seen today are simply fancy
menus inserted automaticaly by FrontPage. As HREF is supplied as applet
option, what about writing some plugin for Arachne which would convert
most commonly used auto-generated Java classes into HTML/JavaScript.
I must say I hate JavaScript syntax and object model. I like PHP, except
that I would write variable$ instead of $variable, and it would be basic
;-) But as Arachne 2 wants to be minimal browser, we must have
JavaScript. And once we have JavaScript, we should write all user
interface of the browser in JavaScript - I wouldn't use any new XML
language like Mozilla's XUL, because everyone (was forced) to learn
Javascript (which is ugly object oriented piece of crap, IMHO). So I
would abandon all ARACHNECFG= and <ARACHNE ...> stuff, and move to
prorpietary JavaScript class arachne.* (like arachne.menu,
arachne.systemwidecfg..., arachne.usercfg...) which would be allowed to
be accessed only by trusted HTML documents (eg. local files).
Configuration files in JS format (like Mozilla has) is probably the best
option, because I would like the browser to include as few parsers as
possible (namely HTML parser, CSS parser and Javascript parser). So
ARACHNE2.CFG would look like
arachne.systemcfg.ppp_phonenumber("123456");
arachne.usercfg.email("some@somewhere");
(navigator.prefs can be added later for mozilla compatibility ? it is
not really important, I think... maybe readonly API ?)
By the way, CVS for Flowerpot and Arachne2 is already ready, so you can
start sending usernames and passwords and installing CVS, if you are
interested. The problem is that I haven't uploaded any Arachne 2 code
yet... it is not clear, how much "from scratch" we should start, but I
believe it should be very "from scratch". I mean, we can transplant HTML
renderer from Arachne 1 later, but I want to declare some basic concept
rules for portable Arachne - and you can help me, of course...
What should go into Flowerpot ?
Keyboard, mouse, graphics, fonts, image display, audio (?), networking.
That's absolutely clear.
But I suggest including also kind of "registry" (both multiuser and
single-user), emulation of multiuser enviroment for platforms like DOS
and Win32 (system-wide vs. user-specific configuration files, accessed
via some "registry" interface..). In DOS, all dialing and TCP/IP stuff
must be included in Flowerpot, too. Normal operating system don't let
applications dial on their own, etc. But Flowerpot may provide some API
for let's say connecting, disconnecting, launchign apps, etc., so
Arachne can provide HTML interface to do this stuff.
What we want from Arachne, what Mozilla cannot provide ?
- compatibility with very simple OSes, maybe with lack of multitasking
and limited amount of memory available. 640 K limit is good for
eliminating braindead code - allocation let's say 16 MB chunk of memory
by malloc() is reason why software became so crappy, and usage of
cryptical and buggy low-level classes too.
I suggest keeping Arachne to be fullscreen-oriented, themizable via
skins (xmms/winamp class of applications). On single task OSes,
multi-tab (not multiwindow) GUI would be available, on multitask OSes,
multiple copies of application (even owned by the same user) must be
able to run. This may be supported either on Flowerpot or on Arachne
level. Maybe Flowerpot should stay resident as daemon on let's say
Linux, so all Flowerpot-based apps (I expect simple games to appear
soon) can share flowerpot services ?
Eg., imagine fullscreen networked game, which would include button for
starting and terminating PPP connection like Arachne does. This is
completely different in DOS and in Linux (and of course in Windows),
although dial on deman may be available.
We may want:
- Flowerpot to stay resident in DOS, and eg. be able to connect with
Arachne sitting on top of it, and continue while some other Flowerpot
based app is launched.
- Flowerpot to detect existing connection (eg. packet in autoexec, or
existing newtwork interface in Linux), and pass connection status to
appliation. In Linux, we want Flowerpot-apps to share status while at
least one such app is running (like KDE, GNOME or Mozilla project does -
expcept that we want to do it in a very simple and lightweight manner),
while in DOS, we need basicaly the same without multitasking - launching
external application should be flowerpot-aware, which basicaly means
using either lock files or TSR - lock files solution would be more
robust, but TSR more flexible. Basically, we should write TSR WATTCP,
but I abandoned this idea already long time ago, so simple status
passing (like my-ip.bat file does) and shared config may be enough.
What we are writing is not just new web browser, but mainly new API -
because crappines of existing software is based mainly on the fact, that
underlaying libraries and object classes are crappy. KDE is slightly
smoother then GNOME (altough I like GNOME more), because only people who
knew how to use Gtk correctly were GIMP authors. Most non-GIMP Gtk
applications use some subset of Gtk, which behaves more or less crappy
and user-unfriendly...
Simpler API for Flowerpot will result in more people developing Arachne,
and more people porting Flowerpot to other platforms. Lets go back
somewhere to ZX Spectrum days, when programming was easy and accessible
for everyone...
For example fonts: font naming conventions differ from platform to
platform. We will have some
flwr_text_xy(int x, int y, char *str) function definitely.
but what about
flwr_setfont() ???
should it specificaly name font face (Arial...) or just font family
(serif, sans-serif, monospace, fantasy ?)
What about
flwr_setfont("font-family: sans-serif; font-size: 12px ");
?
Eg. moving CSS parsing into Flowerpot! This would allow using X-lib
font features in Linux, Windows TTF inteface in Windows, and existing
simple font set for 16bit DOS... but parsing text string may take some
time (on the other hand, all graphical operations take some time, so
it should be such a big problem...).
I would eliminate all htmlfont(size,style) statesment from future
Arachne, and always store font information in CSS format, in future Arachne.
As CSS attributes can be applied on most graphical objects (boxes,
images, tables, fonts...), writing user interface in CSS/HTML/JavaScript
would allow also writing scripts using CSS/HTML/Javascript - eg.
specialy stylised buttons would look the same way inside built-in
toolbars and built-in mail and desktop pages... and Arachne users would
be given chance to learn CSS, which is anyway the only way to go these
days... (css is slightly less braindead than adding more and more extra
tags, on the other hand, I would appreciate XML syntax for CSS... but it
is to late these days...).
