Where do we discuss issues with Direct

Just because other systems are doing stupid things does not mean we should follow suit.

I never said we should, just highlighting a difference that ought to be taken into account.
I think we can pretty much assume these days that a person trying RISC OS of their own volition is “reasonably competent” with how to use a computer, and sufficiently familiar with something along the lines of Windows or Linux. So we really ought to consider starting from there, understanding that “applications appear in the filesystem” (and yes, Apps is a filesystem, just not a “real” one). This differs from most everything else I can think of where you either get a pile of icons in a sort of app browser (usually swipe up on a tablet/phone) or a big-ass menu listing them all.

which is well out of date and your information is also very dated

Oh? From what I can make out from developer.apple.com (I’m reading the HTML directly, it refuses to render correctly on Firefox and Chrome) it looks like you can plug the device into a computer to access the photos (MTP mode). Using whatever iTunes has become you can also access music and some application data (Documents maybe Library) if the app chooses to expose it. Software such as iMazing gives a much greater access to the filesystem but it cheats, it doesn’t access the filesystem, it reads the data from a recent device backup.

On the machine itself (and what I was referring to when I said the filesystem doesn’t exist as far as the user is concerned), applications can involve the OS to transfer files from one application to another (like Dolphin being able to open PDFs in Abode Reader). There’s no filesystem browser and apps cannot touch files belonging to other apps. That’s because unlike Android, iOS enforces a pretty strict sandbox.

It’s basically security by design and while it may irritate people like me who tend to wander the filesystem and wipe unnecessary crap (you’d be amazed how much can pile up in /sdcard/Android/Data/*/Cache), it does mean that – exploits and hacks aside – data belonging to one app is invisible to all other apps. Android, on the other hand, only has the one permission – allow app to read/write files (yes/no).

where you either get a pile of icons in a sort of app browser (usually swipe up on a tablet/phone) or a big-ass menu listing them all.

Whenever I install an application on Windows it asks me whether to create a shortcut on the desktop (aka pinboard). So for me that is the equivalent to the Apps folder on the icon bar in RISC OS except that it is open all the time. The ‘Program Files’ directory is equivalent to the $.Apps folder.

Each shortcut points to the directory where the application lives and can easily be examined.

Anyway… specifics of iOS, Windows, etc and whether or not a determined and knowledgable user can get to the stuff in the filesystem is not really that relevant. The point is that, for the majority, systems these days tend to try to hide as much as the filesystem as possible (even back in the days of XP, it was “My Computer” and “My Documents and Settings” that the user was supposed to see).

RISC OS, on the other hand, has its filing system as an integral part of the “experience” ¹ with applications and files potentially intermingled, plus there’s no “default” place to store files (you need to open ‘$’ and then open an appropriate directory) and there’s no memory or default location offered (CSD is normally $).

Just… it’s different. In a way that might need explaining. Go find a friendly child who is not familiar with RISC OS and you’ll get all the feedback you need…

¹ I detest that expression but can’t think of a better one.

In iPadOS there is a file browser (called, imaginatively, Files). There are sections for files stored on the iPad itself and files stored in iCloud; you can also link it to online services like Dropbox. You can create folders. However, while some apps expose their files in the “on my iPad section”, others (including most of Apple’s own apps) don’t—though such apps do generally include “Save to Files” on the Share menu.

RISC OS is still (except for some versions of Select) a single-user system; Windows didn’t do an awful lot to keep documents successful in the days of Win95/98, nor, AFAIK, did pre-OS X MacOS. Still, at least RISC OS files don’t have “data forks” and “resource forks” to contend with—the current Mac OS and iPad OS still support such a notion; compress a folder containing some files on an iPad, open the resulting .zip on a non-Apple system, and you’ll see…

If someone would like to volunteer to keep a log/list or otherwise manage the feedback it would be helpful.

I would be very interested in doing just that. It could be a bit like the Archive Online Offline series in which I summarised mailing list discussions for general interest but, er, online.

For this I could trawl ROOL Forum discussions, receive personal emails amd add my own comments all onto some web pages that anyone could read. They could also report responses and thumbs up/down/pending from those responsible for the make-up of new versions of the RISC OS Direct download.

I think FTP to a suitable space on, say, Orpheus would work.

I think FTP to a suitable space on, say, Orpheus would work.

Wouldn’t a public bug tracker be more useful, since it would also allow all users to check for known issues?

Bernard I assume you are on about the applications supplied with Direct and not the OS? Since the OS is just the normal RISC OS version with a Direct theme.

This should only discuss ideas for the applications to be supplied or fixed on DIRECT and not the OS.

Not sure a bug tracker is actually necessary since it not bugs we are looking at, its the applications for NEW users we should be focusing on.

If anyone does not like the current theme for DIRECT they can always offer there own versions to be added to the Themes application in the OS.

I assume you are on about the applications supplied with Direct and not the OS?

Well, yes, but I have also found missed opportunities in setup and configuration options, and in documentation, that could enhance the experience of the, er, inexperienced.

Not sure a bug tracker is actually necessary since it not bugs we are looking at, its the applications for NEW users we should be focusing on.

Precisely.

I have written to Andrew and Richard with my initial suggestion of how it might be done.

Not sure a bug tracker is actually necessary since it not bugs we are looking at

You are aware, I presume, that a “bug tracker” is a generic tool that can track anything from serious problems to suggestions for improvements? Call it an “issue tracker” or “ticket system” if you prefer.

My concern with “FTP Space on Orpheus” is that, not being public, this list will soon fill up with things that should be getting tracked and recorded here as part of the wider RISC OS 5 project. Keeping the list in public view should help identify what is a RISC OS 5 issue and what is actually a RISC OS Direct matter. It will also ensure that useful information isn’t being hoarded by the RISC OS Direct “team” (I’m aware that Bernard isn’t directly part of that, yet), and not being made available to those who need it.

A RISC OS Direct sub-forum on here?

A RISC OS Direct sub-forum on here?

Well that would be up to ROOL to decide upon in consultation with RODev. But, given Andrew’s suggestion:

If someone would like to volunteer to keep a log/list or otherwise manage the feedback it would be helpful.

my view is that a public forum or mailing list would not be the easiest way to manage user input in this case. Steve’s suggested method might be a good candidate: can he point to a package that Orpheus/RODev might host for the purpose?.

Whatever method is chosen, I think it will be most helpful to the maintainers of RODirect if the log/list is managed by a few who see or receive inputs from interested and supportive parties, and then summarise the pros, cons and planned actions for all to read.

Combined various thoughts from other postings into one.

Well, yes, but I have also found missed opportunities in setup and configuration options, and in documentation, that could enhance the experience of the, er, inexperienced.

I see your point, and would agree re documentation/instructions, its a pretty the Wi-Fi sheep videos are not really accessible on RISC OS itself. Less sure about configuaration and setup changes. Are they the same issues in the “standard” RO builds? if so they should be discussed in these forums. If not thenOk might be suitable to be raised in the new Forum/website.

You are aware, I presume, that a “bug tracker” is a generic tool that can track anything from serious problems to suggestions for improvements? Call it an “issue tracker” or “ticket system” if you prefer.

OK I see what you mean Steve, I was more thinking you meant as issues with the OS which should be raised here. But an ‘issue tracker’ for issues with the applications in DIRECT makes sense to me.

Whatever method is chosen, I think it will be most helpful to the maintainers of RODirect if the log/list is managed by a few who see or receive inputs from interested and supportive parties, and then summarise the pros, cons and planned actions for all to read.

I am a little unsure about this idea since, their would be little transparancy in what being said/suggested. Anyway who would decide the pros/cons and action to be taken. that should surely be RO Developments decision.

I would suggest to take a look at the NetSurf bug tracker and see if it answers the requirements. I suspect it would. It’s free and it’s usable from NetSurf.

It will also ensure that useful information isn’t being hoarded by the RISC OS Direct “team”

Ooh, I’m not sure “hoard” is the right word. I don’t see the suggestion as being at all malicious, more a reflection of how much the world has passed us by in that a public issue tracker didn’t come to mind first….. ;-)

and then summarise the pros, cons and planned actions for all to read.

That’s sort of what a bug tracker does. Like, uh… https://www.riscosopen.org/tracker/tickets/filter?status=1

Note how you can access things that are fixed and things marked as “not gonna touch that”, but by default you see the outstanding issues, this helps to concentrate on what’s important and still outstanding. Forums and mailing lists fail in this respect as it’s a bit of a free for all (look how this topic has meandered on its way here) whereas bug trackers (or issue trackers if you prefer) keep things simple and to the point. Each issue is a specific thing with its own specific references and follow-ups that pertain to that one specific issue. It’s also considered bad form to add in stuff like “well while you’re doing that, could you also…”. New issue, new ticket. That’s how it goes.

And no, no to having somebody summarise issues. I mean, who’s going to have the time to do that?!

I would suggest to take a look at the NetSurf bug tracker and see if it answers the requirements. I suspect it would. It’s free and it’s usable from NetSurf.

Mantis would have been my suggestion, for the same reasons.

That said, most source code control hosting sites offer issue tracking these days, so if you’re not precious about being able to access it from NetSurf, just set up an account on one of them — there’s no need to upload source to it. A lot of recent projects mentioned around here seem to be using these sites, anyway, so they’re hardly alien to the platform now.

That’s sort of what a bug tracker does.

Exactly.

And no, no to having somebody summarise issues. I mean, who’s going to have the time to do that?!

Again, exactly.

Given how few people we have around here and how overloaded everyone is, why create a new process that depends on a small “inner circle” of “trusted” people? By all means limit who can administer other people’s tickets in the tracker to a small team of project admins, but trackers are used precisely because they remove the need for one person to process everything. Users can raise tickets themselves, other people can browse them, and the team in charge can prioritise or close as required.

I have written to Andrew and Richard with my initial suggestion of how it might be done.

(which did include the summarising task that is one idea but clearly not really the best). No reply yet, but I trust they read this thread with its highly practical recommendation of an issue tracker, and go for that.

I can’t speak for Richard, but I’m afraid I don’t have the time (or practical experience) to [quickly] set up a bug-tracker-server, which is why I asked if someone in the community could take point. I’d be happy to use it if that’s what you’d like, but right now my “to-do” list is pretty lengthy, so wouldn’t want to set something up myself.

Basically, my idea is that we’ll probably be doing an update in (say) June, and when we come to do it, having a (somewhat) curated list of issue [somewhere] would minimise stupid omissions.

I have Direct running as a headless server.

In this configuration, it starts up with a screen resolution of 640×480 (which, when using VNC) can be changed via the Display icon on the task bar).

However, if Configure Screen is used to try to set the boot resolution, then an error is given that the file Resources:$.Resources.ScreenMode.Monitors.EDID0 is not found.

This was fixed some long time ago with the ROOL build.

Is this an example of the sort of errrors we are going to be re-visiting because Direct is not built by RISC OS OPEN?

Basically, my idea is that we’ll probably be doing an update in (say) June,

I hope not. We do not need anybody else re-creating bugs that have already been fixed.

John Sandgrounder. With respect you are basically talking a load of rubbish. RISCOS Direct is simply RISCOS 5 – version 5.27 as of a specific date as built by ROOL, plus a Direct theme and a range of software added for NEW users, you are not a new user! The update I expected will be the then current version of 5.27 in June or it might even be the “stable” 5.28 if ready plus any suggested improvement to the added software.

Your issue is not a bug as such it is a missing file. and have you actually created an EDID file? If not you will get the error.

A number of your posts relating to DIRECT have come across as negative and you have claimed its a fork – which it is not.

Your issue is not a bug as such it is a missing file. and have you actually created an EDID file?

Doesn’t the OS create an EDID file as part of the monitor detection process?

A number of your posts relating to DIRECT have come across as negative and you have claimed its a fork – which it is not.

The problem for me is the ongoing unwillingness to make the project transparent. The plan still seems to be to keep a secret, “curated” list of issues about the bundle, which means that only the trusted few will be able to see it and comment/advise.

When you’re “tweaking” the OS (KeyMapper doing odd things with the Windows keys, for example) and bundling third-party software for an out-of-the-box experience – none of which is bad, per se – it would be good if the reported problems could be seen by anyone who wanted to look at them. That way, people who recognise a problem (including the developers of the affected software, whose goodwill seems to be getting overlooked in this) could feed back suggestions for a fix, instead of relying on the time and range of experience of those who are allowed access.

Even if a bug tracker isn’t considered a good idea, at least “curate” the list on a public-facing web page so that at any time, anyone can look at it and see what the accepted problems are. That, and have a forum somewhere (a sub-forum here would be good, if ROOL were happy for it), so that questions can be discussed without approval from the “curator”.

Your issue is not a bug as such it is a missing file.

Good grief! When was a missing file not a bug?

and have you actually created an EDID file?

No the file is missing from the (read only) file system Resources.

A number of your posts relating to DIRECT have come across as negative

Now why do think that was not intentional? The build was unecessary. See next point.

and you have claimed its a fork

I did not claim it was fork. Read the first five posts in this topic:-
https://www.riscosopen.org/forum/forums/2/topics/15279

Doesn’t the OS create an EDID file as part of the monitor detection process?

I was under the impression you had to create it first, but as John claimed its a fixed bug then all he has to do is update the OS ROM image himself. The image as supplied is based on a version of RISC OS 5.27 from Feburary I believe i.e. before the south west show when it was launched.

The problem for me is the ongoing unwillingness to make the project transparent. The plan still seems to be to keep a secret, “curated” list of issues about the bundle, which means that only the trusted few will be able to see it and comment/advise.

Andrew has asked someone to manage a curated list, which everyone should be able to have access to, and be aware of including software developers. Bernard has offered to do the work, but seemed to want to ‘control’ it more. I agree with you that it must be open. OS fixes should as normal be dealt with through this forum, issues uncovered with the software in the Direct version should be listed for fixing or software removed/replaced on the curated list. A good example is the new frontend Andrew Conroy has developed for keymapper to make it easier for new users and long standing users as well.

That, and have a forum somewhere (a sub-forum here would be good, if ROOL were happy for it), so that questions can be discussed without approval from the “curator”.

I also agree with this as well.

But we must remember that DIRECT is aimed primarily at NEW users of RISC OS.

I was under the impression you had to create it first,

You might wish to go and look at how the EDID support was implemented. Effectively the EDID system writes an MDF on the fly in ResourceFS, which is then passed to the Display Manager. It’s quite clever, but not if the file doesn’t get written…

And creating files in ResourceFS isn’t trivial from a user’s point of view, either. What you would do is reconfigure the MDF in Configure… oh, except that John can’t, because !Boot errored due to the missing file and has therefore locked Configure out.

but as John claimed its a fixed bug then all he has to do is update the OS ROM image himself.

That shouldn’t be necessary in a ready-to-go OS build targeted at new users, though. Especially not given that those new users will be used to systems that can read the correct monitor resolution and go.

John’s setup sounds a little bit different, as a headless server will be pushing the bounds of the error handling in the EDID system, but if ROOL fixed it, then the fix should really be in Direct… and hounding someone for pointing that out isn’t helpful.

It sounds as if it would probably be a fix in !Boot, not the ROM image, too—although I could be wrong on that.