Thread
System 6 Browser Development Opinions
Please rank the following features in order of importance to you for a System 6 browser (maybe Equill will rephrase that so it makes sense) ...
* Image Support
* Forms
* Can download files
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Doesn't bomb when you quit
If you have any interest in using a browser with system 6, please think about this. What do you consider useful, and what can you live without?
There are features I left out. You can include them in your ranking if you think they're important, but make sure you rank all of the ones I've asked about. Yes yes, we all want flash. Try to keep it realistic?
Thanks.
* Image Support
* Forms
* Can download files
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Doesn't bomb when you quit
If you have any interest in using a browser with system 6, please think about this. What do you consider useful, and what can you live without?
There are features I left out. You can include them in your ranking if you think they're important, but make sure you rank all of the ones I've asked about. Yes yes, we all want flash. Try to keep it realistic?
Thanks.
On the good side you don't have to worry about AppleScript.
Some words of wisdom: "It is easier to make a correct program run faster, than make a fast program run correctly".
May I recommend MPW as the development environment?
Sure, you can even write it if you like!
When first programming on a Mac Plus I used Lightspeed C 3.0, I wrote a RAM disk driver so I could copy the development environment onto the RAM disk to avoid the floppy shuffle.
Later I used THINK C 5.0 once I had a 20Mb hard drive for the Mac Plus.
I then moved to Symantecs C++ 7.0 when I got my first PowerPC.
Now the MPW tools are free there is really no excuse not to use those for open source projects.
Writing a browser,.... hmmm.
Later I used THINK C 5.0 once I had a 20Mb hard drive for the Mac Plus.
I then moved to Symantecs C++ 7.0 when I got my first PowerPC.
Now the MPW tools are free there is really no excuse not to use those for open source projects.
Writing a browser,.... hmmm.
I would be perfectly satisfied with a text-based browser along the lines of Wannabe, with the ability to download images and view them offline. Some minimal forms support would be fantastic, but if it unduly complicates the project, I vote for deferring that feature to EquantsBrowser 2.0. An 8MHz 68000 just doesn't have enough horsepower to do much beyond text, so simply being able to launch Google searches and download other System 6 goodies would float my boat.
And yes, the non-crashing feature would be a most welcome distinction from Samba.
And yes, the non-crashing feature would be a most welcome distinction from Samba.
For me it would be non-crashing, then forms, for the ocassional visit to the forum [] ]'>.
] ]'>.
I appreciate the feedback, but if you could rank all of the features I listed, it would help me out. I'm not interested in just people's top choices, but their bottom choices and in between choices as well.
That list again was:
* Image Support
* Forms
* Can download files
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Doesn't bomb when you quit
Don't worry about development order, or feasibility. Just rank them based on what you'd need/want in order to actually end up using the browser.
Other comments beyond that scope are very welcome and wanted, but the list! Regard the list!
Thanks.
That list again was:
* Image Support
* Forms
* Can download files
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Doesn't bomb when you quit
Don't worry about development order, or feasibility. Just rank them based on what you'd need/want in order to actually end up using the browser.
Other comments beyond that scope are very welcome and wanted, but the list! Regard the list!
Thanks.
Something that worked well with google would be cool for me (so I can search and grab drivers as needed). Probably impossible to do gmail?
Yeah, anything that uses HTTPS is impractical. I have a google-weather client, that uses Google's api and displays local conditions/forcast, and I started an Google yellow pages client as well, but haven't finished it. Web APIs leave the door open for all sorts of specialized mini-internet clients.
As a thought, CTB works on System 6, could one not wrap up all the MacTCP client nastiness and hide that in a comms tool. Then any client CTB aware app could use it.
Eg, The old "TCP tool" could do a simple TCP or telnet stream.
You could have an HTTP tool which would have the URL as one of it's configuration parameters, then connecting and reading would give you the page.
If you then wanted to add HTTPS you provide that as a CTB tool.
I'd be happy to develop a simple HTTP tool as described.
Eg, The old "TCP tool" could do a simple TCP or telnet stream.
You could have an HTTP tool which would have the URL as one of it's configuration parameters, then connecting and reading would give you the page.
If you then wanted to add HTTPS you provide that as a CTB tool.
I'd be happy to develop a simple HTTP tool as described.
I sorta liked how Wannabe implemented things. Since it was text only, it was fast (no tables or forms to parse and adjust formatting for, never mind JavaScript or CSS). Yet it went a step beyond the typical text mode browser by supporting logical formatting, so that headers looked like headers rather than the body text.
Of course stability is the most important thing. Speed should be near the top of those important things to consider too. Compatibility is nice, but you won't be able to achieve that and a usable browser on the 68000. (It is amazing how large the HTML component of a typical web page is these days.)
Of course stability is the most important thing. Speed should be near the top of those important things to consider too. Compatibility is nice, but you won't be able to achieve that and a usable browser on the 68000. (It is amazing how large the HTML component of a typical web page is these days.)
If I could view this forum in just plain text with no images, that would be pretty cool. I don't care about much else really. I don't know how feasible that is though.
* Plain text layout
* Can download files
** Text search
* Forms
** Decent table rendering
* Beyond plain text layout (ie, bold, font sizes, etc)
* Image Support
* Doesn't bomb when you quit
Assuming this browser would be mainly targeted at compact macs, I'm thinking image support would be low priority. I'd even go so far as to say it would be downright horrible to gaze upon most websites rendered in 1-bit glory.
I slipped in tables because Lynx does a horrible job and it's one of the few things that irritates me about it. Fancy text stuff would be nice, and I'm guessing it wouldn't be a huge thing to implement, but not crucial.
Text search would be a plus... I'm imagining loading some huge page that's rendering really badly and all I want to find is a driver that's linked somewhere near the bottom.
* Can download files
** Text search
* Forms
** Decent table rendering
* Beyond plain text layout (ie, bold, font sizes, etc)
* Image Support
* Doesn't bomb when you quit
Assuming this browser would be mainly targeted at compact macs, I'm thinking image support would be low priority. I'd even go so far as to say it would be downright horrible to gaze upon most websites rendered in 1-bit glory.
I slipped in tables because Lynx does a horrible job and it's one of the few things that irritates me about it. Fancy text stuff would be nice, and I'm guessing it wouldn't be a huge thing to implement, but not crucial.
Text search would be a plus... I'm imagining loading some huge page that's rendering really badly and all I want to find is a driver that's linked somewhere near the bottom.
* Doesn't bomb when you quit (ever, if possible)
* Forms
* Can download files (maybe the ability to download images as they come up?)
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Image Support
This would be my list of priorities, in that order. I also agree with luddite that good table support would be nice.
* Forms
* Can download files (maybe the ability to download images as they come up?)
* Plain text layout
* Beyond plain text layout (ie, bold, font sizes, etc)
* Image Support
This would be my list of priorities, in that order. I also agree with luddite that good table support would be nice.
That's a good feature I hadn't considered.
* Plain text layout
* Can download files (or pass the url to another/better app)
* Forms
* Beyond plain text layout (ie, bold, font sizes, etc)
* Text search
* Decent table rendering
* Image Support
* Doesn't bomb when you quit
* Can download files (or pass the url to another/better app)
* Forms
* Beyond plain text layout (ie, bold, font sizes, etc)
* Text search
* Decent table rendering
* Image Support
* Doesn't bomb when you quit
+
* Multiple window or tab support
* Multiple window or tab support
Multiple window support.
Consistent with System 6 user interface guidelines
Works under both Finder and MultiFinder.
I'm going to suggest NOT implementing tables for two reasons:
1. A lot of layout is currently done with CSS, so a web page will look mangled even if you have table support. (Some modern web browsers support turning off style sheets. Try it to see what I mean.)
2. It is very hard (thus computationally intensive) to make rendering decisions based upon HTML tables. It will probably make the browser unusable on 68000 Macs, and nearly unusable on any other System 6 capable Mac.
And a third reason for kicks:
3. Most web pages expect to render the page at > 800x600 (probably more like 1024x768 these days). Using tables enforces their decisions policies, not using tables circumvents those formatting decisions. Well, the former doesn't have to be true if you decide how to render the table based on other criteria.
Image support is partially possible, and probably even encouraged, on System 6 Macs. A web browser for the Nintendo DS allows you to view images when you click on a special link. The image is brought up in a separate window. They do this because images on small screens suck, but images can still be useful. They also do it because the current DS environments don't support multitasking. It is possible that some System 6 users will have Multifinder disabled -- particularly if they have a lot of RAM.
1. A lot of layout is currently done with CSS, so a web page will look mangled even if you have table support. (Some modern web browsers support turning off style sheets. Try it to see what I mean.)
2. It is very hard (thus computationally intensive) to make rendering decisions based upon HTML tables. It will probably make the browser unusable on 68000 Macs, and nearly unusable on any other System 6 capable Mac.
And a third reason for kicks:
3. Most web pages expect to render the page at > 800x600 (probably more like 1024x768 these days). Using tables enforces their decisions policies, not using tables circumvents those formatting decisions. Well, the former doesn't have to be true if you decide how to render the table based on other criteria.
Image support is partially possible, and probably even encouraged, on System 6 Macs. A web browser for the Nintendo DS allows you to view images when you click on a special link. The image is brought up in a separate window. They do this because images on small screens suck, but images can still be useful. They also do it because the current DS environments don't support multitasking. It is possible that some System 6 users will have Multifinder disabled -- particularly if they have a lot of RAM.
I agree with the no-table-support approach.
Image support, beyond the fact that I've never written code to display images, seems nice, but unembedded would be the way to go. The issue I have with images is there are so many layout images that are just unimportant. It'd be nice if there was a way to isolate the useful images, but there really isn't. There are 103 (non-unique) images used on the page for this thread alone. I thought about having a "image list" dialog that lets you get a list of the unique images, but then they're out of context and I don't know _how_ useful that is. Anyway, I'm happy to stop thinking about image support.
I would imagine that 68kmla phpbb functionality would be version 2.0 to never, but I would like to come up with a test suite or set of sites used as "targets" for development. Off the top of my head I'd like to see it work with Gamba's site and Wikipedia (read only).
Tomlee mentioned wannabee, which I've never used, but his description is what I had in mind for rendering. Using different font sizes and styles within the text, and possibly even small icons.
Well, there's stuff to think about.
Image support, beyond the fact that I've never written code to display images, seems nice, but unembedded would be the way to go. The issue I have with images is there are so many layout images that are just unimportant. It'd be nice if there was a way to isolate the useful images, but there really isn't. There are 103 (non-unique) images used on the page for this thread alone. I thought about having a "image list" dialog that lets you get a list of the unique images, but then they're out of context and I don't know _how_ useful that is. Anyway, I'm happy to stop thinking about image support.
I would imagine that 68kmla phpbb functionality would be version 2.0 to never, but I would like to come up with a test suite or set of sites used as "targets" for development. Off the top of my head I'd like to see it work with Gamba's site and Wikipedia (read only).
Tomlee mentioned wannabee, which I've never used, but his description is what I had in mind for rendering. Using different font sizes and styles within the text, and possibly even small icons.
Well, there's stuff to think about.
Oh, a couple more, get through those pesky firewalls...
* SOCKS support
* HTTP proxy support
* SOCKS support
* HTTP proxy support
i honestly think it'd be easier to come up with a new protocol for forums that worked over something like http (maybe just a domain specific markup - use http and cgi, but return something that's not HTML...) and a web frontend a la phpbb and usenet style system 6 client, than writing a system 6 browser that could display a phpbb website with an acceptable degree of accuracy.
I agree paws. I've actually looked into that exact solution before. It would be very elegant.
Well, I just looked at this page with page style turned off ... it's not all that different, just a lot plainer and a bit messier. It gives me an idea of what I could perhaps expect from a very basic System 6 browser. Party like it's 1993!
Course I know bugger all about the technicalities, but it was perfectly readable, reasonably tidy, and I'm posting now with styles off. Don't know if that helps the discussion re phpbb at all...
Course I know bugger all about the technicalities, but it was perfectly readable, reasonably tidy, and I'm posting now with styles off. Don't know if that helps the discussion re phpbb at all...
What about a proxy that turns the pages into html for primitive browsers?
Well, let's say someone wrote a script that returned
(msg (author "bunsen") what about a proxy that turns the pages into html for primitive browsers?)
Than you could do pretty much anything with that... It's a lot easier to generate HTML than it is to parse it...
I'm in over my head ...
I'm assuming that paws is referring to a LISP like notation, which is fairly straight forward to parse since almost anything can be part of a token (except parentheses IIRC).
On the other hand, a structure like the UNIX mbox format may be more appropriate. Particularly if you have the server side do a bit of the work and particularly if you are expecting someone else write the client side software. (mbox is a series of fields, with space for a plain text message. Conceptually, that will be easier for most programmers to understand.)
On the other hand, a structure like the UNIX mbox format may be more appropriate. Particularly if you have the server side do a bit of the work and particularly if you are expecting someone else write the client side software. (mbox is a series of fields, with space for a plain text message. Conceptually, that will be easier for most programmers to understand.)
Try looking at it from Lynx... it's fairly horrible, but can be used it you're determined. I think that's a better approximation of a minimal System 6 browser.
To my tastes, wannabe is a better model to emulate. It does a great job at sensibly rendering pages in pure text mode. If wannabe ran on a 68000, I'd be very happy. [And yes, I've already communicated with the author; he's not inclined to rewrite it for the 68000.]