log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
- Big NVMe news for the RISC OS at the South-West Show (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: General: Who *wants* an Open Source RO?
 
  Who *wants* an Open Source RO?
  This is a long thread. Click here to view the threaded list.
 
Simon Willcocks Message #42225, posted by Stoppers at 20:30, 16/5/2003
Member
Posts: 302
I don't think any application is so especially wonderful as to keep me using
RO, it comes down to just the WIMP (and the style guide).

So, I wonder: why are people talking about an Open Source RISC OS? I'd much
rather have a RO-WIMP front end to Linux (or OpenBSD) that uses a low level
graphical interface to duplicate the look and feel of RISC OS (AA fonts,
drag and drop saving etc.), and applications modified to match the style
that RO does so well.

I think it would be worth porting many RO applications to Linux, using an
OSLib library to make it easy for C programs, at least, and allowing new
applications to be developed with the easy to understand API. (An emulation
program that allows ARM programs to run on the system would be a plus, but
native applications are better.)

ROX doesn't really do it for me, because it's still X based and all the
applications running on it still look and feel like Linux Apps. I'd have an
X server running as a "native" application, to run unported code, but the
majority (hopefully) of applications running will have been patched (at
least) to make them behave "properly" in the WIMP.
  ^[ Log in to reply ]
 
Annraoi Message #42230, posted by ams at 11:27, 17/5/2003, in reply to message #42225
Member
Posts: 56
While I have *nothing* against Linux (after all it's just another operating system), Linux will continue with RO being emulated on top or not. But will RISC OS ?

At a time when things are beginning to lookup for RISC OS it appears as if some (ROL/VA/MD for example) seem intent on moving it over to Windows. The approach you suggest Simon is just the Linux variant of the same thing.

The only virtue to your proposal is it does not line Bill Gates pockets.

As I see it the "worse case" scenario (no RO native hardware) I'd suggest a portable microkernel that is compatible with the HAL in RO5 - then it might be possible to port RO without the inherent bloat of Linux (no offense intended - but it seems a bit over the top to have to run one whole OS in order to use another one !!!!).

As we've not reached the worse case scenario (and hopefully will not) how about supporting the RO hardware vendors who still prove there *is* an alternative to the PC and Windows.



Regards

Annraoi
  ^[ Log in to reply ]
 
Antony Sidwell Message #42232, posted by ajps at 14:03, 17/5/2003, in reply to message #42230
Member
Posts: 48
At a time when things are beginning to lookup for RISC OS it appears as if some (ROL/VA/MD for example) seem intent on moving it over to Windows.
That's just not true though is it? It's a fun way to interpret the "Alpha" portable if you like to discredit the non-Castle part of the market, but that's all.

VA have one product - a RISC OS emulator that runs on Windows. That doesn't mean they want to destroy the ARM hardware-based systems, but they aren't going to turn down a chance to sell a better product and make money for their company.

MD have put in a huge amount of work to develop a computer from scratch which will run RISC OS natively. If their vision of the future was to move everyone over to Windows, I think they probably would have saved themselves the grief. They wanted to make some money on the side of their main product by selling something that fills a niche in the RISC OS market - a portable. It's not ideal, but it will be useful for some people.

ROL have one purpose, which is to fund their development of the OS through sales of that OS. The "Alpha" thing means that they sell copies of the OS which will fund development of the OS. There is *no* reason in the world for ROL to want to move people to Windows. Just like there is no reason for them to backport their improvements to the OS so that everyone can use them for free - there's no money in it, and with no money, no more improvements.


As I see it the "worse case" scenario (no RO native hardware) I'd suggest a portable microkernel that is compatible with the HAL in RO5 - then it might be possible to port RO without the inherent bloat of Linux (no offense intended - but it seems a bit over the top to have to run one whole OS in order to use another one !!!!).
Linux isn't the most bloated kernel in the world - not as slimline as RISC OS, but not bloated.

Whatever you use you would need an emulator in your "microkernel" to be able to "portably" run RISC OS apps on it. The HAL doesn't actually make RISC OS entirely hardware independent - it just makes it easier to move it from one ARM-based hardware design to another.

As we've not reached the worse case scenario (and hopefully will not) how about supporting the RO hardware vendors who still prove there *is* an alternative to the PC and Windows.
Yup, like ROL and Castle at the moment, MD if they ever produce their Omega for public consumption or if you need a portable machine capable of running emulated RISC OS right now (which includes supporting VA).

Good call.
  ^[ Log in to reply ]
 
David Boddie Message #42236, posted by davidb at 16:14, 17/5/2003, in reply to message #42230
Member
Posts: 147
As we've not reached the worse case scenario (and hopefully will not) how about supporting the RO hardware vendors who still prove there *is* an alternative to the PC and Windows.
The trouble is that, when you do reach the worst case scenario, it's far too late to do anything about your predicament as, by then, all the developers who would have been willing to migrate the platform have already left.
  ^[ Log in to reply ]
 
Simon Willcocks Message #42240, posted by Stoppers at 20:08, 17/5/2003, in reply to message #42230
Member
Posts: 302
Ah, the thing is, I don't much care if RISC OS survives, as long as I can
use a sufficiently similar GUI.

The approach I'm suggesting is a very usable and easy to learn alternative
to KDE and Gnome for Linux; perhaps some applications will be developed
specifically for it, others would be ported (from RO or Gnome/KDE) and all
the other Linux applications would be available via an X server.

The hardware would never fall far behind, since it runs on standard hardware
*as well as* ARM hardware. It's also not an impossibly huge job (providing
much of the functionality of the RO API using GNU/Linux libraries).
  ^[ Log in to reply ]
 
Andrew Duffell Message #42241, posted by ad at 21:11, 17/5/2003, in reply to message #42240

Posts: 3262
In the end all these companies are businesses. Their prime aims are to survive and make money. They will do this by any means possible.
  ^[ Log in to reply ]
 
David Boddie Message #42244, posted by davidb at 02:31, 18/5/2003, in reply to message #42240
Member
Posts: 147
Ah, the thing is, I don't much care if RISC OS survives, as long as I can
use a sufficiently similar GUI.
Well, I have a similarly selfish approach to the "RISC OS market" but I'd rather like to keep my data as well. ;)

I don't care too much about the GUI as long as it's fairly user-friendly.

The approach I'm suggesting is a very usable and easy to learn alternative
to KDE and Gnome for Linux; perhaps some applications will be developed
specifically for it, others would be ported (from RO or Gnome/KDE) and all
the other Linux applications would be available via an X server.
You should probably look at this page for inspiration:

http://roxos.sunsite.dk/

The hardware would never fall far behind, since it runs on standard hardware
*as well as* ARM hardware. It's also not an impossibly huge job (providing
much of the functionality of the RO API using GNU/Linux libraries).
It depends on whether you're keeping a load of the legacy stuff. If you're only really interested in the look and feel then most of what you're after is already available elsewhere, although you may not like the form it takes.

The point is: if you're not interested in keeping the applications, or your data in their file formats, then you may as well pick a better starting point than the RISC OS GUI.
  ^[ Log in to reply ]
 
Simon Willcocks Message #42246, posted by Stoppers at 09:23, 18/5/2003, in reply to message #42244
Member
Posts: 302
Thanks for the link, it sounds very promising.

I really, really like the RISC OS GUI, it's what is keeping me using this old computer for day-to-day tasks. I have a 2.4GHz machine upstairs gathering dust despite the fact that it compiles code up to 60 times faster than my SARPC (OK, only 12 times faster the first time I try it).
  ^[ Log in to reply ]
 
Simon Willcocks Message #42247, posted by Stoppers at 09:29, 18/5/2003, in reply to message #42241
Member
Posts: 302
Yes, but there are two ways of approaching the problem. One is to try to kill the competition, the other is to cooperate (in limited areas) to grow the market. With a market the size of this one, only the second makes any sense, but everyone seems to have gone for the first. :(

Even so, I think ROL were in a position to force a level playing field a couple of years ago, but didn't.
  ^[ Log in to reply ]
 
Annraoi Message #42252, posted by ams at 12:47, 18/5/2003, in reply to message #42232
Member
Posts: 56
At a time when things are beginning to lookup for RISC OS it appears as if some (ROL/VA/MD for example) seem intent on moving it over to Windows.
That's just not true though is it? It's a fun way to interpret the "Alpha" portable if you like to discredit the non-Castle part of the market, but that's all.
Is the effect of providing a laptop and emulation software, WindowsXP and Select 3 a thing that will make it *easier* for people to (in effect) move to Windows the answer *must* be yes.

First off the laptop is expensive enough (soaks up some money people might have kept for buying *actual* RISC OS compliant hardware (the curious one in this is that would also hit *MD* - why would they do something that damages their own soon to be released Omega ?). Then you have the slice for VA and ROL - and (the bigger slice of the software component of the sale) to Messrs Gates and Balmer.

The least damaging option would have been to make RO4/Select3 + VA available for existing PC laptop owners (that at least doesn't suck as much money out of the RO market).

As to RO on another platform (aka the worst case scenario) then a limited kernel/ARM processor emulator is the way to go. Yes Linux is more bloated than RO - but no where near as badly as (say) Windows, but the point is can we do better than Linux ?

I mean VA needs a raft of specific Windows calls to do what it does, there is *still* no full RO emulation on Linux - it would therefore be more sensible (IMHO) to produce low level x86 (or whatever) kernel - with an ARM (just the processor) emulated (the other hardware can be handled by the HAL and the relevant drivers). You'd probably wind up with something that runs rings around VA (I stress not due to any deficiency in VA - I am rather impressed with it - but rather that you'd have cut the middle man (Windows) out of the process.



Regards


Annraoi
  ^[ Log in to reply ]
 
Antony Sidwell Message #42266, posted by ajps at 14:52, 18/5/2003, in reply to message #42252
Member
Posts: 48
Is the effect of providing a laptop and emulation software, WindowsXP and Select 3 a thing that will make it *easier* for people to (in effect) move to Windows the answer *must* be yes.
No, the answer is "No". If you honestly believe that anyone using RISC OS couldn't, if they wished, move all their essential computing across to Windows at relatively low cost, you're in a dream world.

People use RISC OS because they like it, and possibly in one or two cases, because they've invested a lot in it and can't afford to move. A Windows laptop won't suddenly change any of that.

The portable lets people use RISC OS on a portable machine. That's it. That's the purpose. It isn't a signal of "intent", as *you* said, to move over to Windows. As I thought I made abundantly clear earlier it is not in the interests of MD, ROL or even VA (their customer base is current and past RISC OS users).

You might as well say that RComp are intent on moving people to Windows with their UniPrint and other Windows-specific netwroking products - it all makes it easier to use Windows alongside RISC OS and so clearly encourages the use of Windows, no?

First off the laptop is expensive enough (soaks up some money people might have kept for buying *actual* RISC OS compliant hardware (the curious one in this is that would also hit *MD* - why would they do something that damages their own soon to be released Omega ?). Then you have the slice for VA and ROL - and (the bigger slice of the software component of the sale) to Messrs Gates and Balmer.
Well, this is the point surely, MD wouldn't do anything to damage sales of their own product (except obviously their reluctance to actually finish and/or release it).

The portable is exploiting the market for a RISC OS portable, and no one is likely to say "I really want to pay £1000 for a mid-range Windows portable which can just match the speed of my current RiscPC under emulation" unless they actually want a portable.

They could get a PC (portable or static) on its own cheaper than that, or buy a faster RISC OS machine is they wanted RISC OS non-portable hardware.

The least damaging option would have been to make RO4/Select3 + VA available for existing PC laptop owners (that at least doesn't suck as much money out of the RO market).
Well yes, but on the other hand, you wouldn't have liked that anyway, because it would make it too easy for people to dump RISC OS in favour of Windows.

They must have their reasons for doing things this way, and it is likely to be in their best interests as businesses.

It will also help a few people who want a portable machine capable of running RISC OS for some reason, but are unwilling to use RedSquirrel.

As to RO on another platform (aka the worst case scenario) then a limited kernel/ARM processor emulator is the way to go. Yes Linux is more bloated than RO - but no where near as badly as (say) Windows, but the point is can we do better than Linux ?

I mean VA needs a raft of specific Windows calls to do what it does, there is *still* no full RO emulation on Linux - it would therefore be more sensible (IMHO) to produce low level x86 (or whatever) kernel - with an ARM (just the processor) emulated (the other hardware can be handled by the HAL and the relevant drivers). You'd probably wind up with something that runs rings around VA (I stress not due to any deficiency in VA - I am rather impressed with it - but rather that you'd have cut the middle man (Windows) out of the process.
It would be a mammoth job however you chose to do it, and trying to implement it on top of the smallest kernel you can find wouldn't make it any easier to access the range of graphics cards, sound devices, NICs, etc. that are out there.

Anyway, that has nothing to do with the thread really, which was about re-implementing something with a GUI at least as good as RISC OS rather than finding ways to emulate RISC OS better.
  ^[ Log in to reply ]
 
David Boddie Message #42336, posted by davidb at 19:10, 18/5/2003, in reply to message #42266
Member
Posts: 147
If you honestly believe that anyone using RISC OS couldn't, if they wished, move all their essential computing across to Windows at relatively low cost, you're in a dream world.
This is fair comment but contradicts what you say immediately below. I'm probably misinterpreting what you mean by "anyone" and "low cost". ;)

People use RISC OS because they like it, and possibly in one or two cases, because they've invested a lot in it and can't afford to move. A Windows laptop won't suddenly change any of that.
It's the investment that's the problem, and I'm not necessarily referring to the amount of money spent on software and hardware. The appearance of "legitimate" Select on a Windows laptop in itself won't affect that because customers are still locked into all those legacy applications under Virtual Acorn.

You might as well say that RComp are intent on moving people to Windows with their UniPrint and other Windows-specific netwroking products - it all makes it easier to use Windows alongside RISC OS and so clearly encourages the use of Windows, no?
You have a fairly good point there, but RISC OS punters tend to see those sort of products as adding functionality to the operating system, rather than replacing it, and are happy to spend money on them.

The portable is exploiting the market for a RISC OS portable, and no one is likely to say "I really want to pay £1000 for a mid-range Windows portable which can just match the speed of my current RiscPC under emulation" unless they actually want a portable.
Well, it may be "exploiting" the users who feel they need an officially sanctioned, portable RISC OS solution but people still continue to feel that it's acceptable to pay over the odds for RISC OS hardware. :(

[ Alternative kernel to Linux ]
It would be a mammoth job however you chose to do it, and trying to implement it on top of the smallest kernel you can find wouldn't make it any easier to access the range of graphics cards, sound devices, NICs, etc. that are out there.
Yes. Why reinvent the wheel?

Anyway, that has nothing to do with the thread really, which was about re-implementing something with a GUI at least as good as RISC OS rather than finding ways to emulate RISC OS better.
Well, it does lead to interesting questions about how one might do this and retain some sort of compatibility with current applications. For example, for "legal" graphics calls, one might adapt existing libraries to provide a "framebuffer" for RISC OS and handle the conversion between pixel formats.

There's no need to "go to the metal" to get things done.
  ^[ Log in to reply ]
 
Owen Griffin Message #42338, posted by snig at 20:30, 18/5/2003, in reply to message #42336
Member
Posts: 44
Open source RISC OS is stupid. Get you heads screwed on.
  ^[ Log in to reply ]
 
Peter Naulls Message #42347, posted by pnaulls at 07:56, 19/5/2003, in reply to message #42338
Member
Posts: 317
Open source RISC OS is stupid. Get you heads screwed on.
Sigh. Let's have some common sense here.

Open Source RISC OS _is_ Stupid. Let's state the reasons:

It's not as if RISC OS isn't being actively developed (BeOS for example) - it is, by two parties with a commerical interest in improving it.

No disrepsect, but most of the people posting to this thread don't really understand OS design. Much the same was true when such a thing was attempted 2 years ago as a result of a similar thread here. It never got off the ground for lots and lots of reasons, but this was an underlying theme.

Doing an OS from scratch (or substantially from scratch or some variation thereof) is an enormous amount of effort. Let's say 20 people full time for 3 years, then we might be thinking about the first alpha.

The same effort applied to RISC OS in terms of applications, utilities, promotion of the OS itself would have an *ENORMOUS* impact on the ability of the OS to grow, and be useful to a much greater audience.

But then, I fear that I will fail to convince those who think an OS RO is the way forward.
  ^[ Log in to reply ]
 
GuestX Message #42365, posted by guestx at 09:51, 19/5/2003, in reply to message #42347
Member
Posts: 102
Open Source RISC OS _is_ Stupid.
It's nonsensical to attempt to reduce the debate to such simplified position statements. Claiming that an open source RISC OS is "stupid" (even though we're actually talking about something a bit different) is like claiming that "horses suck". A great soundbite but lacking in context, meaning and justification.

Let's state the reasons:

It's not as if RISC OS isn't being actively developed (BeOS for example) - it is, by two parties with a commerical interest in improving it.
Commercial or comical? ;-) Actually, no-one disputes the continued development of the operating system. It's just that people are concerned that aside from the remedying of various architectural showstoppers, there isn't any hardcore re-plumbing going on in the bowels of the operating system itself. Jibes about pretty new icons may seem flippant, but they are also rooted in this kind of factual observation.

No disrepsect, but most of the people posting to this thread don't really understand OS design. Much the same was true when such a thing was attempted 2 years ago as a result of a similar thread here. It never got off the ground for lots and lots of reasons, but this was an underlying theme.
Well, the originator of this thread wasn't necessarily talking about...

Doing an OS from scratch (or substantially from scratch or some variation thereof) is an enormous amount of effort. Let's say 20 people full time for 3 years, then we might be thinking about the first alpha.
And for many people, that isn't interesting for the reasons also given by certain contributors in this thread.

The same effort applied to RISC OS in terms of applications, utilities, promotion of the OS itself would have an *ENORMOUS* impact on the ability of the OS to grow, and be useful to a much greater audience.
That depends on whether you're a man on an impossible mission. RISC OS was a nice applications platform when people were willing to put up with the limitations of the operating system/environment. Since that time, we've left the microcomputer age and modern hardware can comfortably support more demanding operating system features. Moreover, such features made platforms more credible for the development and use of various kinds of applications - compare and contrast Apple and Microsoft's offerings from the early 1990s with their current offerings, especially in the light of Internet applications.

But then, I fear that I will fail to convince those who think an OS RO is the way forward.
Acorn considered re-plumbing RISC OS and putting in various microkernels. This could have made for an interesting operating environment, but I suppose that they found it all too daunting, or that they saw the writing on the wall for ARM-based desktop systems. I suppose someone could attempt this work and produce something which would give adequate support for the hardware in the various Acorn/Castle/Microdigital models, but supporting generic hardware would be far too ambitious - Apple have an operating system that they could potentially ship on Intel platforms today, but that would demand a huge investment in device support that changes the nature of their strategy completely.

So, I believe that to deliver a RISC OS experience on generic hardware, the best bet is either to provide applications on more popular operating systems that deliver much of that experience, or to provide a RISC OS applications environment for those operating systems. Of course these strategies rain on various people's parades because they deny the supposedly fundamental superiority of the "total RISC OS experience", but realists know that the world has moved on and that a proprietary operating system developed on a small scale for uncompetitive hardware isn't going to be attractive to the mainstream any time ever.
  ^[ Log in to reply ]
 
Peter Naulls Message #42395, posted by pnaulls at 11:27, 19/5/2003, in reply to message #42365
Member
Posts: 317
Open Source RISC OS _is_ Stupid.
A great soundbite but lacking in context, meaning and justification.
Which is precisely why I proceeded to justify it.
Incidentally, I dislike this hiding behind "GuestX" or whatever. Hiding behind nicks where your true identify isn't obvious undermines your position somewhat.

It's just that people are concerned that aside from the remedying of various architectural showstoppers, there isn't any hardcore re-plumbing going on in the bowels of the operating system itself.
That's simply not the case. And even if it was, most people here, as I said, aren't qualified to comment on OS architecture beyond throwing about flippant phrases about what should be done.

Doing an OS from scratch (or substantially from scratch or some variation thereof) is an enormous amount of effort. Let's say 20 people full time for 3 years, then we might be thinking about the first alpha.
And for many people, that isn't interesting for the reasons also given by certain contributors in this thread.
Then this conversation must remain entirely academic.


The same effort applied to RISC OS in terms of applications, utilities, promotion of the OS itself would have an *ENORMOUS* impact on the ability of the OS to grow, and be useful to a much greater audience.
That depends on whether you're a man on an impossible mission.
(snip non-sensical stuff which doesn't have very much bearing on what I actually said above).

It remains the case that vast improvements can be made to RISC OS in many many areas without delving into the OS. Most of the actual "failures" in RISC OS are lack of applications, and for the most part, their exclusion has little to do with missing (perceived or otherwise) OS features. I'm asking you use your energy more wisely.

But as I said, people will go on about the wonders of a mythical Open Source OS, and probably simply not do anything in either direction.
  ^[ Log in to reply ]
 
Simon Willcocks Message #42431, posted by Stoppers at 13:45, 19/5/2003, in reply to message #42338
Member
Posts: 302
Open source RISC OS is stupid. Get you heads screwed on.
That was pretty much the point of this thread.

Perhaps I should have called it "Who *wants* an Open Source RO, anyway?" or even "Who wants *RO*, anyway?".

What I was suggesting was an Open Source GUI for Linux that allows Linux programs to be written in the style of RISC OS WIMP programs.

Given a Filer and an X Server, I believe this would be a good environment to work in.

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort and doesn't provide a unique selling point for RO since the original is already available on Linux.

The GUI could even become popular (it's simple to use, elegant, easy to program for and available to try on hardware people have already bought) and there could be orders of magnitude more people developing for it than now. If not, a few of us could still tinker with it secure in the knowledge that it will continue to be possible to use new hardware printers and interface types as soon as anyone else.
  ^[ Log in to reply ]
 
Peter Naulls Message #42435, posted by pnaulls at 13:52, 19/5/2003, in reply to message #42431
Member
Posts: 317
Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort
That's simply not true. I've already demonstrated that with my porting project. And Unix programs are emminetly more portable than RISC OS programs for lots of reasons.

Forget unique selling points (bit I snipped) - RISC OS needs fundamentaly important points such as big applications.
  ^[ Log in to reply ]
 
Andrew Sidwell Message #42444, posted by takkaria at 14:29, 19/5/2003, in reply to message #42431
Member
Posts: 324
Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving)
Right, this is where you're completely wrong. You'll find that most X11 applications use toolkits - things like wxWindows, GTK, Qt/KDE, etc. These all have completely different ways of working - there's no way you can "incrementally port" them, unless you write libraries to mimic their APIs, which will be a pain because (hopefully) your brand new spangly Open Source Windowing Server won't be quite as bloated as (say) Qt.

It's possible, of course, that a brand new Open Source Windowing Sever will never happen and you'll end up implenting OpenSourceDecentGUI as an X11 library, with yet another window manager and session manager...

Of course, you'll never end up doing any of this, so it's largely academic.
  ^[ Log in to reply ]
 
GuestX Message #42445, posted by guestx at 14:45, 19/5/2003, in reply to message #42444
Member
Posts: 102
It's possible, of course, that a brand new Open Source Windowing Sever will never happen and you'll end up implenting OpenSourceDecentGUI as an X11 library, with yet another window manager and session manager...
Just as the development of a completely new RISC OS operating system (as opposed to either porting applications or developing a compatibility layer) is misguided or overambitious, I would suggest that to ignore projects like XFree86, which have extensive support for various display chipsets, is equally misguided. People have set up projects to develop "leaner" display engines for UNIX-like systems, but very few have come very far, and even fewer can now be regarded as mainstream.

Of course, you'll never end up doing any of this, so it's largely academic.
That's not to say that he can't share his opinion.
  ^[ Log in to reply ]
 
Peter Howkins Message #42446, posted by flibble at 14:55, 19/5/2003, in reply to message #42225
flibble

Posts: 891
In reply to the general question, yes I would like to see an open source RISC OS.

Peter, who would like some |teaearlgreyhot|
  ^[ Log in to reply ]
 
GuestX Message #42449, posted by guestx at 15:01, 19/5/2003, in reply to message #42435
Member
Posts: 102
Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort
That's simply not true. I've already demonstrated that with my porting project. And Unix programs are emminetly more portable than RISC OS programs for lots of reasons.
Yes, but what about all those POSIX-like APIs which don't have decent RISC OS equivalents? I don't deny that graphics toolkits can be ported, and I also don't deny that applications can be ported as a consequence of that. Indeed, the increasing availability of open source tools for RISC OS does make it a more attractive platform for developing on (although it's a shame that it didn't start happening in earnest in 1993 rather than 2003). However, what was suggested (and I'm not entirely in agreement with the entire suggestion) was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.

Forget unique selling points (bit I snipped) - RISC OS needs fundamentaly important points such as big applications.
That's true, but then the user and developer experiences are also important. Even with a shiny XScale, do some tasks lock the entire desktop for the sake of it? What about the printing system? Is it still a hack on top of the graphics system?

Consider this: if Macintoshes still ran some kind of Mac OS <= 9 variant and Mac OS X never happened, how do you think Mac users would respond to criticism that they use a "toy OS"? Of course, many of them would still defend the deficiencies.

Now consider RISC OS, consider what would happen if it were replaced by something comparably better, and consider the change in mindset that would come about. I can understand why people don't believe that new applications for "classic RISC OS" are the beginning and end of halting the RISC OS market's steady decline.
  ^[ Log in to reply ]
 
Peter Naulls Message #42456, posted by pnaulls at 15:14, 19/5/2003, in reply to message #42449
Member
Posts: 317
Yes, but what about all those POSIX-like APIs
Relatively few.

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.
Having studied the matter in a great deal of detail, this is an utterly ridiculous conclusion.
Because RISC OS programs are so unportable in comparison.

Now consider RISC OS, consider what would happen if it were replaced by something comparably better, and consider the change in mindset that
Which, as we say, is nothing other than academic because people aren't willing to take on board the practicalities. They'd prefer hand waving and talking instead.


And indeed, hiding behind nicks like "GuestX".
  ^[ Log in to reply ]
 
GuestX Message #42462, posted by guestx at 15:40, 19/5/2003, in reply to message #42456
Member
Posts: 102
Yes, but what about all those POSIX-like APIs
Relatively few.
Well, isn't threading one of the big ones with respect to various client applications?

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.
Having studied the matter in a great deal of detail, this is an utterly ridiculous conclusion.
Because RISC OS programs are so unportable in comparison.
The contributor whose suggestions you were busy criticising wasn't merely (if at all) discussing the portability of the few RISC OS applications that anyone would be bothered to port to his UNIX-based environment; who on Earth would want to port any of the RISC OS-originating Web browsers to another operating system? His comments focused on porting UNIX/POSIX/X11 applications to his modified environment. I don't see how it is ridiculous to compare the effort of porting UNIX-originating applications between UNIX-based environments with that of porting from one of those environments to RISC OS.

Anyway, on the subject of making RISC OS applications work in his environment, we can already see emulators doing a fair job of that. One might envisage better integration with the native environment, but I think it's fair to say that other emulation technologies have delivered such integration in the past. Meanwhile, on the other side of the coin, we have the legacy data that such applications produce, and one does not necessarily have to use exactly those applications to continue working with such data.

Now consider RISC OS, consider what would happen if it were replaced by something comparably better, and consider the change in mindset that
Which, as we say, is nothing other than academic because people aren't willing to take on board the practicalities. They'd prefer hand waving and talking instead.
Yes, that's right. Still, whatever floats your boat... in that small pond with the other big fish.

And indeed, hiding behind nicks like "GuestX".
I find that people who post with their real name are automatically granted much more of a realistic world-view. Oh, hold on...
  ^[ Log in to reply ]
 
Peter Naulls Message #42465, posted by pnaulls at 16:03, 19/5/2003, in reply to message #42462
Member
Posts: 317
Yes, but what about all those POSIX-like APIs
Relatively few.
Well, isn't threading one of the big ones with respect to various client applications?
At which point we discover the gap between reality and your view of the situation. pthreads is being actively worked on for Unixlib, and isn't exactly a "Big API". There's very little else that doesn't already have some kind of support and couldn't be improved.

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.
The contributor whose suggestions you were busy criticising wasn't merely (if at all) discussing the portability of the few RISC OS applications that anyone would be bothered to port to his UNIX-based environment;
But I was. The question is implicit, and underlies the whole argument.


Anyway, on the subject of making RISC OS applications work in his environment, we can already see emulators doing a fair job of that.
No, that's a _completely_ different topic, and has no place in a discussion like this. Emulators are emulators, and they do _NOT_ help provide an open source RISC OS on any platform. The technologies are very disctinct.


And indeed, hiding behind nicks like "GuestX".
I find that people who post with their real name are automatically granted much more of a realistic world-view. Oh, hold on...
It gives you some kind of credibitlity, instead of sitting anonymously on your high hourse and dishing out random declarations about what can and can't happen.

But as I say, your comments continue to demonstrate that all you want to do is talk, and in some cases above, facts and practicality be damned.
  ^[ Log in to reply ]
 
Ian Hawkins (g0tai) Message #42477, posted by g0tai at 16:22, 19/5/2003, in reply to message #42449
Member
Posts: 82
Now consider RISC OS
<crap snipped>

Now consider supporting RISC OS Select and getting everything *today* instead of spreading BS about something that blatently is *not* going to happen this side of the millennium, and is also not needed.

Ian.
  ^[ Log in to reply ]
 
GuestX Message #42480, posted by guestx at 16:29, 19/5/2003, in reply to message #42465
Member
Posts: 102
At which point we discover the gap between reality and your view of the situation. pthreads is being actively worked on for Unixlib, and isn't exactly a "Big API". There's very little else that doesn't already have some kind of support and couldn't be improved.
Well, I was actually asking a question about thread support from my high horse. Still, I can imagine that it is a big API if it is also showstoppingly unavailable (for any given platform without native threading and a native threading API).

The contributor whose suggestions you were busy criticising wasn't merely (if at all) discussing the portability of the few RISC OS applications that anyone would be bothered to port to his UNIX-based environment;
But I was. The question is implicit, and underlies the whole argument.
In discussions, when people say something like this...

What I was suggesting was an Open Source GUI for Linux that allows Linux programs to be written in the style of RISC OS WIMP programs.

Given a Filer and an X Server, I believe this would be a good environment to work in.

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort and doesn't provide a unique selling point for RO since the original is already available on Linux.
...what tends to happen is that people take notice of the contribution, comprehend what is being discussed, and then respond to those points of discussion, rather than to bring in some favourite but not entirely relevant topic and to claim erroneously that this was the topic of discussion when it clearly wasn't. Unless you enjoy having an argument with yourself.


Anyway, on the subject of making RISC OS applications work in his environment, we can already see emulators doing a fair job of that.
No, that's a _completely_ different topic, and has no place in a discussion like this. Emulators are emulators, and they do _NOT_ help provide an open source RISC OS on any platform. The technologies are very disctinct.
Neither I nor the person whose argument you've been busily ignoring actually suggested that. What emulation does (in many of the ways that the term "emulation" can be interpreted) is to provide part of the emulated experience in other environments; which was kind of the point behind the contribution of the person whose views you seem to have hijacked.


It gives you some kind of credibitlity, instead of sitting anonymously on your high hourse and dishing out random declarations about what can and can't happen.
So saying...


No, that's a _completely_ different topic, and has no place in a discussion like this.
...isn't at all like stating what can and can't happen?


But as I say, your comments continue to demonstrate that all you want to do is talk, and in some cases above, facts and practicality be damned.
Well, yes, I'm talking because The Icon Bar forums aren't really a good development environment. There isn't a "Build project" button at the bottom of the page when I've finished addressing your "relatively large aquatic creature in relatively small aquatic environment"-style "arguments".
  ^[ Log in to reply ]
 
Simon Willcocks Message #42495, posted by Stoppers at 19:45, 19/5/2003, in reply to message #42444
Member
Posts: 302
Right, this is where you're completely wrong.
That's a pity.

I was thinking along the lines of using DirectFB (http://www.directfb.org/) as the basis for the BNSOSWS. They've already written an implementation of GTK+ for it, at least.

Why couldn't I search for, e.g. "gtk_file_selection_new" in an application and modify that part of the code to use a different set of widgets including an icon to drop on a Filer window?

By the way, the reason I was thinking of limiting the system to the framebuffer was so that the filer and all the applications would be running locally and therefore have the same view of the filesystem, I thought that might make the task smaller (I'd also only support eigenvalues of 1 and 24 bit colour, at least to start with).

Of course, you know everything about me, right?
  ^[ Log in to reply ]
 
Andrew Sidwell Message #42497, posted by takkaria at 19:56, 19/5/2003, in reply to message #42495
Member
Posts: 324
I was thinking along the lines of using DirectFB (http://www.directfb.org/) as the basis for the BNSOSWS. They've already written an implementation of GTK+ for it, at least.

Why couldn't I search for, e.g. "gtk_file_selection_new" in an application and modify that part of the code to use a different set of widgets including an icon to drop on a Filer window?
You originally said that you wanted a way to be able to write in the style of RISC OS WIMP applications. You haven't addressed the concern of having more than one toolkit. GTK may be nice, but it doesn't make for RISC OS' style. You'd be looking into a new toolkit, which is why I suggest that incremental porting won't work.
  ^[ Log in to reply ]
 
Simon Willcocks Message #42501, posted by Stoppers at 20:29, 19/5/2003, in reply to message #42497
Member
Posts: 302
You originally said that you wanted a way to be able to write in the style of RISC OS WIMP applications.
That is true, and implementing (some of) the funtionality of OSLib using DirectFB was the approach I wanted to take to that.

You haven't addressed the concern of having more than one toolkit.
No, I haven't. I think one would be enough to be getting on with, and the rest can run on the X Server application I was talking about (and look alien).

GTK may be nice, but it doesn't make for RISC OS' style. You'd be looking into a new toolkit, which is why I suggest that incremental porting won't work.
Well, starting from a normal GTK application, couldn't you:

* change it so it doesn't open a window on startup, just put an icon on the icon bar (and open the original startup window when select clicking the icon),
* open files dropped on the icon bar as if they'd been chosen from a file->open dialog on a default new window
* move menu items that affect the whole application to the icon bar menu (preferences, etc.)
* use drag and drop saving
* respond to file open messages if the file type is supported by the application
* (trickier) pop up menus on middle button pushes, with selection of something under the pointer if nothing is already selected

... and so on?

I just don't know enough to write a new toolkit from scratch, but I'd have a better idea once I'd modified a few GTK apps.

Besides, how do you think I'd convince people to use a brand new toolkit, anyway? An evolutionary approach is probably more likely to succeed.

One other RO - style adjustment I'd look into would be to lock window re-draws so that they happen seqentially and the most recently requested (by the user) first.
  ^[ Log in to reply ]
 
Pages (2): 1 > >|

The Icon Bar: General: Who *wants* an Open Source RO?