NetSurf on RISC OS faces axe

Support for the RISC OS port of open source web browser NetSurf could be dropped as the project focuses on future development. The ROS flavour of the software hasn't been worked on for more than two years - although the browser core is being actively improved - sparking concerns by the development team. In a mailing list post today, the group appealed for a RISC OS programmer to take on the role of maintaining NetSurf for ROS. NetSurf was first developed for RISC OS desktops but later branched out to other platforms, including Linux.

Click here to visit this news quickie

Previous: RISC OS 5 port hopes for netbook now in production
Next: Dual-head DVI ViewFinder graphics card announced

Discussion

It would be a real shame if this happened, but you can't blame the NetSurf guys. If there aren't the coders out there, then I guess the game's more or less up. Shame to be overtaken by BeOS, though! lym on 6/8/09 4:31PM [ Reply | Permalink | Report ]

We've constantly been told that they were preparing the way for javascript. So have they been doing this or not? AW on 6/8/09 8:53PM [ Reply | Permalink | Report ]

JavaScript is core functionality. It has absolutely nothing to do with the front end. And yes, we have. You can see the inroads we've been making; a brand new, up-to-date CSS parser has just been merged into test versions. We're not asking for a RISC OS "core" programmer, because that's meaningless. The core is entirely OS-agnostic. Moving features from the already well-developed RISC OS front end to the core means that they can be debugged (RISC OS's debugging tools are shockingly poor by comparison to those available elsewhere) and so other front ends can take advantage of them without having to reimplement them themselves. This should lead to a better NetSurf all round; for RISC OS and other platforms. Unfortunately, nobody's touched the RISC OS front end in over two years, which is why we're asking for somebody to. rjek on 6/8/09 9:33PM [ Reply | Permalink | Report ] Does this mean that there is no point in downloading NetSurf until there is someone to update the Risc OS front end? jlavallin on 19/8/09 8:08PM [ Reply | Permalink | Report ] As I understand it, no. While the lack of a RISC OS maintainer is holding up the release of some major updates, other updates (including bug fixes and the like) are still being produced. stevef on 19/8/09 9:31PM [ Reply | Permalink | Report ]

AW: Read the development plan page linked from the mailing list post. tlsa on 6/8/09 9:01PM [ Reply | Permalink | Report ]

So it's apparently not so much the front-end as the fact that it's easier to write core sections on other platforms. Then why isn't the advert for a RISC OS "core" coder? "Many of the features that were in the RISC OS front end are now being moved to the core, so that there will be less RISC OS specific code, and that code can be tested properly on platforms with better debug tools." AW on 6/8/09 9:26PM [ Reply | Permalink | Report ] It would appear that you've woefully misinterpreted Michael's email. Moving common functionality (such as full save, page searching, textareas, treeviews, scrollbar widgets, etc) into the cross-platform core is the correct thing to do to reduce the effort required to produce a platform frontend. As part of this process, APIs get redesigned to be significantly more sane. A great deal of the RISC OS-specific code makes assumptions which do not hold in the core of NetSurf (which has to be portable). The result of these API changes, along with other, less obvious, differences is that the existing platform frontends then require fixing to work with the new core functionality. Unfortunately, there's been nobody to do this for the RISC OS frontend for the last 2.5 years. During that time, any such fixes have generally been made by Michael or myself. I have reached the point where I can no longer commit significant amounts of time to fixing the RISC OS frontend -- what time I do spend on NetSurf (and, for the avoidance of doubt, I've written the best part of 50,000 lines of code in the last year or so) gets spent on improving the core engine. Therefore, we have a choice: 1) Continue to perpetuate the myth that the RISC OS frontend is actively supported. 2) Ask for someone to come along and maintain the RISC OS frontend. 3) Remove the RISC OS frontend from NetSurf as it's getting in the way of necessary changes for the long-term good of the browser. As I've explained, option 1 is no longer viable. This leaves options 2 and 3, which Michael's email outlines. Our preference is clearly 2 -- dropping support for any platform is not a decision we take lightly. However, when it gets to the point where progress is being hindered, difficult decisions have to be made. jmb on 6/8/09 10:32PM [ Reply | Permalink | Report ] All I can say, is thanks for the (I'm sure) many tireless hours put into NetSurf's development, as I use it on my RISC PC when the Missus is on the PC (and thanks to facebook, that's a lot of the time) I would love to step up and help, but alas I'm a BASIC programmer, and so would need to learn (very well) C :@) I hope you find a person suitable, but I am not surprised by your decision! em2ac on 7/8/09 12:15AM [ Reply | Permalink | Report ]

Just to clarify, will the existing frontend work with future core coding? How simple/complex will it be for a C-savy RO user to download a potential future non-RO version of the source, and plug it into an old RO frontend? Anon on 7/8/09 11:00AM [ Reply | Permalink | Report ]

> Just to clarify, will the existing frontend work with future core coding? No, not without a maintainer for the RISC OS front end. jmb clarified this in his comment. tlsa on 7/8/09 11:25AM [ Reply | Permalink | Report ]

So having a front-end programmer guarantees that any core work will work for RISC OS? AW on 7/8/09 12:05PM [ Reply | Permalink | Report ]

Having a programmer who does nothing won't guarantee anything other than stagnation. However, having a RO frontend coder will allow us to proceed with core changes without worrying about who will have to dive in and try and fix up the RO frontend when it breaks this time. D. Kinnison on 7/8/09 1:12PM [ Reply | Permalink | Report ]

I hope Netsurf are successful in finding someone to help with the front end for RISC OS. It would be a great pity to lose a great browser, just as things were getting more interesting! sascott on 7/8/09 12:30PM [ Reply | Permalink | Report ]

I remeber being dead chuffed to buy a copy of Netsurf 1 on CD at wakefield a couple of years ago. I told the guys then that they were doing a marvellous job. I say the same now. Well done guys and thank you for a decent usable browser. It will be sad if the ROS development stops, but I guess all things have their season. Currently I use on my RPC NS2 + Development releases. Thanks again guys and good luck in the future. Becky on 7/8/09 2:50PM [ Reply | Permalink | Report ]

Just how big is the code for the RO GUI? How many files, how many lines of code? And would the code pass a code review at the place where I work? davehigton on 7/8/09 4:47PM [ Reply | Permalink | Report ]

60 .c files, 40 .h files, 1 .s file. Totalling 41000 lines approx And I doubt it'd pass code review if you closed your eyes, held your nose, and said "yeah whatever". It's old crufty code and needs some serious loving. Kinnison on 7/8/09 5:34PM [ Reply | Permalink | Report ] Are you thinking of stepping in or do you have recommendations? AW on 7/8/09 7:31PM [ Reply | Permalink | Report ] I'm not thinking of stepping in. I think it's important that some idea of the scale of the work should be publicised for the benefit of anybody who might consider it. A few months ago, I downloaded the NS source to see if I could do anything about subscripts being rendered as superscripts. I couldn't get even the first idea of where they were handled. davehigton on 7/8/09 8:29PM [ Reply | Permalink | Report ] It's the CSS vertical-align property, handled in layout_line() in render/layout.c. tlsa on 7/8/09 9:06PM [ Reply | Permalink | Report ] It is impossible to write a web browser where this sort of location activity is easy, I feel. There are just too many inputs to the layout from 15 years of committee cruft. greping NetSurf's sources for keywords is surprisingly effective, though. The HTML and CSS parsers are easily navigable, however. rjek on 8/8/09 11:01AM [ Reply | Permalink | Report ] The first things I searched the source for were "superscript" and "subscript". The results weren't helpful. Thanks for pointing me at the function that handles it; but there's and indication of part of the problem. No mention of "superscript" or "subscript"; the fragments turn out to be "super" and "sub". davehigton on 10/8/09 9:55AM [ Reply | Permalink | Report ] Exactly as there should be. [link] flibble on 10/8/09 10:08AM [ Reply | Permalink | Report ] Correct. NetSurf's layout engine is entirely based upon CSS. Any HTML presentational hints that apply to a given element are converted to CSS properties when calculating the relevant styling for the element. Thus, in the case of <sub> and <sup>, there's a pair of style rules in the default stylesheet, thus: sub { vertical-align: sub; font-size: .83em; } sup { vertical-align: super; font-size: .83em; } jmb on 10/8/09 11:29AM [ Reply | Permalink | Report ] By far the simplest way to find out where things are handled is to grep the sources. If that yields nothing, then ask the existing developers -- it's likely they know the answer. jmb on 9/8/09 8:32PM [ Reply | Permalink | Report ]

As was remarked in connection with another topic recently, money isn't the answer, but it helps. Maybe the NetSurf developers should consider a development fund along the lines of Peter Naulls' for Firefox. Or maybe now is the time to consider a modest commercialisation of RO NetSurf, along the following lines. Stage 1: the next stable RO release (3.0?) is offered for a minimum charge of £X, or more if the upgrader feels like supporting the work voluntarily. The resulting income supports the work of future-proofing the RO frontend. Stage 2: RO version 3.01 is then released with the upgraded frontend on the same £X+ basis. The disadvantage of this approach of course is that upgraders to 3.0 only are supporting work the benefit of which they will not receive. The above flies in the face of NetSurf's voluntary approach; obviously the best outcome would be for a true volunteer to step forward. But this browser is too important to the platform to be allowed to wither without all options being considered IMHO. (The value of X to be set according to the amount required divided by the expected uptake). bucksboy on 8/8/09 12:59PM [ Reply | Permalink | Report ]

NetSurf is (partially) under the GPL. Compulsory pricing will not help more than the donations for release CDs we already ask for. If people want to pay somebody to develop the RISC OS front end, then that's their interest; I don't think the project as a whole would want to. However, finding a developer who would work for cash is very almost as difficult as finding one who will work for free. rjek on 8/8/09 5:03PM [ Reply | Permalink | Report ] Aside from the fact that throwing money at this kind of problem may not end up being that helpful (and might even make things worse), where is this pool of commercial RISC OS developers who aren't already working on other projects? Having money to throw at a problem is fine, but only works if there's someone who wants to catch it (IYSWIM). stevef on 8/8/09 5:10PM [ Reply | Permalink | Report ] "where is this pool of commercial RISC OS developers who aren't already working on other projects?" Quite. I would love to help but I can't even find enough time for the projects I already have. Alan inchiquin on 11/8/09 11:11AM [ Reply | Permalink | Report ]

"where is this pool of commercial RISC OS developers who aren't already working on other projects?": I have no idea, I'm not a programmer. But I support ArtWorks, Firefox, RISC OS 5, ROOL and other important RO developers, including financially, and I (and there may be others who also) would be willing to do the same for NetSurf if that was deemed helpful. bucksboy on 8/8/09 6:46PM [ Reply | Permalink | Report ]

Presumably though, if you are gradually taking as many features as possible out of the front ends and into the core, coding the front ends themselves will become easier? In this case then at least the job will become more rather than less simple as time goes on---even if RiscOS isn't kept fully up to speed. Is that how it will work? Monty on 8/8/09 11:23PM [ Reply | Permalink | Report ]

See my earlier comment. It's not as simple as moving features wholesale from the RISC OS frontend into the core. jmb on 9/8/09 8:35PM [ Reply | Permalink | Report ] But also, to avoid scaring off potential programmers, it is not as complicated as working on the NetSurf core. It is "only" a RISC OS Wimp program that needs to be worked on, without needing to get involved in the complexities of HTML, CSS, DOM, etc. helpful on 10/8/09 2:31AM [ Reply | Permalink | Report ] Correct. Almost the entirety of any NetSurf frontend is simply concerned with handling events and rendering things the core or window manager asks for. A frontend need not care what is actually being displayed in a window -- it simply deals with drawing primitives (e.g. lines, arcs, rectangles). jmb on 10/8/09 11:37AM [ Reply | Permalink | Report ] This obviously applies to the rendered part of the HTML window, but I assume the frontend has to have an idea of different kinds of controls etc for dialog boxes and menus. Or is this handled differently? AlanB on 12/8/09 11:56AM [ Reply | Permalink | Report ] I assume you mean form controls? If so, then the only thing the frontend needs to care about is select menus. Even that can be provided by the core, if the frontend does not want to provide its own menu. In fact, I envisage only the RISC OS frontend ever overriding the default menu in this case, given that emulating RISC OS menu functionality in the core isn't a particularly good idea. jmb on 12/8/09 12:46PM [ Reply | Permalink | Report ]

I can see a problem for NetSurf if RISC OS support is dropped - who is going to provide bug reports? At least 90% of the messages on the NetSurf mailing list are from RISC OS users. Suddenly there would be almost no testers, which could seriously hamper devlopment. helpful on 13/8/09 11:16PM [ Reply | Permalink | Report ]

The fallout from the recent massive CSS-related changes in the core suggests otherwise. All we received was a bunch of bug reports about issues we already knew about. I fully expect other large-scale changes to the core to follow the same pattern -- things simply don't get into the core code without us being fully aware of the impact. That's not to say, of course, that all the code is free of bugs (that would be ridiculous) or that we don't value the reports we do get. It does indicate, however, that the amount of testing we do before things get into the core results in far more robust code than you might expect. jmb on 13/8/09 11:59PM [ Reply | Permalink | Report ] That comes across as a real slap in the face for every one that has supported NetSurf, both by reporting bugs and financially, since it's inception on RISC OS. Other platforms came in relatively recently, and now you can't wait to bin RISC OS off. druck on 14/8/09 7:13AM [ Reply | Permalink | Report ] The team obviously have binned off RISC OS personally, but if they actually wanted to bin off RISC OS collectively, then they wouldn't bother searching for a maintainer. jess on 14/8/09 9:45AM [ Reply | Permalink | Report ] > That comes across as a real slap in the face for every one that has supported NetSurf, both by reporting bugs and financially, since it's inception on RISC OS. I doubt it was intended. Bug reports are always useful. The developer's can't visit every page on the web and bug reports have been good especially for highlighting layout issues. With the recent change to LibCSS, I don't think we'd really said anywhere (that would be seen by users) that the CSS parser and selection engine had changed, and what issues to expect. So we got a bunch of reports about stuff we expected and also a couple of reports of stuff we didn't know about on the bug tracker, iirc. Anyway, yes, losing the RISC OS users as testers is one of the sad sides of having to drop RISC OS support. > Other platforms came in relatively recently, and now you can't wait to bin RISC OS off. This is just complete rubbish. Noone wants to "bin RISC OS off". The reason we can't maintain the RISC OS front end has been stated several times. I'll state it again. + There are nolonger any NetSurf developers who have WIMP knowledge and RISC OS hardware or time to invest in it. This has been the case for the last two and a half years. We've mentioned before that there was noone developing the RISC OS front end, but to my knowledge noone approached us to help. It is precisely because we don't want to drop RISC OS support that we made this urgent appeal, asking for developers to help. We've also spent time recently simplifying the RISC OS build instructions and making it far easier for a RISC OS developer to get NetSurf built. For example now, to build and install all our libraries (like Hubbub, LibCSS, etc) you just need to type *make install. As for the other platforms and how recently they came in, it really has nothing to do with the problem the RISC OS front end faces. The AmigaOS front end has an Amiga developer to work on it, the BeOS front end has a BeOS developer. The GTK front end has mostly been developed by GSoC students lately. The difference is that there are people to develop those front ends, while for the RISC OS front end there is noone. This is sad, but other than asking for a developer to help maintain the RISC OS front end, what else can we do? tlsa on 14/8/09 9:48AM [ Reply | Permalink | Report ] I think Druck has slightly overreacted, as at no point have I got the impression that the NetSurf team *want* to drop RISC OS support. It is just that if there is no one to work on it, what else can they do? Hopefully all this discussion will prompt a C Wimp programmer to come forward and take on the challenge. helpful on 14/8/09 1:49PM [ Reply | Permalink | Report ]

Perhaps ROL/ROOL would be interested in producing a front-end that uses NetSurf's core? RISC OS has long needed an up-to-date native browser (like the 21st century Browse). They have experienced WIMP developers I presume? Just a thought. Smiler on 14/8/09 10:29AM [ Reply | Permalink | Report ]

Yeah, plug the NetSurf backend into the Browse frontend - best of both worlds Anyone got some incriminating photos of Andrew Hodgkinson so we can make him do it helpful on 14/8/09 12:42PM [ Reply | Permalink | Report ] If only I had the time! I've been following the thread and it'd be great to get involved but there is no point committing to anything at present. All I would do is let people down. That's not a "no forever" but it's a "no for now". As for incriminating photos - the picture of me dressed head to foot in camo gear in front of a too-tall Risc PC at Acorn World many years ago is about as bad is it gets. Since it was distributed in full colour horror-o-vision on the front of Archimedes World, it's hard to imagine anything worse. And yes, I've seen some of the more recent show photos; no contest so far adh1003 on 20/8/09 4:45PM [ Reply | Permalink | Report ] "it's hard to imagine anything worse. And yes, I've seen some of the more recent show photos; no contest so far" Ooh, I like a challenge. flibble on 20/8/09 7:46PM [ Reply | Permalink | Report ] "As for incriminating photos" I've certainly seen what I need to see. But then I'm probably mistaken. So I won't comment on my conclusion. sa110 on 21/8/09 4:26PM [ Reply | Permalink | Report ] Don't you think both ROL and ROOL perhaps have their hands full with their respective projects? sa110 on 4/9/09 3:26PM [ Reply | Permalink | Report ]

As much as I think NetSurf is easily the best browser available on RISC OS, and probably has a lot of potential, I'm not sure that if we only have resources to pursue one browser on RISC OS, that NetSurf should be it. In the shape of NetSurf we have a browser that has not had any RISC OS work done on it in quite some time. If that changes, and they get a RISC OS maintainer, then we'll still have a browser that is not capable of going on a lot of websites. Maybe we'd be better off looking at Mozilla Fennec, which is like Firefox but aimed at smaller devices, or maybe Origyn, which is a portable version of WebKit. thegman on 14/8/09 1:02PM [ Reply | Permalink | Report ]

But Mozilla Fennec on RISC OS is a lot of work, including work on the core and Netsurf is much less and mostly simpler work on the frontend. egel on 14/8/09 1:43PM [ Reply | Permalink | Report ]

I'm not sure about how much work a Fennec port would be, I can only guess really, I expect Peter Naulls would know a lot more, as he ported Firefox, which I would (maybe naively) assume is very similar. I will make some cursory investigations into OWB and see how I go. thegman on 14/8/09 1:52PM [ Reply | Permalink | Report ]

The last thing we need is another half finished, slow, buggy browser. druck on 14/8/09 8:22PM [ Reply | Permalink | Report ] [link] flibble on 14/8/09 11:39PM [ Reply | Permalink | Report ] OWB has an excellent rendering engine with Javascript etc, however: * It is (arguably) slower than NetSurf. * You'll have to code the entire GUI and a lot of expected features yourself. * and of course it's more work to port a new browser than do a bit of work on an existing one (OWB is quite a lot larger than NetSurf and takes much longer to compile - it is also all in C++ which puts me off!) When NetSurf gets Javascript, for the most part it will easily surpass OWB - even with only minimal effort spent fixing-up the RISC OS frontend. I've spent a year less on NetSurf than Joerg has on OWB, and I have ended up with a more complete browser - because most of the functionality is in the core already, it just needs a menu or button added. Chris (maintainer of the AmigaOS 4 frontend) chrisy on 23/8/09 6:16PM [ Reply | Permalink | Report ]

Has anyone stepped forward yet ? If it was BBC BASIC and desktop WIMP programming I'd have gone for it. A C programmer I am not. (I'm busy teaching myself ARM assembly at the moment which I'm finding surprisingly rewarding. The speed boost from optimised assembler is quite astonishing...) I can't help thinking of the NetSurf team waving a massive wad of £5 notes at the Wakefield show from sales of the NetSurf RISC OS CD. If it helps someone step up to the mark, I'm sure most punters at the London Show would chuck that person a fiver. Hell, what's £5 ? 200 x £5 = £1000 Surely that's tempting to someone ? Just a suggestion.... Regards, Martin. martin on 14/8/09 3:27PM [ Reply | Permalink | Report ]

I've lost count of the number of people who say "I'd love to help, but I'm only a BBC Basic programmer" Well, how about helping by learning C, and then helping directly? And again, money doesn't help a jot if there's nobody to give it to. Most of the money we collect at shows gets gobbled up by travel and stand expenses. And £1000 might get you a month's work. It's more than that. rjek on 14/8/09 3:36PM [ Reply | Permalink | Report ] "Most of the money we collect at shows gets gobbled up by travel and stand expenses" Your stand booking for the London Show seems to have been lost in the post We are willing to give the NetSurf team a free stand, so you can use the show to try to drum up programmer support. How about it? helpful on 14/8/09 6:05PM [ Reply | Permalink | Report ] I'm not sure any of us can make the time to attend. rjek on 14/8/09 6:56PM [ Reply | Permalink | Report ] Now that really would be a slap in the face for RISC OS users Come on, it's only one day! And being organised by ROUGOL, it's bound to involve beer and curry at some point helpful on 15/8/09 2:54AM [ Reply | Permalink | Report ] Sorry, but we have real lives outside RISC OS and NetSurf. And it's more than one day for the developers who don't live in the south of England; I remember driving down from Manchester to the Guildford show one morning to arrive at 8am, and driving back the same day. Nasty. rjek on 15/8/09 11:10AM [ Reply | Permalink | Report ] Rob I enitrely agree with you. Unless you are able to stay over, doing it all in one day from Manchester is a bit of a strain. sa110 on 15/8/09 11:30AM [ Reply | Permalink | Report ] Have you not heard of those big long things on wheels called trains? Journey time from Manchester Piccadilly to Feltham is just under 3 hours, most of which you can spend asleep. We've deliberately made the opening time slightly later (11am) to make it easier for those with longer journeys to get there in time without needing to stay overnight or set off horribly early. helpful on 16/8/09 5:15PM [ Reply | Permalink | Report ] I'm not carrying the equipment we normally bring (two LCDs, two RISC OS boxes, two laptops, our banner, gang leads, ethernet switch, lunch, etc etc etc) on a train. rjek on 16/8/09 9:18PM [ Reply | Permalink | Report ] We can provide the LCDs, gang leads, ethernet and lunch. So that only leaves the two RISC OS machines (A9's going by previous show visits), two laptops and the banner. Unless you are carrying tham all on your own, that's easily transportable by train. helpful on 16/8/09 10:52PM [ Reply | Permalink | Report ] You've seen the size of our banner, yeah? Forget it. It's not happening. (At least, not anybody from NetSurf north of Watford.) rjek on 17/8/09 9:18AM [ Reply | Permalink | Report ] And how many hundreds were raised for the Firefox 2 port? Is that finished yet? No amount of money can make more hours in the day for developers work on these projects, especially when there is very little else to motivate the work as most developers have long since looked to other platforms for fundamental necessities like web browsers. druck on 14/8/09 8:26PM [ Reply | Permalink | Report ] People who put money up front for free software development almost always get what they deserve: nothing. A bounty scheme is far better. rjek on 14/8/09 11:10PM [ Reply | Permalink | Report ] "People who put money up front for free software development almost always get what they deserve: nothing" Why do they deserve nothing more misplaced generosity? Maybe they are being unrealistic in expecting something, but they *deserve* nothing? What a charming attitude. Monty on 15/8/09 11:19AM [ Reply | Permalink | Report ] should read: *for* misplaced generosity Monty on 15/8/09 11:20AM [ Reply | Permalink | Report ] Throwing your money away with no promises or guarantees is pretty naive, if you ask me. rjek on 15/8/09 5:32PM [ Reply | Permalink | Report ]

Is there a good C tutorial around that would give some one the basics to maintain the RISC OS front end? Revin Kevin on 14/8/09 5:24PM [ Reply | Permalink | Report ]

Any number. Search Amazon, Google, and your local night school. rjek on 14/8/09 6:56PM [ Reply | Permalink | Report ] Revin, The RISC OS Connect site has development links to tutorials and general information for ARM Assembler, BBC BASIC and C. You may find this useful. sa110 on 15/8/09 11:35AM [ Reply | Permalink | Report ] The link, which I forgot to insert in my previous post is: - [link] sa110 on 15/8/09 11:37AM [ Reply | Permalink | Report ] For better or worse, I imagine many home-grown RISC OS programmers followed something like the following sequence: 1. Learnt BASIC 2. Learnt WIMP programming in BASIC 3. Learnt portable-ish C 4. Programmed C in a BASIC-like way with a library like OSLib, DeskLib or (back in the day) RISC_OSLib 5. Programmed C with a higher-level toolkit like the Toolbox (or DeskLib to some extent) (and if you go down the lower-level route, assembler and writing modules will fit in somewhere, but aren't of concern for someone doing WIMP stuff) Now of course you can do these differently, or in a different order. But I think the biggest step is 2. Once you have some idea of how to program, learning how to interact with the WIMP is the main thing. Having done that, switching language (especially if you've even seen other computer languages) isn't so hard... just takes a little while to get your head around new features like structures, a while until you stop making stupid typos, a while to iron out your silly bugs, and a while to develop a good coding style (peer review helps a lot with all this). You can, of course, short-circuit this by going straight to the Toolbox. But sooner or later you'll need to interact with the WIMP directly. So it's worth knowing how the WIMP works even if you rely on something else to do the legwork most of the time. This is more the case than, say, Unix where there's not so much of a need to learn Xlib because libraries like GTK cover it more. But by all means start with the Toolbox and then fill in the detailed WIMP stuff later. I think I would actually suggest BASIC is a better environment to learn WIMP programming than C as it's more dense. Especially with a library so you don't have to do all the q%!(q%?3) stuff. Then you can switch to C which will have a similar library, and better structure support for manipulating WIMP data. caliston2 on 15/8/09 8:05PM [ Reply | Permalink | Report ] "I think I would actually suggest BASIC is a better environment to learn WIMP programming than C as it's more dense." I favour static type checking, speed, reliability, and readability over density of code. Any day. rjek on 15/8/09 8:37PM [ Reply | Permalink | Report ] How's a compiler faster than an intrepreter? How's fumbling around with bits in C more reliable than BASIC snippets? How's lenghty C functions more readable than BASIC? How do you square readability as being opposite to code density? That said, DrWimp's good for learning the WIMP, C's best for serious programming. Anon on 21/8/09 4:29PM [ Reply | Permalink | Report ] "How's a compiler faster than an intrepreter?" Err. Because it generates native code? Or are you talking about the actual done-once compilation? All RISC OS development I've done for years and years has been on a Linux box. Compilation is essentially instant. "How's fumbling around with bits in C more reliable than BASIC snippets?" Only amateurs or the disinterested fumble. Everybody else crafts something beautiful and elegant. "How's lenghty C functions more readable than BASIC?" Casting, structs, type names in function prototypes, block comments, finer-grained variable scoping all make code much much much easier to read. "How do you square readability as being opposite to code density?" Buh? "C's best for serious programming." Which NetSurf is. rjek on 21/8/09 8:03PM [ Reply | Permalink | Report ]

Any takers yet? AW on 26/8/09 10:16PM [ Reply | Permalink | Report ]

If no takers, I might have a look into it, but it would be a while as I would need to learn C (I am fairly good at picking up new languages from pre-built well commented code, as I did for Java) Might need some help though! So I would apologise for that even before I were to start. However if there were anyone doing it, I might (given time as I have 2 kids) look into it any as a helper. em2ac on 10/9/09 7:07AM [ Reply | Permalink | Report ]

It would be a real pity if support for the RISC OS end was dropped, I hope someone comes forward with the necessary skills and enthusiasm. Fortunately the latest version of Firefox is much improved and runs fairly fast. Thanks Chocky ! broon on 29/8/09 4:33PM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

It's the Music, Man
It comes from not-so-far away
 14 comments, latest by cynic on 3/2/05 7:59PM. Published: 18 Aug 2004

Random article

Accounts software CashBook updated
Version 1.10 also to be demonstrated at Wakefield 2008
 Discuss this. Published: 24 Apr 2008

Login

Useful links