Michael Polak wrote:
> 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.
I think arachne needs a runtime for plugins... sort of multitasked apps.
>
>
> 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).
Turn it into a dos port of Mozilla...? Maybe.... but difficult.
I think that if we just used some source code from mozilla to make life
easy.
>
>
> 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.
Java is needed for chatrooms. And the like. I like the idea of Java.
>
>
> 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).
I like object orientated.
>
>
> 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.
I never use the PPP button simpily because i use ethernet :)
>
>
> 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.
Multitasking.... isnt too hard... see if you can get some code from that
project of decompiling DV/X that
source code would work well.
>
>
> - 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.
For the Linux version... try to get an X11 version out... that or with
GTK or QT.
>
>
> 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)
Mmmm those single click icons shit me. I agree with you there... and my
applets are just coooool
> , 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...
I noticed that occurance.
>
>
> 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
I like XML...
>
> 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...).
Im learning XML i like it... i could help code it
>
>
>
>
