More site updates

any thing constructive that is posted or helpful is shot down by the die hard conservative seniors

We’re all for ideas and help, but it needs to be realistic.

No, this OS isn’t going to magically become 64 bit, or written in C, or GPL . . . without a hell of a lot of work. Unpaid work, at that, quite likely by those conservative seniors, who will have to field endless amounts of “but it isn’t Linux/POSIX/NTFS/etc etc etc” and “you broke it, it now sucks”.

The reality is that we’re trying to do the best we can with a codebase that was started in the mid eighties, next to no budget, nowhere near enough hardware support, very few developers (and even fewer experienced with OS level code), and an OS that is essentially alien to everybody and everything else.

Realistic ideas are more than welcome. Enthusiasm is also welcome, but please keep it grounded.

64bit train here we go…., it does as you say require a lot of work and the lack of developers that are willing to do the job is down to money and time, we essentially have a fairly decent OS that functions very well considering it is over 30 years old, the best solution for now while trying to tackle the 64bit issue would be to stop gap for now with multicore support for what hardware we have and and maybe bridge the gap for with a silent hypervisor layer with the OS running on top on newer hardware until 64bit is ready, as i suspect we are looking at at least a decade away for 64bit. the main focus really should be getting the browser up to standard with G-Streamer and plugin support which in it self is a big task, which ROD seems to be doing a good job so far. I personally am not sure on why we have separate entities of distributions os RiscOS under ROOL and ROD, this seems like the old days of ROL and Castle with RO4/RO5. Hardware support yes is limited, can’t use a webcam to do a meeting, no youtube still, USB seems to be restricted to a certain degree, i get the issues and im certainly well versed on the lack of budget, but in the years ROOL has been running RO5 is doing okay and it’s still keeping me excited for the future. But i wish more focus was on the OS as a whole and not just !Paint, im in the process of learning to code and have been for the past few months, and im only learning because i want to help in the future.

we essentially have a fairly decent OS that functions very well considering it is over 30 years old, the best solution for now while trying to tackle the 64bit issue would be to stop gap for now with multicore support for what hardware we have and and maybe bridge the gap for with a silent hypervisor layer with the OS running on top on newer hardware until 64bit is ready, as i suspect we are looking at at least a decade away for 64bit.

Take a deep breath, and then start a thread over in Wish lists
A bullet pointed list of the proposals would be a good start

A bullet pointed list of the proposals would be a good start

Yup. That lot seems like a reasonable beginning (I think some of it is already underway). I’d second the list, flesh out some of the stuff a little more.

and not just !Paint

There was a specific bounty for Paint that somebody took on.
I’m not against this. Not everybody feels happy working with the low level stuff like FileCore or USB stacks, and the apps need a little love too (what’s the point in alpha blending if there’s nothing to make alpha blended sprites?).

I am, I should add, extremely grateful for the PNG export. It means for my blog I can knock up crappy diagrams in DrawPlus, use an app to make the DrawFiles become sprites, then export as PNG in Paint to dump directly onto my site.

can’t use a webcam

At the moment I’d even settle for grabbing still images from a USBvideo device… I have four (a crappy webcam, an even crappier thing for taking photos of film negatives, a CVBS/S-video recorder/framegrabber, and a recorder/framegrabber that has HDMI input. All work under Android, but it’s… not terribly nice.

So, please add “some sort of USB video support” to your list. ;)

Ive added a list :)

If I can, Andrew, can I put in a request for the ability to change email address without having to give up on a profile and create a new one? Free services come and go, people change provider, an email address isn’t a thing of permeance.

I’ll second Rick’s request. I’m due to shut down some older domains I have to keep ongoing costs down.

Rick:

If I can, Andrew, can I put in a request for the ability to change email address

It’s a reasonable request, with a “web tech is awful” answer.

I’m certainly up for trying, but I’ll have to get to that after we’ve gone live, which means post-surgery once I’m able to type again. If analysis indicates I only need to do e-mail revalidation in Hub then these days that’s easy. However, I suspect that there’s a long tail of user records that get copied out into the family of Rails apps we have and those then use that e-mail address (where it is relevant) internally. So, if you edited your Hub e-mail address, I’d have to somehow replicate that into the user table in Beast (the forum engine) in some “not a total hard-coded hack that’ll break next week” way, else any “notify me” type stuff in the forum would go to the wrong place.

The integration with Hub in the old apps was a shallow as possible to try and make upgrades easier (the road to hell is paved with good intentions) so I didn’t try and completely replace local user tables with references to Hub data. These days, that’d probably be better but it’s a big chunk ‘o’ work even under the modern framework.

It would be not too hard to have the apps check the local user record (where there is one) against current Hub user data and do an update in the same part of the integration that uses the Hub login as a foundation for that lookup anyway – it’s doing a database query regardless. Trouble is, that only works when you next make a request to that application. If you changed e-mail in Hub but didn’t (say) visit the forum for a few days, notification e-mails in that period would still be going to the wrong place… So that’s not good enough.

(I’d sooner drop the e-mail address columns in all non-Hub databases & have the relevant model attribute readers delegate to the Hub user instead).

(Actually that could work and be quite easy).

(Train-of-thought post writing FTW).

In days gone by we could have got a lovely girl from the typing pool to do the keyboard work while you recover. The best I can offer these days is a couple of medium sized children. We might have to stick blox fruit emojis on the non alpha keys so they can find them though.

I’d like to thank everyone for this discussion and for bringing the Online Safety Act to our attention. Thanks also for moving the thread about the Act over to the Aldershot forum, which seems like the most appropriate place to continue that discussion.

An update:

• The new site is 100% complete and we’ve shaken down the front-end a fair bit. There must be some new bugs, but we don’t know about them if there are. I’m sure you good people will discover them in time!
• The new server environment is ready to go with all relevant maintenance, archiving etc. stuff done and tested fairly well, with a few “nice to have” items parked for now.
• We need a little for some free time (people involved have things that are forced to higher priority for a while) to get to the point where we can actually cut over the domain to the new IP address; this delays this a bit beyond the weekend, can’t be helped. Will be another week or two before we go live.

The improvements you’ll see should be:

• Similar or faster speed throughout
• A UI refresh with fundamentally the same styles, but cleaner, more consistent and with less legacy cruft (e.g. no CVS or SVN viewer, since that’s all in GitLab; more use of horizontal rows to stop information stacking vertically, given the prevalence of wider displays these days)
• Font sizes are a bit larger in some places, e.g. the forum text you’re reading now is tiny. Not the IMHO comedy huge fonts that seem all the rage on some new fangled sites these days ;-) but just hopefully a bit easier to read.
• Gravatars show in comment boxes for news articles and bug tickets now
• Mobile-friendly variant that works pretty well
• More accommodation for NetSurf, assuming v3.11 with or without JavaScript
• What we hope are friendly, unobtrusive little panels here and there that remind you how to get in touch with a moderator, if you feel you need to
• A few small quality-of-life things like the Tickets filter staying open if you’ve chosen any non-default filter, rather than closing itself again on each page fetch

NetSurf is a bit curious as it does obey media queries for maximum screen width but does not recompute that as you resize its window. If you load a page with the window quite narrow, then, you’ll get the mobile-like layout, which is very “vertical”. If you widen the window that won’t change, but reload the page, and you’ll end up with the “full” desktop styling with floating sidebar, full tables and generally a more information-dense view.

The delay on rollout means I fail to go-live before my shoulder surgery date, but there’s not much typing left to do in the remaining work, so I think it’ll be OK. Our cutover downtime might be longer as I’ll be typing slowly, but it’ll be mid-afternoon in NZ time, so stupid-o-clock in the UK and hopefully most people won’t even notice.

Some screenshots. The differences for mobile are very obvious, though – at least in screenshots – it’s a bit harder to spot changes the “full” / desktop site case.

Wide viewport, forum 1

Wide viewport, forum 2

Wide viewport, tickets 1 (scrolled down a bit)

Wide viewport, tickets 2 (scrolled down a bit)

Mobile, forum 1

Mobile, forum 2

Mobile, tickets

Mobile, bounties

Note how, for mobile screen sizes, some wider table views collapse into columns with some less-essential information sometimes omitted. iOS accommodations are present, so landscape view will show the same font size as portrait (rather than doing Apple’s rather odd default of increasing the font size just when you’ve tried to make more width-wise room for content!) and use the full screen width (rather than dodging the notch or island; the default 5% gutters on our site do that already).

RISC OS NetSurf example 1

RISC OS NetSurf example 2

…and if you really wanted to…

Looks great especially the mobile view looking forward to using that going forward on my phone when checking the forum away from my desk.

the forum text you’re reading now is tiny

I’ve got 150% default scaling scaling on all my Linux browsers, and that works well with the forum, and other sites such BBC News and The Register, etc. On Netsurf with one Ctrl+W click it scales to 150%, but there is no intermediate zoom without going to a fiddly menu, so don’t make the text too big.

looking forward to using that going forward on my phone

Yup. I mostly use my phone these days so a mobile view will be very welcome.

Andrew – be sure to test it on Android Chrome. Chrome has a “feature” where it will analyse the page and start resizing things to make important parts stand out. Because it’s Google and screw you we are gods, this behaviour is baked in and can’t be turned off. It… Can sometimes go oddly wrong.

Will there be a link to click to force a view? Like to get mobile on a desktop or desktop on a mobile?

Trendy-modern: Will there be a dark mode? ;)

so stupid-o-clock in the UK

What’s that? I often run into the daily downtime (what, about 5.30am UK?) because I’m an hour ahead and this stupid corpse that I inhabit seems to give up sleeping after about five and a half hours regardless of how tired I actually am. 😪

Good luck with the surgery, and many many thanks for keeping things ticking around here.

Nice work on the mobile (and looks great everywhere)! :)

Rick – thanks for the heads-up. I haven’t tried the Android simulator so I’ll download all that gubbins and give it a try. That’s what the fast internet plan is for, ha!

The view is just responsive CSS at 860 or 480px breakpoints. There is no UA sniffing whatsoever so the likes of Safari iOS’ “request desktop web site” makes no difference. I don’t have any short term plan to change that. As the post above mentioned, that’s why you get mobile-like styling in a narrow NetSurf window, or indeed, by resizing any browser window.

I do wonder if I might find time for a dark mode at some point but it’s low priority as actual site features such as first-post auto-moderation across all apps are IMHO more important.

I’ve figured out a way that should allow apps to update their user records when a Hub user changes email address or display name, in a decoupled fashion. Working on it over the weekend since go-live is delayed so I can break the code freeze.

What’s that?

NZDT is 13 hours ahead of UTC. It looks like France is +1, so it’s a simple 12-hour switch for you: if it’s 3 PM in NZ then it’ll be 3 AM in France.

I do wonder if I might find time for a dark mode at some point

My usual technique (CSS variables) certainly won’t work in NetSurf¹ :) but I suspect it’d still be possible to implement such a thing. The hard part is probably deciding what colour to make everything!

¹ To be clear, I don’t expect dark mode to be functional in NetSurf, but using variables for both modes would mean that even light mode wouldn’t work correctly.

Chris:

My usual technique (CSS variables) certainly won’t work in NetSurf1 :) but I suspect it’d still be possible to implement such a thing.

Correct. I did experiment with variables for a brief while – it would be great to be able to define some geometry and colour constants in the ROOL central 2025 stylesheet that’s then imported into each per-app specialist stylesheet, so that they wouldn’t have to hard-code “look-alike” styles for custom elements. But, of course, that ruins things in NetSurf. This isn’t much of a complaint though, since NetSurf v3.11 is so far along compared to even v3.10 for stuff like FlexBox support that I’ve been able to use a wide range of much more modern approaches than ever possible before if RISC OS compatibility was desirable (which it obviously is). It’s been great to take advantage of NetSurf’s improved abilities. It’s an amazing piece of software.

Now that I have a processing pipeline established under Rails 8 and on, I could possibly move to SCSS and have the ROOL 2025 stylesheet held in a Common repo with SCSS variables used. It’s a lot of conversion work so I’m not in any rush to do it, but with at least one application in our collection uses SCSS already it’s at least a familiar path.

As for dark mode, it’s just a tonne of work in all the places where background, text and border colours are defined – there are a lot of such locations – for something that’s pretty niche and while nice to have, gives no functional benefit compared to the very many things requested in previous threads asking “what would you like adding to the web site”.

Rick:

Well, this was non-trivial. But it seems to work:

• https://github.com/pond/hubssolib/commit/10ab74ed6503d5487b8d5b45d075603057885be2
• https://github.com/risc-os-open/beast/commit/678c1f0ae0935bc8bf8cfa6ede6f79e5206f68f3
• https://github.com/pond/canvass/commit/6ad4a4400af09ee9f812cba6b0dcb088a2927381

On local machine, at least, this invokes appropriate behaviour in self-registering apps to self-update their user records when a Hub user is changed. I could also do this for the baked-in, non-relational author strings in things like ticket and ticket change records in Collaboa, or the page author fields in the Wiki, but I’m not too worried about having old “real name” fields in views really. The trouble is one of speed. The above approach is slow – Rake tasks boot the entire Rails stack at each invocation and I’m holding a database transaction open the whole time that’s happening. With two tasks running currently for Beast and Collaboa it’s tolerable, but it’ll become intolerable pretty quickly, especially when some of those tasks are doing heavy update-all-rows operations matching records via a display name column that’s probably not even indexed. All the while, the user waits.

• Rationale for use of wrapping database transaction: If any of the tasks fail, I need to roll back the Hub data. I don’t want some last minute failure in Hub to happen after successfully running all registered on-change handlers, as then I’d have to manually reverse the changes in each of the apps that’d run their change handlers. So thats why I didn’t write code to call the tasks and then update Hub’s internals without a transaction being open first, even though long-running database transactions are usually a bad idea. It’s not hard to alter the code if this proves a bad choice down the line.

• Rationale for not pushing tasks into a background job: Management. I’d need a job runner and some way of being aware of outcomes. I also kinda hate eventually-consistent systems at such small scales as ours. There’d be trouble ahead, too, if a user with updated Hub info managed to interact with another site app before it’d sync’d data – the app would assume a new user was being encountered and try to create a new user record for them, then end up trying to update the old one once sync happened, with bad consequences given the presence of uniqueness constraints on things like e-mail address!

If you don’t fancy doing a dark theme from the ground up, you could do one for browsers that support it (mobile devices, mainly).

The browser, in dark mode, will generally invert the document colours, so you’ll just have to patch over the things that it messes up.

For my blog, I just added this to the CSS:

@media (prefers-color-scheme: dark)
{
   BODY { background: black; color: white; }
   H2 { color: cyan; }
   A:link { color: yellow; }
   A:visited { color: gold; }
   .content-left { background: black; }
   .content-right { background: navy; color: cyan; }
   table.calendar { color: yellow; }
   table.calendar th { color: yellow; }
   table.calendar td.link-now { background-color: #077; font-size: 11pt; border: solid blue 1px; border-radius: 4px; }
}

The automatic colour flipping in browsers that can do automatic dark mode isn’t bad here. I’m not sure what the logic is behind why some icons are flipped and others aren’t, but…

It would be nice to have it like this on NetSurf too, but I understand that may well be a lot of work. We can wait for the 3.1 release. ;)

The perfectionist wants it to not look – nasty. I mean, there are curious inversions there implying that you’ve some kind of extension interfering or your browser decides to invert images on some heuristic in dark mode; either way it’s interfering and you’re not seeing a “true” clean dark mode. But some points in general:

• Yes, that works for that page of the forum, but there are several other site sections
• Note things like the status GIFs on the left – those really need recreating as PNGs without all the weird masking that Beast did with GIF tricks there.

It’s all those edge cases of the Flash messages, borders, striped tables, images that assume a bright/white background that need recreating – that’s what takes all the time. And of course, testing it all.

(That’s not to say that as far as CSS goes – by all means do my work for me! Each major navigation section needs its own set of styles but this time around I’ve also leaned much more heavily on a central stylesheet – so it’ll all need some unpicking, but at least if I’ve got chunks of copypasta then it’s a lot easier for me to get something up quickly, even with additional image processing needed here and there).

If you want dark mode on Firefox or Chrome/Chromium use the Dark Reader plugin, which works really well for the majority of sites, it’s a lot more sophisticated than simply inverting the colours, and you can choose the brightness and contrast levels. As for RISC OS; until there is a released dark theme for the desktop, there isn’t much point on web sites, you wont see it over the glare.

Firefox on Android doesn’t try to bodge the sites like Chrome does. It will respect dark mode if:
a, the user has chosen it
and:
b, the style provides specific dark mode content

Point b is why my style above specifically sets the background and text colours, it’s for Firefox.

Druck, sadly Chrome on Android does not support plugins. I think this was a conscious decision by Google to not want advert/tracker blockers in the bundled browser, but it’s just another reason to use something else.

Generally third party plugins aren’t needed in mobile. If the device and/or browser ¹ is in dark mode, then the browser will make the site dark if there’s style support or, in the case of Chrome, try to do it anyway and far too often mess it up ². ;)

¹ Settings are usually “Light mode / Dark mode / Follow device theme” (and the device can be set to switch at sunrise/sunset).

² A common problem seems to be sites that have black text on a light textured background suddenly end up as light text on a light textured background. BeebMaster is largely unreadable.

BeebMaster is largely unreadable.

Correction, it was. I’ve just updated Chrome (from 127.blah to 133.blah) and they’ve messed with dark mode yet again. It no longer seems to try to do it automatically (which means this is now garish white).